I never thought that it would be a promising approach to build entire web apps using wasm. You don't just have to make it possible to interact with the DOM. You also have to have the right high level language to do this kind of DOM interaction and application logic. JS isn't bad for that purpose and it would probably take a lot to find something that is much better (which compiles to WASM instead of js, like ts and svelte do).

The only real avenue for js-free web applications would be to completely abandon the browser rendering path and have everything render into a canvas. There are experiments to use UI toolkits designed for the desktop. But even that I see more of a niche solution and unlikely to become very widely used. HTML/css/js have become the lingua franca of UI development and they are taking over desktop applications as well. Why should that trend reverse?

> completely abandon the browser rendering path and have everything render into a canvas

Yeah, go ahead and trash the little bit of accessibility we still have. <canvas> by itself already asks webdevs to shit on people with visual disabilities. But getting rid of the DOM (for vague reasons) would really nail the coffin of these pesky blind users. After all, why should they be able to use anything on the internet?

This, and AI making webdevs consider to obfuscate things for scraping reasons, and Microsoft Recall making devs play with the idea of obfuscating OS-level access to their (privacy-sensitive) apps, which in essence would also trash accessibility, are the new nightmares that will haunt me for the next few years.

Unfortunately this is how Flutter web apps work.

> You also have to have the right high level language to do this kind of DOM interaction and application logic.

That just means you personally like JS. In my opinion many languages are better than it.

Maybe that's not the dominant mindset anymore, but I for one would love to use a language that's actually built for functional/reactive programming instead of inventing half-baked JavaScript dialects for that purpose. Elm was a language in that spirit, but it never felt complete.

You can probably build something in PureScript.

Makes me sad that PureScript doesn't have more adoption, not that I'm surprised. It's orders of magnitude better than Elm and even improves upon Haskell in some meaningful ways (row polymorphism).

Gone are the days it used to show up routinely in sites like HN, another proof how the language adoption cycles go.

Sorry, I am turned off by the CRDT in there. It immediately smells of overengineering to me. Not that I believe git is a better database. But why not just SQL?

Merges require revisioning. JSON or SQL do not have that in the model. This variant of CRDT is actually quite minimalistic.

I would argue LWW is the opposite of a merge. It is better to immediately know at the time of writing that there is a conflict. CRDTs either solve or (in this case) don't solve a problem that doesn't really exist, especially for package managers.

Git solves that problem and it definitely exists. Speaking of package managers, it really depends. Like, can we use one SQLite file for that? So easy, why no one is doing that?

idk, debian for example uses plain text files. I have to imagine it would bring some advantages to move that over to an sqlite to improve performance, but then it seems package management designers fall into the two categories of either under-engineering or over-engineering the solution. There is little glory in evolving something incrementally, everyone wants to do green field stuff.

I think this is speaking in the absense of sufficient protections like laws. Because how does it help that a hypothetical law protects you if that law doesn't exist?

I think you’ve missed some context now, we’re responding to someone who is being dismissive of the pain experienced by users in these cases.

I am surprised that Taiwan and China are not mentioned in the article or in these comments. Given the threat that China will get to Taiwan and capture control over the unrivaled TSMC, investing into silicon while we can is pure and simple de-risking in a de-globalizing world.

The meaning of the term "opt-in" is that it is off by default and has to be manually enabled. "opt-out" means it is on by default and you have to manually turn it off. "opt-in-by-default" or "opted in by default" are needlessly confusing.

True, yes. Totally agree with you on the fundamental definition of opt-in vs opt-out.

You can also have a checkbox that says "I consent to having my data used for training", which would look like "opting in", and it could be true by default.

Or you can have a checkbox that says "Leave my data out of your training set", which would look like "opting out", and which could be unchecked default.

Technically, they're both "opt-out", but I've seen enough examples (intentionally confusing and arguably "dark patterns") that I personally don't really consider "it's opt-in" to be a complete statement anymore.

Edit: I'll add that, in the comment I was replying to, it very much looked like you had to go to a settings page in order to opt-out, which I think is entirely reasonably described as having been opted-in by default. Here's what they had written:

> All you have to do is flip a single switch in the options to turn it off

And I actually think "opted-in by default" is valid and calls out cases where it looks like you consent, but that decision was made for you. Although in this case I think I've seen other comments that describe the UX differently, but my comment was more of a general comment than about this particular flow.

Well I would say that the machine should not override the human input. But if the machine makes up the plans in the first place, then why should it not be allowed to change the plans? I think that the hilarious part in modifying tests to make them work without understanding why they fail is that it probably happens due to training from humans.

It's the kind of thing you do with macros in C++.

Yeah probably, I mean I thought of it but never went as far as actually adding something.

Far more common than what exactly? Because if you look at the range of the exponent, you should still come to the conclusion that floats can represent more non-integer numbers than integer numbers.

Rebuilding from scratch also takes longer than installing a prebuilt package. So while it might be worth it for a heavily used application, in general I doubt it.

Also I think in earlier days the argument to build was so you can optimize the application for the specific capabilities of your system like the supported SIMD instruction set or similar. I think nowadays that is much less of a factor. Instead it would probably be better to do things like that on a package or distribution level (i.e. have one binary distribution package prebuilt by the distribution for different CPU capabilities).

> authentication, validation and security

Those are generally solved using SSL, no need for centralized storage.