
Why We Won’t Be Writing JavaScript in Five Years - Gxorgxo
https://medium.com/thoughts-from-travelperk/why-we-wont-be-writing-javascript-in-five-years-f48b3274c327
======
wppick
The browser is an extremely well designed platform/environment. Web
applications run on pretty much ever modern device: Windows, Mac, Linux, game
consoles, smartphones. It's an awesome distributed system that allows for
deploying applications from server to client in an efficient way. The barrier
to entry has historically been very low, getting a hello world app running is
incredibly easy. The web has always been extensible -- you can add scripts to
any existing web page if it doesn't quite meet your needs, or to make yourself
more productive. The web has typically been an open platform. You used to be
able to view source and see how someone built something (even by unminifying
the js). Sharing code is very common, just look at how many jQuery plugins
exist. The web community has a culture of evolving and pushing forward even
with issues like fragmentation (Internet Explorer). I'd argue that the type of
developers who are willing to pick up JavaScript given it's issues of not
being typed, having to figure out all the workaround for making up for weird
type conversions, the flexibility of it's language and having to make all of
your data structures out of JSON objects, functions, and utilizing the scope
chain are the reason why the web has been so fruitful and productive. The web
community formed around JavaScript, and I don't think it was successful in
spite of JavaScripts "shortcomings". I think it's shortcomings ended up being
(and causing) very good design.

~~~
jomamaxx
"The browser is an extremely well designed platform/environment. "

Uh, it's an expansive platform, but it is not even remotely 'well designed'.

The 'barrier to entry' is actually getting worse for basic apps. How many
tools must one use? Crazy framworks that keep changing?

'The browser' is the only platform one can develop for these days wherein you
have no idea how your app will function 'in the field'. You use a lot of crazy
product decisions and compatibility tables to 'estimate' for what % of your
audience the app will work.

Behold: the biggest company in the world leaves their browser documentation
_empty_ :

[https://developer.apple.com/reference/webkitjs/2030049-webki...](https://developer.apple.com/reference/webkitjs/2030049-webkit_js_functions)

All of the limitations of JS described in the article are true. That said, I
don't think JS is going anywhere.

------
jack9
> Despite all these efforts, JavaScript still falls behind if compared to
> other programming languages and will have a very hard time catching up.

Wat? This statement is devoid of reason or proof. I hate javascript, but at
least explain that Browser adoption + momentum is why people aren't writing
client code in python yet.

~~~
Gxorgxo
Thanks for you feedback jack9, maybe I haven't made myself clear enough.

I think the reason we aren't writing client code in Python yet is at least
partially explained later in the article. Even if all browser vendors decided
to adopt a new language (say Python) we would still have to support all the
older versions around. That's why WebAssebmly is such a great innovation:
there's one single compilation target and we can write code in any language
suits our needs.

------
FrancoDiaz
I don't see what the difference is between WebAssembly and what we have now.
Now we have transpiling to ES5. Eventually, we'll be "compiling" to
WebAssembly. The only difference is that one target is a bytecode and the
other is a source language.

~~~
Gxorgxo
If you transpile to ES5 you get code that still has to run in the JS engine.
WebAssembly is low-level code that gets executed faster and allows you to
build different kinds of abstractions on top of it. It's comparable to sending
an executable to the browser, it could have been written in any language.

~~~
FrancoDiaz
Uhmm...yeah, I thought I pretty much said that. My point was from the
application developer's perspective, what's the difference? Even now, C++ can
be compiled to JS via EMScripten to asm.js.

I don't write "JavaScript" right now. I write Typescript. Most of the front-
end ecosystems that I deal with (primarily Aurelia and React) aren't being
written in ES5. It's usually ES6/7 and Typescript.

------
jomamaxx
Uhmm, yes, Javascript has limitations.

But to say that we won't be using it 5 years I think is simply wrong.

------
open_dave
I'm not sold that this is a good thing. Opening up the web to many languages
will fracture the community. This is not good for newcomers looking for a
place to start, as the landscape could be too vast.

~~~
Gxorgxo
They way I see it we're already fractured. We have tons of frameworks,
libraries, and tools. And they are not easily interoperable. I know React but
how good is that if I need to start working with Ember?

Backend developers already have many languages to choose from, and the
communities are doing fine.

My only worry will be in the very beginning when dozens of new languages will
compete with each other. In the long run, I think a fistful will survive.

~~~
open_dave
We are fractured with frameworks, etc., but the underlying language (JS) and
patterns are interoperable.

Its true that backend has had this since the dawn of time, but _not_ having
that on the frontend allowed it flourish. I agree though that after a certain
amount of time, only a few languages will live on.

~~~
Gxorgxo
I don't want to be the millionth guy that mocks JS. I appreciate it because it
brought us here. And it certainly helped to have only three languages (HTML,
CSS, JS) in the early days but nowadays there are transpilers for each of
them. The things we use the web for are simply so disparate that can't be
covered by one single set of technologies

------
leepowers
This really hinges on the development of WebAssembly, the timeline to getting
to a stable release version, and adoption by each browser vendor.

For instance, to use my location, my web browser displays a prompt asking if I
want to share my location with a web site. I get to decide if I trust a web
site.

If a website wants to run an arbitrary bytecode on my computer would it also
ask for my permission first? Of course, web browsers interpret arbitrary
JavaScript without asking for permission, so this may be a distinction without
a difference. But how will vendors implement this?

The most likely scenario, I think, is that in any scenario where WebAssembly
is widely adopted it will live side-by-side JavaScript for at least a decade
or longer. Vendors will continue to ship JavaScript interpreters - so there's
no immediate reason to jump from interpreted to bytecode. Most web sites that
use JavaScript don't use that much. Meaning, WebAssembly is an over
complication for a very common type of web site, the informational, landing
page, photo sharing, blog, etc. In fact, if there's just a few AJAX calls or
simple interactions on a site, you'd be an asshole to implement it in
WebAssembly. Programming is about removing complexity. Imposing a bytecode
compiling tool-chain is unneeded.

Also, we have front-end ecosystems, like the large online collection of jQuery
plugins. Want a photo slider? Just drop in the JavaScript include and go. This
may be mitigated by compiling jQuery and existing plugins to WebAssembly. (And
possibly become part of optimizing front-end assets). But if you're going to
use the JavaScript/jQuery ecosystem why would you code just your part in Ruby
or Python or some other language? If you were to do this, you would be an
asshole. If your ecosystem is JavaScript, write your code in JavaScript. The
problem is not the programming language used. The problem is understanding the
context (web browser) and interacting with multiple front-end environments,
across a wide range of network speeds and devices.

That being said, I've worked on several large projects where writing in one
language, compiling to bytecode, and running everywhere would have been
awesome.

Assuming wide-spread adoption WebAssembly will probably have the following use
cases:

1) Large, complex web apps with a heavy front-end footprint.

2) Used as part of the optimization pipeline. Instead of minifying, combining,
and zipping JavaScript, compile to WebAssembly for delivery.

3) Programming tasks/scenarios where JavaScript literally cannot be used due
to the limitations of the language.

