Notices by Nolan (nolan@toot.cafe), page 7

@jlamar It's all open source. I definitely don't remember what I did. 😂

@codesections I actually think Google's "interventions" approach is reasonable, and they do a good job. They get a lot of flak, but their focus is on performance and security.

@sil That's kind of where I'm at, yeah. The only problem with my scorekeeping app is that I'm pretty certain there are still no good card/board game scorekeepers on Android. (Or at least, mine is the only one that isn't stuffed full of ads and in-app purchases.) And since I still play board/card games occasionally, I should probably update it. Sigh

@sil Google has sent me a lot of threatening emails about these apps, so I expect them to remove them eventually. My bad for writing working software 5 years ago!

(Caveats about Flash and Chrome's "interventions," yes yes. https://github.com/WICG/interventions But in general, websites don't just break in newer browsers.)

And yes, I know I should probably get off my ass and actually update the app so that it works on newer Android versions. But I feel like I *shouldn't have to*.

Have you ever used a website that just "stopped working" on a newer browser? No, because people would just switch to another browser. But Google has no such pressures for Android, so they're fine with breaking apps that used to work perfectly fine.

Love the comments on my old Android app I haven't updated since 2014: https://play.google.com/store/apps/details?id=com.nolanlawson.keepscore

- "Used to be great, and I recommended it highly. Last several months, however, something changed and it is no longer stable."
- "I used it for years, however when I upgraded to a GS9, the app keeps crashing."
- "I used to love this app and recommend to others all the time. However I upgraded my phone and it doesn't work on the newer phones."

Android does not seem to care about backwards compat.

@pkra Yep you're right, at 32:57 he says: "You can't really detect whether you're in a high-contrast theme or not with CSS… actually you can with CSS, but not with JavaScript necessarily." I must have just heard the first part.

Incidentally since you can detect it with a CSS media query, you can also detect it in JS using window.matchMedia().

@pkra I totally must have misheard him. Thanks for the correction! :)

@varx Nice demo! Yes I would wonder about rich text pasting, and also about screenreaders... but I think with the right workarounds it could be a viable solution. :)

@varx Yeah I discussed this a bit here: https://toot.cafe/@nolan/102781484507615774. I think it just looks a bit too ugly to have a split-second delay before the textarea changes height. Or to have extra padding as you describe.

Might be too clever to actually use in production (assumes we can make the <pre> look *exactly* like the <textarea>, which seems tricky given UA stylesheets), but it's kind of neat that it actually works. In theory it's more efficient than recalculating layout on every keypress, because the height is only set on the <textarea> when the <pre>'s height actually changes.

Today's web experiment: a <textarea> that auto-resizes using a hidden <pre> tag and ResizeObserver to watch it for when its height changes. https://github.com/nolanlawson/pinafore/issues/1476

@tomayac It sounds like effectively they've created an application format that can run within one of the Chinese super-apps like WeChat or AliPay? And that's it's based on JS + CSS + a templating language that native apps can render? I heard it through the grapevine that Facebook is working on something similar.

@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.)

@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.

Anyway I guess what I'm saying with this thread is that there's still a lot more that can be done with the web, and I'm a little disheartened by the lack of imagination out there. Svelte is doing cool things. Rails+TurboLinks is still an unsung wonder. But there should be like 10 more equally brilliant experiments pushing the web into weird and wild directions. I wish that's where the industry was right now.

If I had to put my money on it, I'd say the untapped frontier is still Service Worker. You can use a Service Worker for more than just caching and notifications. You can put your whole damn app in there. Then you've got an app where the business logic lives on a separate thread from the UI, just like the cool kids over in iOS and Android. How neat would that be? But nobody's doing it.