Why We Won’t Be Writing JavaScript in Five Years

Why We Won’t Be Writing JavaScript in Five Years(medium.com)

12 points by Gxorgxo 9 years ago | 18 comments

wppick 9 years ago |

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 9 years ago | |

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

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

jack9 9 years ago |

> 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 9 years ago | |

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.

jomamaxx 9 years ago | |

It's pretty rational to say that JS will have a 'hard time catching up' - all you have to do is look at the upcoming specs and see where it will be 'in theory' in a few years, and it's still far behind other languages.

FrancoDiaz 9 years ago |

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.

bobajeff 9 years ago | |

Yep, from a developers perspective there is very little difference between asm.js and WebAssembly.

The main differences for developers will be the download size for compiled code will be smaller and the startup time will be faster.

Outside of those differences all browsers will consistently optimize for it. At least one upstream compiler backbend (clang/llvm) will support it. So you'll get more tooling from outside of the few folks working on emscripten and you'll more likely see support from language frontends like Swift and Rust.

Gxorgxo 9 years ago | |

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 9 years ago | | |

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.

gsnedders 9 years ago | | |

WebAssembly is still run in the JS engine, though. And especially if we start adding GC support to it, that's not going to change.

jomamaxx 9 years ago |

Uhmm, yes, Javascript has limitations.

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

open_dave 9 years ago |

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.

Vendan 9 years ago | |

I've basically just been waiting for it to happen for years. We already have so many languages that range from "javascript + some" to completely different languages that all compile down to JS, and it hasn't killed the community yet. Worrying about "where will a newcomer start?" is about as pointless as worrying about where a new programmer will start. I mean, I already have the choice of countless languages for the desktop, getting that exact same freedom on the web seems like a great idea!

Gxorgxo 9 years ago | |

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 9 years ago | | |

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.

leepowers 9 years ago |

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.