Hacker News Reader

The current webdev paradigm is "treat JS as bytecode". We have enormous build processes that compiles high-level languages (TS, JSX, SASS etc) into "low-level" and unreadable JS/CSS/HTML. The latter were supposed to be the high-level language interfaces to the browser. It's a mess.

We'll be much better off with an actual compilation target i.e. WASM, full stop.

There’s a cycle where something gets big because people use it. Say, a mushroom picker puts up a document about picking mushrooms. Now he can enjoy his hobby most excellently!

Next the programmers get interested. They help the mushroom picker upgrade his site with maps and a spreadsheet you can search and everything. Now the programmers can enjoy their hobby most excellently!

Then the overengineers take over and insist that it run Linux. Now you can compile Linux to Wasm, and it works if you just configure the endpoints according to an elegant scheme! The overengineers can enjoy their hobby most excellently!

But the mushroom picker who started this thing isn’t going to come back. No one ever picks up the thread of development again, and there’s nothing to do except “be online.” The ride is over.

There's nothing preventing people from creating a regular HTML/CSS/js site, just like they can do right now, even though all major browsers already support wasm.

WASM makes browsers simpler, not more complex. It's much easier to get the implementation of a 20 page spec correct, than the combinatorial monster that is 200 highlevel language specs and APIs. The more we can push into a small formal core, the better. Formal verification tools call this the de Bruijn criterion. You create a small formal core for your proof system, and everything highlevel just compiles to that.

Surely that is a noble goal!

But isn't it a case of XKCD 927? https://xkcd.com/927/

I.e. I would say the probability is zero that because WASM exists other existing complexity of browsers will be removed.

Because the web is so vast, if you once add a feature to browsers you can never remove it because that would break an unknown amount of websites, or even intranet sites.

So now we have wasm + N other subsystems, so N+1, and the security of N+1 systems is less than that of N.

We break/deprecate the web all the time. Web backwards compatibility is a myth, it's just that wo don't get any calls from the 90s complaining that their dogs website broke.

How long have you been using the Web?

ActiveX? DYNSRC? Frames? Flash? How about Gopher support? Capabilities being removed is a time-honored tradition in the browser world.

> It's much easier to get the implementation of a 20 page spec correct

JS spec was also 20 pages. Until we got modern Javascript.

wasm spec will grow. Just look at the roadmap: https://webassembly.org/roadmap/

Feature creep is an orthogonal issue that I 100% agree with. We need to stay vigilant and push back against bloat wherever possible. Exceptions are a mistake imho, memory64 is an absolute must have otoh.

I feel like you're pretending like there's no value to it? If there was no value then yeah it would be stupid to do it. But it is valuable, because people want within-10%-of-native performance.

If people want native performance, they could just publish native software instead of websites :)

native gui dev sucks, and the web does a way better job of sandboxing than native things do.

Yes they can, if they have the time and skills to port it to the many plattforms desired. But maybe you do see the point, that it is a bit easier to develope and test for only one plattform, as opposed to ... many?

(have you ever released something cross plattform?)

Point being, the web is a plattform now (since quite a while) and not anymore a static site displayer. Provide a technologically better alternative and people will use that.

The web is the best distribution platform we currently have and increasing performance via WebAssembly means a wider variety of programs are now viable on the web.

And lose all the value of distributing their software via websites! Again, if you ignore all the value of solutions, then yes, the solutions seem bad.

Perhaps that is just the tax they ought to pay for wanting to squeeze out more performance? :)

The alternative of not paying that tax by using WASM means "I want native performance but I don't want to pay the price of having to do native development."

So what developers are doing here is creating an externality - external cost which other people have to pay:

Browsers for the average internet user who just wants to read some news get worse in terms of security because some people want to distribute their software more conveniently at zero cost.

The cost is paid by the users who all now have WASM in their browser, even if they don't need it.

Then I'm running their code outside of the world-class sandbox the browsers provide.

Distributing native software is a PITA nowadays. You're either at the mercy of a random App Store review process, or you can't run the software you just downloaded outside an app store because the operating system doesn't allow it.

> But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML?

The problem is javascript sucks. We want to be able to write any kind of application, but we don't want to have to do it in javascript. Ideally, this would mean that you pick Java or C# instead and use one of several cross-platform UI frameworks, but I've never found a native UI framework that was as easy to work with as HTML. If C# would just let us write native UI with HTML and CSS (and not just using electron), then I would never write a webapp again

Would it not be feasible to turn electron inside out, and have chromium as a library, with bindings for various languages?

I don't think so, no, or rather, I think you might lose out on "the web" part of it. That is, that the web really is a bunch of stuff, all accessible in one "thing", and stuff can and does "link" to various other stuff.

E.g., consider an OIDC log in. It's really one app (the relying party), redirecting to a whole different app (your SSO of choice). You can't exactly do that in another app without, I think, really running into issues of "is it my SSO, or a phish?". The browser provides that trusted layer of "I am look at this app" (via the URL bar). And even then … that's fraught with absolutely immense tons of peril.

It's also a distribution mechanism: I don't have to download Slack, Discord, Postman, etc. — I just go to a URL, and the browser downloads the code needed. (I can and do download some of these, and there are some advantages to do so. But then extend it to every app I use on the web: my bank, Turbotax, my email, my three different loan payment sites, my landlord's payment site … that'd be far too many downloads.)

> We want to be able to write any kind of application, but we don't want to have to do it in javascript.

To make "any kind of application" on the web you need the web to provide sensible APIs for those applications. And Javascript has nothing to do with it. E.g. lack of controls listed over at https://open-ui.org/ has nothing to do with Javascript.

> If C# would just let us write native UI with HTML and CSS

Good luck implementing anything beyond the most basic controls with HTML and CSS.

You're just misunderstanding what he's asking for.

I don't. His concern is completely misdirected. The problem with the web as a UI/app platform isn't Javascript

Rather, wasn't that the promise with Flash, Java, Sliverlight

Oh right, and ActiveX!

They were all proprietary though

Yes, except OpenJDK that provided IcedTea, so community patches were possible

The improved sandboxing model is supposed to be why this one's going to turn out better (and why it's worth losing some of the ease of development of the old ones...)

Silverlight lives on! i started in SL 1.0 and moved onto Xamarin and now to .NET7. Its the same code, same concepts, just different conventions around the APIs.

For me, WebAssembly is another target. ive been building webview based app UIs with (usually) native backends, cross platform for atleast 10yrs now. I still use libraries i made for SL because PCL was just the first evolution of dotnet! Life is good on the MS gravey train! Im running the same code literly everywhere, backend, frontend, UI, mobile, tablet, cloud. THE SAME CODE, just thin bootstrappers and OS specific impls of various services.

The best part of WASM i think is that i can write services in different languages, for specific purposes, if i ever need to. Yep, i can use scheme or haskell if the need fits, but c# has been evolving too and i can write functional anyways. Im not in the industry where a thin abstraction causes me scaling issues, but i am in one where its hard to find good devs, and usually they can read c# and pick it up quickly no matter their preferred poison.

> All I hear when someone writes "WebAssembly is coming" is

"... coming to your insecure browser; not mine."

> To disable WASM in Firefox, set "javascript.options.wasm = false" in about:config.

Exactly. Here's hoping the banks fail before they can start requiring WebAssembly to log in to their websites. ;)