Tags: react

19

sparkline

Tuesday, October 31st, 2017

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

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

CloseBrace | A Brief, Incomplete History of JavaScript

Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:

  • the early era: ~1996 – 2004,
  • the jQuery era: ~2004 – 2010,
  • the Single Page App era: ~2010 - 2014, and
  • the modern era: ~2014 - present.

Nice to see “vanilla” JavaScript making a resurgence in that last one.

It’s 2017, the JavaScript ecosystem is both thriving and confusing as all hell. No one seems to be quite sure where it’s headed, only that it’s going to continue to grow and change. The web’s not going anywhere, which means JS isn’t going anywhere, and I’m excited to see what future eras bring us.

Tuesday, July 4th, 2017

Jekyll Includes are Cool - daverupert.com

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:

Writing HTML that contains JavaScript, not JavaScript that contains HTML, feels good to me.

The key feature for me is that this approach doesn’t have to depend on JavaScript in the browser:

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

Starting a React-Powered Comment Form | CSS-Tricks

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

Painting with Code : Airbnb Design

Very clever stuff here from Jon in the tradition of Bret Victor—alter Sketch files by directly manipulating code (React, in this case).

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

153 ☞ A Crash Course in React

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

Flatris

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

The road to Firefly 6, part 2, Roobottom.com

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

Server Side React

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

ZEIT – Next.js

I haven’t made a website with React, but if and when I do, this Node.js framework looks like it aligns nicely with my priorities. It’s all about the universal JavaScript (the artist formerly known as isomorphic JavaScript).

Sunday, September 25th, 2016

First impressions of React

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

What is React?

I’m in a similar position to Remy:

I don’t use React. I don’t really gravitate towards larger frameworks, only because my daily work doesn’t require it, and I’m personally more interested in the lower level techniques and parts of the web and JavaScript.

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

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

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 user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

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:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Monday, November 16th, 2015

Aerotwist - The Cost of Frameworks

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.

You should use [insert library/framework], it’s the bestestest! / Paul Lewis - YouTube

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.

6. You should use [insert library/framework], it's the bestestest! / Paul Lewis

Wednesday, August 26th, 2015

Whatever works for you

I was one of the panelists on the most recent episode of the Shop Talk Show along with Nicole, Colin Megill, and Jed Schmidt. The topic was inline styles. Well, not quite. That’s not a great term to describe the concept. The idea is that you apply styling directly to DOM nodes using JavaScript, instead of using CSS selectors to match up styles to DOM nodes.

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.

I expressed concern that styling via JavaScript raises the barrier to styling from a declarative language like CSS to a programming language (although, as they pointed out, it’s more like moving from CSS to JSON). I asked whether it might not be possible to add just one more layer of abstraction so that people could continue to write in CSS—which they’re familiar with—and then do JavaScript magic to match those selectors, extract those styles, and apply them directly to the DOM nodes. Since recording the podcast, I came across Glen Maddern’s proposal to do exactly that. It makes sense to me try to solve the perceived problems with CSS—issues of scope and specificity—without asking everyone to change the way they write.

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.

So I was kind of surprised by the bullishness of those who seem to honestly believe that this is the way to build on the web, and that CSS will become a relic. At one point I even asked directly, “Do you really believe that CSS is over? That all styles will be managed through JavaScript from here on?” and received an emphatic “Yes!” in response.

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.

I don’t think you do your cause any favours by jumping straight to the “you must do this” stage. I think that people are more amenable to hearing “hey, here’s something that worked for me; maybe it will work for you” rather than “everything you know is wrong and this is the future.” I certainly don’t think that it’s helpful to compare CSS to Neanderthals co-existing with JavaScript Homo Sapiens.

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:

It depends.

Sunday, May 31st, 2015

How we built the new gocardless.com — GoCardless Blog

A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.

Monday, February 14th, 2011

Who Is Arcade Fire??!!?

Oh, dear. It seems that some people have not been notified.