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

@slightlyoff @fabricedesre This makes a good case for https://lists.w3.org/Archives/Public/public-web-perf/2019Jun/0008.html

@slightlyoff I guess I'm just surprised it took so long. Did other Google properties take as long to start shipping Service Worker? Is the Search team just especially sensitive to measuring and A/B testing to avoid small regressions?

@slightlyoff Yeah they don't even mention Dojo.

@pnathan Offline support

"Frameworks before jQuery" by Jay Hoffmann https://thehistoryoftheweb.com/frameworks-before-jquery/

Good history lesson. Also a good lesson in why JavaScript libraries shouldn't mutate global prototypes.

In building Pinafore, I've been surprised every step of the way how much effort it is to get the Service Worker to work correctly. I had to be really careful with deploying to multiple server nodes, I had to write code to selectively clear the cache, and after Chrome changed their implementation I had to change how the "reload" button worked.

All this for something that *still* occasionally seems to break and cause people to not be able to refresh to update the site, which is… bad.

"Bringing service workers to Google Search" by Jeff Posnick https://web.dev/google-search-sw/

The complexity required to get Service Workers working in a modern web app is kind of mind-boggling. Google Search is something I'd think of as a pretty "simple" web app, and yet here they are using every trick in the book: navigation preload, postMessage, navigator.storage, cache headers, etc.

I've done both native Android development and web development, and my impression of the two stacks are:

- Android: a beginner can make a smooth, performant app out-of-the-box
- web: you have to be an expert or a savant to make something that doesn't suck

I won't even get started on iOS, which has different UI paradigms that are even harder to replicate on the web (e.g. springy animations).

I have no illusions that a web app like Pinafore performs as well as a native app like Tusky. Smooth animations, responsive scrolling, startup time – even the most lightweight webapp I could possibly build just can't touch a native app.

"Facebook’s open source browser contributions" by Vladan Djeric https://code.fb.com/web/browser-contributions/

"Like many complex applications on the web, our desktop Facebook.com website is slower to load than our native mobile Android app on the same hardware — even though the web app loads an order of magnitude less code."

I had kind of forgotten that there was ever a push to make web apps that could perform as well as native apps. It almost feels like we've given up on that idea.

@arkag I'll probably do it this weekend. :)

photog.social must have totally automated their deployment of new Pinafore releases, because I see this kind of announcement like, an hour after every release. Good on them! https://photog.social/@ambassador/102307447930852850

@baldur Yeah I guess programmers tend to have strong opinions about this, because it's common to have an experience like: "We built a big product over many years. We used <x technology>. It failed. We blame <x technology>." When usually it's just complexity itself that weighs you down.

@baldur I still think SSR with vanilla is valid for some use cases. I can see lit-html making sense too.

Once again social media is pretty bad at nuance. It also doesn't help that some folks are paid by their employer to relentlessly promote <x technology> regardless of whether they've actually used it or understand the tradeoffs.

@baldur Agreed, yeah. I have strong opinions about stuff like web components, but social media tends to be a poor venue to hash it out. Blog posts tend to be longer and allow for more nuance.