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

151–160 of 324 posts

Re: Should JavaScript be split into two languages?

#151

Post by wiseowise »

nenadg wrote: post #148
wiseowise wrote: post #119

Earlier quoted context omitted.

> There is already too much exhaustion around switching frameworks and paradigms in the JS world What's wrong with VanillaJS?

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

Re: Should JavaScript be split into two languages?

#152

Post by ec109685 »

peutetre wrote: post #85
jokethrowaway wrote: post #76

Earlier quoted context omitted.

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…

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

Re: Should JavaScript be split into two languages?

#153

Post by mdaniel »

nephy wrote: post #42

The US government needs to fast track breaking up Google asap. Chrome needs to be torn from their festering lich hands, so that the web can be free of their self serving, and frankly bad, proposals.

Out of curiosity, which of the fragments of Google would you expect to take ownership over that codebase?

I had always imagined that if the DoJ took any action it would be to cleave the ad business away from Google. Although if they went so far as to take action against GCP I bet Amazon, Amazon Marketplace, and AWS would start to get sweaty palms

Re: Should JavaScript be split into two languages?

#154

Post by sshine »

anon7000 wrote: post #138
sshine wrote: post #6

JavaScript is two languages: 1) JavaScript, the original assembly language of the internet, does not need new language features. 2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5. The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underly…

This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax! There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc. I mean even newer features like nullish coalescing and optional chaining are at 93-94% supp…

Interesting.

I did assess the ES6 coverage of ~97% a month ago.

I just evaluated that while it sounds high, 3% of people is a lot of people to cut off if your JavaScript is essential.

E.g. Firefox sits at ~2.7% browser market share. (Not incidentally the part that doesn't support ES6, but it's a demography the size of my own.)

Re: Should JavaScript be split into two languages?

#155

Post by ec109685 »

ratorx wrote: post #14
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.

This is mostly a solved problem in regular compilers, and sourcemaps etc do currently exist for JS. I agree that the tooling/UI around this could be better, but by focusing on this approach, things like Typescript get better as well.

Are there debuggers that can single step over the transpiled bits so that it feels like the methods are implemented natively? Otherwise, it becomes a mess.

Re: Should JavaScript be split into two languages?

#156

Post by nitwit005 »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

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.

Re: Should JavaScript be split into two languages?

#157

Post by ec109685 »

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.

If it’s not implemented as a built-in feature of the browser, wouldn’t half the internet break if features were removed that people were counting on?

Re: Should JavaScript be split into two languages?

#158

Post by sshine »

em-bee wrote: post #90
xscott wrote: post #82

Earlier quoted context omitted.

Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application is currently using the javascript host, and the well written ones are pretty snappy.

this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did…

> i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM

That doesn't have to be true.

Eventually WASM will get direct access to the full browser API, without going through JavaScript.

The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are available.

Those things aren't available in other JavaScript VMs, like Node. (There's no DOM to interact with.)

And they're not yet available in the WASM VM in the browser, either.

The reason is that the WASM APIs/ABIs have not stabilised. It takes time to make right, but there is progress.

Re: Should JavaScript be split into two languages?

#159

Post by DidYaWipe »

nitwit005 wrote: post #156
Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

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.

Re: Should JavaScript be split into two languages?

#160

Post by neonsunset »

ameliaquining wrote: post #149
Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

A core requirement of WebAssembly was that (ignoring I/O for the moment and considering only the computational core) you should be able to run arbitrary existing code on it, and the effort involved in getting it working should be comparable to porting to a new architecture, not to a new programming language. What this particularly meant, in practice, was that it needed to be a good compilation target for C and C++, s…

This is not true. CIL could be an excellent compilation target for C++ and was quite literally made with that in mind. C# was inspired as much by C++ as it was by Java. And CLR back then was made with consideration of C++/CLI, which exists even today. You can't effectively express C++ code with JVM bytecode, you absolutely can with CIL. You can even express most of Rust's generics with CIL nowadays, retaining monomorphization, save for zero-sized structs and other edge cases.
Post reply on HN