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

131–140 of 311 posts

Re: WASM Is the New CGI

#131

Post by oscargrouch »

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…

I worked on something in this space[1], using a heavily modified Chrome browser years ago, but I consider I was too early and I bet something in this lines (probably simpler) will take off when the time is right.

Unfortunately I got a little of a burnout for working some years on it, but I confess I have a more optimized and more to the point version of this. Also having to work on Chrome for this with all its complexity is a bit too much.

So even though is a lot of work, nowadays I think is better to start from scratch and implement the features slowly.

1 - https://github.com/mumba-org/mumba

Re: WASM Is the New CGI

#132

Post by swiftcoder »

curtisblaine wrote: post #106
swiftcoder wrote: post #97

Earlier quoted context omitted.

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...

But how do you do that without essentially downloading the whole social network to your local machine? Are other people's comments, quotes, likes, moderation signals something that should stay on the server or should be synced to the client for offline use? In the first case, you can't really use the social network without connecting to a server. The second case is a privacy and resources nightmare (privacy, because…

Usually folks looking for this sort of social network are also looking for a more intimate social experience, so we're not necessarily talking about sync'ing the whole Twitter feed firehose.

I don't think it's unreasonable from a resources perspective to sync the posts/actions of mutual followers, and from a privacy standpoint it's not really any worse than your friend screenshotting a text message from you.

Re: WASM Is the New CGI

#133

Post by pjmlp »

SkiFire13 wrote: post #57
pjmlp wrote: post #7

Earlier quoted context omitted.

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.

All of those bytecode formats were designed to support higher abstractions. WASM on the other hand was born from asm.js, which tried to remove abstraction to make code run faster. Ultimately the goal for WASM was to run code faster, hopefully near native speed, which is not a priority for all the bytecodes you mentioned. If that wasn't needed then Javascript would have been enough.

Revealing lack of knowledge, some of those bytecode formats were designed for low level languages like Pascal, Modula-2, C, C++, among others.

Re: WASM Is the New CGI

#134

Post by pjmlp »

thot_experiment wrote: post #29
pjmlp wrote: post #7

Earlier quoted context omitted.

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.

The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.

Applies to most bytecode formats, it is a matter of implementation.

Re: WASM Is the New CGI

#135

Post by pjmlp »

iforgotpassword wrote: post #41
pjmlp wrote: post #7

Earlier quoted context omitted.

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

Same premise of many other bytecode formats since 1958, a matter of implementation and marketing.

Re: WASM Is the New CGI

#136

Post by afiori »

Starlevel004 wrote: post #101
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…

You can't easily decompile WASM so it makes it harder to block inline ads.

You can alreay compile javascript into https://jsfuck.com/ and you could also very easily recompile the wasm into js.

Obsuscation and transpilation are not new in jsland

Re: WASM Is the New CGI

#137

Post by pjmlp »

pdpi wrote: post #51
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…

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…

WasmGC is there no matter what, unless we are talking about an incomplete implementation, also plenty of linear memory based bytecodes since 1958.

Re: WASM Is the New CGI

#138

Post by pjmlp »

IshKebab wrote: post #44
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.

Only because Mozilla refused to adopt PNaCL.

Re: WASM Is the New CGI

#139

Post by artikae »

justanotherjoe wrote: post #122
DougMerritt wrote: post #80

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'.

All it takes for something to be replaced is something that does the job better. You can only really apply your definition in hindsight, after something has stood the test of time. You can't tell the difference between sails and wheels until after the rise of the steam engine.

Re: WASM Is the New CGI

#140

Post by flohofwoe »

iainmerrick wrote: post #119
singularity2001 wrote: post #66

Earlier quoted context omitted.

except that WASM has a huge classloader / linker problem: It's still very hard to combine two wasm files into one and get the memory merger right. Maybe component model can fix it but it comes with so much bloated nonsense that an adaption in Safari might take forever.

It's a problem for some use cases, but is it really a "huge" problem in general? You can't easily publish a library in WASM and link it into another application later. But you can publish it as C++ source (say) and compile it into a C++ application, and build the whole thing as WASM. What are the scenarios where you really really want libraries in WASM format?

The only situation I can think of is a plugin system for native applications, where 'WASM DLLs' would solve a lot of issues compared to native DLLs.

But those WASM plugins would be self-contained and wouldn't need to dynamically load other WASM 'DLLs', so that situation is trivial even without the WASM Component Model thingie (which I also think is massively overengineered and kinda pointless - at least from my PoV, maybe other people have different requirements though).

Post reply on HN