
What Does “One JS” Mean in a World of Transpilers? - jashkenas
http://tc39.github.io/tc39-notes/2018-03_mar-21.html#12iiib-what-does-1js-mean-in-a-world-of-transpilers
======
dflat
The ECMAScript stage 3 proposals related to decorators and class private and
static fields need a lot more time to bake - maybe a few years. The whole # or
-> thing seems fundamentally wrong. The standards process needs to slow down
until better ideas emerge from the JS community and the Babel ecosystem.

I do like the idea presented of having a transpiler track and a JS engine
track. Keep the ES spec for the JS engines simpler and hoist all the
syntactical sugar onto the transpilers.

~~~
BinaryIdiot
> I do like the idea presented of having a transpiler track and a JS engine
> track. Keep the ES spec for the JS engines simpler and hoist all the
> syntactical sugar onto the transpilers.

Alternatively, if you focus on getting web assembly up to speed, you can
compile any flavor of JavaScript you want directly to web assembly. You
wouldn't need transpilers at all except for backward compatibility (which
would eventually fade).

At least that's the future I'd like to see.

~~~
RussianCow
Everyone keeps saying this, but it doesn't make sense to compile JavaScript to
WebAssembly. Even if WASM had enough built-in APIs to allow you to implement
JS without also implementing its runtime, you would lose all of the JIT
performance optimizations. There is literally no benefit, aside from being
able to implement non-backwards-compatible features (which doesn't feel like a
strong reason to me, given the cost).

~~~
BinaryIdiot
> you would lose all of the JIT performance optimizations

I don't follow. Why would losing optimizations from one language prevent
optimizations from being done in an IL? Are you saying that Web Assembly can't
be as fast as JavaScript? If so, why?

> There is literally no benefit, aside from being able to implement non-
> backwards-compatible features

You ignored the benefit I outlined above. Why would you want a single
scripting language to be the only one to ever be used in a web browser? Heck,
web assembly can even make the ECMAScript iteration loop tighter if you really
wanted to.

I'm having trouble seeing the downsides to this approach.

~~~
RussianCow
Years of development have gone into making JavaScript in the browser really,
really fast. If you re-implement a JS engine on top of WASM, you lose all of
that work—unless you do something crazy like compile V8 into WASM, but then
the client is going to have to download an enormous payload just to run your
app.

Even if WASM had APIs for GC, interaction with the DOM and browser APIs,
interop with JS, etc, you would still have to compile the JS ahead of time
into a static binary, and so the browser would not be able to apply its JIT
magic to your code.

I'm all for the dream of running any arbitrary language in the browser, but
it's simply not realistic for any language that has a large runtime, which is
most dynamic languages.

~~~
pjmlp
Google just discussed WebAssembly 2.0 at IO, those APIs are coming.

They also unveiled Autocad running on WebAssembly.

~~~
Jasper_
I haven't seen any work from any browser implementers working towards host-
bindings _or_ GC. I just skimmed through the I/O talk, as well: AutoCAD was
running in a 2D canvas through emscripten in a WebWorker, while the rest of
the code was a custom-built React/TypeScript app. Hardly the desktop AutoCAD
everyone is thinking of...

... and I didn't spot any mention of "WebAssembly 2.0", whatever that might
mean...

~~~
pjmlp
Then watch it properly, pay attention to the announcement of the upcoming APIs
like direct references to DOM nodes, bypassing JavaScript.

Or how the Autocad guy explains the C++ code is exactly the same as on the
core product.

We might loose the battle against Electron, but in the end the browser will be
just yet another general purpose VM.

------
Animats
Welcome to the future of publishing - automatically generated audio
transcripts of PowerPoint presentations.

~~~
eddyerburgh
They aren't automatically generated. These are the notes taken in the meeting.
There were several note takers that worked over the three days to record the
meeting.

