Add structs/value types, pattern matching and we can freeze the language until end of days.
Should JavaScript be split into two languages?
111–120 of 324 posts
Re: Should JavaScript be split into two languages?
#112Split it into a thousand pieces and send each to separate, distant stars. Put three in a Phantom Zone.
Re: Should JavaScript be split into two languages?
#113Earlier quoted context omitted.
Assembly is not a language runtime. Even if you had WebAssembly as the core, you'd still need to compile JavaScript to WebAssembly, manage the GC, etc which all would still suffer from the performance implications mentioned in the article. Also... do you really think its wise to rewrite v8 to target WebAssembly?
It already supports WebAssembly. All browsers do. Here's a demo of Dart and Flutter compiled to WebAssembly: https://flutterweb-wasm.web.app/ WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript? Google has started migrating parts of Google Sheets to WebAssembly. They're compiling Java to WebAssembly and seeing a 100% performance increase: https://web.dev/case-s…
[flagged]
Re: Should JavaScript be split into two languages?
#114Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
Yes and no, there is a significant bundle size problem with wasm which is hard to fix. I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications. What's more likely is that all of this will probably be eclipsed by LLM and virtual assistants - which could be controlled by native apps with a dynamically generated GUI or voice. I think APIs exposing…
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications.
Cool stuff, let's kill web for good.
Re: Should JavaScript be split into two languages?
#115No. Javascript should be split into 3 languages and html and css should be split into 20 languages. Seriously frontend is already the most fragmented and fast changing area of web there is. Don’t split the language.
> and fast changing area Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.
> Who cares?
I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.
Re: Should JavaScript be split into two languages?
#116I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't understand why it needed to be reinvented from scratch and why it needs to be so limited. We could already be writing web code in Rust, Java, C#, Python, and heck even Haskell, if we had just done that. I know that I'm skipping over the engineering effort required to make this happen but I get a sense that the engineering effort is not the stumbling block. I want to know the details of what is.
Re: Should JavaScript be split into two languages?
#117Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it. Keep the single threaded event loop approach but kill the JS semantics.
Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages.
I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView.
There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well.
Re: Should JavaScript be split into two languages?
#118I 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.
> sourcemaps etc do currently exist for JS.
Are those being supplied with every website you use?
Re: Should JavaScript be split into two languages?
#119All 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.
> There is already too much exhaustion around switching frameworks and paradigms in the JS world
What's wrong with VanillaJS?
Re: Should JavaScript be split into two languages?
#120Earlier quoted context omitted.
You're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures"…
From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://gi…
Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around.
I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.