Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
This is posed as a pretty heavy counter, "foo foils this," but it's only been to degrees so far, and the extend we're going is radically different where we're headed. Certainly hacking modern webapps isn't the most fun, but often it can be! Even if the app in question is pretty shitty & mean about how they distribute their bundles.
Backend APIs have often been one of the webs best points, not it's hinderances, in terms of explorability. Certainly it conceals what happens behind the scenes, but the "single page app" model leaves an intrepid DevTool user with at least as much power as whatever the webapps inbuilt capabilities are, and far less handcuffs. Huge numbers of sites have "unofficial" clients, since it's so stupidly easy to open devtools, look at network traffic, and write some instrumentation/alter stuff around a little and see what you get. Since the normal app behavior has to transit a network barrier, and that's quite visible, it very quickly lights up & shows the interface. Where-as in many native apps, state is just latent in the process, suffused everywhere, & deeply murky & unclear.
Less web-ish things can be problematic. Folks who just open websockets & start speaking TCP protocols aren't very "web" (even though they use a tool the web happens to have). GraphQL is maybe somewhere inbetween: there's still enough regular evidence, but everything is a little different & normal webdev tools need a lot of extra help to do ok. GraphQL is a partial stray from the paved webdev path.
Ideally everyone should ship source maps. But there's a lot of negative behaviors against this, mostly for no real good cause. Just turning on the pretty-printer for the mangled/uglified source code, & debugging some DOM events is often enough to figure out what a thing does pretty quickly, to get into the architecture pretty easily, even when it is all minified. Often the minification is only partial, only extends so far, as we talk to data sources & storage; we can start to see properties & json that look regular, that give us meaning & clues. Minification mainly serves the users, by being very mildly smaller than compression; rarely is it an active defense again comprehension, and rarely is that active defense effective; everything is too much the same, the patterns are all common, the platform is all normal.
How close or how far we stray from Babel matters. "The platform is all normal" is being put to the sword by these upstarts, with amazing zeal & excitement. There are absolutely going to be tons of good normal not too wild webassembly codebases out there that at least leave the web platform as primary, that are advanced & not javascript but are at least web-like, and that'll be a bit harder to understand & decrypt & learn about (to perform natural science on). Understanding these is going to require a more advanced capability. It'll feel a bit more like breaking out Ghidra & wandering in (https://github.com/NationalSecurityAgency/ghidra), than DevTools, even with the most minified websites we have today.
But there are also going to be countless new virtualizing universes of compute that simply do not care at all, that are micosms until themselves: Inland Empires, as Disco Elysium characterized. The level of Ghidra disassembly skills required to get anywhere is going to be expontentially higher in many wasm realms.
Wasm is a big turning point, is definitely a fall of Babel. Others have pointed out & absolutely right, many many wasm users will still embrace the web platform, it's higher level "text/html" mime-type underpinning, it's apis. Wasm will amplify the challenge, even here. Right now there's a ton of glue-code projects- Rust's wasm-bindgen is a big glue-maker, and simply wrapping our heads around the multi-verse of code-spaces running, wasm-bindgen bridging us between page space and wasm code space, is going to be an intense new experience, but in many cases it will be fine & managable. DevTools will help. Hopefully source-maps come into vogue somehow. But there will also be uncountable infinite reaches of virtualization, where people are just off doing something entirely different & else, where disassembly requires understanding mountains of virtual machine & rendering engines to get anywhere, where nothing makes sense, and reason & natural science & understandability of the world about us is truly lost.
There are challenges today, but it's overall ok, and tomorrow looks harder, but there's still lots of room for hope, but there are also spreading reaches of dark, where it's likely understanding what happens will converge with impossibility. The web today is murky, but in no way resembles that darkening.
Hello world with production artifact and Binaryen optimization produces a 128K Wasm file for now for https://github.com/vmware-labs/wasm-languages/tree/main/kotl..., but the Kotlin/Wasm team has not tracked those data points recently so there may be footprint regressions to fix. They are going to have a look and also to enable Binaryen by default for production artifacts.
This is indeed a very important point, and I care deeply about that.
For Compose for Web, there has been I think a lot of debate to decide if the Web rendering should be Canvas or DOM based. At least for now, it seems the official support is focusing on Canvas rendering for pixel-perfect rendering, and it already works with Koltin/Wasm, see https://news.ycombinator.com/item?id=34779746. This choice is probably driven by Kotlin current mobile app main use case.
But via community-driven project like https://github.com/varabyte/kobweb or https://github.com/mpetuska/kmdc, Compose for Web can also be a good Web citizen and perform DOM based rendering.
This is indeed a very important point, and I care deeply about that.
For Compose for Web, there has been I think a lot of debate to decide if the Web rendering should be Canvas or DOM based. At least for now, it seems the official support is focusing on Canvas rendering for pixel-perfect rendering, and it already works with Koltin/Wasm, see https://news.ycombinator.com/item?id=34779746. This choice is probably driven by Kotlin current mobile app main use case.
But via community-driven project like https://github.com/varabyte/kobweb or https://github.com/mpetuska/kmdc, Compose for Web can also be a good Web citizen and perform DOM based rendering.