1. 24
  1.  

  2. 2

    I’m watching Wasm with interest, but I’m nowhere near ready to jump in.

    Specifically, I’m curious if we’re going to head down the route we’ve gone over and over: create a new sandbox, hype it, develop tools for it, continue to tweak the experience, then in the end we’ve got yet another architectural tier we have to understand and plan for.

    I remember a long time ago reading a book that advocated seven (!) layers of objects between the persistent datastore and the user. Are we going to see something like MVVMVM?

    Still, looks hella fun to play with.

    1. 4

      I played with wasm over the weekend too (and blogged about it here: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html#webassembly-in-d ), it is kinda interesting to play with but I’m still not sure there’s a real use case… I’m not sold on SPAs at all (almost all of them I see would be better made as a traditional server-side site) and it remains awkward and bloated for progressive enhancement on them.

      But it is kinda cool to demo desktop applications to users by sending them a link in the web browser. Possibly it will be a convenient way to send little games to mobile phones too.

      Still though it is kinda fun, especially since it is an excuse to go kinda-sorta “bare metal” and write the kind of code you don’t get to write everyday :)

      1. 2

        I know what you’re saying and I mostly agree: any app of serious complexity is going to require some sort of tiering, and it’s much more useful to go to a full-fledged back-end than it is to start bit-twiddling.

        Having said that, I think I can see a business case. There are a lot of developers developing apps suffering under the plantation/walled garden system we now have called app stores. If they could make visually-complex apps (read: they look cool like video games) and deploy them in one page, they could easily skip the registration, install, dev fees and everything else that goes with app development.

        I have no idea if that’s possible. I know that if I started playing around with the tech, that would be the type of UX I’d be shooting for.

        1. 2

          One thing I never seen is some native widget/UI framework that looks even remotely ok. GTK, Qt, Swing etc all are great in theory but looks absolutely shocking in practice.

          I know they can be skinned, but why can’t it at least somewhat tasteful out of the box?

          I think that unnecessarily forces a lot of people down the electron route cause with CSS we know how to make a design system from scratch that looks good.

          An open-source tasteful cross platform UI toolkit with HDPI support and maybe GPU accelerated. Is it too much to ask? :)

          1. 2

            An open-source tasteful cross platform UI toolkit with HDPI support and maybe GPU accelerated. Is it too much to ask? :)

            Don’t forget accessibility. IMO, the problem is that a fully featured UI framework that works for everyone is such a big project that it can probably only be done with corporate backing.

            1. 1

              What counts as tasteful is fast-moving, subjective, and application-specific. Default UI design is rarely updated, designed by committee, and supposed to be used by many different applications. It’s not like the HTML defaults are very good; it just benefits from having lots of good templates.

              Also, a lot of “tasteful” UI work is barely usable designer ego stroking. Most applications, electron-based or otherwise, would be better off if they were less tasteful and more usable.

            2. 1

              I have no idea if that’s possible. I know that if I started playing around with the tech, that would be the type of UX I’d be shooting for.

              It’s possible, just not with Rust yet. Maybe with Java applets though :-)

            3. 1

              SPAs may not be the most efficient design but until a server-side framework gives me the same integrated unit testing and template rendering tests that something like vue or react does then you can’t convince me that server-side is better. Those benefits properly used far outweigh the costs of SPAs. Full unit and integration tests of my UI without having to use a broken tool like selenium is worth so much more.

            4. 2

              I think the v1 of WebAssembly seems to be done really well, but I am sort of skeptical of the new bridges to JS, with garbage collection, exceptions, etc. It’s like a whole new VM.

              In other words, they have VM with a C memory model, and they also need a VM with a JS-like graph-of-objects memory model, but that claims to be language independent. And the exceptions stuff seems to be aimed at making C++ efficient.

              And all the wrapper generators that seem to be arising. Although I understand why these problem have to be solved.

              It’s very difficult to make that stuff truly language independent – you will end up with some bias, likely toward JS.


              But I think there are actually several use cases for WASM in a shell. I wrote a little bit about that here:

              http://www.oilshell.org/blog/2020/07/ideas-questions.html#a-shortcut-for-implementing-an-engine

              So the regex engine is one (although the thing I outlined is probably way more general than necessary). Doing arbitrary string manipulations in a non-crazy syntax is another. And writing stdin/stdout filters is another. The good thing about those applications is that you don’t need a JS-like graph-of-objects memory model. You just need the original wasm memory model – arrays of bytes.

              Of course this is all totally speculation and I probably won’t have time to work on it… But if anyone has experience and interest, feel free to ping me :)

              And I mentioned problems: provenance is one. Another one is debugging. I have been using GDB a bunch lately in plain C++ code, and I doubt that the experience of debugging WASM is even up to GDB levels. Although I’d be interested in pointers on that.

              Oh and the benefits I see are: capability-based security which is very relevant to shell, runtime compilation, and (in theory) portability. I guess I would provide a bare bones WebAssembly runtime with bindings to the file system or something. Many tools invoked from shell simply access the file system and not much else, e.g. the re2c compiler itself, a C compiler, etc. You don’t need graphics APIs or anything like that.