JavaScript is the C++ of the Web
When I started my PhD, back in 2009, I told my advisor I wanted to work on optimizing dynamic programming languages. A big part of my thesis was going to involve the implementation of a JIT compiler for some dynamic language, and so our discussion rapidly became focused on which language I should be working with. In the end, we ended up choosing JavaScript. It was a good compromise: a widely-used “real-world” programming language, warts and all, that was still small enough for one person to realistically implement a compiler for. The ECMAScript 5 specification was around 250 pages long, and I read the whole thing from cover to cover before I began working on Higgs.
Since then, I feel I’ve been watching JavaScript go the way of C++, it’s becoming a “kitchen sink” language. So many new features have been added that the new ES6 specification document is literally twice the length of the ES5 specification. Worse yet, a year before the ES6 specification was even completed, there was already a laundry list of features scheduled for integration into ES7. They weren’t nearly finished with ES6, and they were already planning ES7. There are a number of semantic inconsistencies in JavaScript that need fixing, but the ES6 and ES7 additions do nothing to fix those, they merely add new features (read: complexity) to the language.
Personally, I’m a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand. The bigger your language, the more semantic warts will pop out and the more behavioral inconsistencies are going to occur between different VM implementations. If JavaScript is really “the assembly language of the web”, then why does it need all these high-level features? The logical thing to do would have been to freeze as much of the JS semantics as possible, and focus on improving support for JS as a compiler target. I believe that the answer as to why JS keeps growing is largely design by committee.
Of course I’m biased. I implemented my own JavaScript JIT compiler and the fact is, I’m too busy to keep up with all these new additions. Still, it seems to me that in the web world, nobody takes the time to pause, breathe and think things out for even a moment. Case in point: Mozilla made a lot of noise with asm.js, a standard for compiling native code to JS that was allegedly better than Google’s Native Client. I think asm.js is still new enough that developers haven’t really had any time to adopt it, it’s only been used in tech demos, but Mozilla and Google are already working on WebAssembly, which in all likelyhood will make asm.js irrelevant. Think about that for a second: asm.js, which is still very new (2013, it’s only two years old), is already mostly irrelevant, before anyone even had time to adopt it.
WebAssembly is essentially what Brendan Eich told us we didn’t really want or need: a bytecode format for the web. A somewhat more neutral platform for all compilers to target. As a compiler implementer, it still seems to me like it’s a bit of an unfortunate compromise: a way to retrofit a web-bytecode into JavaScript VMs. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, whereas GCC, clang, and other real-world compilers usually generate Control Flow Graphs (CFGs) at the output stage, not ASTs. Forcing compilers to convert CFGs back into ASTs seems like a decision made to simplify the job of WebAssembly VM implementers, at the expense of everyone else.
Pointers Gone Wild 
It’s the problem of JavaScript as a Language and Javascript as a platform. JavaScript the platform needs to be able to do everything that is required by Languages that are compiling to JS.
If it takes the Kitchen sink approach, JavaScript becomes a shitty language, If they don’t JavaScript becomes a Shitty platform.
The thing that sticks in my mind is that for all the enhancements to Javascript, an effective while(true) causes a hang. You can’t write a blocking IO program as simple as cat
while(!eof()){writechar(readChar());}
I’m working on a proposal for JavaScript pre-emption (virtual interrupts) that would help, but I don’t really expect people to like the idea much.
I noted in https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#more-expressive-control-flow That they list “No action” as a possible solution.
I’d still prefer a CPU style ByteCode. Notch posted a single Page Spec for his DCPU-16 There were multiple compatible emulators within 3 days. The first compiler was out in less than a week. Simplicity of specification is really important.
What do you think, how compatible WebAssembly could possibly be with semantics of native interpreted languages? Something like `@safe` D subset, for example.
Probably quite compatible since it’s going to be engineered with compilation of C and C++ code in mind.
There’s nothing wrong with a programming language being a “kitchen sink” programming language. Those are the kind of languages we need for writing the largest, most sophisticated software systems around.
C++ has excelled at real-world usage because it’s such a power language. With C++14, you can write extremely low-level C-like code, you can write mid-level Java- and C#-like OO code, and you can even write high-level code using lambdas and other techniques from functional programming. The best part is that you’ll also get excellent performance and excellent portability, even when mixing these various styles within a single library, application or system.
Since C++ is so powerful and practical, we see it used to write almost all of the really critical software we use today, including the implementations of so many other programming languages! No other language comes close to matching C++’s such widespread use for so much critical software.
The biggest problem with JavaScript isn’t that it’s gaining too many features. The problem with JavaScript is that it’s fundamentals are so very broken. This is where it differs from C++. C++’s fundamentals are generally quite sane and sensible. It may not be perfect, but it’s nowhere near as much of a, pardon my language, total shitshow like JavaScript is. C++ is a large structure built on a very solid and proven foundation. JavaScript is a large structure built on a shaky, wobbly foundation that’s broken in some areas, incomplete in others, and just plain totally missing in yet others.
There’s just no need for JavaScript. If web browsers supported a proper runtime system, then we could finally throw away JavaScript, and just write all of our software in high-level C++. We’d all be better off if this is how client-side web software was developed.
– Ted
Agree 100%
JavaScript was a simple scripting language for web pages (clue is in the name!).
Unfortunately its grown to be a very ugly beast, with every iteration making it a more complicated and no doubt more broken and vulnerable.
Security is everything in a web page/application, the bigger the language/API the more likely you are to have problems – for example the new privacy issue with the Web power management API
Unfortunately there are too many incompetent people making rushed and rashed decisions in the world of JavaScript and browsers -some real world sanity is required. Just because you can doesn’t mean your should!
Or programmers could use the right tool for the job instead of wanting one programming language to do everything..
WebAssembly [1] is the next version of asm.js (not a competitor): It is initially a binary format for asm.js and later will gain new features. Due to WebAsssembly, JavaScript doesn’t have to play the role of “assembly language of the web”, anymore. For example, a few features were added to ES6 only to help with compiling to it. In the future, JavaScript will only gain high-level features, while WebAssembly will only gain features that are useful for compilers.
I do agree with ES6 having new quirks, but I don’t agree with it being bloated. It is still playing catch-up with scripting languages such as Python.
Lastly, you should take a look [2] at upcoming feature proposals and the design process for ES7: ES7 will be a tiny release and the design process has been explicitly created to avoid design by committee (ES6 used a similar process).
[1] http://www.2ality.com/2015/06/web-assembly.html
[2] https://github.com/tc39/ecma262
Ted you are so far off base, you are already out.
Let’s get rid of Javascript and just use C++ ? That idea is idiotic.
I agree with most of this article. ES6 has some nice features, but it’s over blown and feels like some coffeescript guys got control and started morphing things in their preferred direction. I don’t like it but were are stuck with it. I agree that we are stuck with more of the same with ES7 on the way.
It very much reminds me of the way that Java went, with more and more complications added in the name of sophistication, until you had to a full time and dedicated student of Java to be able to really “play”. The “cool kids” have the wheel now, and anyone who disagrees is just not cool.
That’s a very bold statement! Really good insight though, thanks for the post up.