It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.
Should JavaScript be split into two languages?
11–20 of 324 posts
Re: Should JavaScript be split into two languages?
#12Earlier quoted context omitted.
good point. in a sense webassembly is that minimal very performant language. let javascript and typescript compile to webassembly, and you essentially got what is being proposed here
WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity. But there's still far to go. Large parts of the browser API are still not directly available in WASM. I very much look forward to WASM reaching stability. It's very enjoyable to run Rust code in the browser.
right, making those APIs accessible from WASM is something i am also waiting for.
Re: Should JavaScript be split into two languages?
#13All this championing Javascript as a single language for front and back end work, now to be split for different use cases. Hopefully this is how Javascript dies if that is the route Google pushes it.
There is already too much exhaustion around switching frameworks and paradigms in the JS world, but I guess everyone likes getting jerked around by corpos and evangelists these days.
Re: Should JavaScript be split into two languages?
#14I really don't like it as it is difficult to debug code when the code that runs isn't the code I wrote.
This is mostly a solved problem in regular compilers, and sourcemaps etc do currently exist for JS.
I agree that the tooling/UI around this could be better, but by focusing on this approach, things like Typescript get better as well.
Re: Should JavaScript be split into two languages?
#15JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?
Re: Should JavaScript be split into two languages?
#16I really don't like it as it is difficult to debug code when the code that runs isn't the code I wrote.
With the right debugging tools, transpiled alternatives to JavaScript are easier to debug than vanilla ES5.
For example: TypeScript's sourceMap [1], Elm's time-travelling debugger [2], Vue.js DevTools [3], just to name a few I've tried. Especially well-typed languages tend to behave well at run-time once they pass type-checking. Or rather, I have not made enough front-end code to discover transpiler bugs.
[1]: https://www.typescriptlang.org/tsconfig/#sourceMap [2]: https://elm-lang.org/news/time-travel-made-easy (2014 [3]: https://devtools.vuejs.org/
Re: Should JavaScript be split into two languages?
#17I'd argue that other languages did this (or something similar) to great success, most notably Java.
That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes.
With an interpreted language like JavaScript, the dividing line is a little grayer, because the shippable code isn't bytecode, it's still just text. But it still seems to make sense to me to target a a "core", directly interpretable language, and then let all the syntactic sugar be precompiled down to that (especially since most JS devs have a compilation step now anyway). Heck, we basically already did this with asm.js, the precursor to WebAssembly.
Re: Should JavaScript be split into two languages?
#18Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new language features doesn't make sense, then preprocess them away before executing the scripts. You could even do this for past features that made it into ECMAScript but haven't turned out to be useful, instead of ossifying a specific moment in time's tooling.
Re: Should JavaScript be split into two languages?
#19I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes. W…
It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.
Re: Should JavaScript be split into two languages?
#20All this championing Javascript as a single language for front and back end work, now to be split for different use cases. Hopefully this is how Javascript dies if that is the route Google pushes it. There is already too much exhaustion around switching frameworks and paradigms in the JS world, but I guess everyone likes getting jerked around by corpos and evangelists these days.
We’ve run React for almost a decade now and the only major parts we’ve swapped have been react build with Vite. Angular has been even more stable since the switch to TS. As far as the frontend frameworks themselves changing massively, that’s a different story, but it’s not like C# didn’t go from Windows .Net to Core/Framework to cross platform .Net, and so on for different language frameworks.
On the Backend there are very few issues, outside of FFI only being in unstable for Deno I suppose, but you could frankly be running the same old Express API you did a decade ago and be perfectly fine.
If you’re burnt out on changes and keeping up with things I think the issue is mostly a “you” issue. You don’t have to chase down the latest hypes or fads. In fact I think you almost never should.