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

41–50 of 324 posts

Re: Should JavaScript be split into two languages?

#41

Post by no_wizard »

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 huge miss.

Honestly it should have been roadmapped to replace the built in Number type

Re: Should JavaScript be split into two languages?

#43

Post by TheRealPomax »

"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 to backtrack on existing features" makes very little sense. If you're going to split something into core and "compiles down to core", then a LOT of features can be moved out of core because they're just (definitely worth keeping, but not necessary in core if that split were made) convenience APIs.

Re: Should JavaScript be split into two languages?

#45

Post by tredre3 »

sshine wrote: post #16
silvestrov wrote: post #7

I really don't like it as it is difficult to debug code when the code that runs isn't the code I wrote.

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

> transpiled alternatives to JavaScript are easier to debug than vanilla ES5

As easy, certainly. But how are they easier?

Re: Should JavaScript be split into two languages?

#46

Post by dimal »

I think I understand the argument but this sounds like it would make things worse. The argument that new features almost always make the language worse doesn’t hold true from my perspective as a developer. (I could imagine the perspective of a language implementor being very different.)

I like that JavaScript now has modules/imports, destructuring, Proxies, async/await, etc. These were all new features at one point, But yeah, why did Symbol.species get in? Seems like it’s to enable some odd subclassing pattern? I’m an anti-OOP zealot, so my hot take would be that maybe OOP subclassing is unnecessarily complex already, so stuff like that shouldn’t make it in. We got the OOP syntactic sugar, which is enough. Stop there.

How much of the extra complexity is from stuff like that that is rarely used? Maybe we just need to be a lot more conservative about what makes it in, but stopping changes and forcing everything into more tooling complexity is not the direction I’d like to go in. We need to reduce tooling, not increase it.

Re: Should JavaScript be split into two languages?

#47

Post by no_wizard »

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

I'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…

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

Re: Should JavaScript be split into two languages?

#49

Post by nephy »

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.

Re: Should JavaScript be split into two languages?

#50

Post by zb3 »

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.

While I don't want any compile step either (js should stay), I'm actually confused by your statement.. are there any benchmarks? Are you saying that for example v86 would run faster without wasm?
Post reply on HN