
JavaScript's world domination - janjongboom
https://medium.com/@slsoftworks/javascript-world-domination-af9ca2ee5070
======
cognivore
Might be one of the saddest things I've read linked out of Hacker News. As
developers we're doomed to a future of using a awful language because it
happened to be at the right place at the right time and was good enough. Now
we're stuck with it. Reminds me of DOS.

~~~
samspot
It has awful parts that should be avoided. Once you learn to avoid them you
can have a great time. This isn't that different from most other languages. I
think javascript has just been more heavily complained about. There is also an
automatic look-down-your-nose tendency that most of us started with, including
myself. Once I decided to learn more than the bare minimum I became very happy
with it.

~~~
LBarret
It"s the very strange mix of very bad ideas and very good ideas that's
baffling. Some other languages are homogeneously bad (php) but provides less
suprises than js, because of their regularity. js is bipolar/schizophreniac.

~~~
pluma
JS is special because it has to be backwards-compatible.

It basically contains its entire history, from a PHP-like hack job that
started it to the very elegant ES6/7\. It's probably one of the few languages
that expose their whole fossil record.

~~~
sacado2
Don't forget C++. Being older, it accumulated more cruft.

------
mark_l_watson
The author mentioned transpiling other languages to Javascript and Javascript
to Lua.

Personally, I much, much prefer working in Clojurescript to Javascript. Once
my dev environment is setup, and I am rolling, there is not much inconvenience
or build delays at all. My setup is editing in IntelliJ (both Clojure and
Clojurescript), one clojure repl, and one lein autobuild task to keep the
generated Javascript up to date, given about a one second delay.

Javascript is not such a bad language, I use it directly when doing meteor.js
development, but I think the future is better languages like Clojure, Haskell,
Scala, etc. transpiling to Javascript.

All that said, that was a nice article!

~~~
timepiece
I can't wait for the time to be able to write in javascript native code to run
on Android or iOS. Maybe a future TypeScript would be the solution for this
but it is not too late to remind people that transpiling is a two way street.

~~~
gcp
What does "native code" mean in that sentence?

~~~
timepiece
iOS and Android native dev environment

~~~
rpcope1
Is your Javascript VM not already in native code when you're running
Javascript on these platforms? Or are you suggesting that the instruction set
for the chips on these devices "be pure javascript"?

~~~
timepiece
That's what I meant by native development in iOS/Android

javascript-to-java and javascript-to-obj-c transpiling

I'm fully aware of the existense of alternatives out there like PhoneGap,
Ionic ..etc but I'm envisioning a future where you could write in javascript
mostly everything you could do in other languages and transpilers take care of
the rest.

~~~
Nitramp
Both of those platforms have perfectly reasonable languages available (Java &
Swift or ObjC), why would you use JavaScript over them?

Cross platform UI has AFAICT never worked, so you won't be able to reuse code
from one platform on another, or is that what you intend to do? In that case
you could still transpile from either Java or Swift...

~~~
timepiece
Because I detest Java and I find it to be archaic, old-fashioned and clunky
but that's just me.

------
chondle
Great read, but it seems like the article overlooks a few other pretty
significant reasons for Javascript's current dominance: (a) jQuery and (b)
Apple keeping Flash out of iOS made from the start.

Say what you will about the relative inelegance of jQuery, at the time of its
release it certainly made JS--particularly DOM manipulation and AJAX--very
accessible and cross-browser compliant. It definitely made articles like this
seem quaint. [1][2]

At about the time of jQuery's release, Flash development was a viable
alternative for smaller sites. I was doing bits and pieces of freelance around
2007 and after the iPhone came out, even my least tech-saavy clients stopped
talking about Flash.

Pretty sure that these two bits made it so that every front end dev/ designer
in the world was at least passably decent at Javascript by the time Node
arrived.

[1] [http://boxesandarrows.com/htmls-time-is-over-lets-move-
on/](http://boxesandarrows.com/htmls-time-is-over-lets-move-on/) [2] Also,
Mootools and Prototype and YUI etc, but jQuery is the one that became
ubiquitous

~~~
flaki
As for jQuery - nobody disputes that it had HUGE impact on the web -
document.querySelector(All) itself is the living proof to that claim. It's
just... it was around for waaay to long.

Building tools and extending what is currently made available to developers by
the platform - all this is in our very natures as developers. We did that even
in the early days, when low-level primitives were mostly missing to support us
in that work.

Jake Archibald explains this in a comment on Nat Duca's post over at G+[1] -
give developers some primitives; see what they do with them - then distill it
and create high-performance features out of what now you already know there is
a _market for_. TC39 works on this basic principle (everybody whines about
types in JavaScript - TypeScript might be the JavaScript's jQuery here, paving
the way for some distilled type system in JS (or SoundScript. or anything else
that's out there).

 __*

As for Apple - I am siding with Peter-Paul Koch on this[2] - Apple had some
quite a few good deeds in favor of the web, but that was a long time ago.
Nowadays it just seems to be protecting its walled garden that is native apps
& the related ecosystem - certainly not giving a whole lot about making the
web a better place (or devs, for that matter). The Pointer Events fiasco is a
perfect reminder to all this.

For any good Apple has did to the web, the surely made equal bad so the scales
are (IMHO, at most) 50-50 here.

[1]:
[https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB](https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB)

[2]:
[http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...](http://www.quirksmode.org/blog/archives/2015/02/tired_of_safari.html)

------
pdpi
> JavaScript just happened to be a nice fit to evented, non-blocking I/O, and
> a single-threaded event-loop based environment.

I keep seeing variations on this statement, and I have never figured it out.
What, exactly, is it about JavaScript that makes it particularly appropriate
for this paradigm?

The way I see it, the only abstraction JS provides that helps with this is
first class functions, which are also present (and often richer and more
robust) in many other languages.

~~~
chubot
Not just first class functions -- anonymous functions, and closures.

Python has first class functions, but not anonymous functions, since lambdas
aren't full functions.

And Python doesn't have closures, because you have to use "global" or
"nonlocal" (in Python 3) to assign a a variable in an enclosing scope.

These features let you write concurrent state machines in JS without explicit
state -- you basically use the stack as state.

Python was pretty early in terms of event loop programming for interpreted
languages -- asyncore in the stdlib, and Twisted. But I agree that the node.js
style is nicer than asyncore, Twisted, or Tornado. I prefer coroutines over
state machines, but if you're going to write state machines, than doing it
with anonymous closures is nicer than doing it "manually" with classes and so
forth.

Tcl was even earlier, but Tcl is pretty foreign to most people, and was more
of an embedded language than a scripting language. Pretty sure Tcl has full
anonymous closures, but it is a bizarre language in some other ways.

I haven't seen the event loop style in Perl but I think you can do it. If
someone has an example I'd like to see it. To me, Perl only barely qualified
as a real programming language because you can't even name your function
params? At least when I used it, which was over 10 years ago.

~~~
barosl
> I prefer coroutines over state machines

And that's why Python supports `asyncio` (not to be confused with `asyncore`
which is obsolete). So I prefer:

    
    
      sock = yield from connect('localhost', 7942)
      msg = yield from read_message(sock)
      print(msg)
    

to this callback hell:

    
    
      connect('localhost', 7942, function(sock) {
          read_message(sock, function(msg)) {
              console.log(msg);
          });
      });
    

And they're completely equivalent. Why would someone actually _like_ the
latter, except you're forced to use it because of the prevalence of
JavaScript?

`asyncio` is not only easier to use than the traditional "manual" state
machines with classes, but also much faster than something like `Twisted`. In
my crappy local benchmark[1], it easily beat `Twisted` in a considerable
margin. That may be because of the flaws in my test code, but still their
performance is on par. I see no points in relying on callback hell, at least
in Python, except the lack of the libraries that support asyncio, which makes
me a little bit sad.

[1] [https://github.com/barosl/ws-bench](https://github.com/barosl/ws-bench)

~~~
timepiece
Can't you use promises/deferreds instead?

~~~
ufo
One thing yield/await does is that if plays nice with existing control-flow
mechanisms in the language. You can put them inside a for loop, if statement,
try-catch block, etc. With promises all of those have to be reimplemented in a
library and all your code needs to be converted to the "promisified" version
of things.

The different syntax also prevents you from creating functions that can be
reused by both sync and async code.

The big thing promises and other callback-based control flow libraries do is
that they fix exception handling in async code (its a PITA to add error
handlers in every callback when writing async code by hand). They also let you
avoid some of the awkward "pyramid of doom" nesting but thats not really
killer feature because you can also achieve that by using tons of named
functions.

~~~
tracker1
async/await are coming with ES7 and available today with BabelJS and other
transpilers. Though not part of core, they rely on thenables/promises, which
handle the reject/resolve which get composed with generators.

The required bits are in place... alternatively you can use co/koa which uses
generators along with yeilding promises to act in a similar fashion.. it does
work pretty well, and will only get better.

------
arh68
JavaScript is popular because browser vendors have not yet agreed on anything
better. Remember Native Client? You might as well forget it -- Mozilla didn't
sign on. ActiveX is a joke, but if Mozilla & Google et al had moved more
confidently towards something Native Client-ish, we could be writing web apps
in Go/Rust instead of JS. (or Groovy, $lang_of_choice) But what's their
incentive to make that effort?

Ajax was great when IE rolled it out all by themselves. It first might seem
like a skunkworks like ActiveX if you didn't know better. Give it a few years'
time, coordination and cooperation, and now we've got a Websockets RFC.
Consensus takes time.

As crusty as JS may be, I don't think these are dark times at all. I think the
rate of evolution (in JS engines, ES6/7, ..) is so swift it's more worthwhile
to stick to the JS platform than to reinvent the web yourself.

~~~
DonHopkins
What's ironic is that Mozilla is deeply infused with its own version of
ActiveX called "XP/COM" that's practically the same thing (to a point), just
using a totally different set of (open source) tools.

You can use and implement COM or XP/COM components in C, C++, JavaScript and
(theoretically but not commonly for XP/COM) other languages. XP/COM is not
syntactically compatible with COM, and uses a completely different headers,
tools, etc, but they're identical in memory layout and behavior and design. Of
course beyond identical IUnknowns, XP/COM's interfaces, metadata, and
JavaScript interoperability are totally different than ActiveX on IE.

They eventually realized they'd gone too far with it, and went through a "de-
COMification" phase around 2002, and it's been a few years since I worked on a
xulrunner application, but as far as I know, XP/COM is still pervasive
throughout Mozilla/Firefox/xulrunner, including its deep internals and its
chrome user interface layer.

COM was a good solution for a particular set of problems at the time, which
Mozilla also needed to solve, so XP/COM made sense in that context. But these
days, it makes more sense to use JavaScript and JSON directly as the
interoperability layer between components and other languages, instead of COM.

JavaScript won the language war, so it gets the privilege of being the
"linguistic motherboard" that you can plug other languages, emulators and
components into.

------
vezzy-fnord
There's plenty of interesting historical facts here, but they're interspersed
with an emptier and rather sensationalistic writing style that seems to
overemphasize the novelty of the various solutions listed. More importantly,
the post doesn't seem to answer the question that it poses at the beginning -
"It’s not too long until your very toaster will be running JavaScript… but
why?" The only answer I got out of it was "Because."

I find the implication in the Moore's law section about performance to be a
bit unfortunate. Ideas like this only strengthen Wirth's law. We're talking
about plain old JavaScript here, after all, not some hypothetical
Smalltalk/Erlang hybrid language with mystic productivity benefits or anything
like that.

------
at-fates-hands
The impact on front-end development in the last three years has been
undeniable.

Even now, you're either a Javascript Developer or you're a designer (a
designer with HTML/CSS chops but really weak Js skills), the role of the
front-end dev has morphed seemingly morphed into this two for some reason.

~~~
cozuya
Rebecca Murphey also said this today but in my experience I'm not really
seeing it. Just checked job listings now and all front end positions heavily
promote HTML and CSS with minor exceptions for more JS heavy roles. More
telling is a lack of non-JS roles i.e. I'm certainly not seeing any "HTML/CSS
developer" positions open.

------
linkregister
What I thought to be the most promising part of the article:

Tessel created "a compiler that translated the JavaScript source to Lua and
executed the translated code on the very compact Lua virtual machine on the
microprocessor of the device".

linked: [https://tessel.io/blog/98257815497/how-tessel-works-the-
basi...](https://tessel.io/blog/98257815497/how-tessel-works-the-basics)

~~~
tracker1
The newer tessel is actually abandoning this model in favor of a faster system
that just runs actual node/iojs and modules built for the platform
architecture.

------
findjashua
I think if React Native lives up to its promise, it's going to drive a much
bigger adoption than node/iojs has.

------
0xFFC
As javascript lover I should admit that I think this is not about about
javascript as language, It is more about being in right time and right
place.Every one here knows javascript is awful language for optimizing and V8
kind of blow it up with every kind of optimization most of us cannot even
imagine.Imagine instead of javascript , Python/Lua was standard way of browser
to make dynamic content in ~2000 and web explosion days.Then I think we would
talk about that language instead of javascript today.When you looking at big
picture , you can see google push's Dart , which they somehow (at least I
think) plan to replace javascript with Dart (I am not telling it is going to
be that way , But I think this is how they have plan to do in long-term
future)

~~~
0xFFC
UPDATE : just a day after this comment , Google announced it will not
integrate dart to its browser and it will only focus on dart2js. So , I was
Wrong google long term plan.

------
beat
Wow. Lots of information there, lots of things I didn't know about!

Part of me is appalled that a language as icky as Javascript is taking over
the world like this. But I'm happy that any language at all is giving us this
level of flexibility and standardization.

------
DigitalSea
Javascript is definitely an interesting language. For a while there it was the
lament of code purists who shrieked every time you called it a language with
the usual retorts like, "Javascript isn't a language, it's a hack"

I think ECMAScript 6 is definitely a welcome change to the language, ES7 will
be undeniably better (even if for Object.observe alone). Now that releases for
ECMAScript specifications will be released yearly, we'll see the language
evolve and now that we have a nice range of evergreen browsers, developers can
take solace in the fact they don't have to support older browsers for much
longer (as new features are released, browsers incorporate them).

While Javascript definitely has its warts, what other language can boast of
the same market share as Javascript? There is no such thing as a perfect
language. Not to mention its low barrier to entry, nothing to deploy, no
compiler to configure and how powerful it is in capable hands. I think the
success of Javascript was more than being in the right place at the right
time, I think its ease of use spurred a booming community. Not to mention the
fact you could be confident you can write Javascript and it'll run basically
anywhere.

People who feel the need to complain about how bad Javascript is to educate
themselves further or most likely have never used it properly. There are
definitely bad parts in Javascript, but any decent developer who has a good
understanding of Javascript knows what those bad parts are and how to avoid
ever encountering them. Any language allows you to write poor code, some just
make it easier than others (like PHP).

For me the biggest and most exciting thing to happen to Javascript is
React.js. And once it is released if my gut-feeling is correct: React Native
is going to drive the Javascript language even further, possibly spurring a JS
revolution even more-so than Node.js/IO.js has.

------
smrtinsert
Blind luck. Web developers had copied and pasted functions for years, a few of
them grew up from that basic beginning and tried to make lemonade.

Can't wait till the next big one, because this one isn't doing it for me.

------
tracker1
Really great read... I used to write a lot of JScript in classic ASP, as well
as the MS script runtime in windows... I think the only really ugly part was
when you had to deal with COM enumerations. I also used to use hidden frames
as post targets and use JSONP-like callbacks into request queues... most often
I'd use the ADO option which allows for a response to be serialized into a
string specifying a field and row delimiter.. I'd have my client-side script
split this out. I also remember it being much faster early on to fully re-
render a frame vs. manipulating the DOM for a lot of things. DHTML while
supporting NN4/IE4 was a pain.

I couldn't be happier for where JS has come.. I use node's tooling daily, and
although I do use BabelJS for ES6 features, I find it to be a very good fit
(with more functional thinking) for a lot of problems.

------
ffn
As much as I am anally pained by the following things in JS:

1 + "2" = "12" but "1" \- 1 = 0

0 == false ( "if window.scrollTop ..." will occasionally break on user scroll
)

undefined == null ( why do we need 2 empty sets? )

undefined + "dog" != null + "dog" ( breaks transitive property )

undefined !== null ( but native operators like ? and if uses == and not === )

I'm really glad Javascript is taking over. Mostly because I am a small
business / indie dev and using Javascript allows me to off-load a lot of work
onto distributed client computers. Which, in turn, allows me to piggy back off
of Google, Github, etc., for free hosting and be massively "scalable" to
traffic spikes with no cost to me. Js has become massively portable so rapid
prototyping and deliver is more possible now than ever.

~~~
timepiece
"1" \- 1 = 0

Seriously, what answer were you expecting other than this?

I'm really curious!

~~~
pwang
Any decent language that wants devs to be able to reason about operators and
types would throw a TypeError here.

Shitty languages will cause devs to have to purchase books entitled
"ShittyLanguage: The Non-Shitty Parts", wherein chapter 8 talks about "avoid
using the subtraction operator because of ambiguous precedence, transitivity,
and coercion rules; instead use jQuery.minus()."

~~~
tracker1
Easy.. don't let shitty programmers write code.. oh, that's right, everyone
has to learn/start somewhere.

I've seen some pretty horrible code, with any number of bugs in pretty much
every language I've ever seen. If you're passing a string into a function that
expects a number, you deserve what you get. parseInt(value,10) for user input
isn't so hard.. if you want to ensure a numeric value, you can always ~~value
... though that's slightly less obvious to someone new to the language.

JS evaluation expressions are far nicer than most languages I've worked with..
aside from C#'s addition of .? I can't think of much that comes close to as
fluid in terms of handling end user input and massaging it into something that
works correctly.

Your comments remind me of the XML everywhere mindset that used to be so
prevalent in "enterprise" programming... JSON is a much better abstraction for
data models, as it is less disconnect from actual code.

Personally, I prefer a "don't cause an error unless you _really_ have to"
approach to development... if you can recover from an error condition, log it
and do so... if you can't, blow up the world. Java's error handling comes to
mind here as particularly cumbersome to deal with... Node's typical callback
pattern, and similarly promises/thenables is much easier to work with in
practice.

JS has some really hideous parts... just the same, the Browser is an
environment where you expect things to do "something" and mostly still work
when parts break... the services that back browsers should likely do the same.
JS is a good fit for this use case.

------
ForHackernews
Reminds me a bit of this talk: [https://www.destroyallsoftware.com/talks/the-
birth-and-death...](https://www.destroyallsoftware.com/talks/the-birth-and-
death-of-javascript)

------
tambourine_man
_…since both Webkit and node.js used V8 as their JavaScript engine…_

Maybe you meant Blink, WebKit uses JavaScriptCore

~~~
flaki
Chromium, rather than Webkit, but yes - thanks for pointing that out I have
fixed this (Blink was created much later, in early 2013).

------
elchief
And don't forget to write your Postgres stored functions in JavaScript with
PLV8

------
aikah
wether one likes javascript or not,this is a good article one must read about
the state of javascript today.

------
malthaus
Ah - the pain of path dependence

------
bricss
Yeah, JavaScript rocks!

------
mahouse
Stop trying to make Firefox OS happen.

------
ttty
I've been saying this for years (: happy to hear

