Live data from Hacker News

WASM Is the New CGI

roborooter.com

121–130 of 311 posts

Re: WASM Is the New CGI

#121

Earlier quoted context omitted.

It's difficult or impossible to compile many languages into JavaScript. WASM is more general.

Do you have a source for this? asm.js (the spiritual precursor to WASM) worked pretty much the same, and an awful lot of languages were compiled to it. WASM does provide a more predictable compilation target to be sure, but I don't think it actually opens any new possibilities re what languages can be compiled.

Multithreading and 64-bit integers come to mind as creating difficulty, and I imagine "raw" memory buffer access having much higher latency to the point where it's completely impractical. For example, a quick search gave me this library [1] that compiles FFMpeg into Asm.js but the author says it is almost a factor 10 slower. Asm.js would also become extremely verbose for any larger code base (imagine compiling a AAA PC game to Asm.js).

It may be as you say that there are no new theoretical possibilities being opened by WASM, but to me it is a natural step forward to resolve inefficiencies and ergonomic problems in ASM.js and make it all less painful. And hopefully WASM won't be frozen in time either - the platform needs to keep improving to make more use-case scenarios practical.

[1] https://github.com/Kagami/webm.js/

Re: WASM Is the New CGI

#122
post #51

Earlier quoted context omitted.

Unlike ActiveX, Silverlight, or Flash, it's an open standard developed by a whole bunch of industry players, and it has multiple different implementations (where Java sits on that spectrum is perhaps a bit fuzzier). That alone puts it heads and shoulders above any of the alternatives. Unlike the JVM, WASM offers linear memory, and no GC by default, which makes it a much better compilation target for a broader range o…

> The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too. Indeed, graphics pioneer and all-around-genius Ivan Sutherland observed (and named) this back in 1968: "wheel of reincarnation "[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer t…

That was why i stopped using the word 'tech' to refer to these things. You don't suddenly go back to stop using the wheel after a time, or suddenly think that printing press was a bad idea after all. Those are techs. Many of the things we call techs nowadays are just paradigms. And frameworks are defnitely not 'new technology'.

Re: WASM Is the New CGI

#123
post #64

Earlier quoted context omitted.

More and more reliably. When people have an abo that cannot be quit every month it gives more financial security to the company. Previously people would buy e.g. the creative suite from Adobe and then work with that version for many, many years to come

Previously people would crack CS from Adobe then work with that version for many, many years to come :)

Previously amateurs would crack Adobe software and then get a letter telling them they needed to pay or be sued when they went professional.

The cracked software was there to onramp teens into users. Adobe has burned this ramp and now no one under 14 uses it any more which is quite the change from when I was 14.

Re: WASM Is the New CGI

#124
post #103

Earlier quoted context omitted.

Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a n…

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possib…

For now, (typical) WASM is indeed more secure than (typical) JVM or .NET bytecodes primarily because external operations with WASM are not yet popular. WASM in this regard has the benefit of decades' worth of hindsight that it can carve its own safe API for interoperation, but otherwise not technically superior or inferior. Given that the current web browser somehow continues to ship and keep such APIs, I think the future WASM with such APIs is also likely to remain safer, but that's by no means guaranteed.

Re: WASM Is the New CGI

#125
post #6

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. S…

Hehehe, so the future is how we used to run applications from before the era of the web.

There is no other industry that is equally driven by fad and buzzword. Try to hide a simple fact that a whole motivation behind SaaS preaching is greed, and bait users with innovative "local-first" option.

It is actually kinda funny to read cries about "enshitiffication" and praises for more web-based bullshittery on the same site, although both are clearly connected and supporting each other. Good material for studying false consciousness among dev proletariat.

Re: WASM Is the New CGI

#126

Earlier quoted context omitted.

> The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too. Indeed, graphics pioneer and all-around-genius Ivan Sutherland observed (and named) this back in 1968: "wheel of reincarnation "[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer t…

That was why i stopped using the word 'tech' to refer to these things. You don't suddenly go back to stop using the wheel after a time, or suddenly think that printing press was a bad idea after all. Those are techs. Many of the things we call techs nowadays are just paradigms. And frameworks are defnitely not 'new technology'.

> Many of the things we call techs nowadays are just paradigms

More like fads sold to milk even more money from people.

Re: WASM Is the New CGI

#128
post #6

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. S…

I definitely view the browser as an app delivery system... one of the benefits being you don't have to install and thus largely avoid dependency hell.

Recently I wrote an .e57 file uploader for quato.xyz - choose a local file, parse its binary headers and embedded xml, decide if it has embedded jpg panoramas in it, pull some out, to give a preview .. and later convert them and upload to 'the cloud'.

Why do that ? If you just want a panorama web tour, you only need 1GB of typically 50GB .. pointclouds are large, jpgs less so !

I was kind of surprised that was doable in browser, tbh.

We save annotations and 3D linework as json to a backend db .. but I am looking for an append-only json archive format on cloud storage which I think would be a simpler solution, especially as we have some people self hosting .. then the data will all be on their intranet or our big-name-cloud provider... they will just download and run the "app" in browser :]

Re: WASM Is the New CGI

#129

Earlier quoted context omitted.

AFAIK the big new thing in WASM is that it enforces 'structured control flow' - so it's a bit more like a high level AST than an assembly-style virtual ISA. Not sure how much of that matters in practice, but AFAIK that was the one important feature that enabled the proper validation of WASM bytecode.

I don't think there's any significant advance in the bytecode beyond e.g. JVM bytecode. The difference is in the surface area of the standard library -- Java applets exposed a lot of stuff that turned out to have a lot of security holes, and it was basically impossible to guarantee there weren't further holes. In WASM, the linear memory and very simple OS interface makes the sandboxing much more tractable.

I worked on JVM bytecode for a significant number of years before working on Wasm. JVM bytecode verification is non-trivial, not only to specify, but to implement efficiently. In Java 6 the class file format introduced stack maps to tame a worst-case O(n^3) bytecode verification overhead, which had become a DoS attack vector. Structured control flow makes Wasm validation effectively linear and vastly simpler to understand and vet. Wasm cleaned up a number of JVM bytecode issues, such as massive redundancy between class files (duplicate constant pool entries), length limitations (Wasm uses LEBs everywhere), typing of locals, more arithmetic instructions, with signedness and floating point that closer matches hardware, addition of SIMD, explicit tail calls, and now first-class functions and a lower-level object model.

Re: WASM Is the New CGI

#130

Earlier quoted context omitted.

Except with runtime safety, no installation process, no pointless scare popups when trying to run an app directly downloaded from the internet, and trivial distribution without random app store publishing rules getting in the way. In a way - yes - it's almost like it was before the internet, but mostly because other ways to distribute and run applications have become such a hassle, partly for security reasons, but mo…

Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it wo…

> They could do all this (except for the sandboxing thing).

The sandbox is very very important, it is the reason I mostly do not worry about clicking random links or pasting random urls in a browser.

There are many apps that I would have liked to try if not for the security risk.

Post reply on HN