Friday, August 9th, 2019
Thursday, August 8th, 2019
This is a clever use of the
srcdoc attribute on iframes.
The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.
I’ve just been adding
loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.
Thursday, August 1st, 2019
I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.
I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.
And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a
div to a
button. That’s quite a barrier to entry.
In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.
I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.
Wednesday, July 31st, 2019
Charlie’s thoughts on dev perception:
People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.
Tuesday, July 30th, 2019
Thursday, July 25th, 2019
Dave enumerates the things about Vue that click for him. The component structure matches his mental model, and crucially, it’s relative straightforward to add Vue to an existing project instead of ripping everything out and doing things a certain way:
In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks.
Sunday, July 21st, 2019
Brad describes how he has found his place in the world of React, creating UI components without dabbling in business logic:
Instead of merely creating components’ reference HTML, CSS, and presentational JS, frontend designers can create directly consumable HTML, CSS, and presentational JS that back-of-the-frontend developers can then breathe life into.
What’s clear is that the term “React” has become as broad and undefined as the term “front-end”. Just saying that someone does React doesn’t actually say much about the nature of the work.
When you say “we’re hiring a React developer”, what exactly do you mean by that? “React developer” is almost as vague as “frontend developer”, so clarify. Are you looking for a person to specialize in markup and styles? A person to author middleware and business logic? A person to manage data and databases? A person to own build processes?
Friday, July 19th, 2019
Chris succinctly describes the multiple-
iframes-with-multiple-codebases approach to web development, AKA “micro frontends”:
Thursday, July 18th, 2019
Monday, July 1st, 2019
When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.
Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”
This resonates a lot with Dave’s post:
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
Sunday, June 16th, 2019
Although this piece is ostensibly about why we should be using web workers more, there’s a much, much bigger point about the growing power gap between the devices we developers use and the typical device used by the rest of the planet.
While we are getting faster flagship phones every cycle, the vast majority of people can’t afford these. The more affordable phones are stuck in the past and have highly fluctuating performance metrics. These low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years. The gap between the fastest and the slowest phone is getting wider, and the median is going down.
Tuesday, June 11th, 2019
A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):
I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?
Thursday, May 16th, 2019
A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.
Thursday, May 2nd, 2019
(Mind you, if the framework is being used on the server to pre-render pages, then it’s a moot point—in that situation, it makes no difference to the end user whether you use a framework or not.)
In the last few months I built my very first framework-based front-end, in Vue.js. I complemented it with a router, a store and a GraphQL library, in order to have, respectively, multiple (virtual) pages, globally shared data and a smart way to load new data in my templates.
I am glad I tried a framework and found its features were extremely helpful in creating a consistent interface for my users. My hope is though, that I won’t forget about vanilla. It’s perfectly valid to build a website with no or few dependencies.
If you’re building a large scale application (literally Facebook, Twitter, QuickBooks scale), the performance wins of a framework make the overhead worth it.
Alas, I’ve seen many, many framework-driven sites that are most definitely not that operating at that scale. Trys speaks the honest truth here:
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
I worry that all the perfectly valid (developer experience) reasons for using a framwork are outweighing the more important (user experience) reasons for avoiding shipping your dependencies to end users. Like Alex says:
If your conception of “DX” doesn’t include it, or isn’t subservient to the user experience, rethink.
And yes, I am going to take this opportunity to link once again to Alex’s article The “Developer Experience” Bait-and-Switch. Please read it if you haven’t already. Please re-read it if you have.
Anyway, my main reason for writing this is to point you to thoughtful posts like Hidde’s and Chris’s. I think it’s great to see people thoughtfully weighing up the pros and cons of choosing any particular technology—I’m a bit obsessed with the topic of evaluating technology.
To quote Grace Hopper:
The most dangerous phrase in the language is, ‘We’ve always done it this way.’
The bait’n’switch is laid bare. First, AMP is positioned as a separate format. Then, only AMP pages are allowed ranking in the top stories carousel. Now, let’s pretend none of that ever happened and act as though AMP is just another framework. Oh, and those separate AMP pages that you made? Turns out that was all just “transitional” and you’re supposed to make your entire site in AMP now.
I would genuinely love to know how the Polymer team at Google feel about this pivot. Everything claimed in this blog post about AMP is actually true of Polymer (and other libraries of web components that don’t have the luxury of bribing developers with SEO ranking).
Some alternative facts from the introduction:
AMP isn’t another “channel” or “format” that’s somehow not the web.
Weird …because that’s exactly how it was sold to us (as a direct competitor to similar offerings from Apple and Facebook).
It’s not an SEO thing.
That it outright false. Ask any company actually using AMP why they use it.
It’s not a replacement for HTML.
And yet, the article goes on to try convince you to replace HTML with AMP.
Wednesday, April 24th, 2019
I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.
Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.
I want a transcript of the whole thing.
Monday, April 15th, 2019
Scott writes up that super smart transclusion trick of his.
Saturday, April 13th, 2019
Woah! This is one smart hack!
Scott has figured out a way to get all the benefits of pointing to an external SVG file …that then gets embedded. This means you can get all the styling and scripting benefits that only apply to embedded SVGs (like using
The fallback is very graceful indeed: you still get the SVG (just not embedded).