> Currently, Ruby fully supports the WebAssembly System Interface, WASI 0.1. WASI 0.2 which includes the Component Model is already in the alpha state and a few steps from completion. Once WASI 0.2 is supported it will eliminate the current need of recompiling the whole language every time you need to add new native dependencies: they could be componentized.
Or he could use replit which did go to the trouble of implementing a web backend for the tk wm.
There's also a gtk backend for tk (gtkttk), as convoluted as that sounds, so presumably you could use gtk web implementations (broadway) behind that...
In any case, Tk doesn't require an OS to do window drawing, it's entirely up to how things are hooked up.
That doesn't render a web interface, it just bundles the platform specific executable so you can run scripts embedded in the web browser. Kinda like a hole in the web page into which an exe is shoved.
Also, no browser runs that stuff anymore, and it wouldn'tve been safe to run even when they did.
Yeah this is sort of the point. Much of JavaScripts ascendancy is simple it’s monopoly on being able to run native in browser. Wasm lets you bring other languages to the browser.
The author didn’t mention using the browsers web console or “how do I use rails console in the browser with wasm?”. That’d be interesting to me. Can I write Ruby in the web console and see things change live in my wasm app?
A common usecase for offline-first mobile app situations is shared business logic, especially for validations. Being able to validate client-side and detecting issues without a server dependency is a nice boost to UX.
Great; now all we need is client side integrity verification with super strong DRM and virtualization techniques; and companies will finally start eliminating most of their compute bills by running the server on the client. Bookmark this comment, we’ll see where we are in 2045; I wouldn't rule out WebAssembly becoming a hardware feature at that point. (I never said I like this - but stupider things have happened, like Electron apps; this would just be the finishing of the circle with web development becoming the new native.)
For all "typical" web apps (and certainly the ones for which you'd use RoR) you still need some kind of server providing some kind of central database.
Assuming you don't want to just leave 5432 open and expose your Postgres server for the world to rawdog, you are going to need some authentication and other auth logic on the server side.
So, I don't see companies really rushing to deploy apps this way.
Fun fact, PG supports TLS auth[1] which one could import[2] into a browser context to hypothetically expose it to WASM. I am waving hands here, because I've never used the Web Crypto API in anger, and for sure am not the target audience to run RoR in the browser
I hear you about purposefully leaving 5432 open to the Internet, because "C is gonna C" but I just meant much like its "PasswordAuthentication no" friend, sending passwords over the wire is not the only form of auth nowadays. There's a very real chance putting pgbouncer in front of it[3] would reduce the blast radius of exposing C to the Internet. I was hoping pgcat (written in rust) would be a suitable alternative but it does not seem to allow TLS auth
And you could theoretically just have Postgres be the app server -- you can even write pg stored procedures in friendly languages like Python.
(Tangent: In fact, I sort of used to develop that way with SQL Server back in the early 2000s. VBScript and PHP sucked, and databases in my apps were sometimes shared between different apps, so I liked to put a lot of the data-level logic in stored procedures. You need a migration strategy of course but that was honestly a perfectly fine way to develop. I was productive and remember those days fondly. I didn't expose SQL Server to the net directly, but it was sort of the app server, and stored procedures can be extremely performant since there's no round-trip)
But I mean...
Still. You need private application code somewhere. At a minimum you need it to ensure that users aren't doing and seeing things they're not supposed to do and see. And also to connect to auxillary services e.g. payment processors -- you need to store the credentials somewhere private.
