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

291–300 of 311 posts

Re: WASM Is the New CGI

#291

Post by nwienert »

createaccount99 wrote: post #86
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…

The frontend space is moving away from client-side state, not toward it.

I think you'll find the real long-term movement is to client-side, not away, and that's because it is both a faster and simpler model if done right.

Re: WASM Is the New CGI

#292

Post by therein »

thot_experiment wrote: post #280
therein wrote: post #275

Earlier quoted context omitted.

Yeah very much different constraints. I would send a screenshot if I knew I could make it public because the results look spectacular. Rendering at 60 to 120FPS, perfectly smooth navigation, rendering even 10k OHLC candles without a hiccup.

Don't worry I'm ok without having my eyes burned out by the lack of proper subpixel AA on your fonts. :P 10k candles at 120 fps seems like you could absolutely do it in JS alone, though I suppose the app came first and wanting to deploy it to end users via a webpage is an afterthought. Tbh writing performant JS for something like this isn't fun so despite my comments to the contrary you're probably making the right c…

> 10k candles at 120 fps seems like you could absolutely do it in JS alone

I think so too. I think everything we have is entirely possible to achieve in JavaScript but you're spot on, writing performant JS like this isn't fun and harder to maintain.

> Don't worry I'm ok without having my eyes burned out by the lack of proper subpixel AA on your fonts. :P

Fair fair. It is definitely happening, more noticeable in certain situations. :)

Re: WASM Is the New CGI

#293

Post by kaba0 »

nox101 wrote: post #246
kgeist wrote: post #103

Earlier quoted context omitted.

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…

yes you're missing something. Java applets and flash outside of any security and they ran the users code in that insecure environment WASM, in broswers, runs entirely inside a secure environment with no access to the system. js->browser->os | +--Flash/java-->os vs wasm->browser->os further. WASM and Js are in their own process with no os acesss. they can't access the os except by rpc to the broswer flash/java tho, ra…

Seems like a trivial thing to fix though, it was a lack of will over an explicit design tradeoff. At Applet’s time there was simply no such API surface to attach to and make useful programs.

Re: WASM Is the New CGI

#294

Post by kaba0 »

jeberle wrote: post #273
flohofwoe wrote: post #269

Earlier quoted context omitted.

Signed and unsigned are just different views on the same bits. CPU registers don't carry signedness either after all, the value they carry is neither signed nor unsigned until you look at the bits and decide to "view" them as a signed or unsigned number. With the two's complement convention, the concept of 'signedness' only matters when a narrow integer value needs to be extended to a wider value (e.g. 8-bit to 16-bi…

CPU instruction sets do account for signed vs unsigned integers. SHR vs SAR for example. It's part of the ISAs. I'm calling this out as AFAIK, the JVM has no support for unsigned ints and so that in turn makes WASM a little more compelling. https://en.wikibooks.org/wiki/X86_Assembly/Shift_and_Rotate

Well, it has compiler intrinsics for unsigned numbers, for what it’s worth.

Re: WASM Is the New CGI

#295

Post by iainmerrick »

titzer wrote: post #129
iainmerrick wrote: post #117

Earlier quoted context omitted.

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 under…

I stand corrected! That’s great information, thanks. I didn’t know JVM bytecode had so many problems.

Re: WASM Is the New CGI

#296

Post by kennu »

In my view, the big promise of server-side WASM is to have an evergreen platform that doesn't need regular updates to the application. Just like HTML web pages work "forever" in browsers, WASM-based applications could work forever on the server-side.

Currently it is a huge PITA to have to update and redeploy your AWS Lambda apps whenever a Node.js or Python version is deprecated. Of course, usually the old code "just works" in the new runtime version, but I don't want to have to worry about it every few years. I think applications should work forever if you want them to, and WASM combined with serverless like Lambda will provide the right kind of platform for that.

Re: WASM Is the New CGI

#297

Post by chubot »

randomdata wrote: post #265
chubot wrote: post #261

Earlier quoted context omitted.

FWIW I agree with you -- serverless does not refer to "web server", it refers to "linux server machine" (whether it's physical or virtual) You don't care about the specific machine, the OS kernel, the distro, the web server, or SSL certificates when you're doing "serverless" And the SAME was true of "PaaS" This whole subthread just proves that the cloud is a mess -- nobody knows what "serverless" is or that App Engin…

> it refers to "linux server machine" (whether it's physical or virtual) No, "server" most definitely refers to software that listens for network requests. Colloquially, hardware that runs such software is often also given the server moniker ("the computer running the server" is a mouthful), but that has no applicability within the realm of discussion here. If you put the user in front of that same computer with a ke…

fly.io is "serverless", but there are HTTP servers inside your Docker container, so I don't agree -- in that case it refers to the lack of pinning to a physical machine

https://fly.io/blog/the-serverless-server/

Pretty sure Lambda has an option for that too -- you are responsible for the HTTP server, which is proxied, yet it is still called serverless

---

On the second point, I wrote a blog post about that - https://www.oilshell.org/blog/2024/06/cgi.html

It would make for a much more interesting conversation if you cite some definitions/sources, as others have done here, rather than merely insisting that everyone thinks of the terms as you think of them

Re: WASM Is the New CGI

#298

Post by adamc »

kaba0 wrote: post #282
adamc wrote: post #241

Earlier quoted context omitted.

But web pages were not so sluggish, hence people chose them over using applets.

Web pages at the time could at most , its interactivity was extremely limited compared to what we have know. Meanwhile a java applet could include a full-blown IDE/CAD/what have you

Well, web pages could submit forms, which was the main thing. I remember working on apps where we went with web pages because applets were too slow, regardless of the features we gave up. Images were generated on the back end instead, for example.

Re: WASM Is the New CGI

#299

Post by jauntywundrkind »

VyseofArcadia wrote: post #286
jauntywundrkind wrote: post #264

Earlier quoted context omitted.

These are all the views of a fossil. Maybe some truth, historically, but years out of date. Want an offline app? Possible for a long time, build a local-first app. Don't want to build a client-server system? Fine, build an isolated webapps. There's so many great tools for webdev that get people going fast, that are incomparably quick at throwing something together. It's just bias and ignorance of an old crusty compla…

These are all the views of someone who is hopelessly naive. Maybe some truth, but ignorant of where we came from and how we got here. This is a diseased view, is reprehensible, small minded, and aggressively mean, and it's absurd given how much complexity has been poured into making computers do simple things in the most complex way possible. My man, I am not a fossil. I came of age with web apps. But I am someone wh…

> Browsers are massive, complex, and resource hungry. Sure, I'll just run my application inside another complex application inside a complex OS. What's another layer? But actually, raw JS, HTML, and CSS are too slow to work with, so I'll add another layer and do it with React.

That's just your opinion, and you're overgeneralizing one framework as the only way.

A 2009 mobile phone did pretty damned awesome with the web. The web is quite fast if you use it well. Sites like GitHub and YouTube use web components & can be extremely fast & featureful.

Folks complain about layers of web tech but what's available out of box is incredible. And it's a strength not a weakness that there are many many ways to do webdev, that we have good options & keep refining or making new attempts. The web keeps enduring, having strong fundamentals that allow iteration & exploration. The Extensible Web Manifesto is alive and well, is the cornerstone supporting many different keystone styles of development. https://github.com/extensibleweb/manifesto

It's just your opinion again and again that the web so bad and ke, all without evidence. It's dirty shitty heresay.

Native OSes are massive, complex, and resource hungry and better replaced by the universal hypermedia. We should get rid of the extra layers of non-web that don't help, that are complex and bloated.

Re: WASM Is the New CGI

#300

Post by randomdata »

chubot wrote: post #297
randomdata wrote: post #265

Earlier quoted context omitted.

> it refers to "linux server machine" (whether it's physical or virtual) No, "server" most definitely refers to software that listens for network requests. Colloquially, hardware that runs such software is often also given the server moniker ("the computer running the server" is a mouthful), but that has no applicability within the realm of discussion here. If you put the user in front of that same computer with a ke…

fly.io is "serverless", but there are HTTP servers inside your Docker container, so I don't agree -- in that case it refers to the lack of pinning to a physical machine https://fly.io/blog/the-serverless-server/ Pretty sure Lambda has an option for that too -- you are responsible for the HTTP server, which is proxied, yet it is still called serverless --- On the second point, I wrote a blog post about that - https://…

> fly.io is "serverless"

Right, with the quotes being theirs. Meaning even they recognize that it isn't serverless-proper, just a blatant attempt at gaining SEO attention in an effort to advertise their service. It is quite telling when an advertisement that explicitly states right in it it has nothing to do with serverless is the best you could come up with.

Post reply on HN