Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

181–190 of 324 posts

Re: Should JavaScript be split into two languages?

#181
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

Re: Should JavaScript be split into two languages?

#182
post #154

Earlier quoted context omitted.

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

> 3% of people is a lot of people to cut off if your JavaScript is essential

These are probably the 3% that won’t affect your business much. They’re more likely to be on older hardware and also have less discretionary income. Or browsing on really weird hardware that is also unlikely to lead to a sale.

Re: Should JavaScript be split into two languages?

#183

Earlier quoted context omitted.

Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold: WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). The r…

> Dealing with strings is not fun right now. And dealing with strings isn't fun in many other languages or runtimes or OSes. e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan objects" - https://learn.mic…

> The Erlang string type is implemented as a single-linked-list

This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.

Re: Should JavaScript be split into two languages?

#185
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…

I mostly don’t mind JavaScript only thing for me is number data type and no int. The other part that is annoying is lack of standard library so we get left-pad crap.

Re: Should JavaScript be split into two languages?

#186

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…

The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules from within the same page without either a) hacking the global object or b) generating unnecessary resources).

Re: Should JavaScript be split into two languages?

#187
post #75
post #69

Earlier quoted context omitted.

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

The DOM itself is very slow, much slower than Javascript, so you're not going to be seeing any great performance increase if WASM can access the DOM directly.

I also have to wonder if people are excited about replacing Javascript, why they would want to have HTML/CSS/DOM on top of WASM. A different front-end UI tech could be much better than slow, old DOM.

Re: Should JavaScript be split into two languages?

#188

Earlier quoted context omitted.

> and fast changing area Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.

> Who cares? I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.

I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be.

Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.

Re: Should JavaScript be split into two languages?

#189
post #172
post #145

Earlier quoted context omitted.

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 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" and you'll see that WebAssembly is manipulating the DOM.

    Not that hard 
     
     
    document.addEventListener('DOMContentLoaded', () => { 
        /* Compile this module with wat2wasm to make the binary below: 
     
            (module 
                (import "env" "easy" (func $easy (param i32))) 
                (func $run (param) (result) 
                    (call $easy (i32.const 123)) 
                    (call $easy (i32.const 456)) 
                ) 
                (memory $mem 1) 
                (export "run" (func $run)) 
                (export "mem" (memory $mem))  
            ) 
        */ 
     
        const binary = new Uint8Array([ 
              0,   97,  115,  109,    1,    0,    0,    0,   
              1,    8,    2,   96,    1,  127,    0,   96, 
              0,    0,    2,   12,    1,    3,  101,  110,  
            118,    4,  101,   97,  115,  121,    0,    0,  
              3,    2,    1,    1,    5,    3,    1,    0, 
              1,    7,   13,    2,    3,  114,  117,  110, 
              0,    1,    3,  109,  101,  109,    2,    0, 
             10,   14,    1,   12,    0,   65,  251,    0,  
             16,    0,   65,  200,    3,   16,    0,   11,   
        ]); 
     
        const imports = { 
            easy(arg) { 
                const div = document.createElement("div"); 
                div.textContent = "DOM this: " + String(arg); 
                document.body.appendChild(div); 
            } 
        }; 
     
        const module = new WebAssembly.Module(binary);  
        const instance = new WebAssembly.Instance(module, { env: imports });  
        instance.exports.run(); 
    });
    
    

That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export.

I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas.

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

And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.

Re: Should JavaScript be split into two languages?

#190
post #168
post #128

Earlier quoted context omitted.

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.

that's not what pike is doing though. int and float are still kept separate. btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly

You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
Post reply on HN