There are some great service worker optimisation tips in these slides.
A really nice example of progressive enhancement: creating a layout with
inline-block, then flexbox, then Grid.
The reality is transpiling and including polyfills is quickly becoming the new norm. What’s unfortunate is this means billions of users are getting trillions of bytes sent over the wire unnecessarily to browsers that would have been perfectly capable of running the untranspiled code natively.
script type="module" and put your transpiled fallback in
Most developers think of
<script type="module">as way to load ES modules (and of course this is true), but
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Here’s the closing keynote I gave at Frontend Conference in Zurich a couple of weeks back.
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.
A deep dive into the CSS declaration that Jen told me she wants on a T-shirt.
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.
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.
Tuukka Ojala is a programmer working on the web. He’s also blind. Here are the tools of his trade.
Jason lists the stages of gradually turning the Cloud Four site into a progressive web app:
And you can just keep incrementally adding and tweaking:
You don’t have to wait to bundle up a binary, submit it to an app store, and wait for approval before your customers benefit.
I quite like this proposal for
geo element in HTML, especially that it has a fallback built in (like
video). I’m guessing the next step is to file an issue and create a web component to demonstrate how this could work.
That brings up another question: what do you name a custom element that you’d like to eventually become part of the spec? You can’t simply name it
geo because you have to include a hyphen.
Alla looks at ways of documenting animations into a pattern library. I tell ya, her book is going to be unmissable!
Lin gives a deep dive into Firefox’s new CSS engine specifically, but this is also an excellent primer on how browsers handle CSS in general: parsing, styling, layout, painting, compositing, and rendering.
Everyone’s been talking about
font-display: swap as a way of taking the pain out of loading web fonts, but here Chris looks at
font-display: optional and
font-display: fallback as well.
I like this list:
This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project.
I’ve added them to my collection of design principles.
This is a smart way to queue up POST submissions for later if the user is offline. It’s not as powerful as background sync (because it requires the user to revisit your site) but it’s a good fallback for browsers that support service workers but don’t yet support background sync