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

201–210 of 324 posts

Re: Should JavaScript be split into two languages?

#201

Post by peutetre »

ec109685 wrote: post #152
peutetre wrote: post #85

Earlier quoted context omitted.

> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications Here you go. Do both native and wasm: https://avaloniaui.net/ https://platform.uno/ https://flutter.dev/ Flutter example: https://flutterweb-wasm.web.app/

Not that please. The flutter example took 20 seconds to load and the scroll is super choppy. It’s unfortunate there isn’t a more native “app like” UI toolkit. Especially on mobile, web apps generally are bad and a lot of the reason is trying to shoehorn an app experience onto the dom.

It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly.

If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.

Re: Should JavaScript be split into two languages?

#202

Post by peutetre »

emseetech wrote: post #95
peutetre wrote: post #81

Earlier quoted context omitted.

Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo

Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.

> And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application.

The download isn't much different to a typical website. That Flutter demo in wasm is 2 megabytes.

Avalonia UI's WebAssembly uses canvas in C#: https://avaloniaui.net/

Uno Platform's WebAssembly implementation uses the DOM rather than drawing to canvas: https://platform.uno/

Uno's philosophy is to use platform native controls. The benefit is that you get platform native characteristics, the cost is it will never be exactly the same in each browser and platform.

Re: Should JavaScript be split into two languages?

#203

Post by dang »

itsgabriel wrote: post #181
dang wrote: post #87

The proposal was submitted here but didn't get much attention. Are there other threads? Language Evolution: Problems, and What Can We Do About It? - https://news.ycombinator.com/item?id=41795190 - Oct 2024 (1 comment) Proposal of JavaScript becoming a compiled language: JS0 and JSSugar - https://news.ycombinator.com/item?id=41764825 - Oct 2024 (2 comments)

https://news.ycombinator.com/item?id=41764825

Added. Thanks!

Re: Should JavaScript be split into two languages?

#204

Post by o11c »

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.

As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module systems have.

Re: Should JavaScript be split into two languages?

#205

Post by Izkata »

xscott wrote: post #189
hu3 wrote: post #172

Earlier quoted context omitted.

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

> This is what StackOverflow tells me (2020) Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too. I don't even know what he's on about with Preact/React... Save the following as "ergonomic.html"…

> I don't even know what he's on about with Preact/React...

Around 10 years ago, I was having lunch in a food court and overheard "Luckily I don't have to use javascript, just jquery".

Around 5 years ago, a co-worker admitted he still had issues distinguishing what functionality was python and what came from Django (web framework), despite having used them both daily for years. He thought it was because he learned both at the same time.

I wouldn't be surprised if this was more of the same, and just getting worse as we pile more and more abstractions on top.

Re: Should JavaScript be split into two languages?

#206

Post by a57721 »

wiseowise wrote: post #113
peutetre wrote: post #34

Earlier quoted context omitted.

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

[flagged]

Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.

Re: Should JavaScript be split into two languages?

#207

Post by nitwit005 »

DidYaWipe wrote: post #199
nitwit005 wrote: post #175

Earlier quoted context omitted.

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

And?

Perhaps reread your comment and mine, and you'll see there is a relationship between statements.

Re: Should JavaScript be split into two languages?

#209

Post by Dylan16807 »

xscott wrote: post #128
the-smug-one wrote: post #109

Earlier quoted context omitted.

That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

> This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.

Re: Should JavaScript be split into two languages?

#210

Post by anonzzzies »

xscott wrote: post #103
emseetech wrote: post #95

Earlier quoted context omitted.

Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.

What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?

What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
Post reply on HN