How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?
Wasmer 1.0
41–50 of 168 posts
Re: Wasmer 1.0
#42Earlier quoted context omitted.
If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more p…
Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?
Canvas isn't far off. The web is excellent for the types of UI that people often want to build for application: nestings of boxes interspersed with text.
Re: Wasmer 1.0
#43Was reading through https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT... - what's the current status/eta of raw sockets? Last time I checked wasm consensus seemed to suggest they will never be supported?
Are you talking about the browser or other environments?
There is a proposal [1] for adding sockets to WASI.
This blog post [2] has some more background info.
Outside the browsers, you can always provide extra functionality yourself though by supplying host defined functions as imports. That looses the benefit of a standard API, but is fine for custom deployments.
[1] https://github.com/WebAssembly/WASI/pull/312
[2] https://radu-matei.com/blog/towards-sockets-networking-wasi/
Re: Wasmer 1.0
#44Earlier quoted context omitted.
The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know…
People (developers) want a target (sandbox) that is as "open" as their browser. This means that by definition the slightest presence of business-motives would ruin the entire idea (your example of Ubuntu's snap and Apple's iOS and Google's Android).
I think you're confusing two very different concepts - the fact the browser is sandboxed is orthogonal to its "openness." Sandboxes need not be open, and open platforms need not be sandboxed.
Fundamentally, sandboxes restrict the possible functionality of executable code to prevent it from violating some preconditions within the context a user invokes it. Rarely do developers desire that behavior (it makes it harder for your app to work!), and users complain about it too (when MacOS began requiring explicit permissions for many entitlements, many users complained about the constant nag screens). Browsers have historically needed to reinvent every wheel provided by operating systems to provide features developers require that can't work within the sandbox (cookies, websockets, etc) which prevented entire classes of application from existing.
Browsers have enormous business incentives behind them, I'm not sure why you think that ruins the idea. Google spends gobs of money to prevent anyone from developing a competing non-Google browser, for example. Apple bans any non-Apple browser from existence on iOS and iPadOS.
Re: Wasmer 1.0
#45Earlier quoted context omitted.
Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).
If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more p…
> but I am saying we had decades to do better and didn't
If you ignore everything outside the web, sure.
Games routinely render thousands of extremely complex objects at over 60 fps. The browser cannot animate a `height: auto` element or display more than a few thousand simple elements without stuttering.
Clearly we have done better. Just not on the web.
And don't get me started on actual complex UIs. TurboVision from the 90s, Qt and Delphi from early 00s had more power and ease to create complex layouts than anything the web can offer today. You can't even implement a proper accessible modal dialog on the web without tearing your hair out.
Re: Wasmer 1.0
#46How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?
Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC.
WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully even the full stable version is backwards-compatible with snapshot-1.
Re: Wasmer 1.0
#47Was reading through https://www.diva-portal.org/smash/get/diva2:1451494/FULLTEXT... - what's the current status/eta of raw sockets? Last time I checked wasm consensus seemed to suggest they will never be supported?
Are you talking about the browser or other environments? There is a proposal [1] for adding sockets to WASI. This blog post [2] has some more background info. Outside the browsers, you can always provide extra functionality yourself though by supplying host defined functions as imports. That looses the benefit of a standard API, but is fine for custom deployments. [1] https://github.com/WebAssembly/WASI/pull/312 [2]…
Yeh, this article kinda confirms what I've been thinking the past few years:
"Implementing a server requires additional API functions exposed - specifically, sock_bind, sock_listen, and sock_accept"
"And while implementing them is done similarly to what was described here so far, there is an underlying issue: there is no multi-threading support in WebAssembly"
Really surprised to see so many people talking this up to running many/most server-side applications with so many fundamental features missing.
Re: Wasmer 1.0
#48Earlier quoted context omitted.
If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more p…
> but I am saying we had decades to do better and didn't If you ignore everything outside the web, sure. Games routinely render thousands of extremely complex objects at over 60 fps. The browser cannot animate a `height: auto` element or display more than a few thousand simple elements without stuttering. Clearly we have done better. Just not on the web. And don't get me started on actual complex UIs. TurboVision fro…
You're talking purely about performance. Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. In many cases they aren't build on any kind of platform at all. They often have element/text positions hardcoded to a specific screen shape. Which is exactly what the browser spends most of its effort preventing: all sizing and positioning is determined automatically based on rules and content, which can be expensive to calculate, but is what makes it so robust.
Qt still exists. It's still being actively developed and still gets used for some modern software. It's actually a perfect stand-in for the current peak of native cross-platform frameworks. It's a contemporary of the web, it supports all the platforms, it has a rich feature set. It even directly supports several languages, something the web doesn't really do. And yet: it's only used in a very small fraction of the apps out there. Why? Because (if you ask me) it simply isn't as flexible or accessible of a GUI layer. It's a very performant GUI layer, and it works very well for certain types of applications. But the web works pretty well for all types of applications. And that's exactly my point.
Re: Wasmer 1.0
#49Earlier quoted context omitted.
The web is a great way to distribute native programs. Click a URL to download, then run.
I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.
That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.
Re: Wasmer 1.0
#50Earlier quoted context omitted.
Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).
First, Stockholm syndrome isn't a thing. Second, there were a bunch of alternatives and the Web won instead of them and not just because they weren't there. I know, some people like running around telling everybody Qt, GTK, Swing or whatever were or even are better, but they are seemingly not for the points that matter for most of GUI apps. But yes, we should make something better going forward.
> First, Stockholm syndrome isn't a thing.
Have you ever had a useful conversation by starting with this?