I don't understand the problem? If v8 wants to split into frontend (sugar, transpiled) and backend language (es5 + few things probably; runtime engine proper), they can just do it, no?
Should JavaScript be split into two languages?
101–110 of 324 posts
Re: Should JavaScript be split into two languages?
#102I'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…
The BEAM VM (Erlang, Elixir) does this with what’s called "Core Erlang", used as lower-level targets before compiling to the BEAM primitives.
https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_e...
Re: Should JavaScript be split into two languages?
#103Earlier quoted context omitted.
Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo
Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.
What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
Re: Should JavaScript be split into two languages?
#104It'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.
WASM is slower than running JavaScript on V8 in almost all scenarios and will likely continue to be for a very long time. Also, many of us don’t want a compile step.
That is a misconception; there is a cost of abstraction, although this cost may disappear if AI gets really smart.
Re: Should JavaScript be split into two languages?
#105Earlier quoted context omitted.
What's old is new again :) 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 goo…
asm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.
PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
Re: Should JavaScript be split into two languages?
#106Better 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.
Go back to garbage "cross platform" UI toolkits and having to help users manage software dependencies on their machine? No thanks.
Re: Should JavaScript be split into two languages?
#107I'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…
> because the shippable code isn't bytecode,
But what if it was?
What I would like to see is:
- a bytecode "language" that roughly corresponds to Javascript semantics, and that is what the engines interpret (and JIT compile)
- browsers still include a compiler to compile JS sourcecode to the bytecode. Possibly wasm could work, although it would need a lot more functionality, like native support for GC, and DOM access, etc.
- browsers include a disassmbler/decompiler to improve debugging the bytecode
Then simple sites, and development can use plain JS source, but for higher performance you can just deploy the pre-compiled bytecode.
Re: Should JavaScript be split into two languages?
#108No. 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.
Re: Should JavaScript be split into two languages?
#109Earlier quoted context omitted.
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower
Re: Should JavaScript be split into two languages?
#110> The tooling idea is particularly appropriate for JavaScript since many developers actually code in TypeScript and rely on compilers such as Babel, Webpack or the TypeScript compiler to output JavaScript.
Hot take