I can't believe I wrote an entire Mastodon client.

If it had been me 7 years ago, I would have done it as an Android app. I was really into Android development at the time.

If it had been me 10 years ago, I'd have written it in… I dunno, Python? So Flask or something?

But these days I really like the web, so I wrote it in Web™

I guess I wanted to prove to myself that it's possible to write a webapp that isn't slow and bloated and terrible and all the things that people say about the web these days.

If I have one regret (or two) with Pinafore, it's that

1) the animations could be a lot nicer, and
2) the offline support could be a lot better.

All the APIs are there. It could have gorgeous intra-page animations and flawless offline support, just like a native app. I just didn't manage to do it. (yet)

The web is capable of so much more than people are doing with it nowadays. A lot of the problems are business incentives (ads, trackers, third-party junk) and cargo cult (bloated toolchains, bloated deps, a main thread that doesn't scale).

We're waiting for the next Ajax/Web2.0/whatever revolution where somebody comes up with a bold new design that's better than everything that came before.

@nolan @alcinnz has some radical ideas about the future of the web.

Follow

@strypey @nolan I don't know how much my ideas cater towards doing more stuff offline, though I'd definitely encourage it.

And really I'm gathering other people's ideas more than coming up with them myself. Extending upon john.ankarstrom.se/replacing-j

Basically I think we should be writing our pages more declaratively (more like HTML & CSS, less like JS) so browsers can better protect privacy/security and render them to different mediums.

@alcinnz @strypey @nolan 1000x this. Weaponised JS and WASM will eventually become impossible to avoid, and blindly trusting all the sites we use is also not a solution.

@dch @alcinnz @strypey I tend to disagree, and I think pining for a lost golden age when the web didn't have JavaScript is counterproductive.

The truth is, we've built an application delivery mechanism that can run client-side code in a sandbox that is secure and performant enough that most web users aren't afraid to click links. That's pretty amazing. We should double down on this system, not replace it with something hypothetical and untested.

@dch @alcinnz @strypey In regards to that article, Meltdown and Spectre were singularly bad security incidents for the web, and for JavaScript in particular. But there are solutions. The short-term solutions were JS language mitigations and timing attack fixes (e.g. removing SharedArrayBuffer, reducing precision on performance.now()). But the long term solution is site isolation – put every tab and iframe in one-process-per-origin. (Chrome already has it, Firefox is working on it.)

@nolan @alcinnz @strypey a bit of both. I live on the edge of security and it’s a dark dangerous place there. Permitting arbitrary code to run on my devices is only going to get worse. Where does it end - a full vm per webpage?
Most sites I use today try to pull in code from 20+ other systems and it’s a disaster. J have zero trust and faith in this model, but I do love web delivered apps. Things like fido2 are examples where js totally a plus. The rest?

@nolan @dch @strypey Spectre/meltdown is far from the only reason I pine for simpler times.

But feel free to defend the status quo as it collapses under it's own weight.

I really don't think the sacrifices for my way is too much: a large fraction of the web will still survive, and most (but not all) of the rest can theoretically be recreated to deliver the same UX.

@nolan
> most web users aren't afraid to click links.

If they're not running something like #NoScript, there are good reasons they should be. Most aren't afraid to use HTML in email either, or install apps from untrusted sources on the same devices they use for banking etc. There are plenty of things uneducated users haven't been taught the dangers of doing. This seems like an odd criteria for evaluating engineering decisions about future technologies.
@dch @alcinnz

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).