At the 14 minute mark I had to deal with an obstreperous member of the audience. He wasn’t heckling exactly …he just had a very bad experience with web components, and I think my talk was triggering for him.
James talks about automation and understanding.
Just because a technology – whether it’s autonomous vehicles, satellite communications, or the internet – has been captured by capital and turned against the populace, doesn’t mean it does not retain a seed of utopian possibility.
Hmm …seems like I should probably wait for the
load event before triggering
All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
A beautiful piece of writing from Virginia Heffernan on how to cope with navigating the overwhelming tsunami of the network.
The trick is to read technology instead of being captured by it—to maintain the whip hand.
Great advice from Jen on writing a book:
- Write emails to Ted. Try to find a little comfort zone inside the larger uncomfortable task.
- Don’t write a Book. Write Chapters. Break a large chore into smaller tasks and focus on one at a time.
- Trap yourself. Set up a workspace that limits distraction and procrastination.
- Don’t despair the zero-word-count days. Give yourself credit for behind-the-scenes work, even self-care.
- Get amnesia. Keep your eye on the prize.
It looks like this is landing in Chrome. The
navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
There are potential security issues around fingerprinting that are addressed in this document.
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.
- the early era: ~1996 – 2004,
- the jQuery era: ~2004 – 2010,
- the Single Page App era: ~2010 - 2014, and
- the modern era: ~2014 - present.
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.
Ooh, this is a tricky scenario. If you decide to redirect all URLs (from, say, a
www subdomain to no subdomain) and you have a service worker running, you’re going to have a bad time. But there’s a solution here to get the service worker to remove itself.
The server-side specifics are for NGINX but this is also doable with Apache.
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.
I like Chris’s list of criteria for the nebulous role of senior developer:
- A senior front end developer has experience.
- A senior front-end developer has a track record of good judgment.
- A senior developer has positive impact beyond the code.
- A senior developer is helpful, not all-knowing.
- A senior front-end developer is a force multiplier.
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.
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.
John Lanchester reviews ‘The Attention Merchants’ by Tim Wu, ‘Chaos Monkeys’ by Antonio García Martínez and ‘Move Fast and Break Things’ by Jonathan Taplin · LRB 17 August 2017
Triple the hand-wringing in this combined review of three books:
- The Attention Merchants: From the Daily Newspaper to Social Media, How Our Time and Attention Is Harvested and Sold by Tim Wu,
- Chaos Monkeys: Inside the Silicon Valley Money Machine by Antonio García Martínez, and
- Move Fast and Break Things: How Facebook, Google and Amazon have Cornered Culture and What It Means for All of Us by Jonathan Taplin.
What this means is that even more than it is in the advertising business, Facebook is in the surveillance business. Facebook, in fact, is the biggest surveillance-based enterprise in the history of mankind. It knows far, far more about you than the most intrusive government has ever known about its citizens. It’s amazing that people haven’t really understood this about the company. I’ve spent time thinking about Facebook, and the thing I keep coming back to is that its users don’t realise what it is the company does. What Facebook does is watch you, and then use what it knows about you and your behaviour to sell ads. I’m not sure there has ever been a more complete disconnect between what a company says it does – ‘connect’, ‘build communities’ – and the commercial reality.