10 ms·

JavaScript is the C++ of the Web

106 points by jsnell 11y ago

niix 11y ago
Interesting perspective. I've been sort of on the other side of the fence and excited about new features. With that said, I do love the simplicity of C and how the features of the language itself are very minimal and learning all of the language is fairly simple task. Do you think maybe the push for the extra functionality is an effort to standardize the millions of JS libraries out there that do this "high-level" functionality already, rather than leaving it up to the user for interpretation?
- tracker1 11y ago
  It's sometimes painful trying to even approach standardizing on a given framework of tools... I've been using babel + browserify and leaning on whatever shims it provides... I mean, even if I limit myself to lodash/underscore, bluebird, and jQuery, I've got a lot of overlapping bits in there... swap jQuery for react and my composition becomes a lot better, but even then I'm using either the ugly method invocation, or creating derived classes (which makes me feel dirty for some reason). Look at even a modest node.js project, and dig into your node_modules tree, it's amazing how many different modules wind up in your codebase to do the exact same thing(s). Ramda, lodash, underscore all in there, and hopefully not all leaking into your client-side. Hell, I'm working on a project now that has both jQueryUI and Bootstrap components in play... and a dozen or so extensions/modules for each of them.... It's pretty ugly pretty quickly. And I don't think the likes of Component or Polymer are all that better in practice. The more that starts to be in the box, and the better people understand it the better in a lot of ways.
thinkingkong 11y ago
Javascript is the only language "of the web" if you want to be blunt about it. Nothing else has ever come close, and itll be challenging to get a concensus on a replacement that wont just compile down to JS anyway.
aaron-lebo 11y ago
A few thoughts: I was all aboard the ES6 hype train before I realized that ES6 was one of many stops. Yes, the ES6 standard may be double the size of ES5 but most of the features were also necessary. ES7 seems like it will be a sizable change as well, and as the author points out, JS seems to be destined to design by committee. The other aspect of this, which the author points at but never says (JS is C++ and they prefer minimalist languages), is JS is stuck with backwards compatibility issues. ES6 adds proper scoping with let but can't completely remove var due to lots of old code. How do you handle that? You can't be too upset about asm.js becoming irrelevant because it was a rough draft of an idea and WebAssembly is an improvement on that. Better we fix those mistakes now instead of waiting 20 years to build on an already adopted but unsteady foundation (ala JS?). Despite some issues that might bother them (like feeding an AST instead of a CFG), hopefully WebA does its job well and lets us use those minimalist languages already mentioned.
phlandis 11y ago
At first glance I thought he meant it was the C++ of the web by popularity. This will probably be the typical pattern of widely used programming languages. Adding features until it is time to start from a clean slate a few decades later.
- loopeydaloope 11y ago
  'he' is a she.
  - delinka 11y ago
    At a quick glance, I can see no byline that might give me a clue as to the correct pronoun of the author. What would you recommend as a neutral pronoun in these cases?
    - phpnode 11y ago
      they
      - pfooti 11y ago
        I use 'xie', but 'they' works too.
    - deleted 11y ago
      [deleted]
    - okasaki 11y ago
      Alternatively, just write 'the author' or 'the writer'
    - phlandis 11y ago
      so many comments and not one adds to the conversation
    - VLM 11y ago
      English will be a pro drop language sooner or later, may as well get used to it. Will not be much of a loss (not lack of it). When spoken, inhale during "pronoun break time" and nobody skips a beat. "At first glance I thought meant it was the C++ of the web by popularity"
bkjelden 11y ago
After working for ~2.5 years on the web stack, I've spent the better part of the last year working purely in C++, and I can agree with the author's sentiment here. Both languages have warts, but JS is a small enough language (at least in the ES5/ES5+Typescript world I was working in) that the warts felt finite. The first couple months were full of surprises, but after that I felt like I had a good grasp on the language, and knew when it was going to bite me. No such luck with C++, however. It still seems like there are several times per week where I'm surprised by some new way the language can screw me over, like non-virtual inheritance, or a newly discovered subtlety in the way includes are processed. Another benefit of JS - since the language is interpreted, build times tend to be much lower, and debugging tends to be much easier than C++. EDIT: Another benefit of JS - people like to give JS devs grief for all of the OSS frameworks they create, but in the C++ world every major company has built their own, in-house, closed-source implementations of the same shit. I'd love to know how many different implementations of a linked list in C++ exist in the wild today.
- hliyan 11y ago
  After 10 years with C++ and the past 2.5 years on JavaScript, I agree with you. JavaScript is to the web what C++ is to systems development. The introduction of Node.js and module systems did the trick for me.
- andrepd 11y ago
  >I'd love to know how many different implementations of a linked list in C++ exist in the wild today. Why isn't the STL linked list enough?
  - AnimalMuppet 11y ago
    NIH syndrome. Some company thinks that they can do better than the STL, or that it doesn't meet their needs, or that they have a bunch of legacy code that was written before the STL and they have to maintain compatibility, or that they're a bunch of special snowflakes that deserve to have their own, or whatever. So they write their own, even though the STL is just fine.
  - 11y ago
jasode 11y ago
>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. After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing. I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are: If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc. For example, take the concept of "classes" that supposedly nobody needs in Javscript (because protoype chains are superior). What is the longest most complicated chapter of Nicholas Zaka's Javscript books[1]?! It's the long chapter on manually simulating classes using prototypes! Same situation with other books that describe home-grown "modules". Even if one chooses to avoid simulated classes in his own js code, one still has to understand the different variations that others write. If classes are not formally specified in the language spec, it's informally specified in everyone else's books, stackoverflow answers, blog articles, and youtube videos explaining js simulated classes. If Javascript had "classes" earlier than ES6, perhaps the over abundance of informal adhoc "class objects" would have been completely avoided. Another example would be "optional default" function parameters. Since javascript's formal language spec doesn't have a feature for default params, it is "simpler" and "easier to learn". (Hey, if one doesn't have to memorize the keyword "optional", that's one less thing to worry about, right?) Hmmm... really?! Look again more closely.[2] The "optional" feature is simply moved into an idiom (multiple idioms!) that all competent javascript programmers must learn. The "smaller" language hasn't saved any complexity -- it does the opposite -- it made JS usage more complex overall. Any language that's used for non-trivial purposes will not be "simple" if looked at holistically by combining both the formal and informal real-world uses of it. However, within that unavoidable complexity, there can be limited subset cases of "simple" for certain scenarios. What does one want a "simple" Javascript language spec for and what can it do? Make the monkey dance?[3] Ok, that's one mapping of "simple" to an end goal and 1995 Javascript specification is probably enough. However, people want to do much more complex apps with Javascript without having to mess around with Typescript, Babel transpiler, etc. To blog writers: please stop characterizing languages as "simple" without any qualifications of use cases. That adjective is no longer convincing on its own. [1]http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691 http://www.amazon.com/Professional-JavaScript-Developers-Nic... [2]http://stackoverflow.com/questions/148901/is-there-a-better-way-to-do-optional-function-parameters-in-javascript http://stackoverflow.com/questions/148901/is-there-a-better-... [3]http://programmers.stackexchange.com/a/221658 http://programmers.stackexchange.com/a/221658
tolmasky 11y ago
The problem with ES6 is that everyone has 2 features they like in it. The only thing that matters in my opinion is generators and (in ES7), async/await. This is a shift we've been seeing in many languages and I think actually tangibly solves a real problem in a transformative way. By that I mean, people will actually think about problems differently. Especially in JavaScript where everything is asynchronous, you need first class support of asynchronocity. There are a bunch of feature I "like" in ES6 but are ultimately useless in my opinion. Arrow functions are great, but could 1) be implemented in a transpolar, and 2) unfortunately behave different with regard to this and thus make the language even harder to understand (why did all my code break when I switched out the arrow function for a normal inline function?). Classes are horrible in my opinion, especially if they start inspiring people to use instanceof, which is a broken feature in Javascript (and hence why we need things like Array.isArray). Due to the fact that in JavaScript you will often have code from different contexts, you can't rely on these checks, and the old-style JS programming encourages you to use feature detection, whereas now you will think you can do something like this. The species properties (so map returns the right thing when you subclass Array for example), is even more complex. The fact that I can subclass Function is a bit absurd. The fact that subclassing Object, vs subclassing null, vs no subclass will be a lot of fun to understand. Let scope is fine I guess, I honestly never thought this was a big deal (coming from C and having to make the switch). It was of course implemented with TDZ which makes it incredibly hard to write in a transpiler, so now you have situations where the transpired code will work but once real let is added your code will break.
- mkozlows 11y ago
  async/await is one of those very C++-ish features, though, due to how it's implemented. Understanding ES5 async callbacks requires very little conceptual understanding -- you need to understand run-to-completion and the event loop (and I guess the idea of higher-order functions), but otherwise it's straightforward. Understanding ES2016 async/await keywords require you to understand all of that, plus ES2015 promises, ES2015 generators, and how they're all orchestrated together to implement async/await. The code looks simpler, but understanding what's really happening is a lot harder.
  - 11y ago
azakai 11y ago
> Too high-level, too JavaScript-centric. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, which seems quite wrong. 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 silly. An AST is used because it allows significantly smaller download sizes, which is quite important on the web, more details here: https://github.com/WebAssembly/design/blob/master/AstSemantics.md https://github.com/WebAssembly/design/blob/master/AstSemanti... WebAssembly is in a different situation than gcc, clang, etc. It makes sense for LLVM IR, for example, to have a CFG, as it is a compiler IR meant for optimization. But WebAssembly binaries are meant to be distributed over the web and instantiated as quickly as possible. > This decision was clearly made to try and simplify the job of WebAssembly VM implementers, at the expense of everyone else. I don't think that is the reason at all. In fact it adds work for those people to handle an AST. But the work is justified by the startup speed benefits that it brings to the web platform.
- pcwalton 11y ago
  I think Luke Wagner put it best. Paraphrased, "an encoded AST is just a bytecode for a register VM with a compressed encoding form for 'the last register I mentioned'". Besides, converting a CFG to a high-level AST is a complete non-problem these days.
  - chas 11y ago
    What resources are there on the state of the art algorithm-wise for doing that conversion?
    - azakai 11y ago
      One option is the relooper [1][2] which is used in emscripten. It recreates high-level control structures as best it can, then falls back to a helper variable when it can't. Another option is node-splitting, where irreducible control flow is solved by duplicating code (but that has a bad worst-case code size increase). [1] http://dl.acm.org/citation.cfm?doid=2048147.2048224 http://dl.acm.org/citation.cfm?doid=2048147.2048224 [2] https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.h https://github.com/kripken/emscripten-fastcomp/blob/master/l...
mrec 11y ago
I don't quite get why the author thinks that wasm will make asm.js irrelevant. As I understand it, what wasm brings to the table is mostly a binary representation of asm.js, with the concomitant size advantages. If they're two different ways of encoding the same thing then I'd expect most toolchain and optimization work for one to benefit the other, and asm.js will continue to benefit older browsers for a while. What made asm.js a breakthrough was that vendors couldn't kill it by ignoring it - it's just Javascript, so it doesn't need explicit support to run, so ignoring it just hurts you in competitive perf benchmarks. Wasm IMHO is a smaller step forward, but I think the mapping is direct enough that a polyfill lib can handle deserializing wasm to asm.js - not ideal, but at that point it's unkillable again. Very different from {P}NaCl, which was very successfully killed by everyone except Chrome ignoring it. DISCLAIMER: I've read about these techs but haven't had a chance to use them in anger yet; apply pinches of salt to taste.
- SpaceCadetJones 11y ago
  If you look at the WebAssembly github they have a pretty detailed roadmap/plan of what they would like to accomplish. In the beginning it is essentially what you just stated, but after that initial goal is completed they are looking to start diverging from asm.js and begin adding in more features.
rrss1122 11y ago
"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." Hey, how about that, another person who thinks this. And this from someone who read the entire ES5 specification and built a JIT compiler for JS. She gives a good example of the web moving too fast. Already asm.js is obsolete and it didn't even mature enough to be used. It's starting to feel like complexity for complexity's sake. Java and JavaScript both had a chance to win in the early days of the browser wars. JS came out on top, and it was vastly simpler than Java. Now they want to turn JS into Java. Maybe this will be the opening Google's Dart needed to take off.
- azakai 11y ago
  It does feel fast for asm.js, but WebAssembly is simply much better than it. We did asm.js because there wasn't an option to do something better earlier; now that there is, with all browser vendors eager to collaborate, it seems pointless to delay. Also, this evolution should not be too disruptive. First, asm.js content will continue to work, since it is just JS; it will also continue to be fast (in fact, WebAssembly will polyfill into asm.js in the short term). Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).
  - vmorgulis 11y ago
    >Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web). The problem is around the API. I know you do your best to provide a platform similar to native (with fopen(), sockets, SDL...) but I wonder if it is not simpler to do that with a VM (a kind of kernel for emscripten) ? From time to time, I look at qemu source code to find a solution. Originally, Fabrice Bellard did a standalone libqemu but it was removed. There is the SPLICE protocol too for the graphics or even VNC. I'm thinking of a layer that do not rely on the DOM or emscripten JS pragmas. Thus we could have a world of lightweight linux/bsd distros for the web. PS: I've seen your work on musl and signals.
JustSomeNobody 11y ago
On the one hand: Who cares!? You don't have to use every feature of a language. On the other hand: What do you expect when something is designed by committee? Everyone wants to add their own special sauce to the mix.
- VLM 11y ago
  Unfortunately you have to know every feature to read or troubleshoot. Someone claiming to never be mystified by an obscure incantation of c++ either is lying or hasn't looked very much. I suppose something had to be invented to make bad perl look crystal clear. Insert bad joke here about not needing a contest to have a obfuscated c++ competition.
rpedela 11y ago
Yeah it is becoming a bit bloated. Honestly I think all they had to do was add import/require and support 64 bit integers and numerics and the language would have been good enough.
outworlder 11y ago
> 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. This, one hundred times. The current excuse for JS's surprising behavior is legacy and the fact that it was built in ten days or something. Now that we are not in such a hurry, could we please fix the thing? It's not like new ES6 code is backwards compatible anyway. I'd argue that we don't need many of those features. Lua is tiny, has a tiny interpreter, has a fast compiler (LuaJIT) and has been resisting new language additions and doing fine anywhere it's deployed. It helps that it has a nice design from the start. But it doesn't have brackets and semicolons. People just love those, it seems.
- LukeB_UK 11y ago
  JavaScript can't fix the legacy issues because of backwards compatibility. Not in terms of making ES2015 code work on old browsers, but making old code work on new browsers.
  - acdha 11y ago
    I agree with the first sentence but the last part seems incomplete. Were you thinking of the difficulties bridging old and new code running in the same app? I like the idea of an opt-in "use modern" to avoid breaking old code but that would get tedious if you needed to call between old and new code in the same app.
  - 1ris 11y ago
    JavaScript even has "int" and such as reserved keyword. A hole lot of stuff could be fixed using them without breaking any compability.
  - outworlder 11y ago
    Can't we run old code with the old semantics unless otherwise specified? We already have stuff that changes semantics, notably strict mode.
nly 11y ago
C++ isn't terribly large. The current language, i.e. the standard excluding the standard library, is about ~700 pages. Smaller than Java. The standard library, as of C++14, is also tiny (but growing rapidly) Imho, the perception of C++ as a large language comes principally from the high combinatorial complexity of its feature-set. It is very much a toolbox language. C++ advocates have only just recently started preaching a collective 'Pythonic' or 'Rubyist' way ("modern C++"). It is, however, still very much a broad church, with less philosophical baggage than many other languages. Strong and differing opinions on the committee seem to keep a single dictatorial programming style from emerging. Tbh, I don't know what the author is worried about. Does Javascript have an overriding mindset/philosophy that is being eroded? Is that the concern? Other concerns about implementations not keeping up don't seem well-founded.
- wuch 11y ago
  If I were to compare complexity C++ and Java, I would say that the former is much more complex and intricate than latter. Complexity of both of course keeps increasing. But, that does not necessarily mean that programming in any of them is getting more complicated. Argument is often made, for example by Stroustrup himself, that while language is getting more complicated, using it is getting easier and more intuitive. This argument seems to have some merit. Going back to C++ / Java comparison, lets have a look at some objective and subjective metrics. I am analyzing "The Java Language Specification - Java SE 8 Edition" and "Working Draft, Standard for Programming Language C++ N4527", in case someone would like to repeat this exercise. The Java specification has 780 pages, C++ standard has 1367 pages. Of course there are quite a few objections to be made about this comparison. First, if you open both standards side by side it is quite clear that typesetting and margins are quite different. Java has wider margins and a bigger font. So as a next step lets have a look at number of words. I converted both PDFs to text using pdftotext and counted number of words using 'wc -w'. This gives 227958 words for Java specification, and 477719 words for C++ standard. But that is still hardly fair. C++ standard contains description of standard library, Java specification in general does not (partially it does specify Object, Class, Thread, and some of exceptions, but lets ignore this issue). How many pages of C++ standard constitute description of standard library? I would say that all from "17. Library Introduction" up to "30. Thread support library", additionally including "Index of library names". Those constitute 777 pages, leaving only 590 for description of C++ language itself. That would be less than Java specification, but if we go back to word metric, this gives us 249186 words for C++ standard, a little bit more than Java, but not much. From more subjective perspective, I would say that Java specification is written using much simpler language, but that does mean that it is less precise. Moreover it seems to me that Java specification contains more non-normative text than C++ standard does. I would also say that reading Java standard from front to back doesn't seem to be very challenging (with small exceptions like overloading, which seems to be one of most complex parts of Java). And when I write 'reading', what I am really mean is reading and understanding. On the other hand I would never said similar thing about C++ standard. Understanding C++ just by reading standard seems almost impossible, as most of commentary and useful discussion is contained elsewhere: in proposals and defect reports.
coldtea 11y ago
>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. Citation needed. Python is a popular first / teaching language and it has as many (and probably much more in 3.5) features as JS. And Scheme is supposedly simple, but not that popular with any large amounts of people, beginners included. There are features that interact in mysterious ways and can be difficult to master (C++ has a lot), and features that are mostly orthogonal (e.g. template strings don't complicate anything related to arrow functions and vice versa). What I'd like to see, with regards to Javascript, is for "strict mode" to extend to the correction of old, long standing warts (e.g. crazy coercion rules etc). But I guess with this new shared "bytecode" for the web announced, we probably wont have this problem for long.
- twerquie 11y ago
  The author has clearly framed these as personal opinions, which as we all know, everyone is entitled to.
  - coldtea 11y ago
    Not in technical disussions: in these you only get to have arguments. Or rather, you can still have "personal opinions" but without arguments backing them are of no use to anybody and you might as well not state them.
    - twerquie 11y ago
      You know, it's possible to have a conversation without having an argument. It is possible to listen to others. Not everything in life, or indeed on Hacker News, is a debate to be won. Sometimes we're just sharing our human experience.
- doktrin 11y ago
  > I think that smaller languages have the potential to be easier to implement > Citation needed Uh huh.
- 11y ago
1ris 11y ago
I once listed to a talk about a "new" JS (don't know witch one. I guess it never was adopted) It started with explaing all the ugly part of the DOM: Variables that are constant, variable that are more like setters, variables that don't show up in a for(x in y) loop. I was very exited. Are they goning to fix all this ugliness? Tidy up that crap? NO! They said: "We want to be able to implement the DOM in JS. That's why we are going to add all this crap into JS". I have no idea from what perspective this makes sense. It's not just that I think it's a bad idea, I have no clue how anybody else could come to the conclusion it was a good idea. This was a way worse than C++. But I think in the end it didn't happen.
w8rbt 11y ago
Since C++ was malinged by the author, I thought this quote relevant. "There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup Source - http://www.stroustrup.com/bs_faq.html#really-say-that http://www.stroustrup.com/bs_faq.html#really-say-that
notNow 11y ago
* If JavaScript is really “the assembly language of the web”, then why does it need all these high-level features?* Someone should introduce this dude to the novel concepts of "figures of speech" and "metaphors" as he's completely clueless losing the plot.
nathansobo 11y ago
I'm happy about the changes that are being made to JavaScript. For new code, stick to a modern subset of the language and enforce it with a linter. It's not ideal, but I'd rather live in a world where ES6 and ES7 features exist than one in which they don't.
fffrad 11y ago
ASM or WASM, I expect a future where both of them are included in the head of the document by two different developer and I have no choice but to maintain them.
adamzubi 11y ago
http://googler700.blogspot.com/ http://googler700.blogspot.com/
CmonDev 11y ago
"Mozilla and Google are already working on WebAssembly" She picked her favourite companies, I guess :). The reality: "The team working on WebAssembly includes people from Mozilla, Google, Microsoft, and Apple" https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly
tempodox 11y ago
I'm afraid I have to concur with the article's title and most of its contents. Instead of letting developers code in a sensible language and simply making JS a better compiler target, the language was bloated with cruft to support manually writing it. For a notoriously overburdened language like JS this is definitely the wrong direction. Like with C++, you now have to judiciously choose which features of the behemoth to abuse and woe betide you if you choose unwisely. Don't touch JS with a ten-foot pole, let a compiler do this dirty work for you.

106 points by jsnell 11y ago

niix 11y ago

Interesting perspective. I've been sort of on the other side of the fence and excited about new features. With that said, I do love the simplicity of C and how the features of the language itself are very minimal and learning all of the language is fairly simple task. Do you think maybe the push for the extra functionality is an effort to standardize the millions of JS libraries out there that do this "high-level" functionality already, rather than leaving it up to the user for interpretation?

tracker1 11y ago
It's sometimes painful trying to even approach standardizing on a given framework of tools... I've been using babel + browserify and leaning on whatever shims it provides... I mean, even if I limit myself to lodash/underscore, bluebird, and jQuery, I've got a lot of overlapping bits in there... swap jQuery for react and my composition becomes a lot better, but even then I'm using either the ugly method invocation, or creating derived classes (which makes me feel dirty for some reason). Look at even a modest node.js project, and dig into your node_modules tree, it's amazing how many different modules wind up in your codebase to do the exact same thing(s). Ramda, lodash, underscore all in there, and hopefully not all leaking into your client-side. Hell, I'm working on a project now that has both jQueryUI and Bootstrap components in play... and a dozen or so extensions/modules for each of them.... It's pretty ugly pretty quickly. And I don't think the likes of Component or Polymer are all that better in practice. The more that starts to be in the box, and the better people understand it the better in a lot of ways.

thinkingkong 11y ago

Javascript is the only language "of the web" if you want to be blunt about it. Nothing else has ever come close, and itll be challenging to get a concensus on a replacement that wont just compile down to JS anyway.

aaron-lebo 11y ago

A few thoughts: I was all aboard the ES6 hype train before I realized that ES6 was one of many stops. Yes, the ES6 standard may be double the size of ES5 but most of the features were also necessary. ES7 seems like it will be a sizable change as well, and as the author points out, JS seems to be destined to design by committee. The other aspect of this, which the author points at but never says (JS is C++ and they prefer minimalist languages), is JS is stuck with backwards compatibility issues. ES6 adds proper scoping with let but can't completely remove var due to lots of old code. How do you handle that? You can't be too upset about asm.js becoming irrelevant because it was a rough draft of an idea and WebAssembly is an improvement on that. Better we fix those mistakes now instead of waiting 20 years to build on an already adopted but unsteady foundation (ala JS?). Despite some issues that might bother them (like feeding an AST instead of a CFG), hopefully WebA does its job well and lets us use those minimalist languages already mentioned.

phlandis 11y ago

At first glance I thought he meant it was the C++ of the web by popularity. This will probably be the typical pattern of widely used programming languages. Adding features until it is time to start from a clean slate a few decades later.

loopeydaloope 11y ago
'he' is a she.
- delinka 11y ago
  At a quick glance, I can see no byline that might give me a clue as to the correct pronoun of the author. What would you recommend as a neutral pronoun in these cases?
  - phpnode 11y ago
    they
    - pfooti 11y ago
      I use 'xie', but 'they' works too.
  - deleted 11y ago
    [deleted]
  - okasaki 11y ago
    Alternatively, just write 'the author' or 'the writer'
  - phlandis 11y ago
    so many comments and not one adds to the conversation
  - VLM 11y ago
    English will be a pro drop language sooner or later, may as well get used to it. Will not be much of a loss (not lack of it). When spoken, inhale during "pronoun break time" and nobody skips a beat. "At first glance I thought meant it was the C++ of the web by popularity"

bkjelden 11y ago

After working for ~2.5 years on the web stack, I've spent the better part of the last year working purely in C++, and I can agree with the author's sentiment here. Both languages have warts, but JS is a small enough language (at least in the ES5/ES5+Typescript world I was working in) that the warts felt finite. The first couple months were full of surprises, but after that I felt like I had a good grasp on the language, and knew when it was going to bite me. No such luck with C++, however. It still seems like there are several times per week where I'm surprised by some new way the language can screw me over, like non-virtual inheritance, or a newly discovered subtlety in the way includes are processed. Another benefit of JS - since the language is interpreted, build times tend to be much lower, and debugging tends to be much easier than C++. EDIT: Another benefit of JS - people like to give JS devs grief for all of the OSS frameworks they create, but in the C++ world every major company has built their own, in-house, closed-source implementations of the same shit. I'd love to know how many different implementations of a linked list in C++ exist in the wild today.

hliyan 11y ago
After 10 years with C++ and the past 2.5 years on JavaScript, I agree with you. JavaScript is to the web what C++ is to systems development. The introduction of Node.js and module systems did the trick for me.
andrepd 11y ago
>I'd love to know how many different implementations of a linked list in C++ exist in the wild today. Why isn't the STL linked list enough?
- AnimalMuppet 11y ago
  NIH syndrome. Some company thinks that they can do better than the STL, or that it doesn't meet their needs, or that they have a bunch of legacy code that was written before the STL and they have to maintain compatibility, or that they're a bunch of special snowflakes that deserve to have their own, or whatever. So they write their own, even though the STL is just fine.
- 11y ago

jasode 11y ago

>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. After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing. I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are: If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc. For example, take the concept of "classes" that supposedly nobody needs in Javscript (because protoype chains are superior). What is the longest most complicated chapter of Nicholas Zaka's Javscript books[1]?! It's the long chapter on manually simulating classes using prototypes! Same situation with other books that describe home-grown "modules". Even if one chooses to avoid simulated classes in his own js code, one still has to understand the different variations that others write. If classes are not formally specified in the language spec, it's informally specified in everyone else's books, stackoverflow answers, blog articles, and youtube videos explaining js simulated classes. If Javascript had "classes" earlier than ES6, perhaps the over abundance of informal adhoc "class objects" would have been completely avoided. Another example would be "optional default" function parameters. Since javascript's formal language spec doesn't have a feature for default params, it is "simpler" and "easier to learn". (Hey, if one doesn't have to memorize the keyword "optional", that's one less thing to worry about, right?) Hmmm... really?! Look again more closely.[2] The "optional" feature is simply moved into an idiom (multiple idioms!) that all competent javascript programmers must learn. The "smaller" language hasn't saved any complexity -- it does the opposite -- it made JS usage more complex overall. Any language that's used for non-trivial purposes will not be "simple" if looked at holistically by combining both the formal and informal real-world uses of it. However, within that unavoidable complexity, there can be limited subset cases of "simple" for certain scenarios. What does one want a "simple" Javascript language spec for and what can it do? Make the monkey dance?[3] Ok, that's one mapping of "simple" to an end goal and 1995 Javascript specification is probably enough. However, people want to do much more complex apps with Javascript without having to mess around with Typescript, Babel transpiler, etc. To blog writers: please stop characterizing languages as "simple" without any qualifications of use cases. That adjective is no longer convincing on its own. [1]http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691 http://www.amazon.com/Professional-JavaScript-Developers-Nic... [2]http://stackoverflow.com/questions/148901/is-there-a-better-way-to-do-optional-function-parameters-in-javascript http://stackoverflow.com/questions/148901/is-there-a-better-... [3]http://programmers.stackexchange.com/a/221658 http://programmers.stackexchange.com/a/221658

tolmasky 11y ago

The problem with ES6 is that everyone has 2 features they like in it. The only thing that matters in my opinion is generators and (in ES7), async/await. This is a shift we've been seeing in many languages and I think actually tangibly solves a real problem in a transformative way. By that I mean, people will actually think about problems differently. Especially in JavaScript where everything is asynchronous, you need first class support of asynchronocity. There are a bunch of feature I "like" in ES6 but are ultimately useless in my opinion. Arrow functions are great, but could 1) be implemented in a transpolar, and 2) unfortunately behave different with regard to this and thus make the language even harder to understand (why did all my code break when I switched out the arrow function for a normal inline function?). Classes are horrible in my opinion, especially if they start inspiring people to use instanceof, which is a broken feature in Javascript (and hence why we need things like Array.isArray). Due to the fact that in JavaScript you will often have code from different contexts, you can't rely on these checks, and the old-style JS programming encourages you to use feature detection, whereas now you will think you can do something like this. The species properties (so map returns the right thing when you subclass Array for example), is even more complex. The fact that I can subclass Function is a bit absurd. The fact that subclassing Object, vs subclassing null, vs no subclass will be a lot of fun to understand. Let scope is fine I guess, I honestly never thought this was a big deal (coming from C and having to make the switch). It was of course implemented with TDZ which makes it incredibly hard to write in a transpiler, so now you have situations where the transpired code will work but once real let is added your code will break.

mkozlows 11y ago
async/await is one of those very C++-ish features, though, due to how it's implemented. Understanding ES5 async callbacks requires very little conceptual understanding -- you need to understand run-to-completion and the event loop (and I guess the idea of higher-order functions), but otherwise it's straightforward. Understanding ES2016 async/await keywords require you to understand all of that, plus ES2015 promises, ES2015 generators, and how they're all orchestrated together to implement async/await. The code looks simpler, but understanding what's really happening is a lot harder.
- 11y ago

azakai 11y ago

> Too high-level, too JavaScript-centric. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, which seems quite wrong. 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 silly. An AST is used because it allows significantly smaller download sizes, which is quite important on the web, more details here: https://github.com/WebAssembly/design/blob/master/AstSemantics.md https://github.com/WebAssembly/design/blob/master/AstSemanti... WebAssembly is in a different situation than gcc, clang, etc. It makes sense for LLVM IR, for example, to have a CFG, as it is a compiler IR meant for optimization. But WebAssembly binaries are meant to be distributed over the web and instantiated as quickly as possible. > This decision was clearly made to try and simplify the job of WebAssembly VM implementers, at the expense of everyone else. I don't think that is the reason at all. In fact it adds work for those people to handle an AST. But the work is justified by the startup speed benefits that it brings to the web platform.

pcwalton 11y ago
I think Luke Wagner put it best. Paraphrased, "an encoded AST is just a bytecode for a register VM with a compressed encoding form for 'the last register I mentioned'". Besides, converting a CFG to a high-level AST is a complete non-problem these days.
- chas 11y ago
  What resources are there on the state of the art algorithm-wise for doing that conversion?
  - azakai 11y ago
    One option is the relooper [1][2] which is used in emscripten. It recreates high-level control structures as best it can, then falls back to a helper variable when it can't. Another option is node-splitting, where irreducible control flow is solved by duplicating code (but that has a bad worst-case code size increase). [1] http://dl.acm.org/citation.cfm?doid=2048147.2048224 http://dl.acm.org/citation.cfm?doid=2048147.2048224 [2] https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.h https://github.com/kripken/emscripten-fastcomp/blob/master/l...

mrec 11y ago

I don't quite get why the author thinks that wasm will make asm.js irrelevant. As I understand it, what wasm brings to the table is mostly a binary representation of asm.js, with the concomitant size advantages. If they're two different ways of encoding the same thing then I'd expect most toolchain and optimization work for one to benefit the other, and asm.js will continue to benefit older browsers for a while. What made asm.js a breakthrough was that vendors couldn't kill it by ignoring it - it's just Javascript, so it doesn't need explicit support to run, so ignoring it just hurts you in competitive perf benchmarks. Wasm IMHO is a smaller step forward, but I think the mapping is direct enough that a polyfill lib can handle deserializing wasm to asm.js - not ideal, but at that point it's unkillable again. Very different from {P}NaCl, which was very successfully killed by everyone except Chrome ignoring it. DISCLAIMER: I've read about these techs but haven't had a chance to use them in anger yet; apply pinches of salt to taste.

SpaceCadetJones 11y ago
If you look at the WebAssembly github they have a pretty detailed roadmap/plan of what they would like to accomplish. In the beginning it is essentially what you just stated, but after that initial goal is completed they are looking to start diverging from asm.js and begin adding in more features.

rrss1122 11y ago

"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." Hey, how about that, another person who thinks this. And this from someone who read the entire ES5 specification and built a JIT compiler for JS. She gives a good example of the web moving too fast. Already asm.js is obsolete and it didn't even mature enough to be used. It's starting to feel like complexity for complexity's sake. Java and JavaScript both had a chance to win in the early days of the browser wars. JS came out on top, and it was vastly simpler than Java. Now they want to turn JS into Java. Maybe this will be the opening Google's Dart needed to take off.

azakai 11y ago
It does feel fast for asm.js, but WebAssembly is simply much better than it. We did asm.js because there wasn't an option to do something better earlier; now that there is, with all browser vendors eager to collaborate, it seems pointless to delay. Also, this evolution should not be too disruptive. First, asm.js content will continue to work, since it is just JS; it will also continue to be fast (in fact, WebAssembly will polyfill into asm.js in the short term). Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).
- vmorgulis 11y ago
  >Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web). The problem is around the API. I know you do your best to provide a platform similar to native (with fopen(), sockets, SDL...) but I wonder if it is not simpler to do that with a VM (a kind of kernel for emscripten) ? From time to time, I look at qemu source code to find a solution. Originally, Fabrice Bellard did a standalone libqemu but it was removed. There is the SPLICE protocol too for the graphics or even VNC. I'm thinking of a layer that do not rely on the DOM or emscripten JS pragmas. Thus we could have a world of lightweight linux/bsd distros for the web. PS: I've seen your work on musl and signals.

JustSomeNobody 11y ago

On the one hand: Who cares!? You don't have to use every feature of a language. On the other hand: What do you expect when something is designed by committee? Everyone wants to add their own special sauce to the mix.

VLM 11y ago
Unfortunately you have to know every feature to read or troubleshoot. Someone claiming to never be mystified by an obscure incantation of c++ either is lying or hasn't looked very much. I suppose something had to be invented to make bad perl look crystal clear. Insert bad joke here about not needing a contest to have a obfuscated c++ competition.

rpedela 11y ago

Yeah it is becoming a bit bloated. Honestly I think all they had to do was add import/require and support 64 bit integers and numerics and the language would have been good enough.

outworlder 11y ago

> 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. This, one hundred times. The current excuse for JS's surprising behavior is legacy and the fact that it was built in ten days or something. Now that we are not in such a hurry, could we please fix the thing? It's not like new ES6 code is backwards compatible anyway. I'd argue that we don't need many of those features. Lua is tiny, has a tiny interpreter, has a fast compiler (LuaJIT) and has been resisting new language additions and doing fine anywhere it's deployed. It helps that it has a nice design from the start. But it doesn't have brackets and semicolons. People just love those, it seems.

LukeB_UK 11y ago
JavaScript can't fix the legacy issues because of backwards compatibility. Not in terms of making ES2015 code work on old browsers, but making old code work on new browsers.
- acdha 11y ago
  I agree with the first sentence but the last part seems incomplete. Were you thinking of the difficulties bridging old and new code running in the same app? I like the idea of an opt-in "use modern" to avoid breaking old code but that would get tedious if you needed to call between old and new code in the same app.
- 1ris 11y ago
  JavaScript even has "int" and such as reserved keyword. A hole lot of stuff could be fixed using them without breaking any compability.
- outworlder 11y ago
  Can't we run old code with the old semantics unless otherwise specified? We already have stuff that changes semantics, notably strict mode.

nly 11y ago

C++ isn't terribly large. The current language, i.e. the standard excluding the standard library, is about ~700 pages. Smaller than Java. The standard library, as of C++14, is also tiny (but growing rapidly) Imho, the perception of C++ as a large language comes principally from the high combinatorial complexity of its feature-set. It is very much a toolbox language. C++ advocates have only just recently started preaching a collective 'Pythonic' or 'Rubyist' way ("modern C++"). It is, however, still very much a broad church, with less philosophical baggage than many other languages. Strong and differing opinions on the committee seem to keep a single dictatorial programming style from emerging. Tbh, I don't know what the author is worried about. Does Javascript have an overriding mindset/philosophy that is being eroded? Is that the concern? Other concerns about implementations not keeping up don't seem well-founded.

wuch 11y ago
If I were to compare complexity C++ and Java, I would say that the former is much more complex and intricate than latter. Complexity of both of course keeps increasing. But, that does not necessarily mean that programming in any of them is getting more complicated. Argument is often made, for example by Stroustrup himself, that while language is getting more complicated, using it is getting easier and more intuitive. This argument seems to have some merit. Going back to C++ / Java comparison, lets have a look at some objective and subjective metrics. I am analyzing "The Java Language Specification - Java SE 8 Edition" and "Working Draft, Standard for Programming Language C++ N4527", in case someone would like to repeat this exercise. The Java specification has 780 pages, C++ standard has 1367 pages. Of course there are quite a few objections to be made about this comparison. First, if you open both standards side by side it is quite clear that typesetting and margins are quite different. Java has wider margins and a bigger font. So as a next step lets have a look at number of words. I converted both PDFs to text using pdftotext and counted number of words using 'wc -w'. This gives 227958 words for Java specification, and 477719 words for C++ standard. But that is still hardly fair. C++ standard contains description of standard library, Java specification in general does not (partially it does specify Object, Class, Thread, and some of exceptions, but lets ignore this issue). How many pages of C++ standard constitute description of standard library? I would say that all from "17. Library Introduction" up to "30. Thread support library", additionally including "Index of library names". Those constitute 777 pages, leaving only 590 for description of C++ language itself. That would be less than Java specification, but if we go back to word metric, this gives us 249186 words for C++ standard, a little bit more than Java, but not much. From more subjective perspective, I would say that Java specification is written using much simpler language, but that does mean that it is less precise. Moreover it seems to me that Java specification contains more non-normative text than C++ standard does. I would also say that reading Java standard from front to back doesn't seem to be very challenging (with small exceptions like overloading, which seems to be one of most complex parts of Java). And when I write 'reading', what I am really mean is reading and understanding. On the other hand I would never said similar thing about C++ standard. Understanding C++ just by reading standard seems almost impossible, as most of commentary and useful discussion is contained elsewhere: in proposals and defect reports.

coldtea 11y ago

>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. Citation needed. Python is a popular first / teaching language and it has as many (and probably much more in 3.5) features as JS. And Scheme is supposedly simple, but not that popular with any large amounts of people, beginners included. There are features that interact in mysterious ways and can be difficult to master (C++ has a lot), and features that are mostly orthogonal (e.g. template strings don't complicate anything related to arrow functions and vice versa). What I'd like to see, with regards to Javascript, is for "strict mode" to extend to the correction of old, long standing warts (e.g. crazy coercion rules etc). But I guess with this new shared "bytecode" for the web announced, we probably wont have this problem for long.

twerquie 11y ago
The author has clearly framed these as personal opinions, which as we all know, everyone is entitled to.
- coldtea 11y ago
  Not in technical disussions: in these you only get to have arguments. Or rather, you can still have "personal opinions" but without arguments backing them are of no use to anybody and you might as well not state them.
  - twerquie 11y ago
    You know, it's possible to have a conversation without having an argument. It is possible to listen to others. Not everything in life, or indeed on Hacker News, is a debate to be won. Sometimes we're just sharing our human experience.
doktrin 11y ago
> I think that smaller languages have the potential to be easier to implement > Citation needed Uh huh.
11y ago

1ris 11y ago

I once listed to a talk about a "new" JS (don't know witch one. I guess it never was adopted) It started with explaing all the ugly part of the DOM: Variables that are constant, variable that are more like setters, variables that don't show up in a for(x in y) loop. I was very exited. Are they goning to fix all this ugliness? Tidy up that crap? NO! They said: "We want to be able to implement the DOM in JS. That's why we are going to add all this crap into JS". I have no idea from what perspective this makes sense. It's not just that I think it's a bad idea, I have no clue how anybody else could come to the conclusion it was a good idea. This was a way worse than C++. But I think in the end it didn't happen.

w8rbt 11y ago

Since C++ was malinged by the author, I thought this quote relevant. "There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup Source - http://www.stroustrup.com/bs_faq.html#really-say-that http://www.stroustrup.com/bs_faq.html#really-say-that

notNow 11y ago

* If JavaScript is really “the assembly language of the web”, then why does it need all these high-level features?* Someone should introduce this dude to the novel concepts of "figures of speech" and "metaphors" as he's completely clueless losing the plot.

nathansobo 11y ago

I'm happy about the changes that are being made to JavaScript. For new code, stick to a modern subset of the language and enforce it with a linter. It's not ideal, but I'd rather live in a world where ES6 and ES7 features exist than one in which they don't.

fffrad 11y ago

ASM or WASM, I expect a future where both of them are included in the head of the document by two different developer and I have no choice but to maintain them.

adamzubi 11y ago

http://googler700.blogspot.com/ http://googler700.blogspot.com/

CmonDev 11y ago

"Mozilla and Google are already working on WebAssembly" She picked her favourite companies, I guess :). The reality: "The team working on WebAssembly includes people from Mozilla, Google, Microsoft, and Apple" https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly

tempodox 11y ago

I'm afraid I have to concur with the article's title and most of its contents. Instead of letting developers code in a sensible language and simply making JS a better compiler target, the language was bloated with cruft to support manually writing it. For a notoriously overburdened language like JS this is definitely the wrong direction. Like with C++, you now have to judiciously choose which features of the behemoth to abuse and woe betide you if you choose unwisely. Don't touch JS with a ten-foot pole, let a compiler do this dirty work for you.