Excellent presentation slides on all things Indie Web.
There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be.
This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.
I’m so, so happy to see some pushback against the misinformation that progressive web apps automatically imply client-side rendered single page apps built from scratch. There’s so much value to be had in turbo-charging an existing site into a progressive web app.
But what we don’t need is yet another TLA like Alien Web Apps.
This could be a one-word article: don’t.
More specifically, don’t design websites for any specific device. That way lies pain (and it is not the way of the web).
But read on for a textbook example of how not to introduce new CSS properties. Apple proposed the new syntax that they’re shipping. Now it’s getting standardised …with a different name. So basically Apple are shipping the equivalent of a vendor-prefixed property without the vendor prefix.
- the early era: ~1996 – 2004,
- the jQuery era: ~2004 – 2010,
- the Single Page App era: ~2010 - 2014, and
- the modern era: ~2014 - present.
A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:
The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.
This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.
Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.
You can use
navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.
Two of my favourite things together at last: pattern libraries and service workers. Infusion is a tool for generating pattern libraries that also work offline.
Thinking about it, it makes total sense that a pattern library should be a progressive web app.
There are some great service worker optimisation tips in these slides.
Rob has redesigned his site and it’s looking lovely. Here’s the first part of a three-part series on the rationale behind the relaunch:
I don’t pretend everything I do or say online is worthy of preservation. But while I’m still breathing, I want to be the one who decides what gets preserved and what doesn’t. And I want it all to be available in one place. Owning and operating my own site is the only way.
An organisation has formed here in the UK as a response to the increasing threats to the web:
We are called to come together in response to growing political and social uncertainty, direct threats to the profession, and a lack of vocal and proactive representation to organise as a representative, independent, and politically responsible industry body.
I like their manifesto; let’s put it to the test-o.
Along the lines of John’s recent post, Henrik makes the business case for progressive web apps.
He also points out how they can be much better than native apps for controlling hardware.
They can be up and running in a fraction of the time whether or not they were already “installed” and unlike “apps” can be saved as an app on the device at the user’s discretion!
Essentially they’re really great for creating “ad hoc” experiences that can be “cold started” on a whim nearly as fast as if it were already installed.
John makes the point that unless you’re one of the big, big players, your native app is really going to struggle to find an audience. But that’s okay—a progressive web app might be exactly what you need.
In short, using native apps as a path to reaching a large number of potential customers and benefitting from crucial network effects is close to impossible.
But, in the meantime, the Web has responded to the very significant impact that native apps had on user behaviour.
For me, the strength of the web has never been about how it can help big companies—it’s about how it can amplify and connect the niche players.
If you’re interested in predicting the future of the web, just look at what high-performance native systems look like, then figure out how we can apply those ideas in the browser.
I like that Tom encourages learning from native, but not at the expense of the web (hint, hint, Google devrels encouraging slavish imitation of native apps in progressive web apps with no regard for URLs).
Our job now is figuring out how to adapt the ideas of high-performance native code while preserving what makes the web great: URLs, instant loading, and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day.
This is the way the web ends
This is the way the web ends
This is the way the web ends
Not with a bang but a duopoly.
I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.
Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.
These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.
An interesting idea from Ruth—using subtle sounds to augment inline form validation.
There aren’t any extremely established best practices for this stuff. The best we can do is make tasteful choices and do user research. Which is to say, the examples in this post are ideas, not gospel.
Here’s Amber’s great talk from the great Material conference last month in Iceland.
Amber Wilson worked in the field of Psychology for many years and is now a budding Web developer at a design agency in Brighton. New to Web development, she is continually eager to improve her skills.
(The silhouettes of Jessica, me, and Joschi in the front row make it look like Mystery Science Theater 3000.)
Manifest files can have categories now. Time to update those JSON files.
A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:
Your site—every site—should be a PWA.
He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:
Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.
I’m doubling down on owning my own content, so I’m excited to have a less-crusty home for it all.
It’s fun! In a world where even sites that aren’t Medium dot com are looking like Medium dot com, I’m excited to try something different.