
JavaScript is the C++ of the Web - jsnell
http://pointersgonewild.com/2015/08/02/javascript-is-the-c-of-the-web/
======
azakai
> 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/AstSemanti...](https://github.com/WebAssembly/design/blob/master/AstSemantics.md)

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
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
What resources are there on the state of the art algorithm-wise for doing that
conversion?

~~~
azakai
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/l...](https://github.com/kripken/emscripten-
fastcomp/blob/master/lib/Target/JSBackend/Relooper.h)

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

~~~
tracker1
True enough... I've been using async/await for about 6-8 months now via
babeljs, and tbh trying to explain it to people so they understand how it
really works is a bit painful... a lot of people don't understand that an
async function is simply a promise wrapper around a generator yeilding
promise-friendly values.

It's kind of important to understand promises to use await/async affectively.
I love the easier to read/follow code though.

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

~~~
andrepd
>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?

~~~
ludamad
Sometimes intrusive linked lists are more efficient and require less cleanup

~~~
nly
With an intrusive linked list you pay the memory cost of having node pointers
all the time. If you're you're going to do that, then you may as well keep all
your nodes in a list all the time, and use splice() to move them around. There
are practically no performance advantages to using intrusive linked-lists in
this case.

~~~
comex
There is a usability advantage, though: with a STL list, you need an iterator
corresponding to an element to move it between lists, not just a pointer to
the value. So all functions taking a reference to an object, if they might
want to move it around at some point, need to take an iterator, and in
particular, object methods cannot do so, unless the class contains a wasteful
iterator-to-self field.

Intrusive lists also allow an object to be in multiple lists at the same time
(usually ones with different purposes) by having multiple sets of prev/next
pointers.

~~~
nly
Boost multi_index solves both of these problems. To simulate multiple lists
you can simply add more than one sequenced index to the container type. The
sequenced index interface provides an iterator_to() method which takes a
reference and returns an iterator, and the container interface allows you to
project one index to another. It's incredibly powerful.

[http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/re...](http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/reference/seq_indices.html)

As a bonus the ownership semantics are clear and memory management remains
trivial. Intrusive lists are useful, i'll grant you, but they'll always be a
last resort for me. Especially if you're implementing them yourself.

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

------
aaron-lebo
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.

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

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

~~~
camgunz
Are you serious? Even if we stipulate that Java is as big or bigger (I don't
think anyone would say Java is more complex), what other mainstream language
is as large or as complex as C++?

~~~
nly
I said it wasn't large, not that it wasn't complex ;)

------
rrss1122
"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
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
>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.

~~~
azakai
Not sure I understand the problem - what is the issue with APIs?

WebAssembly will have the same API access as asm.js, both can call into JS
(and JS can then access any web API).

~~~
vmorgulis
API are OK but they are tedious to implement. You have to discover the good
way to manage each subsystem.

I think of something more low level for a VM that could run inside a web
worker (or in the main thread).

It's visible interface could be (with ArrayBuffer):

\- an address space for a virtual framebuffer

\- an address space for a virtual disk

\- i/o with ports for sockets, mouse, keyboard ...

With that, we could use existing OS. There is too much case to implement all
the existing API and each case can be complicated and have implicit
assumptions.

For example, instead of mapping fopen() paths to localStorage or URLs in XHR,
we could implement an existing hadware API for disk storage.

Instead of implementing SDL, implement a VGA memory.

I think it is more reliable to use on the lowest interface and you can reuse
all the stack (from the kernel, to GNOME and Firefox, all inside the browser).

The rules of mapping what to what will be defined outside the VM. The browser
could be in charge of these rules.

The rules are:

\- save this address space to localStorage (or IndexDB)

\- send this address space in XHR (or websocket)

\- put this address space to this canvas (with putImageData())

I had this idea after reading a spec of a VM for a Forth:

[http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-...](http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-o-
ports)

I'm not criticizing your work nor emscripten at all. I'm a big fan :-)

It's more about making the things simpler, get rid of the complexity, increase
the features and liberate everybody of the burden of mapping native API to Web
API. It's like Cygwin vs qemu/kvm.

I'd like to help emscripten and I see that.

~~~
azakai
Making a new set of APIs like that would need to be done very carefully, to
keep the web consistent and also to make sure it is sandboxed properly and so
forth.

In general the web is actually going in that direction, for example WebGL is
similar to low-level OpenGL. But obviously in many other APIs, that is not the
case.

There are proposals for various new APIs, like for file storage, but they are
each being debated separately. I don't think WebAssembly is going to change
anything in that regard - we can propose new APIs for it, but the proposals
will go through the usual processes.

~~~
vmorgulis
The solution is somewhere in the qemu or kvm world but qemu deals with real
hardware. I'm looking for something simpler than a real machine.

Ideally, qemu could run a virtual cpu just made for asm.js or wasm. The
virtual hardware is accessed thru the Module functions. We could have a peek()
and a poke() like in the old days to read the ports :-)

I remember your first posts about emscripten and the first script in Python.
The gap to fill is similar to "write a backend for LLVM" as you did (not
enough, of course).

There is also the x86 emulator from copy.sh
([http://copy.sh/v86/](http://copy.sh/v86/)).

The general direction is "support blobs in the browser".

About implementing new Web API, I think the process is not so slow but it
relies on non-technical things (like strategy for the companies) so low level
would speed up that.

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

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

------
jasode
_> 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-
Nic...](http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-
Zakas/dp/1118026691)

[2][http://stackoverflow.com/questions/148901/is-there-a-
better-...](http://stackoverflow.com/questions/148901/is-there-a-better-way-
to-do-optional-function-parameters-in-javascript)

[3][http://programmers.stackexchange.com/a/221658](http://programmers.stackexchange.com/a/221658)

~~~
chrisseaton
> What does one want a "simple" Javascript language spec for and what can it
> do?

To write proofs? You don't need to worry about the larger idiom of how the
language is used for that.

And to write a _correct_ implementation of a language you don't need anything
except a correct simple spec. To perform well for idiomatic code you may need
to know about idiom.

~~~
qznc
> To perform well for idiomatic code you may need to know about idiom.

To enforce idioms you include them in the language. This makes the language
easier but less simple. It also means people will use exactly one idiom
instead of lots of variants. This improves performance and makes it more
predictable.

To perform well for idiomatic code you must know about idiom and have
consensus about it and teach it to everybody.

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

------
coldtea
> _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.

~~~
volaski
Why does someone need to provide citation for expressing their opinion on
something that's even so obvious as "I think simple things are easy to teach
and understand, etc.". Do you think complex languages are simpler to teach,
debug, optimize, and understand?

~~~
coldtea
> _Do you think complex languages are simpler to teach, debug, optimize, and
> understand?_

Obviously yes, I do think it, and I gave an example.

Or rather, I think that number of language features is not related to how easy
it is to teach, debug, optimize and understand.

Python has tons of features (maybe even more than ES7 for which he laments)
and yet it's an easy to teach and understand language.

And inversely, C is succint and has few features, but it's complex to teach
and debug.

One key insight it: a language might be big, but you don't need to use all of
its features (or even teach them all).

You can start someone with basic Python, for example, without delving into
async or metaclasses and he can still do tons of stuff. Contrast with the
"simpler" and much smaller C, in which he needs to understand pointers (a
tricky subject) in order to even use the standard library.

A second insight is: a language might be big, but its features could be
orthogonal and easy to understand in isolation, not the "features subtly
affecting each other" mess C++ is.

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

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

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

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

------
CmonDev
_" 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)

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

------
1ris
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.

------
phlandis
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
'he' is a she.

~~~
delinka
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?

~~~
VLM
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"

~~~
psygnisfive
I wonder if this is a reanalysis of initial clipping. English lets you do some
pretty aggressive deletion of initial segments of an utterance, and in many
many cases that ends up being just a pronoun.. hmm

------
notNow
* 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.

