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

171–180 of 324 posts

Re: Should JavaScript be split into two languages?

#171

Post by rixtox »

This is also a result of the detachment of TC39 and the developer community. Just how many JS developers are participating TC39? I can recall multiple TC39 proposals that didn't even consult opinions from authors of notable open-source stakeholder libraries, and went straight into stage 3.

And btw, the TypeScript tooling scene is far from being able to get standardized. TypeScript is basically a Microsoft thing, and we don't see a single non-official TypeScript tool can do type-checking. And there's no plan to port the official tools to a faster language like Rust. And the tsc is not designed for doing tranditional compiler optimizations. The TypeScript team made it clear that the goal of tsc is to only produce idiomatic JavaScript.

Re: Should JavaScript be split into two languages?

#172

Post by hu3 »

xscott wrote: post #145
dmart wrote: post #92

Earlier quoted context omitted.

I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?

Because it's already solved from day one and people keep repeating that it's a problem anyways. Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.

Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too.

This is what StackOverflow tells me (2020):

> Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React.

> JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead.

This feels like "we can have DOM access at home" meme.

Re: Should JavaScript be split into two languages?

#173

Post by ojosilva »

anon7000 wrote: post #141
mircerlancerous wrote: post #32

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…

What do you mean forced upon you? There is no requirement for you to use new features. If you do, it’s because you or your team thinks it’s more convenient — and it really is! map, filter, arrow functions, scope improvements with const/let, etc. are major language improvements. So is null coalescing and optional chaining. You don’t have to use them, but they do make JS more straightforward to work with.

I think "forced upon" could also read as:

- at work they expect me to write code with the latest features

- my colleagues write code with the latest features and I have to review/extend/build upon using the same style

- the community, books, copilots, LLMs, libraries, tooling are "forcing" all that new stuff upon me

- etc.

Re: Should JavaScript be split into two languages?

#175

Post by nitwit005 »

DidYaWipe wrote: post #159
nitwit005 wrote: post #156

Earlier quoted context omitted.

None of them started out with web security in mind. Look at the Java bytecode, and you'll see it features such things as a goto with an arbitrary offset: https://en.m.wikipedia.org/wiki/List_of_Java_bytecode_instru... They had to build a verifier that attempts to ensure the bytecode isn't doing anything bad. That proved to be fairly difficult, and comes at a considerable cost.

But it's not as if security concerns are specific to the Web. Look at the vulnerabilities found in CPUs over the last decade or so. Security is necessary no matter what the delivery medium, so I don't see why this is a rationale for reinventing the wheel.

They genuinely spent years trying to make Java more secure for the web. That was entirely new effort.

Re: Should JavaScript be split into two languages?

#176

Post by sjrd »

davexunit wrote: post #126
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.

Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by import…

> Projects like Hoot (Scheme) and Kotlin port are already demoing such things.

And Scala.js has shipped it. [1] Although technically experimental, it has no known bugs and it has full support of things like manipulating DOM objects from Scala.js-on-Wasm code.

[1] https://www.scala-js.org/news/2024/09/28/announcing-scalajs-...

Re: Should JavaScript be split into two languages?

#178

Post by righthand »

wiseowise wrote: post #151
nenadg wrote: post #148

Earlier quoted context omitted.

> What's wrong with VanillaJS? Absolutely nothing, we all love it, and we also love things built upon that foundation, like TypeScript. But it's optional, and that's a good thing that some people miss to recognize. Therefore, they seek more standardization that 'should be enforced' by your Big Brand's top used product (ie. browser).

My point is that "framework fatigue" is a self-inflicted problem. Nobody forces you to use flavor of the week, VanillaJS and bog standard HTML/CSS are always there for you.

Work in a publicly traded company where people are moving things around for promotions sake. Then you’ll see how forced you are to use the latest flavor of the week. People absolutely do force you.

It’s not just the flavor of the week frameworks, it’s libraries and best practices. Want to work with dates? Do you use moment? Nope that’s deprecated, what do you use? Which moment successor? How do you write react? Classes or functions? You can’t use hooks with classes, so you better update to functions. On and on you run into a decision tree because of the shifting target of javascript. It causes a lot of churn to be migrating and updating to new systems, especially when the new hire can’t help because they don’t understand prototypal inheritance.

Re: Should JavaScript be split into two languages?

#180

Post by Deukhoofd »

dmart wrote: post #92
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.

I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?

They wanted to implement a typing system first so they could transfer complex types with a strict contract first, as large parts of DOM management would benefit enormously from that, and it would be far better to design an API around. This system has been stuck in different iterations for years.

The current active proposal for it is the Component Model: https://component-model.bytecodealliance.org/design/why-comp....

Post reply on HN