DEV Community

Discussion on: What's the worst part about the JS ecosystem?

Collapse
leob profile image
leob • Edited on

Well the problem (at least the Babel part) would go away once 95% users run browsers that natively support ES6. That way at least we'd know that our end users would really run our shiny ES6 code, instead of grand dad's old fashioned ES5 (the transpiled) version - to me this process always feels a bit comical, like we're collectively fooling ourselves. So in a matter of a few years we might at least not need Babel anymore!

But, the funny thing is that Typescript is becoming ever more popular, so we'd still need transpilation. But, what if the TS compiler would be able to do the whole thing - transpilation and bundling (including source maps, minification, and so on), and we wouldn't need Webpack anymore on top of that - now that might be a real step forward in terms of reduction of complexity.

Oh, and what if Web Assembly would take off - that would also be a solution, we'd simply choose our favorite programming language and use that, who needs JS lol.

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author • Edited on

I once complained that an experienced Java developer told me that Js is a disposable language: "any JS engine is a LLVM, I can write in it with whatever language I want". I couldn't understand him at the time, what a junior dev I was...

I'm with you though: I hope for TypeScript to improve its learning curve so that it can become the de facto standard for this field (but this is another story); I can't also wait for WebAssembly to become widespread enough in order to rewrite everything in Rust 😈

Thread Thread
leob profile image
leob

Exactly ... Web Assembly and Rust FTW ! and then TS as an intermediary thing or a stepping stone.

JS is just weird in that you're writing shiny new and slick ES6 or ES7, and then what gets actually run is often mundane old ES5 lol.

Thread Thread
fearphage profile image
Phred Lane

To be fair you're writing Rust, but what actually gets run is often mundane old assembly. It's all just layers of abstraction.

Thread Thread
leob profile image
leob • Edited on

Yes but the difference is that ASM is fast, that's why we're compiling Rust (or C++ or whatever) down to ASM rather than interpreting Rust ... but ES5 isn't faster than ES6 (neither the other way around) - we gain no performance from the transpilation, that's why it always feels a bit more to me like a trick or like we're fooling ourselves a bit, just so that we're can get that warm fuzzy feeling by being able to write "let" or "const" instead of "var" (okay, I'm being cynical here). In other words, if I'm brutally honest it's more about programmer convenience than about performance (unless ES6 can be executed natively by the browser's JS engine).

Thread Thread
peerreynders profile image
peerreynders

Well the problem (at least the Babel part) would go away once 95% users run browsers that natively support ES6.

Even these days public serving web sites should be practicing differential serving:

That way most browsers will be served a ES2017 bundle while legacy browsers have to deal with the larger ES5 bundle with its polyfills.

The root of the problem is that the web isn't a universal, monolithic platform but an infinite continuum of platforms. That is likely not going to change.

Oh, and what if Web Assembly would take off - that would also be a solution, we'd simply choose our favorite programming language and use that, who needs JS lol.

I wouldn't hold my breath.

WebAssembly:

It is also designed to run alongside JavaScript, allowing both to work together.

And languages that require separate multi-megabyte run times aren't going to succeed outside of niche applications - JavaScript doesn't have to ship a separate runtime and Web APIs are all designed with JavaScript in mind. So really C/C++, Rust and perhaps AssemblyScript are the only real contenders for solutions with a broader market but I'd expect "productivity" to take a serious hit.

Given the Mobile Performance Inequality Gap, 2021 a JavaScript payload can be more effective in most cases - as long as it doesn't drag half of npm with it.

Thread Thread
michaelcurrin profile image
Michael Currin • Edited on

@leob code in ES5 will be slower than ES6 because it is more code to execute. I came across this. So to support 1% or 5% or whatever of legacy browsers you make speed and file size worse for everyone

Thread Thread
leob profile image
leob

Interesting!

Thread Thread
michaelcurrin profile image
Michael Currin

Sorry corrected my typo. ES5 slower than, not in.

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

@peerreynders your comment is gold 🦄