> 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.
Seems like tenderlove will be happy: https://x.com/tenderlove/status/1521961429481361408?mx=2
These are all so fun and exciting to me. The kinds of things I dreamed of back in the late 1990s world of extensive browser plugins.
There is a port of PHP to WebAssembly a lot of tools are using for interactive playgrounds.
I myself compiled a JavaScript ES5 runtime to WASM just for fun a couple of years ago.
The progress on WASI support is very exciting!
> 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.
Title is: Ruby on Rails on WebAssembly, the full-stack in-browser journey
thanks mate
https://hn.algolia.com/?q=Ruby+on+Rails+on+WebAssembly%2C+th...
Nice work.
Not exactly related to Ruby on Rails, but why doesn’t there exist a way to run a Python TKinter app in the browser using WASM?
I have a medium sized dependency-free TKinter program written in Python, and AFAIK there is no way to run it in the browser.
Because Tk draws using native OS APIs. So you’d need to run the whole OS in the browser.
Or you could implement a new backend for Tk to draw using some web APIs
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.
It’s been awhile, but if you have a browser old enough, here the browser plug-in for TCL/TK: https://www.tcl-lang.org/software/plugin/
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.
Hmm! I wonder if there’s then a way to bundle something like ViewComponents as WASM, and use them as a React replacement?
What would be the user case of running in your browser?
Outside of making something - it’s very useful for setting up a quick project.
Stackblitz did this with Node (aka their Web Containers).
You could make a new project very quickly and prototype an idea. When finished, download it off the browser and deploy it.
You can create a SaaS with fully private data on the client side while using both local operations and managing control via API calls.
Think of it like a mobile app, but for the browser.
> with fully private data on the client side
How is the data fully private?
FWIW, I read that to mean "not shared with the backend".
Oh! Right, I see. I'd have thought we could do that today in Typescript or something, but maybe they have something extra in mind.
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
1: https://www.postgresql.org/docs/11/auth-cert.html (it's the earliest version still linked on their site)
2: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
3: https://www.pgbouncer.org/config.html#authentication-setting...
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.
Sooo… dies it run faster than actual Ruby?