I had an interesting realization recently: I was three years into my career when I got my first remote job, and it’s been about three years since then. I’ve now spent half my career working in a traditional in-office software development job, and the other half working remotely!

Increasingly, remote work is becoming a common, mainstream thing. Twitter pundits have been quick to form and share opinions, and I’ve seen a lot of misconceptions and misinformation about what “remote work” is, and how it works.

This is part 1 of a three-part blog post series. Today, I’ll share what my experience has been like — it’ll be an honest look at the ups and downs of remote life. Hopefully, this context will be helpful if you’ve been considering remote work for yourself!

• Part 1: My experience
• Part 2: Finding your first remote job
• Part 3: Twitter Mailbag

Clearing up misconceptions

Let’s start by getting this out of the way — most people talking about remote work are describing something very different from my experience.

For example, this common refrain:

“Remote work sounds great because you can work from home in your pyjamas, but it’s not all it’s cracked up to be, because soon you’ll discover how isolating it is to spend all day alone”

This discussion is predicated on a false idea, that “remote work” is synonymous with “working from home”, and that it means you work alone.

I think it would surprise people just how much my “remote work” lifestyle looks like their “normal office” lifestyle:

• I get up early, shower, change into street clothes, and commute every weekday to an office
• I work from around 9:30am to around 5:30pm, grabbing lunch around 11:45am (gotta beat that lunch rush!)
• I have regular meetings with my coworkers, doing things like pair programming with my peers, or hashing out implementation details with product & design
• I socialize in-person with other folks at the office.

This schedule is not universal to remote workers, and that’s kind of the point — the idea with remote work is that it’s flexible. It allows you to construct whatever working situation works for you. Plenty of remote workers do work from home (though none that I’ve met have been the unshaven recluse so often depicted in remote-work discussions), but they do it because that’s the situation that works best for them.

Developing my working environment

I realized pretty quickly that working from home wasn’t going to work for me.

When I started working remotely for Khan Academy, I rented an office at WeWork. It ticked a bunch of boxes, but ultimately it wasn’t the right fit. It was rowdy at times. It was also kinda dreary — they keep their lights dim, so there’s a perpetual 7pm vibe. Despite having all-glass walls, my office wasn’t anywhere near natural light. The office I was renting was small enough that if I stood in the center, I could just about touch all 4 walls without moving.

About a year ago, I switched to a new office.

I’m subletting it from a local Montreal company, located in Old Montreal. It’s not really a coworking space; it feels less like a trendy startup incubator and more like a traditional small business. It grants me the perfect level of in-person social interaction; there are always people around I can talk about hockey or the weather with.

My office is big and bright, featuring tall ceilings and a large window. It overlooks a public square, and I’ve set up a digital piano in front of it, so I can take frequent breaks and watch tourists meander while I noodle on the keyboard. It’s pretty great.

I am very aware that this office is a privilege that many cannot afford — it costs $700 CAD / $525 USD a month. In many cases, though, employers are willing to contribute towards these costs, either in part or in full. And this additional expense is often smaller than the bump in salary folks receive when transitioning to remote work.

Notable differences

For the most part, I’ve been surprised to see how similar remote work is from in-office work. There are some things that are different, though. Let’s look at them in depth.

Salary

I live in Montréal, Québec. According to Payscale, the average Montreal software developer makes about $65,000 CAD, about $49,000 USD. This is dramatically less than in the Bay Area, where Payscale estimates the average salary at around $118,000 USD. That’s a 2.4x multiple!

Remote-friendly companies don’t always pay Bay Area salaries, but in my experience, they tend to pay quite a bit better than local ones. For example, Buffer pays based on San Francisco rates, and deducts up to 25% for cost-of-living. This feels pretty harsh to me, and yet it still comes out to a much more generous salary than is common in Montreal.

If you already live in a high-pay, high-cost-of-living area like San Francisco or New York City, working remotely can grant you the freedom to move wherever you’d like. While not everyone can uproot their family and move, it’s still better to have the option than not.

It’s worth noting: companies are moving away from cost-of-living multipliers. Employees should be paid based on the value they provide, not where they happen to live. The truth is that all kinds of things affect how much of our income is discretionary, such as having kids or being in debt, and employers have never adjusted salaries for those things. If you’re providing Bay Area value, you deserve Bay Area dollars!

Meetings

One of the myths of remote work is that it’s “lone wolf” territory, meant for contractors who need little guidance and have little oversight. The truth is that all of my years as a remote worker have been fairly collaborative, working within tight-knit teams to develop and ship features.

As a remote worker, I have roughly the same number of meetings as I did when I worked in-office.

Most remote-friendly companies will have a policy that every meeting room is equipped with video-conferencing software, and every meeting has a Google Hangout or Zoom session created for it. This way, remote folks can join any meeting added to the calendar without meeting organizers having to do anything special.

It can be hard to fully participate, though. It’s human nature to interact primarily with the people in the same space as you. As a remote employee, your disembodied, televised head is often floating out of eye-line, off in the background. As conversation picks up, it can be hard to get a word in edge-wise. If you wait for the perfect opportunity, you might never have a chance to speak. And if you decide to interject haphazardly, you’ll be the booming voice of God, a gigantic face stretched across a 72" screen, causing heads to swivel around like a mob of startled meerkats. I don’t like drawing that much attention to myself.

If you work for a fully-distributed company, this isn’t a problem, since everyone’s on their own laptop. And many companies are moving to a model where all meeting participants join on their own computer, even those in the same room together. This ensures a level playing field, and makes it much easier for remote participants to participate.

Being kept in the loop

A concern many folks have about remote work is that inevitably, no matter how much Slack is stressed, two employees will bump into each other in the office and share information or make decisions. Folks in other timezones and countries will miss out on that information, and sometimes this can make it harder to be effective at your job.

I can definitely think of times where, say, I spent a day working on something only to learn that the feature isn’t needed anymore… but the thing is, that’s happened to me both as a remote worker and as an in-office worker. Communication challenges are not unique to remote work. And the solutions are pretty much the same:

• Daily standups ensure visibility around what everyone is working on, and if they’re blocked by something
• Being a good communicator, and being sure to follow up frequently. If I’m picking up a ticket from Jira that hasn’t had a comment on it in 4 months, for example, my first step is to contact the stakeholders and make sure the issue is still relevant.
• Working in small (“two pizza”) teams, and checking in with teammates frequently

People assume that it’s harder to stay in touch with people when you don’t work out of the same space, but I’d argue it’s the opposite. Tools like Slack let you instantly fire off a message, without worrying if you’re interrupting someone deep in concentration. When I worked in-office, I was always hesitant to walk over to someone hard at work. Slack gives me license to talk to people more often, not less.

Loneliness, and forming personal connections at work

Of the articles and Twitter threads I’ve read from people who have actually tried remote work, this is the most common issue. For folks who are used to working in an office, it can be hard to transition to a model where you only speak with your co-workers over screens, where there are no Thursday-evening game nights, mini birthday celebrations, or group lunches. In an office, it’s easy to spend twenty minutes by the watercooler, just hanging out with your peers. Those serendipitous interactions don’t occur remotely, every communication is intentional.

In my case, I’ve solved for this by renting an office. The people I share this space with technically aren’t coworkers — we don’t share an employer — but that doesn’t stop us from gossiping about the Habs, currently on their worst losing streak since 1940, or sharing vacation pictures with each other.

It’s also self-evident to me that it’s possible to form close personal relationships with remote coworkers — I’m still friends with many folks I worked with at my first remote job! It may not be ideal, but it works. If hit TLC television show 90 Day Fiancée teaches us anything, it’s that humans are remarkably good at overcoming the artificial nature of long-distance communication.

Another important consideration: depending on where you live, and the size of the organization, you may not be alone in your city! I live in Montreal, a city not really known for being a tech hub, but when I worked at Khan Academy, I had two coworkers that lived here. Once every month or so we’d grab coffee and co-work together, either at a co-working space or at a coffee shop. Many orgs will rent out a small office for cities that reach a certain threshold, blurring the line between “remote work” and “flexible in-office work”.

Remote mentorship

Many folks I’ve spoken to have expressed concern around mentorship; for folks early in their careers, are they at a disadvantage by not being in the same room as the senior devs?

Stress and asking for help — I remember when I was about a year into my career, I was working at a local startup and I had gotten myself into a big mess with Git. I was worried I’d accidentally erase all the progress I’d made on the task that day. The senior dev sat right near me — I could walk over and tap him on the shoulder, but what if he was in the middle of something? I imagined the frustration he might feel, watching his mental house-of-cards collapse as his focus evaporated, all because some sheepish junior dev doesn’t understand source control.

Now that I’m a senior developer myself, I recognize how silly this thought was — I’m always happy to help when someone needs it! But that fact is irrelevant; junior devs often worry about stuff like that, and that worry can lead to bad outcomes, like not asking for help when it’s needed.

There’s something to be said for Slack’s asynchronous model. It’s so much easier to send someone a message, knowing they probably won’t see it right away if they’re deep in concentration.

Receiving help online — What about the actual getting-help itself? Surely it’s better for two devs to sit side-by-side when explaining a problem? I’m not so sure. Tools like Screen Hero (RIP) and Slack’s video conferencing let two people share a screen, each with their own connected mouse and keyboard. Pair programming works really well when the “driver” can use their cursor to indicate a specific line, or draw on the screen using a pencil tool. I expect the tooling will only improve as remote work becomes more common!

Also, I feel like text chat is underrated for stuff like this. It lets the explainer choose their words carefully, and make sure the explanation makes sense. And it provides a permanent transcript that the person being helped can reference in the future, if the explanation doesn’t stick.

Remote intern mentorship — One more anecdote: every summer at Khan Academy, we’d hire a class of college interns. Every intern would be assigned a mentor, a point person to provide technical guidance, assign and review work, and generally make sure that the intern was having a happy, healthy, educational summer.

Mentors could either be remote or in-office, and after a few summers we concluded that it made no difference; interns were as likely to succeed regardless of whether their mentor was sitting next to then in Mountainview, or (as in my case) over 1000 miles away.

I was an intern mentor myself, and it was incredibly fulfilling! I don’t believe being remote was a hindrance at all.

Proceed with caution — Despite all of this, I still recommend proceeding cautiously as a junior developer seeking remote work. I’ve had the privilege of working for stand-out organizations that have put a lot of resources into making the remote culture succeed. If certain conventions aren’t in place, it can be much harder to receive mentorship as a remote employee. I’ll talk more about this in the next post in this series.

Career progression challenges

I’ve had the privilege of working remotely for several different organizations now, and I’ve seen how different structures can lead to different cultures.

At one role in particular, about 50% of the engineering department was remote, while 100% of the executive team (and most managers) were in-office. A good chunk of the executive team was new to the org, and they had come from organizations that were not remote-friendly. This meant that in-office “individual contributors” (ICs) were able to form relationships with senior leadership in a way that remote workers weren’t.

I remember during a particularly contentious period, hearing from an in-office friend that a member of the senior leadership team had come up to them, bewildered to learn that remote workers were unhappy with recent policy shifts. This member of the exec team went to an in-office IC for clarification about how remote folks were feeling, because that’s who they knew.

This problematic dynamic was highlighted during performance reviews. As in many organizations, promotions were determined by senior leadership, and the process was not super transparent. When a remote worker is denied a promotion, it’s hard not to wonder if personal relationships played a part; after all, wouldn’t anyone have a subconscious bias towards the folks they have lunch with every day vs. someone they barely know?

These kinds of “office politics” are not unique to remote workers — at any organization, there’s the risk of executives biasing promotions towards folks they like. Even if everyone works in the same space, there’s no guarantee that relationships will form equally! And I suspect it’s human nature to reach for external factors when trying to understand why we weren’t selected for a promotion.

Despite these caveats, career progression can definitely be harder for remote workers if the company isn’t fully distributed. In the next part of this blog post series, we’ll dig into this a bit more as we learn more about how to find a great remote job.

Conclusion

The goal of this blog post was to share my experiences as a remote worker, with the hope that it provides a bit of clarity around whether or not remote work could be a good fit for you. And it’s a hard question to answer, since “remote work” can mean so many different things. Very few of the experiences I’ve had — both good and bad — are universally true for remote work.

Ultimately, looking back, there have definitely been some bumps on my remote journey, but the overall experience has been very positive. I don’t expect I’ll go back to traditional in-office employment any time soon.

I do think I’m a particularly well-suited person for remote work, though. When I worked in-office, I was on a perpetual mission to find a way to eat lunch alone, without offending anyone or arousing concern. I had wonderful co-workers, but my idea of a perfect lunch is sitting alone in a park, listening to a podcast. In that sense, remote work is a perfect fit for me.

While I do think the concern about isolation as a remote worker is overblown — after all, I’m around people constantly — it is true that it can be harder to form close personal relationships with folks you’re working around, rather than working with. Making friends as an adult is tough! If your current social network is comprised primarily of people you work with, and you thrive on that sort of camaraderie, remote work might be more of an uphill climb for you.

Aside from this, I believe the other concerns folks have about remote work can be mitigated, either by customizing your work environment, or finding a company with the right kinds of remote policies for you.

In Part II of this blog post series, we’ll look at how to go about finding your first remote job, and how to ensure that it’s setting you up for success. I’ve been involved in hiring for several remote-friendly orgs, and I’ll share what companies are looking for. We’ll also examine how to evaluate the “remote-friendliness” of a company, and learn to dodge some bullets.

I talk about remote work quite a bit on Twitter, so be sure to follow me there if this kind of stuff is your jam. I also share cute animals and React stuff. And be sure to check out my actual blog, which features rich interactive posts not possible on Medium.

There is something undeniably satisfying about coming up with clever solutions to hard problems. There is a joy when you challenge yourself to use recursion instead of iteration, for example, or when you create elegant, cascading layers of abstraction that ensure code is never duplicated.

My favourite outlet for this kind of programming is Project Euler.

Project Euler is a repository of challenges based around advanced mathematics, meant to be solved with software. The catch is that your program should run in under a minute, on 2004-era hardware. That means that a brute-force solution often won’t cut it, and you’ll have to come up with a smarter solution.

Here’s an example:

The fun thing about these challenges is that they seem near-impossible at first (at least, to someone like me, who doesn’t have a math background), but often once you start breaking down the problem and experimenting, you arrive at a solution surprisingly quickly.

At least, sometimes. Other times, the problems remain inscrutable. Looking at you, Problem 60.

Once you’ve solved a problem, you’re able to view solutions that other solvers have posted. And oh wow, do people come up with terse, clever solutions for these things.

I’m kinda breaking the Project Euler rules here — you’re not supposed to share solutions, to avoid spoiling it for others — but don’t worry, these solutions are totally indecipherable, at least for folks like me coming from a JS background. You won’t spoil the challenge.

A Haskell solution

Haskell is a notoriously tricky functional language that allows for really concise solutions to hard problems:

A J solution

This J lang solution takes the cake for brevity. J has a rich library of operators, consisting of one or more symbols, and so you can express a ton of logic in a small amount of space:

These solutions leave me pretty awestruck. Clearly these solutions are pretty remarkable. It’s a true skill, and I’d bet the author of this solution felt tremendously pleased with themselves — and rightfully so — for coming up with it.

But, there’s a big difference between recreational programming on your own, and working collaboratively on a shared codebase. When you’re at your day job, or working on a shared open-source project, there are an entirely different set of priorities.

A good barometer: will an intern understand it?

A metric I like to use when writing code is this: will an intern / bootcamp grad / someone just starting their career struggle to understand what I’ve written?

In the context of a shared codebase, good code is simple code. Code that doesn’t do anything fancy. Code that makes minimal use of abstractions. Code that you’d use to explain fundamental concepts to novices.

Let’s look at an example of some code that does some data-munging. Which version of this function do you think is clearer to a new programmer?

Version 2 has a number of things going for it, on paper:

• Less code.
• Less duplication.
• Follows functional-programming principles, like using generic utility functions, reduce, immutability, etc.
• More scalable, could easily handle 10+ fields instead of 2.

And yet, how much longer does it take to understand? How many more calories would be burned, as a new programmer, trying to make sense of it?

Version 2 ticks a lot of the boxes as to what “good” code is, at least in certain circles. But there is a huge readability cost for those characteristics, and in my opinion, it’s a bad deal.

To be clear, I’m not saying that Version 2 is bad, just that it prioritises the wrong things. Everything is tradeoffs, but I believe that readability is king when it comes to shared code.

Also, I am aware that neither version is ideal. This is the best example I could find, but it’s far from a perfect example.

Why is readability so important?

To understand why I think readability is such a crucial attribute of good code, let’s look at a popular open-source library, lodash.

lodash is an immensely popular tool. It’s downloaded more than 26,000,000 times a week on NPM alone, and has over 42,000 Github stars. There is something absolutely curious about it, though; It often has 0 open issues.

This has been true for years now, even when lodash was an essential library for a huge chunk of web developers. How can this be?!

Well, one reason is that the library’s primary author, John-David Dalton, is a passionate maintainer who spends a lot of his time triaging issues as they come in. But I don’t believe anyone, no matter how superhuman, can get a library this popular to 0 issues alone.

Years ago, I heard JDD on a podcast talk about how the key to managing a project like this is to encourage lots of folks to contribute to it. One of the ways he’s done this is by keeping the code at a pretty fundamental level; by using simple, basic constructs, it ensures that aspiring contributors can understand and contribute to the code, regardless of how much experience they have. I believe JDD mentions that they prefer if/else to ternaries simply because less people have experience with ternaries. When the goal is to keep the code simple, the expressive power of the ternary operator is detrimental.

This is important to keep in mind if you’re building an OSS tool, but it’s even more important if you’re working in a production codebase with other humans. Especially ones that have less experience than you.

A plethora of benefits.

Have you ever heard someone say this?

“Less code means less space for bugs to hide”

Proponents of terse, sophisticated code will argue that for every added character, you’re increasing the likelihood of inadvertently introducing a bug, as though the bugs are an invasive species, just waiting for you to type it up a new hideout.

There was going to be a fun image of lurking bugs here, but all the google results I got for “bugs hiding” were absolutely horrifying, so nevermind.

While it may be true that every character stroke increases the likelihood of a typo, those issues are easily caught and quickly resolved. The pernicious bugs— the ones that tend to break user experiences for weeks as developers pass the support ticket around like a hot potato— are often caused by too much complexity, not too many characters.

In order to debug an issue, you have to wrap your mind around what the code is doing. When you create an abstraction to reduce duplication (“Make it DRY”), you add a layer of indirection that your mind has to unpack. The harder it is for your mental model to account for every edge-case and possible state, the more likely it is that you’ll have trouble diagnosing what’s gone wrong.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”

— Brian Kernighan, The Elements of Programming Style

The cost of abstractions.

If the goal is to reduce complexity, and abstractions add complexity, should we abolish abstractions altogether?

I even came up with a silly acronym for this idea! WET — Write Everything Twice.

Well, no. Abstractions are pervasive — loops are abstractions. Functions are abstractions. Programming languages themselves are abstractions over machine code, which itself is an abstraction over transistors flickering off and on really fast. It’s abstractions all the way down.

The key is to weigh the cost of an abstraction against its benefit. Say we’re building a React app, and we have a list of 100 things to render. We could copy/paste the same JSX 100 times, or we could map over an array and write the JSX once. The “complex” solution in this case is totally worth it, because the underlying complexity is commonly known, and the alternative would be burdensome to maintain.

As we build stuff, we make trade-off decisions like this all the time. If I have a point, it’s that we should consider these tradeoffs with the junior coder in mind; how much complexity are we adding for them? Is it worth it?

Inevitable complexity.

Code sometimes has to be complex, because the real world is complex and our software has to model it! We won’t always be able to write code that a junior engineer can easily parse and contribute to. Sometimes the business logic is genuinely really tricky, sometimes we have to use an API with an inscrutable interface, and so on.

I think the best way to deal with this is to try and sequester complexity. Set up clear boundaries between the simple stuff and the complex stuff. Don’t let the complexity seep into the surrounding areas.

John-David Dalton did this with lodash. According to his interview in that same podcast, the vast majority of lodash code is simple and easy-to-follow, and they’ve pushed the complex bits to a sophisticated core that handles the hard problems. This means that most contributors are spared from having to deal with that complexity, since it isn’t sprinkled across the application.

If your app is architected so that the most complex concerns are all dealt with in the same place, you can keep the overwhelming majority of your app’s surface area simple.

What if the junior engineer needs to work on that complex core? Well, good news! They have a more-senior person (you) to help guide them through it. Mentorship and education is a huge part of being a senior developer.

In conclusion.

One of my favourite talks from React Rally last year was Chantastic’s “Hot Garbage; Clean Code is Dead”. I won’t spoil the talk (seriously, go watch it!), but one of the takeaways I took from it is that everyone suffers from impostor syndrome, and one of the problems with that is that we’re always trying to prove to each other that we know our shit. If we write really clever code that nobody else can understand, they’ll recognise how smart and capable we are!

Hopefully by this point in the blog post, if I haven’t failed spectacularly, it’s clear why that idea is flawed.

Over the past few years, my thinking has shifted. The code that impresses me is code that I can understand quickly. Turning a complex problem into simple code is an incredibly hard challenge, and so much more impressive than solving a simple problem with a complex solution.

My goal now isn’t to write clever code, my goal is to write welcoming, accessible code.

Thank you for coming to my TED talk.

Earlier this month, I had the incredible privilege of speaking at React Rally, one of my favourite React conferences. It was amazing.

This was my second conference talk this year — the first being at React Europe — and so I wanted to take a step back and reflect a bit on the process. I remember being very curious about how speaking at tech conferences worked, before I started speaking; it felt pretty veiled and mystical to me.

My hope is that this post will be illuminating, especially for folks looking to get started as a speaker. I’ll go through some of the things that worked for me. Your mileage may vary, of course; this is just my experience.

1. 💡 Coming up with an idea.

The first step to any conference talk is figuring out what you want to talk about!

There are a lot of ways to approach this, but my favourite is to come up with something you feel passionate about, and that you feel isn’t getting enough attention.

In my case, I was really passionate about “explorable explanations”.
An explorable explanation, sometimes just called an explorable, is a project that mixes elements of data visualization, web applications, and video games to create interactive learning experiences. Their goal is to lower the bar for complex subjects by letting the user discover how it works through exploration and experimentation.

Some great examples of explorable explanations:

• District by Christopher Walker
• Parable of the Polygons by Vi Hart + Nicky Case
• Learn Music Production from Ableton
• Tons more available on Explorabl.es

I decided in late 2017 that I wanted to build my own explorable about how waveforms work. It’s a subject I studied a decade ago, and thought could really benefit from being taught in an interactive way.

After several months of work, the project was launched: Let’s Learn About Waveforms.

The response to this project was overwhelming. I got so many deeply-personal thankful emails, from audio students, to people who had struggled learning it on their own, to teachers and college professors who want to use this tool to explain audio or physics concepts in class.

It made me realize that there is a strong need for this kind of content. React developers already have most of the skills needed to produce these kinds of experiences, so why aren’t more of us doing it?

A conference talk seemed like a great way to spread this message, and get folks excited about building their own explorables.

More broadly, I’m always fascinating by interesting intersections between disparate things. I’d love to see creative coding represented more at programming conferences, for example!

Another category of “things we aren’t hearing more about” are things that our users need, that we tend to neglect: stuff like accessibility, localization/internationalization, performance. If you have ideas to make these things easier, even if they’re still hypothetical, I think it’s super worth pursuing!

2. 👀 Finding a Conference.

Once you have an idea for a talk, you’ll want to find a conference to submit it to!

A great resource for finding conferences is confs.tech. There’s also this repo full of web conferences.

Finally, you can find specific conferences by topic; if you work with React.js, for example, you can check the React conferences list to find suitable conferences.

Not all talks will work for all conferences, so you should spend the time to get a sense of what a conference’s “feel” is.

Additionally, there may be restrictions associated with travel. Being Canadian, I’m fortunate enough that I can travel to most countries in the world without a lot of hassle, but this is not universally true.

3. 📑 Submitting a proposal.

Conferences generally have a few invited speakers, but the majority of the lineup will come from a process known as CFP — “Call for Proposals”. This is an open submissions process where anybody can submit proposals for giving a talk.

While every conference has their own submission guidelines, there are some common trends:

• A conference will accept proposals for several weeks/months, typically a few months before the conference. This gives you plenty of time to work on your talk, if it’s accepted.
• There is a “CFP season” in the spring, when a large amount of conferences open up for submissions. Don’t worry if you miss the season, though — there are conferences year-round, so there are always conferences looking for proposals.
• You’ll often need to provide a short public-facing blurb, as well as a more detailed outline that the conference organizers will use to help them decide.

Conference-Driven Development.

A widely-known secret is that most of the time, conference speakers only have a vague idea about their talk when they submit their proposals. Especially for technical talks, it’s common to submit a proposal for a rough hypothesis, and to figure out the technicalities after it’s accepted.

Perhaps most famously, Dan Abramov applied to speak at React Europe 2015 by pitching a new take on Flux that supported hot-reloading and time-traveling. This solution eventually became Redux, although he hadn’t actually gotten it working when his proposal was accepted!

There are a bunch of other examples as well:

Kent C. Dodds on Twitter

@JoshWComeau @dan_abramov In preparation for a talk I was giving about angular-formly, I made HUGE leaps and bounds in its capabilities leading up to the conference (https://t.co/l4WTlbOITi). Half of the things I talked about I had just barely published (https://t.co/gTED58Q8qW)

Vincent Riemer on Twitter

@JoshWComeau @dan_abramov While not as intense as proposing something you haven't built yet, the initial brainstorming and decision to go through with building RNDom was largely motivated with the desire to present something cool at React Conf

Jared Forsyth on Twitter

@JoshWComeau @dan_abramov just about all of my talks have some amount conference-driven development :)

Be warned, though, that this isn’t always the best idea. In addition to the added stress of having a hard deadline, you might kill your enthusiasm for the subject by overworking yourself:

Max Stoiber on Twitter

@JoshWComeau @dan_abramov Myself and @nikgraf also did that with carte-blanche at ReactEurope 2015 (?), in case that's helpful. We worked ourselves to death and then couldn't stand the project afterwards anymore... Maybe a good cautionary tale.

Breaking in.

While there is value in having experienced speakers deliver talks, nobody wants to see the exact same faces, year after year.

Happily, there are constantly new speakers giving talks. At React Rally this year, Shawn Wang gave his first-ever conference talk, and it was great.

Some tips on breaking in:

• It can be easier to book a lightning talk than a full-length talk. My first-ever talk was at React Europe last year, where I gave a 5-minute lightning talk on components that don’t return React elements.
  
  Many conferences won’t cover travel expenses for short lightning talks, though. Frustratingly, this means that this option may not be available to folks without “professional development” budgets from work, or enough disposable income to afford the plane and hotel.
• It’s often very easy to book a speaking gig at a local meetup (lots of meetups struggle to find speakers, and so there often isn’t any sort of approval process, you just email the organizers).
  
  Many CFP forms ask for recordings of previous talks; if you can get a recording of yourself speaking at a local meetup, you’ll have a huge advantage.
• Many conferences will have an initial “blind round”. This means that proposals are evaluated purely by the submission itself, and nothing is known about the proposal’s author. This is a huge boon for first-time speakers, as they don’t have to compete in terms of speaking experience.
• Don’t be afraid of asking for help! My schedule can be pretty hectic but in general I’m always up for helping review CFP proposals, especially for LGBTQ / underrepresented folks. Many speakers with more experience than me also make themselves available to help review proposals.

Don’t get discouraged.

The sad reality is that conferences receive far more submissions than they have slots for. Many conferences can only accept 5% of submissions (or less).

You will get rejection emails. I think I’ve been profoundly lucky, and I still get rejected ~75% of the time.

If you have a talk you really want to give, don’t let a string of rejections stop you from giving it. Record it yourself at home, and share it on Twitter. Let me know if you do, I’ll gladly share it out!

4. 🛠 Building your talk.

After much hard work sunk into crafting your proposal, the stars align and your talk is accepted by a conference! 🎉🎇

If you’re anything like me, you’ll experience a few moments of jubilation, before a horrifying realization settles in: shit, I need to give this talk.

Stress and imposter syndrome.

There is a gravity to conference talks. You’ll be speaking in front of a bunch of your peers, many of them far more experienced and knowledgeable than you. The talk is recorded, and will be available for anyone to watch, forever.

In all of my talks now, I’ve had moments of self-doubt. Imposter syndrome crept in, and I started questioning whether anything I was writing made sense. Maybe it’s all really obvious to everyone else. Maybe it’s all wrong.

These feelings can be helpful (after all, you should be critical of your own work, and try to find mistakes!), but often they outlive their usefulness.

Iteration and Feedback.

First drafts are always bad, in my experience. After sinking dozens of hours into getting a coherent talk together, you might realize that the whole thing stinks. It can be really discouraging.

The thing is, as with anything, iteration is key to success. Take a couple days away from it, and then come back with a fresh perspective. You may come up with solutions to fix the problems.

I changed the entire structure of my React Rally talk when I realized that the order made no sense (I was starting with the most complex bit of code, instead of working up to it). It was a lot of work, done only a few days before the conference, but the talk was so much better because of it.

Feedback is also extremely important. Find someone you trust to give you honest criticism. They’ll spot problems you hadn’t noticed, and offer encouragement for stuff you’re on the fence about. Trust their feedback more than your own.

Local meetups are also a great way to get feedback, and give your talk a “practice run”. It’s not always clear which parts of your presentation will prompt a reaction, and there’s nothing more awkward than having an audience laugh when you weren’t trying to make a joke. Get this out of the way when the audience is tiny!

For my React Europe talk earlier this year, I gave the same talk at React Montreal about a month beforehand, and then grilled everyone who came to talk to me afterwards. The feedback I heard most was that there was too much code in the middle, too much detail in side-pieces that weren’t super germane. I started inserting ✂️️ emoji in places where it wasn’t beneficial to go through the code line-by-line, and it meant I was able to fit much-needed high-level stuff in the talk.

Learning about presenting.

While I work on my talks, I take frequent breaks to watch other conference talks. Take note of the things you like in their talks, and steal them.

For example, in my React Europe talk, I decided to rearrange the slides so that the introduction card (“My name is Josh and today I’d like to talk about…”) only shows up 5 minutes into the talk, after seeing what a nice effect it had in Gary Bernhardt’s The Birth and Death of Javascript.

Some other resources I found very helpful:

• Saron Yitbarek has a great article on improving transitions in technical talks.
• Sara Vieira created a really helpful webapp for finding quality talks.
• Ben Orenstein has a must-see talk on how to talk to developers. It’s full of amazing tips.

5. 🎟 Attending the Conference.

After months of work spent building your talk, whether you’re ready or not, the conference arrives. As a speaker, your conference-going experience will be different in a few ways.

Perks.

Being a speaker comes with perks. For example, many conferences have a “speaker dinner” the night beforehand. This is a great opportunity to meet and chat with the other speakers.

Another speaker perk is that there is often a “speaker’s lounge”, a quiet side-room that only speakers can pop into.

Initially, this idea was a little unsettling to me; one of the great things about going to conferences is being able to chat with the speakers, and if they’re all off in their own space, that doesn’t work as easily! It felt like it would lead to a sort-of caste system, rather than encouraging speakers to mingle with the people paying to see them speak.

After a couple conferences, though, I realized that speakers don’t tend to spend much time in the lounges. Mostly it’s just to give speakers a quiet place to work on their talk, or catch a moment of silence and solitude. As an introvert, I very much appreciated having a quiet spot to sit on my laptop from time to time.

Finally, the organizers typically give attendees a “speaker gift”. A collection of swag and personalized items, as a token of appreciation. At React Rally this year, here’s what we got:

Busy and Stressed.

Depending on how prepared you are, you may still be trying to squeeze in some last-minute tweaks to your talk. At React Rally this year, I was still practicing my talk in the final hours, to the point that I was worried I was going to lose my voice!

There’s also a fair bit of nervous energy in the lead-up. For this reason, the good conference spots are the early ones. You want to go as early as possible, so that you can relax afterwards. Of course, you don’t typically have control over what slot you get, so this is a matter of luck 🤞🏻

6. 🗣 Delivering your talk.

Most people have a healthy fear of public speaking.

Somewhat remarkably, most people tell me that I don’t seem nervous in my talk! This is wild, because I’m very nervous. Maybe the trick is just learning how to not seem nervous?

The more improvised your talk is, the more likely it is that your nerves will get the best of you. For this reason, I don’t ever plan on live-coding in a talk. Maybe after years of practice.

On the other hand, you don’t want it to be too scripted; you want it to sound authentic, and that’s hard to do when you’re reading from a cue card. Instead I like to practice enough that I hit all the same points consistently, but the exact phrasing used varies from talk to talk.

The downside to this is that you will forget to mention things. In every talk I’ve given, I forget to say a handful of things I wanted to.

Time also passes ridiculously fast on a stage. 30 minutes can go by in an instant. Before you know it, people are clapping, and you’re done!

🎭 Is it worth it?

Conference talks are a tremendous amount of work. For my React Europe 2018 talk, I estimate that I spent over 150 hours on the talk; it consumed my mornings and weekends for a couple months.

Assuming you make the median US software engineering salary of $104,000 a year, and put 150 hours of work into the talk, you’ve spent $7500 worth of your time getting it ready.

In addition, preparing a talk is a bumpy ride. There’s a bunch of stress along the way, a bunch of nights and weekends where you really don’t feel like working on it but do anyway, moments of crisis where you think your talk won’t work or isn’t interesting.

For all of that, conference talks tend to reach a surprisingly small audience. It wouldn’t surprise me if this blog post is read more than my recent conference talk was seen!

Sunil Pai on Twitter

I can spend weeks, sometimes months on prepping a conf talk, and it's usually seen live by 200-800 people. the youtube recording gets about 500-2000 views after about a year. a snarky tweet reaches more people in a week. something's wrong here, and it's aching to be disrupted.

So on its face, the math doesn’t look favourable. Why spend so much time and energy on a conference presentation?

In my opinion, there are a few things that balance the scales:

• While relatively few people will see a conference talk, it can be a very impactful way to deliver a message. A well-crafted talk can inspire and motivate someone far more effectively than a tweet or blog post!
  
  For example, CodeSandbox was created by Ives Van Hoorne after attending React Europe, and he credits the conference with making him determined to build it!
• You get to hang out with the other speakers. In many cases, these are the authors of the tools you use every day, or people whose work has inspired you for years.
• It’s a tremendous way to meet like-minded people in attendance. After a conference talk, expect tons of folks to come up and ask pertinent follow-ups, or share some of the interesting things they’ve been doing.
• Speaking at a conference makes people think that you’re a Real Expert™. It lends credibility to what you’re saying, for better or worse.
• It’s an experience. It’s a memory that you’ll have for the rest of your life, a youtube video you’ll be able to watch many years down the line. It’s a heck of a thing!

Onwards!

This has been a wildly educational year for me.

The biggest thing I’ve learned is that I should restrict how many conference talks I commit to writing. I have a finite amount of free time, and spending so much of it on conference talks means I’ve been neglecting other projects.

I think in the future, I’m going to create a single conference talk per year, and submit it to multiple conferences, instead of doing original work for each one. While not all conferences will accept “repeat” talks, there are enough that do that it seems like a reasonable strategy to me.

As your reputation as a speaker increases, new doors start opening. For example, I’m delighted to announce that I’ll be speaking at React Europe 2019! Evidently the organizers liked the talk I gave last year enough to invite me back this year, without submitting a CFP proposal. I’m thankful I have 9 months to prepare, as I have an idea that I think would be really cool, but would involve a whole lot of stuff I don’t (yet) know anything about.

I’ll also be doing a 1-day workshop there, on ✨ whimsical animations ✨. So that should be fun!

A realization I had a few weeks ago is that I’m still very much at the beginning of my career. I’m only ~5 years into what will likely be a 40-year career, so I’m only about 1/8th through! That thought is simultaneously liberating and dizzying; it means I don’t have to feel rushed when it comes to making the most of every available opportunity, but it also means I have no clue what’s ahead.

Conference-speaking is a worthwhile endeavour, but it’s one heck of a bumpy ride, and not always worth it. I’ll continue to prepare talks (as long as folks still want to hear what I have to say), but far fewer.

If you’ve made it all the way to the end here, you must be really interested in conference-speaking! I encourage you to give it a shot. Feel free to reach out to me, I’m always happy to give your proposal a quick read :)

A few months back, I created Waveforms, an explorable explanation that dug into the peculiar magic of sound waves. I got a bunch of feedback afterwards from audio folks who said that they finally understood how sound works, that my interactive thingy helped them bridge the gap between theoretical knowledge and intuitive understanding.

I started wishing I could build content like that in the same way that I wrote posts on Medium. I really like Medium as a publishing platform, but it’s primarily a traditional, text-based blogging engine (sure, you can embed gists and CodeSandbox and things, but it’s hard to make an integrated, seamless, dynamic experience with those tools).

If my blog was essentially a React application, I could build and embed my own interactive widgets. Over time, I’d develop a rich library of these embeddable components, and (hopefully) have the tools needed to create rich, explorable-explanation-style blog posts at the speed of static content.

A few weeks of side-hacking later, and that blog exists now! 🎉 🎆 🎊

The first post is called Dynamic Bézier Curves, and it’s a deep dive into building SVG curves that respond to user input in React.js. Here are some of the nifty interactive bits:

These GIFs aren’t doing it justice, though; you should really go play with it for yourself!

My Future on Medium

While I now have my own custom blogging engine, I won’t be shutting down my Medium account anytime soon!

I’ll likely still want to write mostly-words blog posts, not everything needs interactive elements. For those posts, I’ll cross-post in both places, so you can continue to read on the platform you prefer. Look for a blog post about the virtues of Redux beyond prop-drilling in the near future!

For future explorable-explanation-type posts, I’ll likely throw a quick note on here to let you all know about the new post (like I’m doing here!).

As always, let me know what you think about this decision, as well as the new blog content I’ll be producing!

A Case Study.

In recent weeks, I’ve been working on Tello, a web app to track and manage television shows:

As web apps go, it’s relatively small — about 10,000 lines of code. It’s a React/Redux app, bundled by Webpack, served by a thin Node backend (using Express and MongoDB). 90% of the code is on the front-end.
Source code is available on Github.

There are a lot of aspects to web performance. Historically, I’ve focused more on the post-load front-end side of things: stuff like making sure scrolling is jank-free, and animations are smooth.

In contrast, I don’t often pay much attention to page-load time, at least not on small pet-projects. After all, there isn’t that much code being shipped; it has to be pretty fast out-of-the-box, right?

After doing an initial benchmark, however, I was surprised to see that my 10k-LOC pet project was slowwww: on a 3G connection, it took around 5 seconds for anything meaningful to show up, and more than 15 seconds for all network requests to resolve.

I realized that I needed to invest some time and energy on this problem. It doesn’t matter how beautiful my animations are if folks bail after staring at a blank white screen for 5 seconds!

All in all, I experimented with half a dozen techniques, over the course of a weekend. The end result is that the page shows meaningful content after ~2300ms — A reduction of over 50%!

This blog post is a case-study in the specific techniques I tried, and how well they worked. More broadly, though, it’s about what I learned along the way about diagnosing problems, and what my thought process was for coming up with solutions.

Methodology

All profiling done uses the same settings:

• “Fast 3G” throttled network speed.
• Desktop resolution.
• Disabled HTTP cache.
• Logged-in, to an account with 16 tracked TV shows.

Baseline

We need a baseline that we can compare results against!

The page we’ll be testing is the main logged-in Summary view. it’s the most data-heavy page, and so it offers the most room for optimization.

The Summary view contains a set of cards, like this:

Here’s our baseline profile, on 3G speed. It’s… not great.

First Meaningful Paint: ~5000ms
First image loaded: ~6500ms
All requests finished: >15,000ms

Oof. The page doesn’t display anything useful until ~5 seconds in. The first image only finishes loading around 6.5 seconds, and it takes well over 15 seconds for all network requests to complete.

This timeline view offers a bunch of insights. Let’s walk through it and examine what it’s doing:

1. The initial HTML page is fetched. This is nice and quick, because the app is not server-rendered.
2. The monolithic JS bundle has to be downloaded. This takes forever. 🚩
3. React traverses the component tree, computes the initial mount state, and pushes it to the DOM. It’s a header, a footer, and a lot of black space. 🚩
4. After mount, the application realizes that it needs some data, so it makes a GET request to /me, an API endpoint that returns the user’s data, as well as an array of shows they care about, and which episodes they’ve seen.
5. Once we have that crucial list of shows, the application can fetch:
   - an image for each show,
   - an array of episodes for each show*.
   
   This data comes from the wonderful TV Maze API.

* You may be wondering why I don’t just store episode info in my database, so I can skip all those calls to TV Maze. Ultimately, TV Maze is the source of truth; it has all the info about new episodes. I could make these requests on the server during Step 4, but that would greatly increase the amount of time that step takes, while a user stares into a sea of empty black space. Plus, I like having a lean server layer.

One potential workaround could be to set up a cron job that does daily syncs with TV Maze, and only request episodes directly if I don’t already have recent data. I kinda like that the data is realtime, though… this avenue will be left unexplored, at least for now.

The Obvious Improvement

The biggest bottleneck right now is that initial JS bundle’s size; it takes too long to download!

The bundle size is 526kb, and it’s not currently being compressed at all. Gzipping to the rescue!

With a Node/Express backend, this is easy; we just need to install the compression module, and use it as an Express middleware.

With that incredibly simple fix, let’s see what effect it has on our timeline:

First meaningful paint: 5000ms -> 3100ms
First image loaded: 6500ms -> 4600ms
All data loaded: 6500ms -> 4750ms
All images loaded: ~15,000ms -> ~13,000ms

The bundle went from 526kb over-the-wire to just 156kb, and it make a huge difference on page-load speed.

Caching with LocalStorage

With the obvious first step taken, I looked at the timeline. The first paint is at 2400ms, but it isn’t meaningful. It gets better at 3100ms, but all that episode data isn’t received until almost 5000ms.

I started thinking about server-rendering, but that wouldn’t actually fix the problem; the server would still have to make a call to the DB, and then a call to the TV Maze API. Worse, the user would be staring at a white screen while the server did its work.

Why not use local-storage? We can persist all state changes to the browser, and rehydrate from that state when the user returns. The data will be stale, but that’s OK! The real data won’t be far behind, and this will make the initial load feel so much faster.

Because this app uses Redux, persisting/hydrating state is pretty straightforward. First, I needed a way to update localStorage whenever the Redux state changed:

Next, we need to subscribe our Redux store to this method, as well as initialize it with any data from previous sessions:

There were a few kinks to work out, but for the most part, this was a really simple change, thanks to how Redux is architected.

Let’s take a gander at the new timeline:

Cool! It’s hard to tell from how small the captured screenshots are, but our very first paint is meaningful now; it contains a full list of the shows and episodes from our previous session: at 2600ms

First meaningful paint: 3100ms -> 2600ms
Episode data available: 4750ms -> 2600ms (!)

While this hasn’t actually affected the loading time (we still do make those API requests and they still take a while), the user has data immediately, and so the perceived speed improvement is very noticeable.

Gone is the staggered, things-keep-changing second where content appears as it’s available. While this is often a popular technique for getting stuff on the page sooner, it can be overwhelming when the page keeps updating as new content is available. I much prefer being able to render the “final” UI immediately.

As an extra bonus, this winds up being pretty useful in non-perf ways too. For example, users have the ability to change the sorting of shows, but before this change, that preference would be forgotten when the session ends. Now, that preference is restored when they come back!

There is a downside to this, though: it’s no longer clear whether you’re still waiting for new data or not. I plan to add a spinner in the corner that shows whether additional requests are still being waited on or not.

Also, you may be thinking “This is great for returning users, but does nothing for new users!”. You’re right, but actually, this isn’t applicable for new users. New users have no tracked shows, and so their page load is super quick; just a call-to-action to start adding shows. So we’ve effectively killed the experience of “staring at a black screen forever” for all users, new and returning.

Images and Lazy Loading

Even with this latest improvement, images are still taking forever to load; this timeline doesn’t show it, but it still takes 12+ seconds for all images to be loaded, with 3G speeds.

The reason for this is simple: TV Maze returns large movie-poster-style photos, whereas I only need a narrow strip, used to help tell shows apart at-a-glance.

To solve this problem, my initial thought was to use something like ImageMagick, a wonderful CLI tool I used while making ColourMatch.

When the user adds a new show, the server would request a copy of the image, use ImageMagick to crop out the middle of the image, send it over to S3, and use the S3 URL on the client, rather than using the TV Maze image link.

Rather than deal with this myself, though, I decided to outsource this concern to Imgix. Imgix is a service that sits in front of S3 (or other cloud storage providers) and allows you to dynamically create cropped, resized images. You just use a URL like this, and it creates and serves an appropriate image:

https://tello.imgix.net/some_file?w=395&h=96&crop=faces

A nice bonus is being able to crop based on interesting areas of the photos. You’ll notice in the left/right comparison photo above that it crops the 4 kids on the bikes, instead of just cropping the exact center of the image.

For Imgix to work, the image has to be available via S3 or similar. Here’s a snippet from my back-end code, which uploads an image when a new show is added:

By running every new show through this promise, we get images that are ready to be dynamically cropped.

On the client, I use image properties srcset and sizes make sure that images are being served based on the window size and display pixel ratio:

This helps ensure that mobile clients get the larger version of the image (since those cards wind up taking up the whole viewport’s width), whereas desktop clients get a slightly smaller version.

Lazy Loading

Each image is now way smaller, but we’re still loading an entire page worth of shows at once! On my large desktop window, only 6 shows are visible at once, but we fetch all 16 images at once, on page-load.

Happily, the awesome package react-lazyload offers really simple lazy loading. The code is as simple as:

Alright, it’s been a while since we looked at a timeline.

Our first-meaningful-paint numbers haven’t changed, but image download times are way better:

First image: 4600ms -> 3900ms
All visible images: ~9000ms -> 4100ms

Eagle-eyed readers might have noticed that this timeline only downloads episode data for 6 episodes, instead of all 16. This is because my initial attempt (and the only one I remembered to capture) lazy-loaded the episode card, not just the show’s image.

Ultimately this introduced more problems than I was able to solve in this weekend-long-perf-tune, and so I simplified it. The impact on above-the-fold image load-times is unchanged, though.

Codesplitting

We’re definitely getting to a pretty good place, perf-wise.

One obvious issue is that we only have a single bundle. Let’s use codesplitting to reduce the amount of on-request code needed!

Because I’m using React Router 4, it’s a simple matter of following the docs to create a <Bundle /> component. I played around with a few different configurations, but ultimately, there wasn’t a lot of splitting that made sense.

In the end, I split out the mobile views from the desktop ones. The mobile version has its own views, which use a swiping library, custom assets, and a few extra components. This bundle wound up being surprisingly small — about 30kb before compression — but it nevertheless had a noticeable impact:

First meaningful paint: 2600ms -> 2300ms
First image loaded: 3900ms -> 3700ms

Lesson learned: codesplitting’s effectiveness is hugely dependent on the given application. In this case, the biggest dependencies — React and its ecosystem packages — are used across the site, and don’t need to be split off.

The components themselves could be split off at the route level for marginal gains in initial page load, but then you introduce additional latency on every route change; dealing with spinners everywhere isn’t fun.

Other Approaches Tried or Considered

Serverside Rendering

I did toy with the idea of rendering a “shell” — a placeholder with the right layout, but without data — on the server.

The issue I foresaw was that the client already has access to the previous session’s data, through localStorage, and it initializes with that data. The server isn’t privy to that, and so I’d wind up with the warning about markup not matching between client and server.

I figure that I might’ve been able to shave half a second off my first-meaningful-paint time with SSR, but the site wouldn’t be interactive in that time; a personal pet-peeve of mine is when a site looks ready, but isn’t.

Plus, SSR introduces a lot of complexity, and can slow down development time. Performance is important, but “good enough” is good enough.

Something I’m interested in exploring, but haven’t found the time, is compile-time SSR. This would only work for static pages like the logged-out homepage, but I can imagine it being hugely effective. As part of my build process, I’d create and persist the index.html. This would get served to the users by the Node server as the plain HTML file that it is. The client would still download and run React, so the page would become interactive, but there would be zero server-side build time, since we’ve paid that cost before the code was even deployed.

CDN Dependencies

An idea I thought had a lot of potential was to serve React and ReactDOM from a CDN.

Webpack makes this easy; you can specify an externals key to have it not bundle the given dependency.

// webpack.config.prod.js
{
  externals: {
    react: 'React',
    'react-dom': 'ReactDOM',
  },
}

It seemed as though there were two strong benefits to this approach:

• Serving a popular library from a CDN means it’s likely to already be cached for the user
• Dependencies could be parallelized, downloading in tandem with the app bundle, instead of being a single large file.

I was surprised to see, at least in the worst case where the CDN hasn’t cached it, that moving React to a CDN was harmful:

First meaningful paint: 2300ms -> 2650ms

You’ll notice that React and React DOM are downloaded in parallel to my main desktop bundle, and yet… it actually slows down the total time.

I don’t want to imply that using CDNs like this are never a good idea. I’m not an expert in this stuff and it’s entirely possible that this is something I’m doing wrong, not a flaw with the idea! At least in my case, though, it didn’t pan out.

Conclusion

There are two main ideas I hope this post communicates:

1. Small side-project apps are pretty fast out-of-the-box, but a weekend of experimentation can yield huge speed improvements. The Chrome developer tools make it really easy to poke around and see where the bottlenecks are, and it may surprise you how much low-hanging fruit there is. Servicers like Imgix allow you to defer hard problems to other people, often for free or for very low cost.
2. Every application is different. This post details specific tricks for Tello, which has a very unique set of concerns. Even if these tips aren’t directly applicable in your app, I hope I’ve showcased how performance is a creative part of web development.
   
   For example, the conventional wisdom is that server-side rendering is the way to go. In many applications it is, but maybe a client-side solution using local-storage and/or service-workers would be better! Maybe you can pay some of the cost of SSR during compile-time, or maybe you can do what Netflix does for some pages, and skip shipping React to the client entirely!
   
   Performance is actually really fun when you realize how much creativity and outside-the-box thinking is involved.

Thanks for reading! I hope this was helpful :) Lemme know what you think on Twitter.

View Tello’s source on Github.🌟

Performance-tuning a React application. was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

While they’re all pretty similar from one another, they do vary in a few ways:

• Shape (rectangle, pentagon)
• Color
• Size
• Walk speed

I wanted the ability to control these props when needed, but also to have randomized values used by default, so that I could easily generate a crowd like this without worrying about having to come up with values for them.

In my mind, my ideal setup was something like this:

This didn’t work, because defaultProps doesn’t work like that: the expression is evaluated once, when the component is first seen, and the same randomized value is used for every instance of the component. In other words, I’d get a single randomized set of values, and 10 identical People with those values.

My next idea was to move the logic to the constructor function. When rendering a new Person, props would be copied to state, and blank values would be randomized:

I’m simply appending properties to the instance here because, in my application, I know these values are static; they never change once the component is created, so I don’t have to worry about updating them on re-render. If I did, I’d have to store these values in this.state, and then handle updates with componentWillReceiveProps.

This works! I have a beautifully diverse group of People pacing around.
But, I’m not super happy with it.

It feels like there are two discrete chunks of logic here:

1. The data-munging and randomization to manage the props,
2. Actually rendering the little person, and animating them around

I like when React components only have a single responsibility. This bugger’s doing too many things!

The simplest solution involves just creating a thin wrapper, called RandomPerson:

Thin Wrappers wooo!

Thin wrappers are such a nice pattern. They allow you to “cut the fat” out of your presentational components, so that they can focus on their core concern, without a bunch of important-but-unrelated business getting in the way.

I used this pattern in React Flip Move, an NPM package that handles animating list shuffles automatically. The FlipMove component was already complex enough without all the data-munging needed for its props, so I extracted a PropConverter HOC that tackled all of this for me, so that working on FlipMove itself would be simpler.

You can also use thin wrappers to keep “leaf” components generic, and abstract specific concerns into a reusable “shell”. For example, I may have a <Button> component as the lowest-level primitive… but there might also be a <RoundButton> that provides a few of the Button props but allows the user to substitute most of them… and then maybe a <RoundGoogleButton> component that’s even more specific/concrete.

Also, Purity

Another nice side benefit of this pattern is that our Person component is now pure.

By pure, I mean in functional-programming terms: “given the same set of inputs, a function should produce the same output”.

In our original working example, calling a <Person> wasn’t deterministic: by design, each one would be a little different. Now that we’ve updated it, though, we know that each <Person> with the same props will produce an identical HTML element.

Bonus: More Explicit?

In general, I’m quite happy with the solution above.

If there’s one area I find it lacking, though, it’s a lack of data transparency.

To understand what I mean, let’s look at how you use this RandomPerson component:

What props is Person receiving? We have no idea!

It would be nice if we had a window into what RandomPerson was actually doing, so that we’d have a clearer sense of how our Person component works. Plus, if we ever want to pass in our own props to override the random values, we’d have to go digging through other files to figure out what they are.

Thankfully, there are several ways around this! My personal favourite is function-as-children, a variant of the Render Prop pattern.

The big change is that now we’re expecting a children function, and we’re invoking that function with all of our values.

Here’s how we use our new component:

Is that actually better?

You may have noticed that the render-prop solution is much more verbose; you have to manually specify each prop going through. Plus, function-as-children is a contentious pattern; I love it, but many disagree.

My opinion is that the transparency is a fair price to pay for the additional code, but this is indeed a trade-off, and your priorities might be different.

In Conclusion (TL:DR;)

By moving the randomness out of the Person component and into a thin wrapper, we keep our Person component pure. We also reduce the number of things it has to worry about, so that our Person only has a single responsibility.

By using function-as-children, we make it clear how data flows from the randomization process to the Person component, and the hierarchy is visible at a higher level. Your mileage may vary, though, when deciding if that added transparency is worth the cost.

Thanks for reading! Let me know what you think on Twitter.

Maybe you’re a jQuery developer looking to experiment with a modern framework. Or, maybe you’re an Angular developer wanting to see what all the hype is about. Maybe you’re a seasoned back-end or systems programmer looking to make the jump to front-end. Maybe you’re new to programming in general, but want to learn how to build dynamic web applications.

Regardless of your background, you’ve likely had a similar experience: React itself seems pretty straightforward, but the tooling and ecosystem is overwhelming.

You probably feel like this guy:

I’ve seen and heard variations on this theme frequently. Especially for newcomers, React development can often seem like a complex maze of tools and libraries. Even experienced developers talk about how complicated modern web dev is, and pine for the simple days of just opening an editor and writing.

However, this is a solved problem!

Over the past few years, the React community has put a ton of effort into creating a tool that allows React developers to get up and running almost as quickly as downloading a dependency and opening an editor.

The goal of this guide is to help create your first React app. It shares a step-by-step process, from initial system setup through to deployment, without straying into tangent explanations that aren’t critical at this point in the learning process.

No prior experience with React or its related tools is required, although it does assume that you know the basics of working with a command line and git.

This is a living document, and I’ll be updating it as the landscape changes.

Last Updated: December 9th, 2019

The Quickest Start: CodeSandbox

CodeSandbox is an online REPL. It’s friggin’ amazing.

It lets you instantly bootstrap a React project with everything you need. It runs in the browser, but it supports multiple files, third-party dependencies… It uses VS Code as its editor, which is wild. It’s essentially a full development environment that runs in-browser, and I can recommend it without reservation. You can build a full application using CodeSandbox.

There is something to be said for having everything run on your local machine, so we’ll cover that as well. But if you’re looking for a rocketship-speed start, head over to CodeSandbox, and jump straight to Step 3.

Step 1: Install Yarn

Yarn is a package manager. It helps us manage our project’s dependencies.

If you’re new to programming, essentially you can think of this as a tool to help us easily download and use other people’s code.

Download and installation instructions are available on the Yarn site.

Once you’ve installed yarn, verify that you can use it on the command line. Open a new terminal, and run:

But what about NPM?
You may have seen that NPM is the de facto package manager in the Javascript community, and may wonder why I’m suggesting Yarn.

Without getting too far off-topic, Yarn is a concerted effort by the community to improve package management. Internally it still uses the NPM package repository, so you can still install all the same packages.

Over the past couple of years, the default NPM client has improved. If you’re already comfortable with NPM, you can use it instead. Alternative NPM instructions will be provided as we go along.

Step 2: Create a React application

When people talk about complexity in React development, often they’re referring not to React itself, but in the build system and development environment.

They have a point — as React developers, we tend to build pretty complex dev environments and build systems. We suffer this complexity because it makes React development quicker and more enjoyable.

However, that complexity is overwhelming for those just getting started, and worse, it gets in the way of learning what’s really important: React itself.

Thankfully, there is a have-your-cake-and-eat-it-too solution. It’s called create-react-app.

create-react-app is a command-line tool, owned by Facebook and maintained by talented developers both at Facebook and in the community. It’s amazing. It abstracts away all the complexity and difficulty of implementing Webpack, Babel, a dev server, a production build process, and a thousand other tedious-but-critical things.

It’s zero-configuration by default, and doesn’t clutter up your project directory with a bunch of files you don’t understand.

Note: Eventually, you will want to spend the time learning how this works internally. There’s a lot of neat stuff you can do with Webpack, for example. Our top priority at the moment, though, is getting you excited about building with React, so we can defer this stuff for later.

Yarn comes with a built-in helper for using create-react-app:

yarn create react-app [your-app-name]

I’d like my application to be named cats-n-stuff, so I’ll run that:

If you get an error starting with “A template was not provided”, it’s likely because you have an earlier incompatible version of create-react-app installed. Check out this StackOverflow answer.

If you’re using NPM instead of yarn, you can run “npx create-react-app cats-n-stuff” to achieve the same result.

This command does quite a few things:

• Downloads and installs create-react-app
• Creates a new project folder, cats-n-stuff (or whatever you name your app)
• Scaffolds out a new project, including everything you need to compile a production-ready app, as well as run a development server
• Installs dependencies

You’ll notice the output towards the end gives you a set of commands.
Let’s start by following its instructions:

We should see the following output:

A browser window should also have opened, showing the following:

Let’s open our new project in our code editor. I’m using VS Code. You should see the following files:

Let’s go through them:

node_modules

This directory holds all of our project dependencies, like react and react-dom. It also includes all the dependencies needed to run our build system and development server. Sometimes, folks are alarmed by the size of this directory (~200mb), but it’s important to remember that it includes a whole bunch of dev tooling. Very little code is actually shipped to the user.

public

This directory holds static assets, stuff like our favicon and search-engine preferences. It also houses our project’s only HTML file. Because React is all-javascript, you only really need the HTML file to update the <head> stuff, like title and meta tags. This can always be modified with React as well, but for now it can be simplest to add your own <title> to this file.

src

This directory holds the source code we’ll write to build our application. By default, create-react-app comes with one component — App — and an index.js file that mounts it. It also includes some CSS files — it’s conventional in the React community to colocate styles and code, so that each component has its own stylesheet.

For now, you can ignore the final two files, serviceWorker.js and setupTests.js. We don’t need to fuss with them yet.

Root directory

Finally, the root directory of the project holds stuff related to dependencies (package.json and yarn.lock), as well as a comprehensive documentation (README.md) for create-react-app.

Is this only for beginners? Will I be handicapping myself down the line?
create-react-app abstracts away all configuration, to help you focus on writing the application itself. At some point, though, you may want to access that configuration.

Thankfully, create-react-app has an eject feature that removes this abstraction and exposes the underlying configuration. This means that create-react-app is a brilliant tool not just for newcomers, but also for experienced React devs.

A few years back, it was common to spend the first day on a new project getting the build system and development server set up. Now that you know this process, it should only take a few minutes! And, unlike the days of installing jQuery and firing up an editor, we have a bunch of fantastic tooling that makes our life easier:

• A development server will auto-refresh / hot-reload when we save our files
• We can use modern JS features without worrying about browser compatibility, since babel will translate your code into an older version of JS that all major browsers can understand
• You can import all kinds of files into your JS code, including CSS and images.
• Your editor will warn you when you’re making mistakes, including things that may not be so obvious (like accessibility concerns)

Step 3: Write your application

Alright, our project is ready to roll. Now we have to build our app.

I have a single piece of advice that I often find myself giving, when people are getting started: learn React on its own first.

If you follow many of the tutorials intended for intermediate or advanced users, you may think you need to learn about and install a dozen “supplementary” packages. After all, React is just the view layer, right?

Wrong. Facebook used to say that React was the “V” in “MVC”. They stopped using that language, because it isn’t true; React is an entirely different paradigm, not simply a template renderer. The truth is that React is surprisingly capable on its own.

For example, you don’t need to install Redux or any other state management library at first. I really like Redux, but it will be overwhelming if you try and learn them together, and React comes with a built-in solution for state management: React state.

I believe the best way to learn is to make several small “weekend project” applications. Try and make a game, or validate a form, or build a mini component library. These kinds of projects don’t require any additional dependencies.

Once you’ve built a couple test projects, you probably will want to add React Router. Because React doesn’t come with a built-in router, it does feel pretty critical. Building your own router can be a fun educational project, but I’m also pragmatic enough to realize that sometimes you just want to build a project, and using React Router will unblock you.

You may discover, after your second or third small React project, that certain things are more painful than you’d like. Maybe your homegrown router is proving to be too much trouble, or maybe you feel like your application’s state is hard to manage. This is when you should be searching for pre-existing solutions; after you’ve encountered the problem, not before.

Spend time learning React on its own. Add dependencies as you need them. Try to solve problems yourself; if nothing else, you’ll understand the benefits provided by those dependencies.

Resources for learning React

After spending some time googling for React tutorials, I’ve realized exactly why newcomers find React so confusing.

It’s actually pretty tough to find reliable, up-to-date tutorials that cover React on its own, without delving into webpack and redux and a million other things.

Here are the resources I’ve found that do the job:

1. Official React Tutorial — Straight from the official team. Build a Tic Tac Toe game.
2. The Road to Learning React — A pay-what-you-want ebook that builds a fully-functional HackerNews clone, using create-react-app and minimal third-party libraries. Fantastic resource.
3. Pure React — A great React book by Dave Ceddia
4. Getting Started with React — A wonderful blog post by Tania Rascia

Hooks?

2019 was a big year for React, and one of the biggest changes was the stable release of “hooks” in February. Hooks are a modern React feature that let you access React features like state and refs and lifecycle methods from within functional components.

A common question I see is whether or not you should learn hooks or class components. My personal belief is that hooks are the future, and I’ve heard that it can be simpler and faster to start with hooks. But ultimately, both are important, and it doesn’t really matter which order you learn them in.

Step 4: Deploy

Alright, you’ve built an awesome little toy app. Now you want to show your creation to the world. How do we get this thing online?

Web development is fun, and it’s even better when you wind up with something neat to show off. There’s an incredible amount of satisfaction achieved by showing the world your random side projects.

The first thing we’ll need to do is build our project.

What does this do?
`build` is an NPM script provided by create-react-app. It bundles up your code into ready-to-deploy static files. After running it, you’ll notice a new build directory in your project, including all the compiled JS and HTML needed to run your project.

Builds also use the production version of React, which means it runs faster and doesn’t include the development-mode helpers like error screens.

Deployment services

As with everything else in modern web development, there are a bunch of options for how to actually get your built files onto the internet.

Create-react-app’s documentation covers several possible deployment options, and in my experience, Surge.sh is the quickest, simplest way to get code online quickly.

Let’s install it with Yarn:

We install it globally so that we can use its CLI tool. Let’s run it now:

surge

The first time you run surge, it will prompt you to create an account. Enter your email and come up with a new password.

After that, it’ll ask you for a project path. This is important: it should auto-fill the current location, but we need to add /build to the path, since that’s where the static, compiled files are.

Finally, you can pick a domain. It’ll suggest one at random, or you can try your own.

Remarkably, this is all we have to do. Surge will ship our files to the domain indicated. Check it out:

Simplifying repeat deploys

If we wanted to, we could just repeat this process every time; build, run surge, and then specify a project path and domain name.

We can use NPM scripts to be a little fancy though. Open up your package.json, and find the section for “scripts”. You should find the ones we’ve used already, like “start” and “build”. Let’s add a new one:

"deploy": "yarn run build && surge -p build -d your-domain.surge.sh"

Terminal commands can be stringed together with &&, and so we can create a single NPM script to do all the stuff we need. We build a fresh copy of our project, and then deploy it with Surge, pre-filling some of the required fields.

This command starts by building the latest version of our project, and then invoking Surge with some default arguments. Here’s my “scripts” object in package.json, with the new deploy script:

Now, all we have to do is run a single command, and in under 20 seconds, our glorious project is up for anyone to see.

Other deployment options

Surge is the quickest way I’ve found to get a project online, but there are plenty of options. I really like Netlify — it takes a slight bit more work to get an initial deploy going, but it gives you a ton of stuff in return, including a free SSL certificate and automatic deploys when you push your code to GitHub.

Frameworks like Gatsby and Next

Disclaimer: I work for Gatsby!

React applications have gotten a reputation for being bloated and performing poorly. I don’t think this is quite fair — React does a lot out of the box to make sure its performance is good! — but there is one bit of undeniable truth: by default, React applications do all of their work on the client.

This means that when you load a React application, the initial HTML document is blank, and React has to load all of the JS it needs before the user can see anything.

A common way around this problem is called server-side rendering (SSR). The idea with SSR is that the HTML file can be built before being delivered to the user. Javascript will still run in the browser (otherwise, it wouldn’t be an interactive application), but the idea is that the user shouldn’t have to stare at a white screen while that happens.

create-react-app is a great choice for getting started, but it’s really pretty minimal; it gives you the dev tooling you need to get started fast, and stays out of your way. Over the past few years, frameworks have popped up that offer a bunch of additional features, while still being built on top of React.

Gatsby

Gatsby is sometimes billed as a “static site generator” — It can be used similarly to Hugo or Jekyll. It’s quite a bit more powerful than that, though!

Gatsby builds all of your HTML files at “compile time”, when you build your site, instead of at “runtime” when the user wants to use it. It’s super quick, since unlike server-side rendering, all of the work is done before the user even makes the request!

In addition to this performance focus, we’re doing a lot of really cool stuff at Gatsby, but it’s beyond the scope of this article.

Next

Next is built on a powerful idea: routing should be mirrored in the filesystem, the way it was with PHP. You can create individual components to handle each route, so a file at pages/about/the-team can be reached at your-domain.com/about/the-team.

In addition to this clever routing scheme, Next comes with built-in server-side rendering and automatic code-splitting, two powerful features that keep bundle sizes small and responses quick.

Both Gatsby and Next are great options when looking to build a “real life” project. If you’re just starting out, it probably makes sense to stick with create-react-app until you’re comfortable with React fundamentals.

Conclusion

There are two misconceptions that newcomers often have about React:

• It takes forever to set up a decent build system and dev environment. You can’t start writing your actual application code until you spend hours getting that set up.
• React is a small piece of the toolset needed to create basic web applications, and you have to learn a dozen other things before you can get started.

I hope I’ve done a good job disproving these theories. You can get started in seconds building a glorious front-end web application, and you can start without any extra dependencies.

Addendum: Community Resources

By far the most popular community hub for React developers is Reactiflux. It’s a great place to meet React developers, and get help if you find yourself stuck or confused.

For myself personally, Twitter has been an amazing source to learn more about React and meet the community. Dan Abramov, a member of the React core team and co-creator of Redux, has a great list of people to follow.

Thanks for reading!

I’m keen to hear your feedback on this article! Anything I could do to make it more beginner-friendly? Let me know on twitter.

Simple React Development in 2020 was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past few months, I’ve had great fun experimenting with this idea. I’ve found that higher-order components that handle event-listening are incredibly useful. I’ve even found it remarkably straightforward (although of questionable utility) to create a set of components that mimic the SVG spec, but render to Canvas.

Today, though, I’d like to share a mildly ridiculous idea I’ve had.

EDIT: It’s a real thing now! 🎉

Filtering props

If you’ve worked with React for a while, you’ve undoubtedly ran into this situation.

You have an array of items in props, and you want to render a list of elements. Some of the items passed in, though, aren’t needed. For example, you have a list of todos, but the visibility filter is set to hide completed ones.

Here’s how one might approach the problem:

Essentially, we’re doing the filter within the component, in 1 of 2 places:

• Filter inline. Even if you’re not a separation-of-concerns curmudgeon, you have to admit that it’s a little “busy” to have all that logic in JSX
• Filter ahead of time. This, to me, is clearer, but in a less trivial component, it can move your filtering logic far from your rendering logic. It also spoils the simplicity of a component that immediately returns JSX.

I started thinking about whether there was a way to have my cake and eat it too. Could we keep the filtering logic in the JSX, without it feeling so logic-heavy?

I made a <Filter> component that attempts to do it:

So, that’s a thing.

We pass our <Filter>component the items it needs to filter, and a predicate function that will accept each item as an argument.

Instead of taking an array of children, we take a function instead, which will build that array by applying the function to each filtered item.

Let’s see what the implementation for this <Filter> component is:

I’m guessing that’s simpler than you were expecting!

We wrap our output in a <div> because components can’t return arrays of elements. This is a downside to this technique, but it’s temporary.

Also: we could modify this component to accept an element prop that would allow you to specify a DOM element type or custom component wrapper, but I wanted to keep it simple.

Another potential side benefit: We could hide more performant methods within this abstraction.

Conclusions

Is this all a terrible idea? Quite possibly. I think it’s worth exploring though!

In these contrived examples, the benefits aren’t that clear. But, imagine having a suite of composable array methods as components:

Now this is intuitive UI code, and the idea is super intriguing to me. That said, I’m still not totally sold; performance may be an issue, and really it’s common to do a lot of this work elsewhere (eg. in memoized selectors).

What do you think? I wrote this blog post to get feedback from other React developers. Do you see any merit to this idea? Or, should it be taken behind the barn and shot? Let me know on twitter.

Thanks for reading!

I set up a basic example on JSBin for anyone who wants to tinker around with this idea :)

Every month, Unsplash holds a Makeday dedicated to building cool things, where we encourage everyone in our community to participate. Internally, Makedays are awesome opportunities to work on passion projects; anything that’s interesting and beneficial for Unsplashers, but non-critical.

Since I joined Unsplash a couple months ago, I’ve wanted to do something to expose the crazy amount of traffic that we receive. After some internal discussion, I paired up with Rails guru Aaron Klaassen to build a map that would highlight real-time Unsplash events across the world.

As one might expect, we r̶a̶n̶ ̶i̶n̶t̶o leapt over a number of hurdles, but overall I’m super pleased with the end result :)

Our map handles 4 different types of events: downloads, likes, add-to-collections, and submissions.

Watch them unfold in real-time, across the world.

Caveats

As is often the case, we had to make some concessions due to the time-restricted nature of a Makeday.

Data

The first hurdle we encountered was data. Ideally we’d like to show the origin source of the events — when Jane Smith in Australia likes a photo taken by John Smith in Portugal, we should show the little heart icon in Australia. Sadly, though, we don’t have reliable data for where Jane Smith is, and so all of our location data is based on the photo’s EXIF data.

It’s interesting to note that only ~50% of all Unsplash photos have usable location EXIF data. That means that our actual activity is twice as busy as the one visualized!

Event Types

We also wanted to include viewed photo events, but there’s too many of them. Every minute, more than 20,000 photos are viewed (that’s over 3 views every millisecond!). Our infrastructure wouldn’t have been able to support streaming that many events without some tinkering, and it would have made for a very noisy map.

Of the events we do broadcast, downloads are king; other events are relatively rare. I believe that a big part of this is that many people aren’t registered for an account, and while downloads can be done anonymously, the other events can’t. We have some very cool stuff coming out really soon for our registered members, so hopefully that ratio begins to change!

Animations

On the front-end, performance was a recurring issue. Originally, the markers were done through ‘traditional’ browser nodes, superimposed over the map. With CSS animations, markers faded out gradually. This became too intensive for the browser to keep up with, though, so we switched to rendering the icons directly into the map’s Canvas. This performs better, but we lost the animations; events blink out of existence.

I think the biggest takeaway for me has been how geographically diverse the Unsplash community is. While there are certainly pockets of concentrated activity, I’ve seen photos get downloaded from all around the world. It’s fun to think that our photographers, collectively, have seen and captured so much of our planet.

Want to help us build Unsplash? We’re currently hiring for front-end development, back-end development, and designer positions. Learn more.

Unsplash on a Map was originally published in Unsplash Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The adorable tool that lets you record and re-watch user sessions.

A few weeks ago, I was working on a Web Audio synthesizer called Key&Pad.

It struck me, while I was building it, that I wouldn’t be able to hear the interesting/beautiful/zany sounds that users made with it. What good is making a fun toy app if you can’t see (hear) what people do with it!

Because that project used Redux, though, the solution was obvious: Since every user action was already passing through the store, I just needed some middleware to capture it and track the time between each action. Then, I could just “replay” those actions in realtime.

As it turns out, there were a fair amount of problems that I hadn’t anticipated, and solving them in a generic way has been challenging. This tool is still in early alpha, and there’s a lot that has yet to be solved, but I’ve been using it in production without issue. I figure it’s time to have others start to poke and play with it :)

The Results

Here are some of my favourite recorded sessions so far:
(give the cassettes a second or two to load)

• Noisecore
  A bunch of really neat, really dissonant sounds using bass notes, distortion, and a myriad of other effects.
• Gradual Experimentation
  This user makes some interesting noises with chorus. Mostly I like this session because the experimentation and discovery process is so evident.
• Absolutely beautiful
  A lovely melody that becomes captivating with stereo tremolo. Evolves into a wub-wub dubstep bass.

Remixable

Redux VCR doesn’t mind being interrupted; it’ll keep carrying out its sequence of actions, without complaining if you jam along with it.

I’ve been having a blast playing notes or tweaking effects on recorded sessions. Here’s a simple session you can have fun with; try playing some notes over it, or changing the effects!

Read on to learn more about how it works, how to get started, and where the project is going, or jump straight to the project on GitHub.

How It Works

Redux VCR is built to be modular. It consists of 4 main parts. Each of these pieces operate with Cassettes, plain objects that hold the sequence of actions needed to recreate a user’s session, as well as some metadata.

Capture

Capture is responsible for observing the stream of Redux actions, and selecting the ones it wants to record.

It’s pretty flexible: You can blacklist certain actions that you don’t want to record, or provide a “start action” that will kick off the recording (if, say, you don’t want to bother recording the onboarding process).

It creates a Cassette object, keeps track of how much time has elapsed between actions, and passes it on to the next module when stuff happens.

Persist

Persist is responsible for, well, persistence. The default module uses Firebase, and it will update the remote copy of the Cassette whenever it’s handed an updated version.

It can be debounced, to avoid spamming the server.

Retrieve

Retrieve is the inverse of Persist; it’s responsible for securely fetching the Cassettes. The default module uses Firebase as well.

Unlike the previous two modules, you likely don’t want to ship Retrieve in production. It’s used exclusively in development, so that you and you alone can re-watch user sessions.

Replay

Finally, Replay is the cute little VCR UI that lets you select and control cassettes. It offers the ability to modify the playback speed of actions, and I hope to add a scrubber that will let you jump to specific parts of the sequence.

It also consists of a middleware that allows us to pass custom options. For example, we can specify a max wait time between actions, to trim out long gaps where users are idle.

It also uses a higher-order reducer, to update the state when cassettes are loaded and ejected.

Similar to Retrieve, this is a production-only module.

Serverless Security

A concern with the development of this project was to ensure that users’ sessions were kept secure. At the same time, I didn’t want to enforce any kind of back-end. Key&Pad lives on GitHub Pages with no server-side logic.

Firebase provides a nice solution, with its custom Rules API.

When your application loads, all users are automatically authenticated using Anonymous Authentication. Essentially this just gives them a unique ID that persists for the session.

Regular users are not able to read from the database at all, and they’re only allowed to write to their custom slice of the database, using their unique ID as the key.

For admins, I’m using GitHub OAuth. You specify, in the Firebase Rules, that read access is only given to users who match a specific GitHub account, and then authenticate by clicking the VCR and signing into GitHub.

Getting Set Up

Every project is different, and I’ve tried to make the setup as straightforward as possible while allowing for various configurations.

A full guide can be found on GitHub, but I think an easier way to grok the high-level concepts is to look at some examples.

I’ve created a repo, redux-vcr-todomvc, which installs Redux VCR in a few different ways. Each is a non-merged Pull Request, so you can view the diffs required to integrate Redux VCR into TodoMVC:

• Quickstart
  This is the easiest way to get started, but it’s not recommended for production usage.
• Production-Ready
  This version takes care to keep admin-only modules out of the production build.
• With an Initial Cassette
  Auto-load a specific cassette, specified by a query parameter. This is useful for favouriting a specific cassette, but can also be used to load the last-played cassette from localStorage.
• More to come!

Beyond the setup in the code, some setup is required with Firebase as well. Check out the Firebase Config docs to see how that works.

Help Build Something Cool

This project is really early, and there’s much work to be done. I have limited time to dedicate to this project, and I’m looking for contributors! I have huge ambitions for this tool, but I can’t do it all alone.

As it stands, Redux VCR works great for simple toy apps, like my synthesizer, but it isn’t sophisticated enough yet to handle most use-cases.

Some stuff I’d like to add:

• A way of stubbing out server requests. We likely don’t want to send real API requests when replaying sessions.
• Native window-level event-capturing like mousemoves and scrolls.
• A proper web interface for managing recorded cassettes.
• A scrubber for being able to “skip to” sections of the tape, quickly replay certain sections, etc.

Contributors who open a significant, acceptable PR will be given full collaborator rights. I want this project to be yours as much as mine. For the community, by the community.

Check it out now on GitHub