DEV Community: Joshua Nelson ✨

What were your "gotchas" when first learning React?

Joshua Nelson ✨ — Sun, 25 Nov 2018 07:00:30 +0000

I've found there are some common stumbling blocks that people have when they're learning React, and sometimes there's an "Aha!" moment when they understand.

The difference between ES2015, React, JSX
Complex usage of libraries like underscore or lodash in example code
Understanding the overall "data flow" of React (And, the "Flux" architecture as a concept)
Shared (but different!) concepts in other frameworks like Angular, Vue or even jQuery
The asynchronous nature of some operations (like setState)

Was there anything particularly tricky to get a handle on when you were learning React? What was your "Aha!" moment?

Idealism and Pragmatism

Joshua Nelson ✨ — Wed, 21 Nov 2018 07:18:04 +0000

The fender on the Apollo 17 rover fell off. This was a big problem – dust on the moon is very damaging to delicate instruments and suits.

Luckily, there was a solution – literal duct tape. NASA advised the astronauts to put together some maps in the shape of a fender, and attach it to the rover with duct tape. This fixed their problem!

Of course, this solution is not ideal – the original fender would have worked much better than this. However, with the resources available, this was a good decision – the makeshift fender worked.

Similar questions can come up when making software:

"Hey, is it ok if I just skip writing tests for this one?"

"This is a bit of a hack, do you think it's ok?"

"This isn't the way everything else is done, but it's easier. I think it's ok?"

These are common questions, questions that I have asked many times, and have been asked many times.

How can you tell when a hack is too much of a hack? How do you know if you're being principled, or pedantic?

Decisions like this fall on a spectrum. I think of this spectrum as the "Idealism and pragmatism" spectrum.

Pragmatism

Pragmatism is "dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations."

In the context of software, this surfaces as a way of thinking about utility. A developer who concentrates more on outcomes (delivery, shipping, releases, or features) more than how those outcomes are achieved, is a pragmatic developer.

In practice, this can often mean a willingness to do "hacks". If there is a non-ideal path to a good outcome, taking that path might be pragmatic.

As an example, in the browser, maybe you need to override a window method to fix an urgent bug. Or maybe you need to disable a test to make builds pass. Both of these things are not ideal, but they arrive at a good outcome.

Idealism

On the other end of the spectrum is idealism. Idealism is
the cherishing or pursuit of high or noble principles, purposes and goals"

In software, idealism surfaces when we have a strong principle that we do not violate. A developer who focuses on what is "right", or "the best way to do things" may be idealistic in their attitude.

Idealism in software development practices can come down to blocking things, or saying "no" to things being done incorrectly. It might be deciding to not do a hack, or by spending a little bit more effort to do something the way that it "should be done".

Apart from just saying no to wrong things, idealistic practices might mean writing down principles, like "Document every new feature", or it might mean creating linting rules that force people to write code in a consistent way. The exact principles will depend on the project, but idealism is always about aiming for some high standard, even if it's hard to get there.

These idealistic approaches trade off some short term speed for a long term benefit, like general code quality and consistency, test coverage, or complete documentation of features.

How to know when to be which

Often decisions need to be made, where the answer falls into one of these two categories. Should you be pragmatic, or idealistic?

Actually have principles

You can't be idealistic without having some principles written down, but you also cannot be properly pragmatic without knowing your principles. What is it that is valuable to your project? Having these principles clearly written down and being shared knowledge on your team will help you assess how badly you are violating one of these principles, if you need to.

Maybe you have a principle of "The user experience comes first", and you need to make a choice – delay delivery for one week, or deliver a somewhat buggy user experience. Having that principle written helps you acknowledge what is gained and lost on each side, and make the best call in that situation, acknowledging the costs and benefits.

Know the pressures

Pressure is normal enough when developing software – there are deadlines, roadmaps, and releases. Often, a more pragmatic choice is appealing when one of these pressures are present.

Try and break down exactly what the pressure is. If there a large impact for a certain outcome (other teams / users are depending on a certain deliverable), that is a large impact, but maybe the deadline was just a date selected as a likely shipping date, and the impact of delaying delivery is low.

Be aware of your own bias

Knowing where you sit on the spectrum of idealistic to pragmatic is a good first step. Do you often find yourself being "lazy", or taking shortcuts? Or do you find yourself too often being "stubborn", and frequently saying no? If you aren't sure, you can ask people you work with, who may have a good idea of where your natural tendency lies.

Personally, my tendency is to make pragmatic choices, and I need to put in conscious effort to ensure principles are created and adhered too. (Tools and rules help a lot in this regard, as they are rigid standards that I can't forget about).

If you know how you're naturally biased when making decisions, you can step back when you sense yourself making an overly pragmatic, or overly idealistic decision.

Examples

The pull request

You see something that is not ideal in a pull request. Maybe a test was forgotten, or some could should be refactored. Should you withhold approval?

Things to keep in mind here are that you are setting a standard in your pull requests, and an idealistic approach here is valuable for future work (the standard you walk past is the standard you accept)

However, there might be pressures (see: know the pressures above) that necessitate skipping some of these things.

A pragmatic compromise might be, "Ok, let's merge and release this, but follow up with the proper fixes".

The important thing to monitor here is that those fixes actually occur.

The hack

There's a way to do something that is clearly not ideal – you're breaking an API, or you're doing something that is so obviously wrong, you're almost embarrassed. However, it gets the job done.

Is this ok?

You can examine your principles to see how much it violates them. Is it a worse UX, worse code quality, or a risky change? If it heavily violates your principles, best to not implement this hack.

On the other side, there are times when hacks are useful. Maybe it speeds up other developers, in a way where their code dodes not need to rely on this hack. It may allow you to deliver a high impact release on time, that users or other developers are depending on.

In your decision, you might include a plan to remove this hack in the future. In this plan, make sure you include not only when you would fix this hack, but also why you would fix it. Why might be a ticket, or process that would ensure this gets done. Hacks often live a very long time, so you should be sure you're ok with it being around for a long time.

The bad habit

Outside pressure leads towards the pragmatic approach – outcomes are what's important, but the way those outcomes are achieved is the domain of the engineer. This means that, left unchecked, bad habits and practices can creep in.

In this case, it's important to realise that this is happening (see: Actually have principles), and combat it. This can be by explicitly calling out the principle, and through pull requests, encouraging your team to adhere to them.

The precedent

Sometimes, first code of a new type is being checked in. If you are doing something for the first time, be aware that you are setting a precedent for all similar, future work. Are you making the first GraphQL resolver, the first API model, or the first shared library? You are setting a precedent that many developers will follow! In this case, an idealistic approach is always preferable.

A false dichotomy?

There is a spectrum of pragmatism and idealism, but these approaches are not diametrically opposed. Most of the time, we can have both an ideal outcome, and ideal path. Often the best way to deliver high utility, even in the short term, is by doing things in an ideal way. This is not always the case for some harder decisions though, and there are times when tradeoffs need to be made.

How about you?

Do you fall more on the side of pragmatic, or idealistic? Do you have any tips on how to know where your decision should fall on this spectrum? I'd love to hear!

Protecting performance (Part 4)

Joshua Nelson ✨ — Wed, 14 Nov 2018 08:52:35 +0000

Performance is important for your users, your business, and the world. We need to pick good metrics that reflect real user experiences – and there are many available to choose from.

So now we've picked our meaningful metric, and a tool to measure it with.

Now what?

Maybe you're thinking that now we need to actually fix performance. This is undoubtedly true! We won't address that in this blog though – there is plenty of dedicated resources for telling you what to improve. A great starting resource is the audits panel in the Chrome devtools.

A natural follow up question might be, how long will it take to fix those performance issues?

This is not the right question to be asking. We're in it for the long run – performance is a cultural change we need to make, not a one off effort that we can do once.

The planning phase

Often, performance regressions happen when a feature request materialises in a ticket of some form – a feature that will degrade performance is requested, and it's too late to reverse course. At this point, it's already too late to change things – we need a way of influencing planning much earlier than this, and we need a structured way of making sure that this conversation about performance happens much earlier, during the planning phase.

Performance budgets

Performance budgets are a great way of having this conversation in a structured way. The key steps are:

1. Choose the right metrics

During the previous part, we talked about choosing the right metric – it's important to do this, so that we're focusing on a meaningful metric to improve.

2. Get everyone to agree on a limit

Whoever makes planning decisions needs to agree that the metric (and the limit) that you have chosen for your budget is a good goal.

3. Bring it up during planning

When engineering is involved in planning decisions, this goal needs to be kept in mind and talked about. When things being talked about would impact the performance budget, this needs to be brought up.

4. Figure out how to stay in budget

During this planning phase, compromises can be sought. It might be that the feature itself can be changed to perform better, or it might be that some other performance improvement can be made to allow the budget to be kept overall.

Choosing a limit

Choosing an exact number for the limit is difficult, but here are some things to keep in mind:

0.1 seconds - tasks are considered "instant", in that the user does not perceive a delay (eg. good goal for first input delay)
1.0 seconds - flow of thought is maintained throughout tasks (good goal for subsequent response times)
10 seconds - task switch occurs after this (definitely do not aim for longer than this on any metric)

Apdex

Apdex is another useful, "meta metric" that can be used to protect your performance and measure it at a high level.

In the context of meaningful metrics however, there are two things that I would warn against in the usage of Apdex.

Pick your t value carefully

Apdex works by picking a "t" value, that represents what a user would consider a "tolerable" page load. Anything less than t is considered "satisfied", and anything less than t*4 is considered "tolerable"

Picking a t value of anything much more than 1s can lead to misleading metrics. Consider a t value of t=2. Page loads taking less than 8 seconds would be considered "tolerating", which is quite close to the limit before a user will tasks switch. It is likely that users who load pages in 8 seconds are dissatisfied in lots of use cases, and in this case, the Apdex metric does not reflect it well.

Pick your "load" metric carefully

Apdex also requires a concept of "load time" itself. If you plug in an incorrect load time (maybe you would be using DOMContentLoaded instead of Time to interactive), your Apdex will be incorrect too.

With this in mind, Apdex can be a useful tool for protecting performance. It can be used to normalise metrics into a simple number – this might be useful for aggregating Apdexes. However, without a shared t value, it is hard to compare different Apdex numbers, and hard to relate to their values. A budget or goal measured in seconds can be easier to relate to, and compare.

Over the course of this blog series, we have learnt to measure real user experiences, and pick the right metric to do that. Quickly check that the metric you have chosen is being triggered when in a meaningful state.

Ultimately, for me, dollars aren't inspiring – but making the internet better for everyone, and enabling the open exchange of information for the world, is an inspiring goal. Meaningful metrics are an important step to this goal. Let's make the internet better for everyone! ✨

Choosing a metric (Part 3)

Joshua Nelson ✨ — Wed, 14 Nov 2018 08:49:49 +0000

Performance is a problem, and it’s not getting better. The median mobile page load time is 15.6 seconds – this is unacceptable.

We need meaningful measurements that actually capture the real user experience of a page loading for a user.

There are good and bad metrics out there for measuring this. A good metric is one that accurately reflects this user experience, and a bad one does not.

Bad metrics

We can start with an example of a bad metric. Consider the page loading below:

A common way of measuring page loading speed is with the “load” event. However, the point at when the “load” event is fired, the page looks like this:

Which is obviously not the point at which the page has loaded. Relying on this metric is dangerous. You’ll focus on the wrong things, changing meaningless numbers. Meanwhile, you’ll neglect real issues – and your users will silently suffer.

Good metrics

So, that's a bad metric. But what makes a good metric?

Real user experiences

We’ll say that a metric is good if it reflects real user experiences. There are a number of attributes of metrics that would be demonstrate this:

Measured on a real devices
Measured on a real user’s network
Passes a basic litmus test – when is this metric considering an experience good or bad, for my site? Is that in line with what you think?

Is a “continuous” function

In the maths sense, a continuous function means something similar, but we’ll say that a metric is “continuous” if:

A small improvement in the metric relates to a small improvement in the UX, and a large improvement in the metric relates to a large improvement in the UX.

An example of a metric that would not be “continuous” in this way might be page weight. If you are aggressively code splitting and caching, it might be that an improvement in the page weight relates to no improvement in the UX.

Another metric would be bad if it gave a 100% score if a page loads in <1s and a 0% score if it loads in >=1s – improving load time from 3s to 2s would be a slightly better UX, but would not be rewarded by the metric.

This is a useful property to have in a metric, as it means that the metric cannot be cheated. You can’t quickly render a loading spinner, and have the metric improve. I like to think of the developers who will be looking at this metric as a greedy optimisation algorithm – they will take the shortest path to improving this metric, and ideally, that path will also be the shortest path for improving the overall UX.

Is “repeatable”

Never send a human to do a machine’s job – Agent Smith

Some metrics you can get in an easy, automatic way, through monitoring. Some are easier to get with audit tools. However, you must spend the time to automate gathering this data. This is critical for the long time preservation of the metric – humans are less reliable than machines for regular tasks like this, and it’s very useful to have lots of data points. They will be your friend when debugging performance problems, and a long historical backlog of data is precious.

Metric choices

Let’s have a look at some of the different choices we have, and assess them according to our criteria:

Page weight

Page weight is a good metric in some ways: it is relatively easy to measure, and javascript is expensive. There is always a user experience cost to delivering javascript, so measuring page weight is a good thing.

However, page weight is a proxy for the real user experience – page weight doesn’t necessarily mean that a user’s experience with the page loading was bad. We may be aggressively code splitting or caching, which would mean that this may not fit the criteria set out above.

Ultimately, page weight as a metric will depend on your use case, so think carefully about how the page weight actually impacts the user experience.

Bundlesize is a tool for measuring page weight in an automated way.

Paint timing

Paint timing is a popular choice for measuring performance.

The three paint timing events in the diagram above reflect different parts of the paint lifecycle.

First paint: anything is painted to the page, e.g.: the page background colour changes from white to black
First contentful paint: a DOM element is rendered to the page, e.g.: a loading spinner is rendered
First meaningful paint: meaningful data is first rendered to the page

First paint and first contentful paint are measurable via the Paint timing API, however, first meaningful paint is harder to measure in this way. First meaningful paint is by its nature, meaningful: something that the user thought of as useful to them was given to them. This makes first meaningful paint a good metric, but first paint and first contentful paint may only be meaningful depending on your use case.

Subsequent meaningful paints

For single page apps, there may be subsequent page loads, other than the "first' meaningful paint. Component timing is an approach that enables us to measure these follow up render times. The react-component-timing library is an attempt to create a React wrapper to automate this – contributions encouraged!

Speed index

Speed index is a great metric, but can be initially difficult to understand. One way of thinking of it is, we “integrate the % of the page loaded over time” – which probably didn’t help clarify much, so let’s break that down.

We keep track of what percentage of the page has been loaded at some time interval. We score ourselves based on what % of the page we’ve loaded, and how quickly. As an example, a page that loads everything in 5 seconds will get a worse score than a page that loads half of the page at 2.5 seconds, and the other half at 5 seconds.

This is a good metric in the sense that it is naturally extremely “continuous” – it incorporates the concept of “loaded-ness” into a single number. Optimizing for this number will certainly improve real user experiences.

This is a hard metric to use in some other ways though: it is difficult to understand, meaning that it does not convey user empathy very well. It’s unit-less, and so understands a requirement of the metric itself.

It also requires a tool like webpagetest.org to measure it, as we need to know what percentage of the page has loaded at various intervals. It means that we can’t measure it on real networks and devices, but we can simulate these conditions.

ATF (above the fold) render time

Above the fold render time is the time taken until all of the content above the fold of a web page has loaded.

This metric is relatively easy to understand and empathise with, but it does not deal with post initial load well. It’s hard to measure in real browsers, and in reality, your users probably scroll.

Load event

The load event is triggered after DOMContentLoaded, and after javascript downloads.

This is an easy metric to measure and understand, and so is fairly common. However, there are some risks, as in the example perviously – it may not be triggered at a time that is truly meaningful, particularly with asynchronous requests for meaningful data.

First byte

First byte is easy to measure with the Navigation API, and is useful for diagnosing network and backend issues.

However, this first byte may not represent anything actually meaningful to the user, and so cannot be depended upon alone.

Time to interactive

Time to interactive measures the time taken until the page is ready to respond to user input.

Metrics talked about so far have only concerned themselves with delivering data, but for any application that the user may interact with (most applications!) we need a way of measuring this responsiveness, to understand whether the user would truly consider the experience to be “performant”

Time to interactive is good for doing this, but is less meaningful after the initial page load.

For measuring it, there is a polyfill available that approximates this experience by measuring the time at which the CPU first becomes idle – meaning that the page is ready to respond to user input.

First input delay

First input delay measures the time it took for the application to respond when the user first interacts with it. This could be a mouse click, touch event, keyboard event, or anything else that the user has initiated.

This metric is particularly interesting since every value represents real user pain. If your first input delay for a particular session is 1000ms, that's a full second someone had to wait before the button did anything!

You need to be aware though, that this metric will naturally have some variance. The first input delay will depend on the user – a patient user might wait a long time before clicking something, but another user might click as soon as a button is rendered. For this reason, it is recommended that the 90th percentile is measured, so that you can optimise for reducing those truly painful experiences.

For measuring, there is a polyfill available

DOMContentLoaded

DOMContentLoaded measures the time it takes to parse HTML and download / parse synchronous javascript.

This is basically never what you want. If you're considering using DOMContentLoaded as a checkpoint for your metrics, consider using the "load" event instead.

The metric starter pack

If you're just getting started and want to start measuring something, I would recommend:

Time to interactive
Bundle size
First input delay
First meaningful paint (if you can!)

I recommend these as they work pretty well out of the box, there are drop in ways of measuring them, and they represent real user pain in most cases. However, it's worth examining for your use cases, which of these is the best.

Tools

There are a number of good tools that can be used to measure the above metrics:

The chrome devtools, including the audit tab in chrome ("Lighthouse")
Lighthouse CI, a repeatable version of the audit tab in chrome
Webpagetest.org is an amazing tool for measuring some of the "hard to measure" metrics listed above – it can produce a video of page load, which it can then analyse to calculate metrics like the speed index.
Sentry, New Relic and Google analytics are vital tools for actually tracking real user metrics. Remember the importance of measuring on real devices and real networks – a tool like one of these is essential for doing so.

It's important to choose a good metric, that reflects real user networks, devices, and experiences. It's also important to choose a metric that you can automate the collection of.

Now that we have chosen a metric, we need to consider how we will get to this goal, and protect it from the grasp of entropy!

Measuring performance (Part 2)

Joshua Nelson ✨ — Wed, 14 Nov 2018 08:48:23 +0000

Performance is a problem. The evidence is clear – performance affects your business goals, your user’s happiness, and it impacts areas with poor connectivity even more than you might expect.

It’s really tempting to immediately think, “I already know what to do! Let’s just fix the problem”

Certainly, there are some quick performance wins out there. However, if you want to permanently and certainly improve performance, we need a different approach.

You can’t improve what you can’t measure

This is a popular saying. The rationale is: changing something requires knowledge of both what you want to change, and critically, how to tell if your changes worked. It’s important to know if your changes have made an impact, and by how much, so that you know whether you should keep performing that action, or try something else.

However, I think it is still missing something

You can’t meaningfully improve what you can’t meaningfully measure

We want to be measuring the right thing. If we measure the wrong thing, it’s worse than measuring nothing – we think that we’re having an impact, but we are not solving a meaningful problem. We’re just improving random numbers.

So, we must carefully and deliberately examine what it is we’re measuring, and make sure that what we’re measuring is “meaningful”

What is meaningful?

That’s a great question. In the context of the universe… hard to say. But in a performance context, we have a clear answer:

Meaningful = better for our users

Ultimately, we’re making websites and apps for users. We’re fixing performance for our users, in the hope that we’re making existing experiences great, and enabling more (and possibly different!) users than we had before to use the information we hold.

A user centric definition of performance

We’ve found a problem that is blocking this: performance. Let’s define “performance” for our purposes as:

The time for a page to load for a user

We can break this down to understand what it really is that we’re trying to measure.

What is a page?

From the users perspective, a “page” has the following :

Behaviour
Appearance
Media
Information
Semantic information

Which, from a computer’s perspective, is:

Javascript
CSS
Assets
Data
HTML

So if we want to truly understand a page, and how it is loaded, from the users perspective, we have to understand how these things get delivered to the user

But, are we done? Traditionally, yes. Each of these iterations is considered a page. However, today, the user might perceive something quite different as a “page”

Noting the addition at the end – from the users perspective, there is not much difference between a page loaded through an SPA transition, and the first page load of a site.

So, ultimately, a page is:

A HTML document
A single page app state
An app state
Whatever your users think it is

What is “loading”?

Watch the video below, and decide when you think the page has loaded

Load is not a single moment in time — it’s an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as "fast" or “slow” – https://w3c.github.io/paint-timing/

There is no one event, or one easy answer to say when a page has loaded. It might even require knowledge of the future! You may think a page has loaded, until you see that there was actually more to come. It’s also a spectrum – we have varying states of “loaded-ness”, and a metric compresses this into a single number.

For this reason, we need to be very careful about how we’re picking the metric. It should represent what the user thinks of as “loading”, and ideally, would have a way of representing the user’s perception of "loaded-ness".

Who are our “users”?

Who your users are might be obvious, but that may also be hard to determine. There are many variables to consider: users with fast or slow cpu’s, users with fast or slow internet connections. They may be a regular visitor, or it may be their first time. All of these factors impact the overall experience, and it’s important to measure them to get a better understanding of performance.

Now we know what is involved in loading a page, from the users perspective, we can start thinking about which metrics to actually use to measure this experience

The case for performance (Part 1)

Joshua Nelson ✨ — Wed, 14 Nov 2018 08:47:16 +0000

Note: this is part 1 of a series on meaningful performance metrics.

The median page load time for a website on a mobile device is 15.6 seconds.

15.6 seconds.

Think about that.

Imagine if you picked up a newspaper or book, and the letters were invisible, or jumped around, for a full 15.6 seconds before staying still.

First, you'd probably be shocked, books don't normally do that. After that, you'd probably drop it somewhere around the 10 second mark.

This is a totally normal experience for lots of people when trying to use the web on mobile devices. This is a fundamentally broken experience, and it's one that we can fix.

The pain of slowly loading websites is one that I've felt acutely over the course of my life. I used to live in a fairly small town, in rural Australia.

Australia isn't exactly famous for blazing fast internet speeds. They did a test, around the time I lived there, in 2009. The Prime Minister said

If [the opposition] had their way Australians would be left using carrier pigeons for the future rather than accessing an internationally competitive broadband network

So, they tested it. They flew a carrier pigeon with a 700 megabyte usb drive from the central west, to Sydney, about 100kms or 60 miles.

The carrier pigeon won, in 1 hour and 5 minutes. They sent a car, which took 2 hours and 10 minutes. And the internet didn't even make it, it dropped out twice.

This is the environment that web pages are loading in, every day. But, it was in 2009, so surely things have gotten better since then, right?

Luckily, they have! Internet speeds have improved over time:

Reference

And on top of that, CPU speeds have also been increasing every year:

But alas! The web isn't getting faster at all:

Reference

Why is this? We keep improving our technology, but the internet speeds have stayed roughly the same over the past few years.

A similar thing happens when we add extra lanes to a highway – a phenomenon known as the "induced demand" effect. Research has found that adding extra lanes to a highway doesn't actually improve traffic much at all – and sometimes makes it worse. A 1% increase in highway capacity can lead to an up to 1.1% increase in demand! The more highway there is, the more people want to use it.

A similar thing has happened with the web. As technology has improved, our appetite for media, new experiences, and ultimately, total bundle size, has grown.

Reference

So, this problem is not getting better. But for the sake of our users, it needs to.

The impact of performance

There are three major areas that this has an impact: It affects business goals, user happiness, and ultimately, the world.

Business goals

Performance directly equates to business goals, and money $$$.

Research conducted by Microsoft found that a one second delay in Bing resulted in a 2.8% drop in revenue. Two seconds of delay resulted in a 4.3% drop.

Walmart found that a one second improvement in load time resulted in a 2% increase in conversions, and every 100ms resulted in up to a 1% increase in conversions.

Google found that publishers whose mobile sites load in 5 seconds earn double from mobile ad revenue than sites loading in 19 seconds.

There are many, similar results from all sorts of sites.

So, time invested in fixing performance directly leads to money. It's already worth investing in performance, just based on this alone.

User happiness

Human Computer Interaction research shows that from the users perspective, there are three general categories of tasks:

Tasks in <= 0.1s are "instant" tasks. The user feels as though the system is reacting immediately to their input
Tasks in <= 1s are flow tasks. The user is able to maintain a sense of flow as they are navigating through their tasks. They will notice delay, but it will not break concentration
Tasks in > 10s result in a task switch

However, along that spectrum, from 1 second to 10 seconds, users are getting progressively more and more frustrated. The moment at which the user is switching a task, the user is certainly frustrated – impacting how they feel about your product, and making them unhappy.

The world

A version of youtube was created, called "Youtube feather". This version of youtube was 90% lighter in terms of page weight, and contained just the bare minimum for youtube to load. The creators wanted to see if this would improve average load times for that version, so they opted in a small percentage of traffic.

Strangely, they found that the average load time actually went up!

Upon investigation, they found an increase in traffic from Southeast Asia, South America, Africa and Sibera – areas with traditionally poor internet connectivity. These were actually new users – users who previously would not have been able to use Youtube at all, due to prohibitively slow loading times!

What next?

So, performance is a problem, and it's one worth fixing. However, it's pretty likely if you're reading this that you already think that performance is an issue.

Then, why haven't we fixed it?

There are a couple of common responses I've heard:

The "give up": "It's such a hard problem, we can't fix it"
The "denial": "It's ok, our users have fast internet and cpu's, right?"
The "loop": "Oh god you're right, let's fix it" -> "we fixed it!" -> "Oh god it's terrible again"

So, performance is doomed to be bad until the inevitable heat death of the universe. Ever expanding entropy will claim all. Chaos reigns supreme. We can’t control it, performance will always regress.

Or, we try.

Meaningful performance metrics can save you.

We need a meaningful way of measuring performance, and to make a commitment that we'll hold to, once and for all.

The state of the state: React state management in 2018

Joshua Nelson ✨ — Fri, 15 Jun 2018 06:05:42 +0000

There's always been a myriad of ways to manage state in React. Redux has always been a popular choice, but with React 16, and recently released libraries, there are now even more options. What are these options, and why would you use any of these over any others?

I've gone through some popular choices for managing state in React, and created very simple todo apps to demonstrate their usage. I've tried to keep things as simple as possible, so that you can directly compare these examples. The source is annotated with comments, so take a look and see what best fits your use case!

React's setState()

State is discussed at the start of many different React tutorials for a reason. It's included as a part of React, and is a core part of the way the framework works.

This is referred to as "local state" in the react docs, "state". Here we will call it "setState()" to differentiate from the other approaches.

setState() is a simple way to manage your application state, and doesn't require any libraries beyond just React.

There are some good reasons to use setState():

Your state is not entirely describable as plain objects (you may store unserializable state in setState(), such as DOM nodes, or objects with circular references)
Your changes are not pure functions, and depend on the "outside world" (like, the browser) to determine how state should change
You don't need a global view of the UI – your state will never be persisted or stored remotely.

✨ Example

There's annotated source available for a comparative example.

Redux

Redux is a popular alternative to using setState() when the above constraints no longer hold true. Redux is a set of tools for writing to and reading from a global state in a functional, consistent way. React redux provides a convenient way of mapping your redux state onto React components.

Async redux

For async and remote state, Redux thunk and Redux saga are popular choices. Redux thunk uses redux middleware to allow actions to be async functions, and redux saga uses a pattern that allows easy handling of async behaviour and side effects.

Redux observables is a way of allowing all the power of observables in your state management, pluggin RxJS into redux through some middleware. rxmarbles provides some great examples to give you and idea of what's possible here.

While Redux thunk and Redux saga make async state management with redux easier, but can become one more thing for developers to learn regarding state management.

⚠️ Redux is the de-facto standard for state management in React, but you might not need Redux (by Dan Abramov, a co-author of redux!). Choosing something more complicated than you need will slow you down and complicate simple state changes. This applies to other items in the list - you might not need anything other than setState().

The questions to ask are explained well in you might not need Redux, but in summary – Redux is good if you need serialisable state with an opinionated way of managing global state, but can be overkill for some use cases.

✨ Example

Apollo link state

Apollo link state is a way to combine your local state management with your remote state management. The approach assumes you are using Apollo, which allows you to use GraphQL over Rest. However, you do not need a GraphQL server in order to use this approach! – apollo-link-http allows you to write everything you need to adopt Apollo client side. This means that it's a viable all-in-one solution for state management (async and remote included), even if you aren't using GraphQL.

The way that local and remote state becomes intermingled is through your queries and mutations. apollo-link-state gives you access to a special @client directive that tells Apollo to look for this piece of state in local memory, rather than some remote server.

query GetTodos {
  items @client {
    id
    text
    done
  }
}

Getting Apollo set up just for state management can be a bit of work, but the payoff is a natural way of querying and mutating state, combining local and remote state management.

For simple use cases, and apps that don't heavily depend on async or remote state, Apollo link state is surely overkill. For more involved use cases, Apollo can help by consolidating state management into one system.

✨ Example

Unstated

React 16 has brought with it a new context API, which is a nice way of sharing information around React's virtual tree. Unstated is a library that makes the most of this – it's a light weight way of managing global state across your application.

It's similar to Redux conceptually, but with less opinions about how you should use it. The state is not sliced up into different sections, and defining "actions" is left to you. The API is very similar to React's setState() in shape.

⚠️ Given this, if you're using Unstated, you should again carefully consider if setState() is sufficient for your use case. From the unstated readme:

The unstated readme gives good guidance about when to use alternatives such as Apollo, libraries, or Backbone models and collections.

From the readme:

Unstated isn't ambitious, use it as you need it, it's nice and small for that reason. Don't think of it as a "Redux killer". Don't go trying to build complex tools on top of it. Don't reinvent the wheel. Just try it out and see how you like it.

If you're looking for a simple, un-opinionated state management system and don't want the overhead of alternatives, it's worth looking at.

✨ Example

Honourable mentions

This is not an exhaustive list! I've included some references to alternatives not mentioned here that I haven't yet been able to create examples for or include here.

Stockroom lets you offload your store management to a web worker! This frees up the main thread from computation, and makes all of your requests to read and modify state async.
Backbone models and collections is a well known alternative, and might be sufficient for your use case.
Alfa is a very small and simple state management option.
MobX is a popular choice (hoping I get a chance to try this and add it to the blog!)

Summary

React doesn't include this type of state management itself, which leads to this rise of alternative state management systems. It can be hard to make this choice, but it's good to be allowed the choice – different problems work better with different solutions, and it's nice that React is flexible enough to work with all of them :)

👋 Hi! I’m Joshua Nelson. I’m a developer who cares about making the web a better, for everyone ✨

React explaining, explained

Joshua Nelson ✨ — Wed, 30 May 2018 07:14:12 +0000

Richard Feynman was once asked by a Caltech faculty member to explain why spin 1/2 particles obey Fermi-Dirac statistics. He gauged his audience perfectly and said, “I’ll prepare a freshman lecture on it.” But a few days later he returned and said, “You know, I couldn’t do it. I couldn’t reduce it to the freshman level. That means we really don’t understand it. [1]

Explaining things is hard. It requires knowing that thing intimately, back to front. Putting yourself in the mind of someone who doesn’t understand reveals what you don’t understand. It’s an exercise in empathy, and a skill that can be honed.

Effectively explaining is very satisfying, and is a useful skill to develop. As software engineers, a large part of our responsibility is not only understanding things, but to explain them too. Many times a day, we need to explain things to new team members, product managers, designers, and even people from completely different disciplines.

Is React easy or hard to understand?

I’m going to be honest: I’ve had a hell of a time getting my head around React. More than any other technology I’ve touched over the last 10 years of my career, I just haven’t had it click for me. It’s very frustrating as I really want to learn it, and it’s clear the library has legs.

– Brad Frost, http://bradfrost.com/blog/post/my-struggle-to-learn-react/

This isn’t the first time I’ve heard someone say that React is hard to learn. However, I’ve also heard people say “The core concepts of React are easy to understand!”.

So, which is it? Is it actually hard to understand React? Is it more or less hard than understanding another framework?

There’s no definitive answer. React will be easy to understand for some people, and harder to understand for a different set of people. People come with a different backgrounds, and a different set of “mental models” (more Richard Feynman stories, sorry 😅), which means that the core concepts of React will be easier or harder for different people!

For someone who has worked a lot with web components, React has a nice home in that person’s set of mental models. However, for someone who has only really used jQuery in an ad-hoc way, there are lots of new concepts to understand, and care must be taken when explaining to cover those.

If lot of concepts of React are new to people, it’s useful to know how people understand things, so that we can more effectively explain.

How to explain React things

It took me some time to realise the way you understood React isn’t the way that someone else will understand it.

There are many reasons for this — people come from different backgrounds, with different experiences. They may be more used to how Angular works, or Backbone, or maybe they’re used to using jQuery to manipulate the DOM directly. They might have limited javascript experience, or they may know everything there is to know about ES6. The important thing is to spend time getting to know the background of the people, or person, that you are explaining things to. People learn new concepts by relating them to things they already know, and this can be encouraged with good analogies and comparisons.

Another key reason why someone else won’t necessarily understand it in the same way is due to history, and time. I was talking with a friend recently about how rapidly things change. “Front end stuff just moves so fast! I learnt javascript a year ago, and the next time I came back everything’s different!”. Gradually building up concepts over time made learning React straightforward for me, but for somebody who is confronted with React, ES6, Webpack and JSX all at the same time — these are all new concepts that are easily confused with each other.

So, how can we explain better?

If you don’t pay careful attention to these differences in experiences, your explanation won’t be effective. Depending on whether you’re explaining 1 on 1 or in a group setting, there are different strategies for approaching these varying experiences.

Ask questions regularly. This gives you an opportunity to check in on the person you’re explaining things to. It engages the other person, and makes explaining an interactive process, rather than a passive one. Ask questions that encourage engagement. Instead of asking yes or no questions like “Does this make sense?” (often met with empty nods or “uh, yeah.”), ask “what” or “why” questions, like “What would happen in this situation?” and “Why is this piece of code important?”
Be prepared to change tacts. Since there is a wide spectrum of experience, in a 1 on 1 setting, you should be prepared to tailor your explanation to the individual. This is better as it helps them relate to the knowledge, and allows them to engage more.

Give the right level of detail. If you know something in depth, it’s tempting to deep dive into interesting but unimportant details. Be prepared to use abstractions or skip parts that aren’t relevant to ensure your explanation meets the experience of your audience (note: this doesn’t mean you should simplify to the point of being incorrect )

Examples

Specifically with React, there are common confusing points for people who haven’t been following closely.

ES6 vs. JSX

Introducing these two concepts at the same time is often confusing for people. Looking at the following code sample, we can see there are multiple new concepts combined

import * as React from 'react'; //ES2015 + React
import * as ReactDOM from 'react-dom';  //ES2015 + React
const allCaps = s => s.toUpperCase(); //ES2015
class HelloWorld extends React.Component {  //ES2015 + React
  render() {  //ES2015 + React
    const { name } = this.props; //ES2015
    return (
      <p>Hello, {allCaps(name)}</p>{/* JSX */}
    );
  }
}
ReactDOM.render(<HelloWorld name="Josh"/>, document.getElementById('app'));

Starting off with an overview of which parts are ES6 can be helpful if the person is unfamiliar with this new syntax.

I also made a tool, “React or ES2015”, to help with this. Pasting a code snippet, you can see which parts are React, JSX, ES2015, or ES5, and click through to relevant documentation for each part. This tool may not be helpful to someone who can immediately tell which syntax come from where, but there are many people for who I hope this is useful!

Why are there so many ways of creating components?

A React component can be defined as a class, a function, or by calling React.createClass. This is a confusing point for people new to React. Introduce this concept carefully — provide clear guidelines on when to use each of them, to avoid unnecessary confusion (will you use state? Use a class : Use a function).

The overall model

This is my favourite part to explain, as I think it’s one of the greatest parts of building UI in React. The overall data flow model is generally easy to understand, and understanding this basic concept is a useful mental model.

This is also a great opportunity to compare with other languages, approaches and frameworks that the user is used to. Comparing and contrasting the approaches will help solidify the concepts in the learner’s mind.

From https://facebook.github.io/flux/docs/in-depth-overview.html#content
Pointing out that React is the view layer in the above diagram helps clear up ambiguity around React’s job.

The fundamental idea of the flux model is useful to know, but give the right level of detail, and don’t spend too much time in the abstract. Seeing how things follow this model in practice is more useful than an in-depth, abstract explanation of the flux model.

Helper libraries

When creating demos or writing examples for people, be careful to not depend on helper libraries that are not relevant to the point you are trying to convey. If you’re trying to make a point about React state management, avoid using lodash, react-router, react-intl, or anything that’s not directly related to what you’re trying to explain.

While it’s clear to people familiar with lodash that _.concat isn’t the point of your example, this can be a confusing distraction for people unfamiliar with lodash, and the point you’re trying to make.

State

Another common question relates to what type of state to use. This is getting more confusing for beginners as there are many new alternatives — each with some advantage (they’re small, they’re not running in the main thread, they’re wired to GraphQL, or they’re just using normal React features like store and context).

Personally, I find these new developments exciting, but understandably, new learners find the amount of choice here distressing. Providing clear guidance helps mitigate this. Pick one of these and learn that to begin with — when you’ve come to grasp the main concepts of React, the nuance of which store is best becomes a more relevant question.

How to explain in general

Research shows that people learn more effectively with active, rather than passive learning [2]. Active learning is a style that encourages learners to analyse what they know and do not know. For an explainer, this means encouraging questions, and also asking questions regularly to keep the learner engaged. People also learn more effectively when they are given control over what they want to learn, as this encourages engagement [3].

Once someone is engaged, learning can take place by relating new concepts to existing ones that they already understand. Learning and remembering new ideas becomes easier once that idea finds a place in our set of mental models.

Why all of this?

Front end development is great, and getting better all the time. The way that we can continue making the technology, and the community even better, is by putting effort into explaining things clearly and effectively. More people can learn, become experts, and share new, diverse ideas.

Communicating how technologies, and React, work, is a key part of this. The way you understood React isn’t the way that someone else will understand it, and with some conscious effort, we can get better at sharing our ideas about things with each other 😁

👋 Hi! I’m Joshua Nelson. I’m a developer who cares about making the web a better, for everyone ✨

This is a cross post from https://medium.com/@joshuanelson/react-explaining-explained-13a3fe6e5b9d

Six Easy Pieces: Essentials of Physics Explained by Its Most Brilliant Teacher
(Bransford, 2000, pg.15–20)
J. Scott Armstrong (2012). “Natural Learning in Higher Education”. https://faculty.wharton.upenn.edu/wp-content/uploads/2014/09/Natural-Learning-in-Higher-Education_2.pdf

Software Imagineering

Joshua Nelson ✨ — Fri, 24 Mar 2017 06:34:19 +0000

If you work at a Disney theme park, you might be what they call an Imagineer.

“Imagineer is a portmanteau of imagination and engineering, and the term was coined to describe a role that blends these two concepts. Imagineers design the theme park’s rides, attractions, and overall experience – but they also engineer them.

The process starts off with what is known as “blue sky speculation, or as I’ve heard it referred to, “going to crazy town”. This part of the design process is pure imagination – no limits, disregard reality. Just ask “what if?”

For instance: imagine a ride that could truly convince people that they were flying. No rails, no strings attached. What would it feel like? What would the deal experience be? But, how would this ride actually work? Where are people going to sit? If I can see the ride, I’m not going to be convinced that I’m flying.

Delay any questions or doubts that you might have in your mind. Think about the ideal experience.

I am a developer on the design team at Atlassian. When I joined the team, I didn’t know what I was getting into – I liked front end development, and my team sat under the design umbrella. I bought a few books on design, but I had no idea what I had signed up for.

Aundray Cheam, flickr

Part of my job is taking designs from the Atlassian Design Guidelines, and transforming that into a user interface library for our developers to use. I see the discrepancy between imagination and reality every day. The experiences our designers imagine are fantastic, but I often see designers and engineers unable to compromise when it comes to implementing the designs. If compromises cannot be made, it leads to bad, buggy implementations, or clunky experiences that do not match the user’s needs.

It’s imperative that our designers work closely with engineers, and the engineers with designers, in order to make educated and conscious compromises where necessary.

Compromises

Large scale implementation of design is hard. Developing for web applications and the front end is particularly fraught with difficulty. In theory, we’d be able to tweak design by just changing CSS rules, but reality is not so simple. Overrides, hacks and edge cases are plentiful, and engineers need to be perpetually conscious of these in order to maintain a bug-free experience.

Software engineers are trained to think of edge cases for the software they design. When it comes to talking to designers, this type of thinking can easily influence our conversations. Engineers need to be realistic, but they should also know when the feedback is appropriate, and how to give it.

I recall an instance where a designer did some conceptual work for a new user experience in one of our products. The end result was amazing – it included automatic discovery and running of tests and intelligent repositories that set everything up for you. My feedback for them poked holes in the idea though – I asked, “How would this work? This isn’t what reality is like at all. This cannot
be done”.

Later though, I realised that this was not the point of the exercise – and I approached giving the feedback in the wrong way. I was thinking about the engineering work (my own experience), when I should have been thinking about the end user’s experience. Approaching the idea from the perspective of a user, it’s a fantastic idea. Thinking about the user’s experience first, I would have been able to compromise to achieve the same goals that the designer had – the best possible experience for our users.

Aundray Cheam, flickr

Similarly, designers need to be aware of engineering concerns when it comes to their designs. Often these concerns are technical limitations. A good designer is not afraid of constraints though – if the designer is willing to compromise, and to understand the technical constraints fully, the designer and the engineer can create a better user experience for all users.

During this type of conversation, both parties must be aware of each other’s goals, and know when it’s sensible to compromise. The way to achieve this is through empathy – designers must be willing to understand the goals, concerns, and fears of engineers, and engineers should know why designers create the designs they do. Ultimately, engineers and designers should care about the experience of the user.

The imagineers at Disneyland were able to create a ride that simulated the sensation of flying. This ride is called “Soarin’ Over California”. The ride is constructed with a large screen in front of the participants, completely encompassing the field of vision. They sit in elevated chairs that move as the ride progresses.

Josh Hallett from Winter Haven, FL, USA – Soarin’ – Disney California Adventure

An idea like this is a compromise between engineering and design. Participants don’t actually fly – they don’t even move. However, the core experience, the sensation of flight, was maintained throughout the design and its implementation, and the ride’s users are happier for it.

Design and development, or imagination and engineering, are often thought of as opposed forces, or a line across which a tradeoff can be made – but if both disciplines are willing to fully understand the goals and constraints, we can make better products, experiences, and theme park rides for everyone.

Joshua Nelson

Developer at @Atlassian

(cross-post)