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

71–80 of 324 posts

Re: Should JavaScript be split into two languages?

#71

Post by xscott »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

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.

Re: Should JavaScript be split into two languages?

#72

Post by Kwpolska »

xscott wrote: post #71
Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

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.

The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.

Re: Should JavaScript be split into two languages?

#73

Post by PeterWhittaker »

TheRealPomax wrote: post #43

"ECMA TC39", not "Emca TC39". Also, looks like a bad markup link for TC39. Also note that it's either "co-authored by Mozilla, Apple, Moddable and Sony" or "authored by Guo along with others from Mozilla, Apple, Moddable and Sony", but directly related to that statement, that makes this "not a Google proposal" but clearly an "industry proposal" if it has Mozilla and Apple buy-in. Also, "the proposed solution is not t…

> ECMA not Ecma

Incorrect: https://ecma-international.org/about-ecma/history/

Re: Should JavaScript be split into two languages?

#74

Post by singularity2001 »

no_wizard wrote: post #47
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.

They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to. I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs

   >>  WASM isn’t the silver bullet everyone seems to cling to.
And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.

Re: Should JavaScript be split into two languages?

#75

Post by em-bee »

xscott wrote: post #69
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.

What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.

direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical

Re: Should JavaScript be split into two languages?

#76

Post by jokethrowaway »

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.

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 data and executing functions will fundamentally change what we think the web is.

Re: Should JavaScript be split into two languages?

#77

Post by singularity2001 »

peutetre wrote: post #54
rafaelmn wrote: post #27

Earlier quoted context omitted.

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.

Garbage collection is solved to the extent that host garbage collection is now available via WasmGC: https://developer.chrome.com/blog/wasmgc/ https://v8.dev/blog/wasm-gc-porting But languages like C# want more features in WasmGC: https://github.com/dotnet/runtime/issues/94420 No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.

The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.

Re: Should JavaScript be split into two languages?

#78

Post by bitwarrior »

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 didn't read the article.

Re: Should JavaScript be split into two languages?

#79

Post by em-bee »

xscott wrote: post #71
Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

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.

Re: Should JavaScript be split into two languages?

#80

Post by singularity2001 »

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.

This is a very good at important point:

JS0 should be a subset of current JS

JS1 should be current JS

JsSugar should be current JS plus future features

Post reply on HN