I wasn't checking this slack for some time, but now that I did, I discovered that it passed 1,000 members, really cool! 🎉 I stumbled upon Progressive WebAssembly Apps (PWAAs) yesterday and thought that they might be of interest for members of this group. It's basically just combining Progressive Web Apps (PWAs) and WebAssembly. The main selling points: • Cross-Platform (runs in every modern browser) • Native feel (mobile system ui integration, add to home screen, offline functionality, ...) • Installation as easy as bookmarking a website • Near-native performance using WASM For me, this feels like it could become the go-to solution for cross-platform apps. I'll probably write a Todo-PWAA (I need a replacement for Wunderlist anyway :P) to test this approach. Recording: Slides: https://alexkehayias.github.io/webassemblysf-presentation-20190820/

There seems to be a general trend of browsers adding OS features and OSes adding sandboxing features

What’s the code size for a minimal PWAA producing “Hello world” ?

@Konrad Hinsen "The 'Seed' example app uses the

seed

framework and clocks in at ~600kb (including ~300kb for an icon and splashscreen), works offline, and can be installed to your homescreen on iOS or Android devices." - https://woz.sh/

@Felix Kohlgrüber Thanks for the pointer! Those numbers look reasonable for the 21st century.

The main limitation imo is storage. Both localStorage and IndexedDB have very low size caps (typically ~50mb) and are subject to random deletion whenever the browser feels like it. Also the IndexedDB api isn't great for building a decent query language on top eg transactions are already hardcoded in, every method is asynchronous, there isn't a proper seek method. Overall I get the impression that PWA are still very much built around an online-first model where all your data lives on a server somewhere but you might cache stuff for the occasions where you're offline for a few minutes. It doesn't seem feasible to produce a good offline-first experience on the web today.

@jamii Thanks for your comments, that's an area I haven't looked into yet. For what I'm planning to build, 50mb shouldn't be a problem, but I can see that this would be limiting in other cases (e.g. music app). Regarding persistence / durability, one could argue that smartphones and tablets aren't the right devices for persistent and durable storage anyway. The get dropped, drowned or stolen which makes storing data on them only a bad idea. My current thoughts are that an "end-user home server" and devices connected to it might be the best solution. This would allow for backup, synchronization, availability and scalability of stored data without giving it into the hands of who-knows-whom. But that's another discussion ;-) Back to the point: I could imagine that we'll be able to use WASI within PWAs some day. If I remember correctly, this could allow fine-grained file system access for apps which should fix the current storage problems.

I used to think "the web" was the future of apps. But nowadays I think it's an unsustainably complex Tower of Babel. Are we really going to be building on top of all these poorly-thought-out Web APIs in 50 years? That's a horrifying thought. We should probably keep a couple of APIs at most.

I agree with Nick, though I think apps-on-demand and cross-platform nature of web apps is definitely a step toward the future

I'm hopeful for something emerging out of wasi. The killer feature of the web for apps is easily distributing sandboxed cross-platform code, so separating that out into a platform that supplies just those things and doesn't pile a bunch of compulsory choices on top seems like a win.

one could argue that smartphones and tablets aren't the right devices for persistent and durable storage anyway.

The idea of offline-first apps is that they are completely capable without a network connection, and just use the network for backup / collaboration. Email is a perfect example - with native clients I can search and write emails offline and then sync up when I'm back online, even though the canonical copy of my inbox lives on a server somewhere. Web-based email never seemed to deliver a decent offline experience. A side-effect of building stuff in this way is that offline-first apps typically load faster (because the data is already here), are more responsive (don't have to wait for a network roundtrip to eg autocomplete an email address) and are easier for the user to extend/compose (because all the data and code exists locally already). The future I'm hoping for is we keep the ease-of-distribution of the web but allow building offline-first apps that are actually able to use the full capabilities of the machine. My phone has a 128gb drive. I send/receive ~0.3gb of email per year. Keeping a synced copy really shouldn't be a problem.

@Nick Smith I also wished there were less APIs solving the same task, less poor abstractions and especially less tooling (https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f). But on the practical side, cutting down on existing stuff is pretty hard. Who would decide what to keep and what to do with all existing projects using some tech you'd like to get rid of? In theory, I'm totally with you (together with probably most web devs) in theory, but achieving practical improvements is the real challenge here. I Hope that WASM/WASI will be the kind of restart we all want, but let's see. Another thing is that the web isn't the only platform suffering from growing complexity. I guess that if I wanted to write a native Android app, it wouldn't be much easier than using web tech. The only thing would be that I had to write like 5 other apps for the other major platforms and deal with all the little differences between them. Compared to that, a single web app that can be installed on all platforms and works consistently sounds pretty interesting.

if the browser deleted data it could be restored from the email-server

Only if the server has already synced that data. Otherwise it just deleted some emails that were queued waiting to be sent and undid all the changes to my inbox. And even if there is no data loss, deleting the data assumes that I'm almost always online and that it's only stored locally as an optimization. I have this problem in practice with eg spotify which occasionally clears all downloaded music for some reason, usually just as we're about to drive into the mountains and out of cell phone coverage. Or when I'm abroad and don't have mobile data. There was a proposal to allow tagging browser data as persistent so that it won't be deleted by the browser without asking the user first - that would be big improvement if it lands. But I still expect the APIs in general to be built around an online-first model of the world.