well, there is a promising SQLite wasm on deno that makes it system-independent and can be sandboxed.
You could find it less useful in front-end, but it truly is a game changer for back-end usage. No need to tie in your app to a runtime anymore.
What you described is a modern SPA - just a bunch of static JS files served by a CDN for the most part. WASM cannot do more than what JS does today (and in the future) - for the most parts WASM is just making calculations in JS faster. So this question is not really specific to WASM.
Whether written in JS or WASM, most web apps will always require a backend. You cannot just allow a client side app access to a database. Or trust the client app to not be used by malicious actors - i.e., replacing your business logic JS with custom logic and uploading invalid values to the database.
So you'll always need a backend server to validate the client's logic for security purposes and integrity as well (i.e., some browser behaving differently from others).
PWA + WASM has allowed some logic to move from server side to client side but you will always require a public, secured interface for an online service, in the form of an API (REST/GraphQL/gRPC/OData). Apps that do not require such an online service (eg.: squoosh.app) can of course be written just as a bunch of static files running without a server. A lot of these 'calculator' or image editing websites do their calculations on the client devices and can run completely offline if they add a PWA manifest and a service worker - WASM has nothing to do with this since both WASM and JS can run on offline apps.
A lot of apps that are online services (Reddit's new interface for example) already have their UI ready to run offline, like a native mobile app, since it's static HTML5/JS/CSS cached in the browser. The JS just won't be able to show any content when there would be no connection to a server.
Wat?
Heaps of companies are using wasm in production without issues, take for example Figma have been doing it for years: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
> is there a general plan to have IO/DOM manipulation with wasm only when it becomes ready for production level code or javascript glue will be kept as the method to invoke wasm functions?
I've read in multiple places on the internet that it's on the roadmap but when I look for it i don't see it. It seems to be folded into the garbage collection section, which worries me. Why would garbage collection be required to interact with the DOM?
Kevin Hoffman published a popular book:
Programming WebAssembly with Rust: Unified Development for Web, Mobile, and Embedded Applications
He's working on an updated edition now.
Yeah, I know exactly what you mean. This would be a possible next step for my project, but not really needed for more that’s why I simply precompile and ship the wasm file every time.
Perhaps, you can go check out these guys here: https://qvault.io/2020/09/23/running-go-in-the-browser-with-wasm-and-web-workers/ I think they are working on something that involves automatic wasm compilation based on user interaction.
The easiest way I can think of is as follows: 1. Create a simple API endpoint that when called, compiles the wasm file on the server side 2. restart the web worker that communicates with the wasm runtime. It will reload the new wasm file.
Well, you got the official docs for wasm.
Then there are a couple of papers on more or less specific topics published. Microsoft Academics is a Good place to start.
there are a couple of interesting conference talks available. As well as some good intro videos on YouTube.
You should not bother writing your own compiler ... unless you are really interested in that topic.
If you already know c++, stick with it. The toolchain should be pretty good.
Don’t think there is any special JS knowledge necessary — just look at some basic examples and you will see, that you will only need some boiler plate glue code.
> if only there was a way to communicate with the browser APIs that didn't involve writing tons of wrappers
> Probably not gonna happen any time soon.
I agree, it's not on their list of post-MVP features:
http://webassembly.org/docs/future-features/
Although, I do think this is an area where the community can fill in the gaps.
Nice. Again, I'm also the kind of person who wants to know how things work under the hood.
I'm not personally too familiar with Rust, but these people are: https://github.com/rustwasm/team. They have a discord and everything. There's also the WebAssembly discord server, https://discord.com/invite/nEFErF8, which has some core wasm people on it for more general wasm questions.
You could also start learning how Rust works without wasm, or wasm without rust. I find it easier to learn one new thing at a time (though I rarely follow this advice...)