Hacker News new | past | comments | ask | show | jobs | submit login

> or shipping an entire browser per app. Instead, one ships the app to the browser.

Yes. Instead you're shipping the entire app, including the whole graphical framework, with every app.

To quote Figma, "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser." https://www.figma.com/blog/building-a-professional-design-to...

Are you sure this is what you want?




It makes writing the desktop apps easier, instead of using a separate framework for the web and another one for the desktop (which costs engineering time and money), or, again, shipping an entire browser per app (which saves engineering time and money but is a bad experience for the end user). You can't escape this complexity, there's no way around it if you want to make cross platform apps.

Now if you just want to make a website or webapp (with no intention of making it cross platform), stick with the DOM, it's not going anywhere.


> or, again, shipping an entire browser per app

You're still going to ship basically an entire browser per every app in the browser. Where do you think the new glorious UI for your app is going to come from with WASM?


Why would you ship an entire browser per app? Not sure what you mean, you just ship the application code. On desktop you use the native language code, or if you really want, a native WASM runtime that exists outside of the browser, such as Wasmer or Wasmtime.


Yes, you'd need to ship the entire app. Per every web app per every user.

So, for example. The currently featured app in iOS app store is Plane Finder. It weights 99 MB. [1]

So your proposal now is to ship those 99MB to every user of the web app written in WASM. However bloated we think modern web apps are, they are not even close to these numbers.

https://apps.apple.com/se/app/plane-finder-flight-tracker/id...


Yes? How do you think applications work on non-web platforms?

If you want a thin client app, put all your logic in the server side and don't ship as much code on the client side, whether it be in the DOM or WASM.


So you're sating that users complain that they have to download hundreds of egs of Electron per each app, so your proposal is... to download hundreds of megs of app over the browser anyway.


No, that is not my (or most people's) complaint about Electron. The main complaint is that Electron is slow, and takes up obscene amounts of memory. RAM, not ROM, is the issue.

In contrast, I can have native performance via WASM, even if the binary size is large (it will get smaller over time, but even then, most people don't really care about binary size, they care about speed).


But I definitely don't want to load 100s of MBs for web apps. And compiled wasm cache in browsers isn't unlimited, so it will get purged, and you'll have to re-download apps again.


Fortunately this is a problem that can be solved the same way as regular desktop apps, ie not purging but having a diff based auto updater.


Apps have no control over the browser's compiled cache.

If it's, say, 300 MB, 3 apps will be over that limit, and the fourth will purge at least one of them.


Do you really believe that browser makers will not implement optimizations if we start getting pure WASM apps? They will add long term storage of the app binary, auto updates via diffs, data streaming, etc. Think of them as desktop apps, but they just run in the browser instead.

Why not just use desktop apps you ask? Well, people apparently don't like desktop apps, they want to work in the browser, so we have come to this roundabout way, using WASM.


> Do you really believe that browser makers will not implement optimizations if we start getting pure WASM apps?

They've already done that. That's why compiled wasm storage exists.

Streaming, diff updates etc. are not the property of the browser, but of the app.

And, again, browsers cannot have unlimited storage for downloaded apps.

> Why not just use desktop apps you ask? Well, people apparently don't like desktop apps

People do want to use desktop apps. Instead of actual desktop apps we get shitty web apps running on Electron.


I think you are missing what I'm saying. At the end of the day after this WASM business gets settled, the browser will just be the runtime for WASM apps. Nothing will be stored "in the browser," it will be stored on the user's file system, so I'm not sure why you say browsers won't have "unlimited storage," they'll be able to access as much storage as they need, same as downloading a desktop or mobile app.

When WASM becomes popular enough, browsers will indeed implement streaming and diff update optimizations, just as HTTP 2/3 does today for DOM based sites and applications. Browsers will become the unified runtime for WASM apps, so they will support the common operations and optimizations for such apps.

> People do want to use desktop apps. Instead of actual desktop apps we get shitty web apps running on Electron.

Yes, that is my point. WASM will make these apps fast because they are actually compiled rather than be interpreted by the JS JIT as well as shipping an entire browser per app.

I am honestly not sure what you're arguing for. You talk about shitty Electron apps, which I agree with, but then don't seem to have a solution, which in my case is WASM apps on the browser or via a runtime like Wasmtime. What is it that you actually want?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: