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

91–100 of 311 posts

Re: WASM Is the New CGI

#91

Post by bigstrat2003 »

torginus wrote: post #62
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…

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

Except worse, because everything has to run in a gigantic web browser even if it could be a small native app.

Re: WASM Is the New CGI

#93

Post by adrianN »

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…

CGI is alive and well. It’s still the easiest way to build small applications for browsers.

Re: WASM Is the New CGI

#94

Post by marcyb5st »

jillesvangurp wrote: post #72

WASM replaces a language specific vm (javascript) with a general purpose one anywhere javascript vms are currently used. But not exclusively just there. General purpose here means it can run just about anything with a compiler or interpreter for it. Including javascript. So anything, anywhere. Since it is generally implemented as part of the javascript engine, it inherits a lot of stuff that comes with it like sandbo…

While I don't have a problem with Javascript, I have a problem with the ecosystem around publishing JS for the web. There are so many tools that do more or less the same thing and whose boundaries are unclear. Additionally, when you eventually manage to get everything working it feels brittle (IMHO). For someone that doesn't do that professionally, it is daunting.

Nowadays, the few times I need to build something for the web I use leptos which has a much nicer DX and even if it didn't reach 1.x yet, it feels more stable that chaining like 5 tools to transpile, uglify, minify, pack, ... your JS bundle.

Re: WASM Is the New CGI

#95

Post by josephg »

moi2388 wrote: post #67
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…

> Microsoft uses it today for C#/Blazor. But it isn't the correct approach as dotnet in browser will likely never be as fast as Javascript in the browser. Might be true, but both will be more than fast enough. We develop Blazer WASM. When it comes to performance, dotnet is not the issue

Yep. And when wasmgc is stable & widely adopted, apps built using blazer will probably end up smaller than their equivalent rust+wasm counterparts, since .net apps won’t need to ship an allocator.

Re: WASM Is the New CGI

#96

Post by bryanrasmussen »

csomar wrote: post #26
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…

At the end of the day, all you are doing is syncing state with the server. In the future, you'll have a local state and a server state and the only server component is a sync Wasm binary hehe. Still, you'll be coding your front-end with Wasm/Rust, so get in on the Rust train :)

metaphorically, Rust train does not sound enticing.

Re: WASM Is the New CGI

#97

Post by swiftcoder »

curtisblaine wrote: post #73
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…

Some applications are inherently hard to make local-first. Social media and Internet forums come to mind. Heavily collaborative applications maybe too.

I feel like social media is one of the main things folks want to be local-first. Own your own data, be able to browse/post while offline, and then it all syncs to the big caches in the sky on reconnect...

Re: WASM Is the New CGI

#98

Post by actionfromafar »

curtisblaine wrote: post #82
OtomotO wrote: 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 :)

True but do all those peeople now pay $100 a month to Adobe? Hardly.

Re: WASM Is the New CGI

#99

Post by kgeist »

Laremere wrote: post #49
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 n…

>Wasm has verification specification. This verified subset makes security exploits seen in those older technologies outright impossible

Both Java and .NET verify their bytecode.

>Wasm bytecode is trivial (as it gets) to turn into machine code

JVM and .NET bytecodes aren't supercomplicated either.

Probably the only real differences are: 1) WASM was designed to be more modular and slimmer from the start, while Java and .NET were designed to be fat; currently there are modularization efforts, but it's too late 2) WASM is an open standard from the start and so browser vendors implement it without plugins

Other than that, it feels like WASM is a reinvention of what already existed before.

Re: WASM Is the New CGI

#100

Post by swiftcoder »

winternewt wrote: post #30
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…

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.

Post reply on HN