Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

291–300 of 324 posts

Re: Should JavaScript be split into two languages?

#291
post #285
post #283

Earlier quoted context omitted.

so does that mean accessing the DOM from python is not possible yet? for the second question the example you gave is equivalent to what in plain html/js?

> so does that mean accessing the DOM from python is not possible yet? No. It means you only get what the person who ported CPython or py2wasm gave you. It's not a limitation in WebAssembly, and maybe they have some other (hopefully better) API than the `easy(123)` example I was trying to show. > for the second question the example you gave is equivalent to what in plain html/js? If I understand what you're asking, i…

It means you only get what the person who ported CPython or py2wasm gave you

that's what i meant. it's not possible until someone adds the necessary features to the wasm port of the language. makes sense of course, like any feature of a new architecture.

If I understand what you're asking

exactly that, thank you. it is easier to understand the example if there is no doubt as to what is the js part and what is wasm (it also didn't help that the code was not easy to read on a phone)

Re: Should JavaScript be split into two languages?

#293

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.

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

You're joking, right? A 2mb bundle is *absolutely unacceptable*. People complain about React which is less than 100kb minified and gzipped. This website doesn't even include any images or anything...

Re: Should JavaScript be split into two languages?

#294
post #204

Earlier quoted context omitted.

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.

Which features?

Re: Should JavaScript be split into two languages?

#295
post #290

Earlier quoted context omitted.

[flagged]

> There's no point in trying to make other people stop talking about Lisp Nobody is trying to make you stop talking about it. We’re trying to make you understand that the way you’re talking about it is elitist. When someone said they were confused by the syntax, you could have just explained it without judgement. Instead, you felt compelled to flaunt your membership of the in-group who understands Lisp, and try to ma…

> If I didn’t know Lisp, and my first exposure to it was from someone who sees this kind of toxicity as a reasonable way to speak to people, would I want to join their community?

Wouldn't (didn't!) faze me. Every community has it. The most popular languages, platforms and tools in fact bring out unbridled hostility. Probably, hostility finds a peak in the second most popular camps. :)

We have already lost people who are influenced by this sort of fluff, because those people will be turned away from Lisp by the anti-Lisp trolling about parentheses, niches and slow processing over everything being a list, and so on. There aren't enough Lisp people around to counter it.

Re: Should JavaScript be split into two languages?

#296
post #287

Earlier quoted context omitted.

[flagged]

Sorry to bust your minuscule lisp bubble but just because someone ignored your favorite niche language in an educated career choice, it doesn't mean they are ignorant. Infantile language tribalism though, have no place in engineering and is blatant ignorance when coming from a supposed adult.

Lisp is a family of languages, most of which are suited for many purposes.

Implementations of Lisp are no more niche than other languages with managed run-times.

Lisp has been used for even operating system development: Lisp code taking interrupts, and driving ethernet cards and disks and so on.

Which member of the Lisp family are you talking about, and what do you think is the niche?

Re: Should JavaScript be split into two languages?

#297
post #271
post #258

Earlier quoted context omitted.

My point is that if someone says something is arcane, “it’s not, it’s just [something that you’ve potentially never heard of and almost definitely don’t understand even if you have heard of it]” doesn’t help your case. They could look it up, but the fact that they would have to do so proves the commenter’s point - relatively few programmers understand Lisp syntax, i.e. it is arcane. If you’re trying to raise awarenes…

Exactly. I, like most devs, know what Lisp is. I, like most devs, just don't care.

I had a basic idea of what Lisp was before getting into it some 25 years ago. It soon became obvious that, no, I actually had no idea. It's not that what I thought had been wrong, but it had no content.

I knew Lisp the way I know that that guy walking down the street is my neighbor Bob. But since I've never had a conversation with Bob, I actually have no idea who he is.

When I see Korean writing in hangeul, I know it is Korean writing, but can't read a letter of it (nor speak a word of Korean).

These examples are like knowing what Lisp is.

The thing I had not expected was how the knowledge in the Lisp world and its perspectives are very informative about a whole lot of non-Lisp!

Re: Should JavaScript be split into two languages?

#298
post #292
post #286

Earlier quoted context omitted.

If you think people who chose not to learn a language you like are insecure it tells more about you than about them.

[flagged]

> people who become hostile when you try to talk about something interesting

We’re becoming annoyed not because people are trying to talk about something interesting, but because they are being intentionally insulting and condescending and then using bad faith arguments like this one when they’re called out on it.

Which of these quotes represent the commenter “trying to talk about something interesting”?

> flaunting your ignorance and your anti-intellectualism

> The point is that anyone who's distracted by the arcanity of Web Assembly Text Format obviously doesn't understand the first thing about WASM

> You do know this is 2024, you have Internet access, and you can just look shit up

> In case you've been living under a rock and didn't realize it

> but you're whining, lashing out, and attacking people who are trying to explain it, and trying to police and derail discussions between other people who are more knowledgeable and interested in it, which makes you a rude anti-intellectual asshole… Why don't you just go away and let other people have their interesting discussions without you, instead of bitterly complaining about things you purposefully know nothing about and refuse to learn? How does it hurt your delicate feelings to just shut up and not bitch and whine about discussions you're not interested in?

> And that proves my point that you're flaunting your ignorance and your anti-intellectualism. But you be you. There's no point in trying to make other people stop talking about Lisp by complaining about how proudly ignorant you are, and how you want to remain that way, so you don't want anyone else to talk about it. This really isn't the place for that, since you always have the option of not reading, shutting up, and not replying and interrupting and derailing the discussion, so other more knowledgeable and curious people can have interesting discussions without you purposefully harassing them like a childish troll.

> Look, it's pretty clear I stepped on some insecurity.

Re: Should JavaScript be split into two languages?

#299
post #204

Earlier quoted context omitted.

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.

Which features?

Conditional imports (e.g. depending on browser-version, browser-vs-server) is the big one. This does not inhibit the alleged static analysis goal at all, but the specification is pointlessly hostile to it. I would've expected the "import assertions" proposal to cover this obvious problem, but no, it's just another useless thing that will always have to be transpiled into nonexistence.

Transparent polyfills (or anything that really needs to be loaded "first") also don't work, since async means you can't specify the order to load things. This means that every single module you write has to explicitly mention which exact polyfill it's going to end up using (hope you don't accidentally skip one or specify a conflicting polyfill) ... or you just abandon modules and load your polyfills with a normal script (which means that now your source is a bastard mixture).

Lazy imports are technically possible via dynamic imports, but unnecessarily annoying and break in all sorts of places. Granted, the standardization of the "leaky browser abstraction" makes this pretty awful regardless.

Re: Should JavaScript be split into two languages?

#300
post #189
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"…

(your example becomes a lot easier to read on a computer instead of a phone) but i'd also like to thank you for patiently answering all the questions (esp here: https://news.ycombinator.com/item?id=41961489 and https://news.ycombinator.com/item?id=41964500 (unfortunately the latter comment has been flagged. turn on showdead to read it)).

but what bothers me a bit is that this example still uses custom javascript code.

i tried to find and answer but essentially what appears to be missing is the ability to access js objects from wasm. to access the document object it looks like i need a wrapper function in js:

    jsdocument(prop, arg){
        document[prop](arg)
    }
so far so good, i can import this jsdocument() function and use it to all any property on the document object, but if document[fun](arg) returns another DOM object, then what?

maybe more elaborate:

    callDOMobj(prop, arg, prop2, arg2){
        document[prop](arg)[prop2](arg2)
    }
i can call this function with the arguments ("getElementById", "foo", "append", "more foo") in any WASM language and it will result in calling document.getElementById("foo").append("more foo"); which allows some basic DOM manipulation already. but then i want to continue with that object so maybe i can do this:

    getDOMobj(prop, arg){
        var len = objlist.push(document[prop](arg))
        return len-1;   
    }

    callDOMobj(pos, prop, arg){
        objlist[pos]["prop"](arg)
    }
can you see what i am getting at here? building up some kind of API that allows me to access and manipulate any DOM object via a set of functions that i can import into WASM to work around the fact that i can't access document and other objects directly. it looks like this is similar to this answer here: https://stackoverflow.com/a/53958939

solving this problem is what i mean when i ask for direct access to the DOM. i believe such an interface should be written only once so that everyone can use it without having to reinvent it like it appears to be necessary at the moment.

Post reply on HN