Should JavaScript be split into two languages?

Post by righthand » Sat, Oct 26, 2024, 5:00 PM UTC

devjab wrote: post #20

righthand wrote: post #13

All 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 ar…

Post by peutetre » Sat, Oct 26, 2024, 5:05 PM UTC

nephy wrote: post #49

jas39 wrote: post #11

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.

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.

Post by sshine » Sat, Oct 26, 2024, 5:15 PM UTC

normie3000 wrote: post #22

sshine wrote: post #16

Earlier quoted context omitted.

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:…

> With the right debugging tools, transpiled alternatives to JavaScript are easier to debug than vanilla ES5. So if I agree with GP then I just haven't found the right tooling yet?

Post by no_wizard » Sat, Oct 26, 2024, 5:27 PM UTC

ossobuco wrote: post #57

no_wizard wrote: post #41

One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole. BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions. They also have zero JSON support out of the box which is a…

Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.

Post by xscott » Sat, Oct 26, 2024, 5:53 PM UTC

sshine wrote: post #8

em-bee wrote: post #5

Earlier 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.