Monday, March 5th, 2018
Wednesday, January 24th, 2018
I still haven’t used React (I know, I know) but this looks like a nice explanation of React and Redux.
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.
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.
Tuesday, July 4th, 2017
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
Sunday, July 2nd, 2017
This is a really great screencast on getting started with React. I think it works well for a few reasons:
- Sarah and Chris aren’t necessarily experts yet in React—that’s good; it means they know from experience what “gotchas” people will encounter.
- They use a practical use-case (a comment form) that’s suited to the technology.
- By doing it all in CodePen, they avoid the disheartening slog of installation and build tools—compare it to this introduction to React.
- They make mistakes. There’s so much to be learned from people sharing “Oh, I thought it would work like that, but it actually works like this.”
There’s a little bit of “here’s one I prepared earlier” but, on the whole, it’s a great step-by-step approach, and one I’ll be returning to if and when I dip my toes into React.
Wednesday, April 26th, 2017
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
Friday, March 10th, 2017
This is a nice understandable explanation of the basics of React.
There’s a real skill in explaining something so clearly that even n00bs like me can understand it.
Tuesday, February 21st, 2017
Tetris in your browser. Visit it once and it works offline (if your browser supports service workers) so go ahead and add it to your home screen.
Monday, January 23rd, 2017
A look at the technical details behind Firefly’s pattern library. The tech stack includes Less, BEM, and some React, but it’s Anna and Danielle that really made it work.
Thursday, December 8th, 2016
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
Friday, October 28th, 2016
Sunday, September 25th, 2016
I’m following Remy’s experiments with great interest—his approach sounds like the holy grail:
I’m trying to build a web app that uses progressive enhancement as a design principle with state as a core value to the coding approach.
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.
Saturday, August 6th, 2016
Saturday, December 5th, 2015
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
Monday, November 16th, 2015
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
Wednesday, August 26th, 2015
Whatever works for you
It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.
In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.
I find that a little disheartening. Chris has written about the confidence of youth:
Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.
There are big differences between saying:
- You can do this,
- You should do this, and
- You must do this.
My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.
Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.
“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:
Sunday, May 31st, 2015