Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM Is the New CGI

roborooter.com

Post reply on HN
Print view View original

41–50 of 311 posts

Re: WASM Is the New CGI

#41

Post by iforgotpassword »

pjmlp wrote: post #7
rpcope1 wrote: post #4

So basically we're reinventing the JVM and it's ecosystem?

Yeah, by folks that most likely used to bash Application Servers from early 2000's. Not only JVM, also CLR, BEAM, P-Code, M-Code, and every other bytecode format since UNCOL came to be in 1958, but lets not forget about the coolness of selling WASM instead.

That's a bit oversimplified. I had this thought too and tried to figure out why this is different, and I think there are some major points. The biggest one is in which order they were built and designed. If we take Java and ask why applets didn't take off since they could do everything WASM offers and more, two things come to mind: it was fucking slow on contemporary machines, and the gui framework sucked. WASM is the complete opposite. The gui framework is HTML/CSS, which despite its idiocy in many places had a long time to mature and we've generally came to accept the way it works. Now we just tacked a powerful VM onto it so we don't need to target slow Javascript. There isn't even a new language to learn, just compile whatever you want to WASM, which means you can use a familiar and mature dev environment.

The other point is that WASM is way more open than any of the mentioned predecessors were. They were mostly proprietary crap by vendors who didn't give a shit (flash: security, Microsoft: other platforms) so inevitably someone else would throw their weight around (Apple) to kill them, and with good reason. WASM is part of the browser, so as a vendor you're actually in control regarding security and other things, and are not at the mercy of some lazy entity who doesn't give a damn because they think their product is irreplaceable.

Re: WASM Is the New CGI

#42

Post by xnorswap »

thot_experiment wrote: post #22
TekMol wrote: post #10

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers beco…

Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementa…

Javascript is incredibly well optimised, I'm surprised if there's an order of magnitude difference between JS and WASM without a fundamental difference in algorithm chosen.

Re: WASM Is the New CGI

#43

Post by epistasis »

rpcope1 wrote: post #4

So basically we're reinventing the JVM and it's ecosystem?

The JVM is great and all, but that doesn't mean that it is the be-all end-all of the genre. And having mucked with class loaders and writing directly in JVM assembly in the 2000s as part of programming language classes, I'm not sure that the JVM is even a very high point in the genre.

Sure, it allowed a large ecosystem, but holy crap is the whole JVM interface to the external world a clunky mess. For 20+ years I have groaned when encountering anything JVM related.

Comparing the packaging and ecosystem of Rust to that of Python, or shudder C++, shows that reinvention, with lessons learned in prior decades, can be a very very good thing.

Re: WASM Is the New CGI

#44

Post by IshKebab »

TekMol wrote: post #10

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers beco…

The days of computers doubling in speed every 2 years are loooong gone.

Look into the history of WASM. They did try compiling everything into JS with asm.js, but then sensibly decided to do things properly. I don't know why anyone would object to proper engineering.

Re: WASM Is the New CGI

#45

Post by thot_experiment »

slt2021 wrote: post #35

putting everything in WASM really drains the battery on mobile. I hate WASM heavy websites as often they have bloat of javascript and site is very slow, especially during scrolling, zooming due to abuse of event listeners and piss poor coding discipline. I kinda miss sometimes server rendered index.php

WASM is a double edged sword, if you're compiling fast implementations of heavy lift functions to WASM and calling them in lieu of a JS impl you're going to end up saving battery life.

If you're generating bindings for some legacy disaster and shipping it to clients as a big WASM blob you're going to hell.

Re: WASM Is the New CGI

#46

Post by TekMol »

thot_experiment wrote: post #37
TekMol wrote: post #24

Earlier quoted context omitted.

probably be an order of magnitude faster than the JS implementation What makes you think so?

Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.

Compiling your C to WASM might make it run twice as fast as compiling it to JS.

That's all. All other aspects of the workflow are the same.

Re: WASM Is the New CGI

#47

Post by tsimionescu »

TekMol wrote: post #10

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. The only benefit WASM brings is a bit faster execution time. Like twice the speed. Which most applications don't need. And which plain JavaScript offers about two years later because computers beco…

Debugging a Rust program compiled to Javascript is MUCH harder than debugging one compiled to WASM. That is the whole point. And even making the program work when compiled to JS is iffy, as JS has a few breaking constraints, notably that it is single threaded.

Sure, native JS is easier still. But there is a huge wealth of code already written in languages that are not JS. If you want a web app that needs this code, you'll develop it many times faster by compiling the pre-existing code to WASM than by manually rewriting them in JS, and the experience will be significantly better than compiling that code to JS.

Re: WASM Is the New CGI

#48

Post by llm_trw »

cheema33 wrote: 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…

>Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI.

CGI empowers users and small sites. No one talks about it because you can't scale to a trillion add impressions a second on it. Serverless functions add 10 feet to Bazoz's yacht every time someone writes one.

Re: WASM Is the New CGI

#49

Post by Laremere »

junto wrote: post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

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 number you have as a pointer to memory that doesn't belong to you.

- Wasm bytecode is trivial (as it gets) to turn into machine code. So implementations can be smaller and faster than using a VM.

- Wasm isn't owned by a specific company, and has an open and well written specification anyone can use.

- It has been adopted as a web standard, so no browser extensions are required.

As for computation on clients versus serves, that's already true for Javascript. More true in fact, since wasm code can be efficient in ways that are impossible for Javascript.

Re: WASM Is the New CGI

#50

Post by llm_trw »

curtisblaine wrote: post #40
mattdesl wrote: post #21

Earlier quoted context omitted.

I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.

That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely l…

>Incidentally, I think that's why local-first didn't take off yet

Local first is what we had all throughout the 80s to 10s. It's just that you can make a lot more from people who rent your software rather than buy it.

Post reply on HN