
Ask HN: Is JavaScript's Time Up? - eatonphil
The title is immediately deceiving, but I couldn&#x27;t think of better wording for a title. Specifically, I mean to ask if Javascript as a language front-end (as compared to a compiler target) is coming to an end?<p>With tools like emscripten and js_of_ocaml, I can write C++, C, OCaml, Python, Java, Rust, Haskell, Objective-C, CIL (and any other language that compiles to LLVm bytecode[0]) and use that to power my browser scripting.<p>As we get closer to a Javascript as a bytecode, it seems like there may no longer be a need for Javascript the front-end. If I had to start a new app today, I think I might choose to do it in a unified language that either targets LLVM bytecode, or Javascript directly. In this way I could achieve unification of my server-side and browser-side code. Allow ease of maintenance, hiring, etc.<p>The only reason I can see actually &quot;writing&quot; Javascript continuing is in maintaining &quot;legacy&quot; code bases. Any thoughts?<p>[0] http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;LLVM#Front_ends:_programming_language_support
======
HelloNurse
People would need to learn to not use Javascript, instead moving to a more
exotic language (exotic in the context of DHTML scripting, not in general)
with more complex and possibly less mature tooling.

Given the current popularity of Javascript, this means that the exotic
language must be very compelling; the two main reasons, reusing good libraries
written in some other language and reusing good programmers who don't know and
won't learn Javascript, appear rarely applicable (there are Javascript
libraries for most needs and most developers involved in web development think
they know enough Javascript) and they cover only a portion of most plausible
projects or teams when applicable (there are important parts of the
application beyond any library, and someone will want to use Javascript).

As for actual language fetures (templates in C++, various functional styles in
Ocaml and Haskell, etc.) a language fan needs to justify costs like
performance loss, write-only generated Javascript code, flaky libraries,
gigantic file sizes, and so on.

------
api
I wish.

I used Node recently for a project. Never again. It's just not a good
language, for many reasons. The Node _community_ is good, and the packages in
npm are good, but the language itself is so wishy washy and has so many warts
that if you try to do anything either very complex or performant it crumbles
quickly.

Of course that being said, I've gotten a bit jaded about dynamic languages in
general. IMHO they deliver high productivity up front but you pay for it later
X2 at least. But among dynamic languages Ruby, Clojure, and Python are orders
of magnitude better than JavaScript.

I feel like web developers have Stockholm syndrome with it. They've been
forced to use it, so they sort of forced themselves to pretend it doesn't
suck.

~~~
S4M
Can you elaborate why you think Ruby and Python are "orders of magnitude
better than JavaScript"? I always considered that Ruby, Python and JavaScript
are very closed to each other - dynamic typing, very quick to write.

~~~
api
It's mostly to do with JavaScript's warts:

\- Can't deal with 64-bit integers

\- Insane type system, e.g. null vs. undefined and all kinds of complexity
around seeing what something is. Types are _strings_? Really?

\- No baked-in language-standard way to do async coding despite the language
being inherently async, which leads to a mishmash of promises and indent
cascades with callbacks.

\- How do I use exceptions with callbacks or promises? All kinds of edge case
hell here. Either have exceptions or don't. Again there are probably good
patterns, but since there is no canonical way everyone does it differently.

\- The == vs === mess

\- Lots of fragmentation around how to do classes, inheritance, etc. Getting
fixed in ES6, but there will forever be tons of legacy code where everyone did
it differently.

\- In practice I've found it easier to get leaks in JS event-driven code than
in other GC'd higher level languages.

I'm sure others could list other things.

JavaScript is the product of a death march at Netscape in the late 90s, and it
shows.

~~~
taurath
The most difficult part about Node or Javascript coding is technique and
library selection - you will get contradictory advice because its so popular
or in node's case new, and there are so many choices there is no single right
way, and plenty of ways that may bite you.

\- 64 bit ints (yup)

\- Type system (you'll get over it)

\- Async coding - everyone has a different standard, but it does work
whichever way you do

\- Exceptions - callbacks have err as first parameter, every time. You have to
boilerplate. Promises you have to pass in an error function, you have to
boilerplate. Could definitely be improved, but like handling async there
aren't anything standard, just opinions at this point.

\- always ===, hint your code

\- OO stuff - absolutely. But its also not fundamentally an OO language, its
much more flexible.

\- Leaks - Tooling could improve a LOT. Finding and sticking to a technique is
the biggest part, which can get harder as a team grows bigger. Show me 2
people with 5 years of javascript experience at different places, and you'll
have 2 very different code styles.

If you're intent on making javascript with OO and aren't coding partially for
a browser, use something else. If you want very easy asynchronous
functionality with a very fast communications server, Node is pretty damn
good. Node is great for breaking down complex tasks, as long as you have a
good method of flow control (promises, async + callbacks, etc).

~~~
api
Question is why you'd use it over Go, Java, C#, or even Python or Ruby.

I picked it originally because there are lots of quickly-up-and-running
plugins and similar things in the npm repository. Like I said the community is
great. But the more I work with it, the more it hurts. Pain in a language
should _decrease_ with time as you work with it.

~~~
taurath
It certainly has for me - the hump is likely bigger due to how new it is. Its
hard to settle into a good flow when there are 1000 possible flows to get
into.

------
krapp
Not yet, because languages that compile to javascript don't actually replace
javascript with anything but javascript.

Plenty of people still write their own javascript, to do basic DOM
manipulation and whatnot. I really can't imagine that the common use cases for
JQuery, for instance, are better served by compiling C. It is a scripting
language, even if you want to pretend it's "bytecode", and even if treating it
as bytecode is useful for some people, I would argue that's still the
exception and not the norm.

------
atrilumen
Lately I've been very interested in targeting the browser with Haskell, using
Haste [0].

It appears that, at least for now, this pretty much always requires some
JavaScript FFI work to actually do things in the browser.

This alone is enough to motivate me to keep honing my (functional) JS.

( It's also nice to be able to bang out something quick and dirty with minimal
tooling. )

[0] [http://haste-lang.org](http://haste-lang.org)

~~~
codygman
I think GHCJS well mean having to use the JavaScript FFI much less.

------
manidoraisamy
The biggest advantage of javascript is quick prototyping + manipulating DOM
objects with no tooling (you can debug with javascript console in the
browser). I would die the day, I need a compiler to see a color change on a
button.

~~~
codygman
What if one of those compile to JavaScript languages forked Firefox and/or
Chromium and added support to their languages in the tooling?

Would that suffice for you?

~~~
HelloNurse
Do you mean something like VBscript in old Internet Explorer versions? Do you
understand why it died off?

~~~
codygman
Was VBscript source code visible from the browser? What I'm recommending is
basically something to replace Javascript in exactly the same way (except it's
a sane* language).

* I do concede ES6 is much much better

------
practicalpants
I doubt the MVC JavaScript fad will last much longer, but JS for just
manipulating the DOM and basic web stuff won't go anywhere, especially because
of the necessity of browser tools for webdev.

------
cweagans
In theory, sure, you could use any of those languages for real production
work. But in practice, it just doesn't happen. Javascript is here to stay, I'm
afraid.

------
bonn1
With ES6 JS feels pretty mature, so the question is how much added value would
another language provide and at which cost.

------
sandeshd
ES6 gonna fix the little bit broken part of javascript.

------
indubitably
I hope not, Javascript is awesome.

