Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.
Tuesday, October 31st, 2017
A great bucketload of common sense from Jake:
Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.
And here’s a good way of thinking about that:
I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.
All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:
Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.
Sunday, October 29th, 2017
Friday, September 22nd, 2017
- the early era: ~1996 – 2004,
- the jQuery era: ~2004 – 2010,
- the Single Page App era: ~2010 - 2014, and
- the modern era: ~2014 - present.
Thursday, September 7th, 2017
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.
Wednesday, September 6th, 2017
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.
Wednesday, May 31st, 2017
Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.
Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..
That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.
Monday, May 22nd, 2017
Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:
Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.
I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:
I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.
But we can all agree that the web is a wonderful thing:
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.
Sunday, March 19th, 2017
Interesting ideas around front-end frameworks:
The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.
Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.
Thursday, March 2nd, 2017
A really inspiring post by Jen outlining all the benefits of the new CSS layout features …and the problems with thinking framework-first.
I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.
Sunday, January 15th, 2017
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
Monday, November 21st, 2016
Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can
A cautionary tale of the risks involved with embracing new frameworks.
But when you introduce a new system, you introduce new variables, new failure points, and new problems.
…almost anything is easier to get into than out of.
Thursday, November 17th, 2016
Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.
Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.
I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.
He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.
Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.
Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.
Today’s frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance.
Thursday, November 3rd, 2016
I don’t really have much of an opinion on his central point that browser makers should work more closely with framework makers. I’m not so sure I agree with the central premise that frameworks are going to be around for the long haul. I think good frameworks—like jQuery—should aim to make themselves redundant.
But anyway, along the way, Tom makes this observation:
Google has an institutional tendency to go it alone.
I don’t really mind these inventions. We’re not forced to adopt them, and generally, we don’t. Tom again:
See, that’s a really, really good point. It’s so much easier to get people to adjust their behaviour than to change it completely.
Sass is a really good example of this. You can take any
.css file, save it as a
.scss file, and now you’re using Sass. Then you can start using features (or not) as needed. Very smart.
Incidentally, I’m very curious to know how many people use the scss syntax (which is the same as CSS) compared to how many people use the sass indented syntax (the one with significant whitespace). In his brilliant Sass for Web Designers book, I don’t think Dan even mentioned the indented syntax.
Or compare the adoption of Sass to the adoption of HAML. Now, admittedly, the disparity there might be because Sass adds new features, whereas HAML is a purely stylistic choice. But I think the more fundamental difference is that Sass—with its scss syntax—only requires you to slightly adjust your behaviour, whereas something like HAML requires you to go all in right from the start.
This is something that has been on my mind a lately while I’ve been preparing my new talk on evaluating technology (the talk went down very well at An Event Apart San Francisco, by the way—that’s a relief). In the talk, I made a reference to one of Grace Hopper’s famous quotes:
Humans are allergic to change.
Now, Grace Hopper subsequently says:
I try to fight that.
I contrast that with the approach that Tim Berners-Lee and Robert Cailliau took with their World Wide Web project. The individual pieces were built on what people were already familiar with. URLs use slashes so they’d be feel similar to UNIX file paths. And the first fledging version of HTML took its vocabulary almost wholesale from a version of SGML already in use at CERN. In fact, you could pretty much take an existing CERN SGML file and open it as an HTML file in a web browser.
Oh, and that browser would ignore any tags it didn’t understand—behaviour that, in my opinion, would prove crucial to the growth and success of HTML. Because of its familiarity, its simplicity, and its forgiving error handling, HTML turned to be more successful than Tim Berners-Lee expected, as he wrote in his book Weaving The Web:
I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content. It would turn out that HTML would become amazingly popular for the content as well.
Humans are allergic to change. And that’s okay.
Sunday, October 9th, 2016
We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.
Thursday, October 6th, 2016
It’s not about what works for you. It’s about what works for your users.
If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.
If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.
But it’s worth remembering this caveat too.
Friday, September 23rd, 2016
PPK reads a Hacker News thread so you don’t have to.
Tuesday, August 23rd, 2016
I’m in a similar position to Remy:
But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:
What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?
There are some good responses in the comments.
Monday, August 8th, 2016
Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.
Tuesday, July 12th, 2016
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.