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 😈
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).
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.
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.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
@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
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
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 😈
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.
To be fair you're writing Rust, but what actually gets run is often mundane old assembly. It's all just layers of abstraction.
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).
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.
I wouldn't hold my breath.
WebAssembly:
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.
@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
Interesting!
Sorry corrected my typo. ES5 slower than, not in.
@peerreynders your comment is gold 🦄