21–30 of 324 posts
Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
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
I 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:…
So if I agree with GP then I just haven't found the right tooling yet?
Wouldn'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.
JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?
I'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.
asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do.
This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.
Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
Keep the single threaded event loop approach but kill the JS semantics.
Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
Also... do you really think its wise to rewrite v8 to target WebAssembly?
Wouldn'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.
I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits.
But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.