Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

Post reply on HN
Print view View original

31–40 of 324 posts

Re: Should JavaScript be split into two languages?

#31

Post by no_wizard »

hn_throwaway_99 wrote: post #26
supriyo-biswas wrote: post #19

Earlier quoted context omitted.

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.

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…

I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns.

Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example.

Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard

Re: Should JavaScript be split into two languages?

#32

Post by mircerlancerous »

Sounds like the presenters are assuming that everyone must be using JS in the same way they are. As someone who prefers to work in VanillaJS, I'm already frustrated by all the language changes being forced upon me. So maybe I agree with them that fewer changes should be made, but for completely different reasons. I'd rather them work on API improvements so that web apps get closer to parity with native apps. All this other talk is pointless while web apps remain second class IMO

Re: Should JavaScript be split into two languages?

#33

Post by jefftk »

habosa wrote: post #30

If this happened then JavaScript would be split into 20+ languages, one for each popular compiler. There would be nothing stopping a tool maker from adding their favorite language features even if no other compiler ever adopted them. That would be a disaster.

Outside of browsers this is already how it works. Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.

Re: Should JavaScript be split into two languages?

#34

Post by peutetre »

fny wrote: post #28
peutetre wrote: post #4

Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.

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-studies/google-sheets-wasmgc

Amazon has been migrating its Prime Video app from JavaScript to WebAssembly. They're compiling Rust to WebAssembly and they've seen increased performance and lower memory usage:

https://www.amazon.science/blog/how-prime-video-updates-its-...

Re: Should JavaScript be split into two languages?

#35

Post by LatticeAnimal »

habosa wrote: post #30

If this happened then JavaScript would be split into 20+ languages, one for each popular compiler. There would be nothing stopping a tool maker from adding their favorite language features even if no other compiler ever adopted them. That would be a disaster.

In many ways this has already started happening. TS has enums, Svelte has runes, React has jsx. None of these features exist in JS, they are all compile-time syntax sugar.

While it is admittedly confusing to have all these different flavors of JS, I don’t think this proposal is actually as radical as it seems.

Re: Should JavaScript be split into two languages?

#36

Post by sshine »

kmeisthax wrote: post #18

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.

> features to be implemented as a desugaring step in the runtime itself

The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.

Re: Should JavaScript be split into two languages?

#37

Post by ttoinou »

ninetyninenine wrote: post #9

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

You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.

Re: Should JavaScript be split into two languages?

#38

Post by croes »

em-bee wrote: post #12
sshine wrote: post #8

Earlier quoted context omitted.

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.

So you want more rights for code that’s harder to read than obfuscated JS?

Re: Should JavaScript be split into two languages?

#39

Post by shermantanktop »

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?

I started with your position (vanilla js 4ever!) and after being dragged into the world of transpilation via typescript/eslint/prettier/webpack/babel/etc I do agree that it’s at least as easy. Not sure about “easier” but my debugging needs are not exotic. The painful part is initially setting up the toolchain.

Re: Should JavaScript be split into two languages?

#40

Post by pjmlp »

hn_throwaway_99 wrote: post #26
supriyo-biswas wrote: post #19

Earlier quoted context omitted.

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.

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.
Post reply on HN