Ask HN: Is JavaScript's Time Up? | Hacker News Reader

Ask HN: Is JavaScript's Time Up?

12 pointseatonphil22 comments

The title is immediately deceiving, but I couldn'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?

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.

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.

The only reason I can see actually "writing" Javascript continuing is in maintaining "legacy" code bases. Any thoughts?

[0] http://en.wikipedia.org/wiki/LLVM#Front_ends:_programming_language_support

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.

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.

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.

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.

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).

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.

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.

Oh god, this, 100000000x this! My main frustration is the lack of canonical implementations - there never seems to be a good way to do anything - everything has nasty tradeoffs, so you have to pick the best for each situation - which results in a lot of different paradigms across a codebase. Yuck.

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.

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

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

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.

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?

Done: dart

Yes. As long as the compiler is invisible and fast enough to notice any difference. But then, will we ever have such compiler across all browsers?

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

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

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.

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.

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

ES6 gonna fix the little bit broken part of javascript.

I hope not, Javascript is awesome.

Reply on news.ycombinator.com