DEV Community: Max Rozen

8 Months of OnlineOrNot: From MVP to Stable Product

Max Rozen — Wed, 03 Nov 2021 15:56:02 +0000

Previous articles in this series:

September and October were relatively quiet, so I thought I would write a single article for both months.

While I'd normally try to write at least one useful article per month for OnlineOrNot's audience (as well as an update on how the business is going), I wrote no articles, and no code, actually. Instead, I packed up my life in Sydney, Australia, escaped lockdown, and relocated to France with my wife, and just enjoyed living for a while.

It took just over a month to get over my jetlag, mild burnout from spending months in lockdown, and get back in the groove of working full-time and building OnlineOrNot in the hours before work.

Massive bonus of living in Europe: most of my users are either in this timezone, or nearby (Hi North American friends!) so I'm no longer emailing them at 1am their time.

The Numbers

In October we experienced our first month of negative revenue growth, as of the start of November 2021, we have:

419 (+68) users
7 (-1) paying customers
$127 (-$149) USD MRR

(numbers in brackets are relative to the last update)

You'll notice that a single customer represented more than half of OnlineOrNot's MRR. While it hurt to lose them as a customer, they didn't leave due to missing functionality. Their business helped OnlineOrNot scale rapidly, and I don't lose those gains. For example: from the efforts of keeping them as a customer, our backend scaled from only just handling a few dozen simultaneous Uptime Checks to almost fifty thousand simultaneous Uptime Checks.

While I wish I could say it was beautiful to know I had a business running in the background that requires almost no input from me, it's still extremely early days, and OnlineOrNot's growth engine doesn't work if I'm not routinely writing articles, and interviewing potential customers to improve the product's roadmap.

OnlineOrNot did however manage to continue attracting users without my input thanks to previous marketing efforts:

It's now a matter of converting free users to paid customers.

What I Built

Since coming back to work, here's what I've released:

Bumped a bunch of npm packages (gotta love the JavaScript ecosystem), reducing average frontend build time from 12 minutes to 2 (mainly thanks to the Next.js 12 release)
Added a Discord integration
Migrated from x86 to ARM-based servers (decent performance boost)
Made it possible for customers to select which of our 18 locations to monitor from
Started tracking uptime check usage to allow for future pricing options
Started tracking alerts sent for a future alert "cooldown" feature
Made it possible for customers to remove their own Slack/Discord integrations (before this customers used to email me, and I would do this manually in the backend)
Began to remove the "UI debt" that came with shipping OnlineOrNot in just seven days:

For context, OnlineOrNot is currently three services in one:

Uptime Checks for marketing websites (and soon APIs)
Browser Checks for web apps (also known as synthetic checks)
PageSpeed Checks

I initially built the Uptime Check functionality for regular websites, and just kept adding fields:

I wound up in a situation similar to tech debt, that I call "UI debt". I would get requests for more features that I'd need to add to this form, while also handling support tickets from customers confused about what certain fields do.

After a fair bit of customer feedback, I decided to redesign the Uptime Checks form to allow me to keep providing functionality for power users, while keeping the average use case simple:

What's next

Losing half my MRR from a single customer made me realise I need to talk to more customers and potential customers to understand how I can better serve them with OnlineOrNot. I'm currently reading Michele Hansen's Deploy Empathy and have re-read Rob Fitzpatrick's The Mom Test to get better at this.

In terms of product, I'm planning on extending the Uptime Checks feature to support monitoring APIs better (right now it just supports GET requests and simple body checks), and adding more chat integrations (like Microsoft Teams, and Telegram).

In terms of marketing, I'm getting back in the groove of writing an article every two weeks on DevOps/SRE topics, which I'll also be releasing on this blog.

Building a SaaS in one week: How I built OnlineOrNot

Max Rozen — Sat, 06 Mar 2021 00:52:00 +0000

(This is an article from OnlineOrNot.com. You can read the original by clicking here.)

When I first started building SaaS apps for side projects, it would take me a solid weekend solely to build the Stripe integration. These days, It's possible to build the whole SaaS app in one week.

Table of contents

Background Info
Tech Stack
Approach
Building the SaaS
- First, a blog
- Uptime Checker Test
- On Auth
- Using Tailwind for UI
- On SSR and Emotion
- Forms!
- Latency troubles
- Docs
- Stripe integration
Shipped!
Where to next?

Background Info

Let's start with some background about the app: OnlineOrNot is a pretty standard uptime checker - it does have some fancy logic to ensure the page is actually down before notifying you, but essentially it's a login/sign-up page, a dashboard, a "new page" form, a checker service, a transactional email integration, and a payment integration. I built a similar tool in 2018 (under the same name) to snapshot test GraphQL queries, but that project never took off.

I recently migrated my blog from Gatsby to Next.js, and that got me thinking - How much effort could it possibly be to use Next.js as the core of a SaaS?

I decided to do a quick test, and built a webpage to manually check if any URL is available, in a single afternoon (it's now part of the landing page at OnlineOrNot.com). I was impressed by how seamlessly Next.js blended together React, server-side rendering, and API routes - compared to my regular approach of using Gatsby.js as a landing page, create-react-app as the SaaS app, and a ton of AWS Lambda functions to handle the backend.

Tech Stack

Keeping in mind that I prefer to choose boring technology - I could have used DynamoDB/MongoDB to keep running costs as low as possible, but I opted for a relational data model.

Anyway, here's the tech stack:

Core app: Next.js, hosted on Vercel
UI/CSS framework: Tailwind CSS
Auth: NextAuth.js - a Next.js library
Backend: GraphQL + Node.js, written in TypeScript, sitting on a Next.js API route
Database: Postgres
Worker functions: Node.js/TypeScript, hosted on AWS Lambda
Payment integration: Stripe
Transactional Emails: Mailgun - I'd normally prefer to use Postmark, but didn't want to blocked from shipping by having to wait around to get verified
Newsletter Emails: Convertkit (referral link)

Approach

My work hours for my employer are 9am to 5pm, I tend to wake up at 7am, and go to bed around 11pm. If I gave 100% of my own time to this build, I would have had around 40 hours to work with.

In this particular week, I still either went to the gym, or ran each day, watched some Netflix, had dinner, and went out one night, so I had roughly 20 hours to work with.

Building the SaaS

First, a blog

To begin with, OnlineOrNot started its life as a blog. In particular, I cloned this example: blog-starter-typescript from the Next.js repo.

To get most of the blog functionality I wanted (sitemap, RSS feed, and code snippets in particular), I followed these steps.

Uptime Checker Test

With the blog running smoothly, I built an additional page to manually check uptime (the form you see at OnlineOrNot.com)

To get technical with you, the form submits data to a page living under status/[...url].tsx in my Next.js pages folder. Once it gets a request, it sends off a request to an API route, which then sends the request to one of ten serverless functions deployed around the world (I had to use AWS Lambda for this part).

Seeing app-like functionality work so seamlessly on a blog is what inspired me to see how long it would take me to build a whole SaaS around the AWS Lambda function I wrote.

On Auth

For auth I initially wanted to use Passport, and try out Max Stoiber's recently released passport-magic-login, but I didn't enjoy the user experience of logging into an app with your email only, checking your email, clicking a link, then having to find the original tab to be able to use the app.

After a bit of searching, I came across NextAuth.js, which boasted similar functionality (and heaps more Auth Providers supported), with a bit more polish (to be fair, it's been around longer). It only took me a couple of hours to have both email-only login, and Google Auth0 login working.

Using Tailwind for UI

My typical approach to building UI rapidly would still be to use Bootstrap. In React, I opt for the Reactstrap library. It's never going to win me any design awards, but it helps me get the job done fast.

Since rewriting my own blog from Gatsby to Next.js, I've started writing my CSS using Tailwind utility classes. I find that whereas with Reactstrap I would use the default Bootstrap styles, then manually override each component, Tailwind has me thinking "How can I make this a component I can re-use?" more often, and it makes the code feel cleaner as a result.

To make my use of Tailwind CSS even faster, I paid for Tailwind UI, which has removed the "oh crap, where do I even start?" step for me when working on the frontend. It's kind of like paying for a designer to tell you "here's what screens like this tend to look like" - I highly recommend it.

On SSR and Emotion

One pitfall I noticed with server-side rendering (SSR) and Emotion, is that some of the Tailwind classes use the :first-child selector, and Emotion's SSR support (a CSS in JS library) extracts its CSS to be the first sibling of your component.

As a result, your pages tend to flicker on first load. The fix is simple enough - in Next.js you need to extract the critical styles into the head of the page (I followed the instructions here since I used twin.macro to use Tailwind with Emotion).

Forms!

I used to hate building forms in React until I came across React Hook Form.

Importing the hook, passing ref={register({ required: true })} to a few of my inputs, and implementing a submit handler is all it takes to build awesome forms in minutes these days (though it helps that I've spent a couple of years building forms in React).

Once the user submits the form, they get to see their page being monitored:

Latency troubles

Two days into building the SaaS with login/signup working, and it being possible to add pages to monitor, I decided to ship a v0.0.1 for friends to check out. I'm very glad I did, because I immediately noticed doing almost anything on the production build of the site took 3-6 seconds per click.

I eventually realised that the issue was caused by where I host my database. I typically host my Postgres database in AWS's ap-southeast-2 (Sydney, Australia) region, and Vercel hosts their functions somewhere on the US East Coast - probably in AWS's us-east-1 region.

So each request would hit their CDN, travel half-way across the world to the US, travel half-way across the world back to Sydney, Australia, and back to the US to finish the request.

Shutting down my Sydney database and spinning up a new one in AWS's us-east-1 region greatly reduced the latency issues.

Docs

Before launching, I knew I needed documentation - even though initially I was just building OnlineOrNot as a test to see how much effort is involved in building a SaaS in 2021, as a developer, nothing pisses me off more than crap/incomplete/missing documentation.

I followed the instructions at Docusaurus' homepage, spun up a quick site in Vercel, and mounted it onto the /docs path of OnlineOrNot - a pretty nifty Vercel feature that I loved from AWS CloudFront.

Stripe integration

Integrating Stripe's Checkout requires adding products in the Stripe dashboard, and following the docs - there are also examples to follow.

Since I implemented my last Stripe integration, Stripe launched Billing - greatly reducing the amount of effort required to let users upgrade, change, or cancel their subscriptions.

One of my employer's core values is "Don't f**k the customer", and I strongly identify with it, carrying it with me even when building side-projects. So I knew I had to have Stripe Billing to let my customers cancel at any time.

Rather than build the whole integration myself, I paid for Divjoy (referral link), which conveniently includes a Stripe integration (with Checkout, Billing, and a webhook endpoint). While I only wanted the Billing portion of the codebase, it was money well-spent - it gave me ideas to refactor the integration I built by following the Stripe docs.

Shipped!

With the Stripe integration built and tested, I deployed everything, and here we are - one week after I started toying around with a simple manual uptime checker in Next.js, I have a SaaS with login/sign-up, an app that tracks page uptime, and a way to pay for it (there's also a free tier).

Where to next?

Glad you asked!

I keep a changelog and a product roadmap tracking what's on the radar, what's coming soon, and what's released - I intend to continue shipping features for OnlineOrNot, and continue running it as part of my side-business.

Want to give OnlineOrNot a go?

Get started on the free tier, with 10 reliable monitors, and email notifications - no credit card required.

Get started for free

Guidelines to help you avoid losing your domain

Max Rozen — Sat, 30 Jan 2021 00:52:00 +0000

(This is an article from OnlineOrNot.com. You can read the original by clicking here.)

Imagine you're sitting in your office, and you start noticing emails coming in asking if you'd like to buy your domain.

"Huh, that's weird, I already own that domain" you think to yourself.

A few more emails come in, and they're getting past the spam filter, so you decide to double check your domain manager. Doubt starts creeping into your mind, you start panicking, and you frantically scroll down to where the domain should be, and...

It's gone.

The only option you have is to pay the person that grabbed your domain $3000 USD.

Hold up, rewind...

This sort of scenario can be avoided, yet an entire industry of domain squatters exists due to how commonly it occurs.

In this article, I'll provide advice you can do today to keep your domain secure in the long run.

Table of contents

Enable 2FA
Check that your domain is set to auto renew
Lock your domain from transfer
Check your payment details
Use a reputable domain registrar
Be sure you own your domain
Extend your domain registration
Be aware of any TLD-specific rules around renewals

Enable 2FA

If your domain registrar supports it, enable 2FA (two-factor authentication, also known as MFA/multi-factor authentication). It'll send you an email/SMS/push notification when logging into your domain manager.

While not a foolproof way of stopping hackers, it'll slow them down and alert you if your account has been compromised.

Check that your domain is set to auto renew

Some domain registrars don't enable auto renew by default, particularly when transferring domains.

Check your domain manager to see that it's enabled.

Lock your domain from transfer

While you're checking your domain manager has auto renewal enabled, also double check that your domain's "transfer lock" is also enabled.

Enabling transfer lock for your domain is effectively like a car alarm for your domain. If someone manages to get into your domain manager account, and tries to transfer the domain, you'll receive quite a few emails about it.

Check your payment details

I know this one sounds obvious, but if the payment fails, your domain doesn't get renewed.

The most common mistake is that your credit card expires, and you forget to update the payment details your domain registrar has on file.

On the off-chance your domain registrar accepts Paypal (or similar), also double check that the payment details that they have are also up to date.

Use a reputable domain registrar

There are a few ways to interpret "reputable" - I mean large companies trust them with their services, and the business itself is trustworthy. Certain domain registrars also own companies that "drop catch" domains that expire from their services. Would you want to use a domain registrar that's financially incentivised to let your domain expire?

Here are some reputable domain registrars that immediately come to mind:

AWS
- Some of the largest internet companies trust AWS to host their services
NameCheap
- Decent reputation, has been around a very long time, used to make you pay for privacy, now doesn't
Gandi
- Decent reputation, has been around a very long time
Google Domains
- I hesitated to put this one on the list. Google has a reputation for killing products once it realises it won't be a billion dollar business. Despite this, I've heard Google's Support has been slowly improving over time.

I've personally had negative experiences with GoDaddy and CrazyDomains (in Australia), and would strongly recommend to anyone reading this: transfer your domain ASAP to somewhere like AWS.

Be sure you own your domain

If you purchased your domain through a third-party, like Wix, WordPress, or maybe the agency or contractor that helped build your site, chances are you're not fully in control of your domain.

Sure, it might be easier for you to have them manage the domain for you, and pass the bill along each year, however this sort of arrangement can become problematic when you want to cancel the service, or move to another provider.

If you're having an agency or contractors build your site for you, and they become unresponsive, you risk losing the domain if you also let them manage it for you.

By keeping the login to your domain manager to yourself, you can cut ties with rogue third-parties and move to a different provider.

Extend your domain registration

Most domain registrars will let you extend your registration for around $12 USD per year for .com domains. This lets you remove the risk of your automatic renewal not going through by manually renewing.

For example, AWS offers the following:

Considering the amount of money domain squatters will try to get from you if you let your domain expire, it's a pretty good deal.

Be aware of any TLD-specific rules around renewals

While it's great fun to grab a domain from a country half way across the world from you so you can spell out your brand, different countries have different rules around domain renewals.

As an example, Spain (.es) charges a renewal fee on top of an annual fee. As well as that, if you let the domain expire, there's another renewal fee that ranges from 30 USD to hundreds of dollars (depending on your registrar).

Got any tips I'm missing? Feel free to tweet them at me!

Indiehacking: a review of my 3rd year

Max Rozen — Tue, 22 Dec 2020 09:48:48 +0000

Each year I take this time of year to reflect on how I progressed towards my goal of being self-sufficient as a web developer:

This year is no different, even if it was a total mess.

Table of contents

How I Indiehack
Investing in tooling
Books I Read
Year in review
- Mercenary for hire
- Day-rate contracting
- Startup Tech Stack
- PerfBeacon on the side
- Back into stable full-time work
- Trade-offs, trade-offs everywhere
- Writing weekly
- Taking notes
- Writing a book
Financials
Learnings

How I Indiehack

To save you reading through the previous year's summaries, here's how I indiehack.

I try to keep either a full-time job that doesn't expect me to work 18 hour days to meet tough deadlines, or I take contract/day-rate jobs where I can negotiate to work 4 days a week.

Before and after business hours, and occasionally on weekends, I work on side-projects.

I tend to work in 1-2 hour increments, partly because that's how long I can focus at a time, and partly because I prefer to chip away at a problem, rather than making one big push.

I started the year with the firm belief that running your own one-person SaaS was the only means of starting your own business as a developer. I now see that SaaS is just one type of fix, in a spectrum of fixes - from books/videos/workshops to consulting, to SaaS and other products.

Investing in tooling

I'm not a big fan of re-inventing the wheel when I build my side-projects, so in previous years I invested time in building my own personal framework to spin up SaaS-like solutions.

This time around, instead of investing time, I spent a few hundred dollars on licenses for Tailwind UI and Divjoy.

I still maintain a terraform config for spinning up the required infrastructure for my projects, but now I don't need to think about styling my side-projects, or fiddly integrations like Auth0 and Stripe.

I was able to productionise a web app for one of my projects this year within a couple of hours thanks to these investments.

Books I Read

Until this year, I rarely sat down to read books. Instead, I'd use my commute time to work to listen to audiobooks. As a result, when 2020 happened and I stopped commuting, I started having to make time to read, and as a result of that, I was much more impatient with boring or long-winded books.

Here are the ones that made the cut:

This is Marketing - Seth Godin
How I Built This - Guy Raz
How to Take Smart Notes - Sönke Ahrens
Originals - Adam Grant
Tribes - Seth Godin
Obviously Awesome - April Dunford
The Tipping Point - Malcolm Gladwell

Year in review

Mercenary for hire

I started the year completely burnt out from working for companies that claimed to have certain values, while exhibiting behaviour that ran counter to those values.

So I started looking for React gigs where I could jump in, either fix or build a React app, and jump out as the client needed.

Day-rate contracting

At the end of 2019 I complained across my network long enough that I managed to find myself working as a contractor for a scrappy startup building an entire IoT platform (from devices up to a frontend to display data). Thankfully they had hired a consulting company to handle the IoT device and data ingestion, so I only needed to worry about the web platform.

What started off as a couple of weeks to help the company get to demo day ended up being a few months helping build the company's entire tech stack.

As a result, overnight I unofficially became the:

Product Manager
Frontend Dev
Backend Dev
Data Engineer
SRE
DevOps

and it was surprisingly doable, with the right tech stack (Spoiler: I'm a huge fan of Choose Boring Technology).

Startup Tech Stack

I opted for the same tech stack I know and love for my side projects, and it worked quite well.

For managing tasks/documentation I used Jira and Confluence,
for the frontend I used React via create-react-app.
for the backend I used postgres with a node GraphQL server,
for Infrastructure as Code (IaC) I used terraform,
and for CI/CD I used CircleCI (though these days I'd probably look at using GitHub Actions).

On the data engineering side of things, we would regularly need to transform ad-hoc user-provided data into a format that our system could understand. Essentially, clients would already have IoT devices from competitors, and we would make it possible for them to join our platform via our data engineering efforts.

I was able to automate most of this using Python and AWS S3's event system, so we wouldn't need to wrangle the client's custom datasets more than once.

Side note: it blew my mind how incumbent companies can still charge $10k+ for systems built more than 20 years ago, that these days could be replaced by an ESP32, wifi/3g modem and a python script. Though being able to compete with these companies requires a large professional network and willingness to run high-touch sales that I don't have.

PerfBeacon on the side

While contracting four days a week, I would also work on PerfBeacon before and after work, as well as on Wednesdays. For those that don't know, PerfBeacon helps you keep your app/site fast by automating Google Lighthouse checks.

I managed to finish building the minimum viable product early this year, and started marketing and sales.

After launching PerfBeacon to the world, I built a quick CRM in Airtable, and started selling it to people in my network. I estimate I spent around 40 hours trying to sell PerfBeacon to my network directly, netting approximately zero in sales.

It didn't take long for me to realise that most of running a side business is marketing, rather than product building. Realising I was terrible at marketing, and didn't really know what I was doing lead me to pay for 30x500.

I still run PerfBeacon, it only takes a couple of hours a month on average to keep it running.

Funnily enough, while job hunting this year I ran into some resistance from startups "wanting me to be 100% focused, even outside of work hours on their project". In other words, I would have to drop my side-projects to be able to work for them. Often within minutes of telling me my "vast experience with React" made my profile interesting (I wouldn't have a vast experience in React without side-projects).

Total non-starter, so I kept looking.

Back into stable full-time work

Effectively doing any one of six jobs each day grew old surprisingly quickly, and by February I started to look for long-term contracts at more established companies.

By chance I decided to reach out to a recruiter from Atlassian that ran me through the interview process a year prior, and I managed to get another run through the interview process to be a frontend developer on the Growth team at Atlassian.

I ended up getting the job, and it's been fantastic.

Trade-offs, trade-offs everywhere

Working at a huge corporation like Atlassian has made me appreciate trade-offs much more than any small company ever did.

We regularly run through DACIs (basically a fancy RFC) when making technical decisions. Where before I'd run a technical decision past an architect/CTO, I'm now able to tap into our entire department's expertise to get more context, and see any gaps in what I'm trying to build.

Writing weekly

I started the year only writing whenever I got inspired (basically, after something made me angry enough to write about it). While cathartic, this didn't do much for people who read my blog.

Instead of focusing on things that annoyed me, in July I decided to focus on regularly helping people. I knew quite a bit about React from using it in production for several years (both on side-projects and at work), so it'd be a shame not to share the knowledge.

Since starting to blog more regularly, I went from an average of 20 readers on my blog per day, to about 140 readers per day on days when I don't post my articles anywhere, up to 2500 a day when I do share my articles.

Taking notes

Writing weekly has become easier as I started to treat my articles like "semi-permanent notes" to myself about certain topics in React.

I tend to take notes (whether in a notebook, on my phone, or on scrap pieces of paper) from wherever I see people discussing React (Twitter threads, reddit posts, etc) and eventually type them up into an article. Eventually, I revise the article as I find new information. A good example of this is Keeping up with React Libraries.

I learned this process after reading How to Take Smart Notes by Sönke Ahrens, which I'd highly recommend to aspiring writers out there.

Writing a book

After writing consistently for a few months, I started to notice the articles that would get significantly more traffic and links than others.

In the end, I decided to write a book to try help people more than a few blog posts ever could. It's called useEffect By Example, and I'll be launching it in January 2021.

Financials

PerfBeacon is now break-even (in terms of running costs), averaging between $1-200 MRR.

Judging by pre-orders alone, useEffect By Example looks like it'll beat PerfBeacon in terms of revenue, even in the long term, and, even though PerfBeacon runs on a recurring subscription model.

I'm still very far from being able to employ myself, but at least now I have a repeatable process that works - writing consistently.

Learnings

SaaS is only one way of solving problems for your customers. Explore all possible means (books, videos, workshops, consulting, code snippets, plugins) of solving a problem before diving into building a SaaS. SaaS is often the most difficult, and time consuming way to run a business.

Pre-sales are an incredibly powerful tool to gauge buyer interest. Indiehackers can easily start a gumroad pre-sale to take valid credit card details, and only process the payment when they ship.

Write regularly. Similar to running/working out, the more you work out the muscle, the easier it becomes. There are unintentional benefits to this:

Writing documentation, emails, tickets, etc at work becomes easier
SEO: the more you write, the more long-tail keywords your articles will pick up
You grow an audience that wants to see what you're regularly creating
You get to practice shipping in a way you wouldn't get if you only focused on building product.
- Building OnlineOrNot and PerfBeacon, I got to experience launch anxiety perhaps once every six months, while with my writing on MaxRozen.com I experience it weekly.
- This in turn has taught me lessons on editing, marketing, running a newsletter, engaging with the community, and more that I probably don't even realise yet.

Keeping up with React Libraries

Max Rozen — Mon, 26 Oct 2020 09:48:48 +0000

This is an article from MaxRozen.com. You can read the original here.

It’s no secret React has a library discoverability problem.

While the number of stars in GitHub and weekly downloads in npm might be a good starting point for finding quality libraries, normally you have to wade through a lot of reddit, hacker news, dev.to and individual blog posts to find the best ones.

In this (continually updated) article, I’ll be adding libraries (excluding component libraries, I track those here) worth talking about on a single page.

Accessibility
Animation
Browser Features
Data Fetching Libraries
Data Visualisation
Forms
State Management
Testing

Accessibility

React Aria

React Aria provides you with Hooks that provide accessibility for your components, so all you need to worry about is design and styling. Particularly useful for those building design systems.

Example usage - useButton:

import { useButton } from '@react-aria/button';

function Button(props) {
  let ref = React.useRef();
  let { buttonProps } = useButton(props, ref);

  return (
    <button {...buttonProps} ref={ref}>
      {props.children}
    </button>
  );
}

<Button onPress={() => alert('Button pressed!')}>Press me</Button>;

Animation

Animation adds soul to otherwise boring things. These libraries let you build the web app equivalent of Pixar’s Intro Animation, but in React.

Both libraries have similar APIs and support spring physics over time-based animation, though Framer Motion seems to be used more often on GitHub.

Framer Motion

Framer Motion is an animation and gesture library built by Framer. The added benefit of Framer Motion is that your designers can build animations in Framer, then hand-off designs to be accurately implemented using Framer’s own library.

React Spring

React Spring uses spring physics rather than time-based animation to animate your components. Relative to Framer Motion, React Spring has been under development for longer, with a greater number of open-source contributors.

Browser Features

Ever been asked to implement random features that someone on the product team saw on another website and thought was cool? These libraries save you time on building those features.

useClippy

useClippy is a React hook that lets you read and write to your user’s clipboard. Particularly useful for improving UX, letting you save your users from double clicking on your data fields, by providing them a button to copy values.

ReactPlayer

ReactPlayer is an awesome library that lets you embed video from major sources (YouTube, Facebook, Twitch, SoundCloud, and more), and define your own controls to the video.

React Toastify

React Toastify allows you to add fancy in-app notifications (like the “Message Sent” notification in Gmail) to your React app with only four additional lines of code.

Data Fetching Libraries

You might be wondering why you’d even need a data fetching library, when you could use useEffect and fetch(). The short answer is that these libraries also handle caching, loading and error states, avoiding redundant network requests, and much more.

You could spend hundreds of hours implementing these features in a Redux-like state manager, or just install one of these libraries.

React Query

React Query lets you request data from the same API endpoint (for example api/users/1) across multiple components, without resulting in multiple network requests.

SWR

Similar to React Query (in fact, based on the same premise, see this issue for more info), SWR is another data fetching library worth checking out. SWR has the added security of being used by Vercel in production as part of their platform.

Data Visualisation

Everyone wants to have beautiful charts, but nobody wants to learn no complicated-ass D3

Ronnie Coleman, probably

visx

If you’ve ever used a popular charting library such as Recharts or Charts.js, you’ll know it’s surprisingly easy to reach the limits of what a charting library can do for you.

visx is different, in that it provides you with lower-level React components that are much closer to D3 than other charting libraries. This makes it easier to build your own re-usable charting library, or hyper-customised charts.

Forms

Forms suck. Take it from someone who once had to build a “smart” form with 26 possible fields to fill out - you want to pass off as much as possible to your form library, leaving you with only quick field names to enter.

React Hook Form

React Hook Form is different to other form libraries, in that by default, you’re not building controlled components and watching their state. This means your app’s performance won’t get slower as you add more fields to your form.

On top of that, it’s probably one of the best documented libraries out there - every example has a CodeSandbox, making it easy to fork and try out your particular use case.

State Management

There’s been a fair bit of innovation in state management since the early days of Redux, it’s worth taking a look again if you’re interested in using global state.

Recoil

Recoil is a state management library - think Redux meets React Hooks, minus the boilerplate.

Redux Toolkit

Redux Toolkit (or RTK), is the official, opinionated way to manage your state using Redux.

RTK greatly reduces the amount of boilerplate necessary for using Redux, provides sensible defaults, and keeps the same immutable update logic that we know and love.

xstate

XState is a library that lets you formalise your React app as a finite state machine.

State machines aren’t a particularly new concept, but developers have only recently started to realise that maybe our apps could be less buggy if we explicitly define the states they can be in, and the inputs required to transition between states.

XState also generates charts for you based on your app’s xstate configuration, meaning your documentation will stay up to date as you code.

Testing

React Testing Library

If you haven’t started a new create-react-app project in a while, you can be forgiven for not having heard of React Testing Library (RTL) yet.

RTL replaces Enzyme in your testing stack. While both libraries provide methods for rendering React components in tests, RTL exposes functions that nudge developers away from testing implementation details, and towards testing functionality.

Understanding when to use useMemo

Max Rozen — Tue, 20 Oct 2020 07:08:35 +0000

This is an article from MaxRozen.com. You can read the original by clicking here.

It's pretty common for people to say

Don't use useCallback/useMemo everywhere!

Without actually explaining cases where you would want to use useCallback/useMemo.

In my last article we learned that useCallback is useful for passing stable references to functions down to the children of a React component, particularly when using those functions in a child's useEffect.

If you're scratching your head wondering "...but then, what the hell is useMemo for?", you're not alone!

One hint that the React docs give is:

useCallback(fn, deps) is equivalent to useMemo(() => fn, deps).

Which is great if you're well versed on the significance of passing a function reference versus passing an arrow function that calls the function (while quickly scanning docs for an answer), but for the rest of us, hopefully this article will help.

What useMemo does

In short, useMemo calls a function when dependencies change, and memoizes (remembers) the result of the function between renders.

This is in contrast with useCallback which remembers an existing value (typically a function's definition), between renders.

You want to use useMemo to save yourself from rerunning an expensive calculation to generate a new value, and you want to use useCallback to store an existing value.

When to use useMemo

This part is where it's easy to get frustrated. There are a lot of blog posts out there describing useMemo, and then presenting examples of when not to use it.

Unfortunately, it needs repeating: don't use useMemo until you notice parts of your app are frustratingly slow. "Premature optimisation is the root of all evil", and throwing useMemo everywhere is premature optimisation.

Here are a couple of cases when you should consider using useMemo:

You're noticing a component's render is frustratingly slow, and you're passing a calculation to an unknowable number of children, such as when rendering children using Array.map()
Your app often becomes unresponsive because you're fetching a large amount of data, and having to transform it into a usable format

The key is to focus on the problem.

"My app is slow, and calculation-heavy" is a problem that useMemo helps to solve. Run your app through React DevTools Profiler, as well as Google Lighthouse or WebPageTest to understand its performance metrics, wrap your calculation in useMemo, then measure again.

"I just learned useMemo, and want to use it everywhere" is focusing on the solution, and will lead you to premature optimisation, and a potentially slower app.

Why not use useMemo everywhere then?

In short, it's not a free performance optimisation.

There's an additional cost (memory usage, for one) incurred when setting up useMemo, that can very quickly outweigh the performance benefit of remembering every single function's possible value.

When we use useMemo, we're taking up more memory in order to free up CPU time. If your app is hammering the CPU with a lot of calculations, that's when you might consider taking up some memory and use useMemo instead.

What about stable references?

If you want to keep a stable reference to an object/array that doesn't require recalculation, consider using useRef.

On the other hand if you need to recalculate the value when dependencies change, useMemo is the hook for you.

Potential mistakes when using useMemo

Using useMemo isn't free of pitfalls as well - one of the big ones is that the cache isn't guaranteed to keep all of its values between renders. Taken from the docs:

You may rely on useMemo as a performance optimization, not as a semantic guarantee

Translation: the cache isn't stable!

Meaning if you absolutely want to avoid recalculations with your useMemo call, it's not guaranteed. For a version of useMemo with a stable cache, see useMemoOne.

A Guide to Styling your React App

Max Rozen — Tue, 18 Aug 2020 08:42:05 +0000

If you’re new to React, you might be wondering why there are so many different tutorials that teach different ways to style your React app. The truth is, we’re all still figuring out the best way to do things.

Styles in React were more-or-less worked out in this order:

Global CSS
CSS Modules
CSS in JS (styled-components, Emotion, etc)
- Utility-first CSS
- Styled System
Statically extracted CSS in JS

These days, I recommend starting with CSS in JS. If you’d like to know why, read on.

Quick note

When I say styling, I mean writing your CSS styles more-or-less from scratch. If you’re looking for pre-built components, I wrote a guide to commonly used React component libraries.

Global CSS

Global CSS is likely the way you’re used to styling webpages. You have a giant styles.css file, and try to write BEM or SMACSS names for all of your classes. Alternatively, you have a ton of tiny files, and don’t always know where each class lives.

We as frontend developers quickly realised that global CSS doesn’t really scale. The more teams you have editing a single file, the more likely you are to have CSS that doesn’t do anything (people become too afraid to delete anything in case it breaks).

If you still want to use Global CSS in your React app, all you need to do is import the CSS file at the top level of your React app (assuming you’ve configured webpack to do so, or are using create-react-app).

//App.js
import './styles.css';
import React from 'react';

const App = () => {
  return <div className="some-class">some other stuff in here</div>;
};

CSS Modules

CSS Modules look a lot like Global CSS, in the sense that you’re importing a CSS file into your React component, but under the hood it’s quite different.

A lot of the problems we used to have with Global CSS are gone with CSS Modules.

Your CSS looks like this:

/* style.css */
.makeItGreen {
  color: green;
}

and your React Component looks like this:

import React from 'react';
import styles from './style.css';

const MyComponent = () => {
  return <div className={styles.makeItGreen}>Green!</div>;
};

The key difference here is that only files that import style.css will be able to access the class names that it defines, and the class names that get generated during the build process will be unique.

No more conflicts, no more “too afraid to delete things in case it breaks”, just locally scoped CSS. You can also set-up SCSS/LESS support, if you need it.

The really cool thing about this is that you can start to play around with JavaScript to change a component’s styles.

import React from 'react';
import styles from './style.css';

const MyComponent = (props) => {
  const myStyle = props.color === 'RED' ? styles.makeItRed : styles.makeItGreen;
  return <div className={myStyle}>{props.color}!</div>;
};

Although, that starts to get a bit messy if you’re using several props to change the style and behaviour of your components. What if your styles could just be components?

CSS in JS

That’s where CSS in JS comes in.

Libraries like styled-components and Emotion make it possible to wrap components (including divs, spans, <p> tags, <a> tags) with styles, and use them as React components.

The best part is, you can use all of the standard CSS features you’re used to, such as media queries, and :hover and :focus selectors.

Our example from above now becomes:

import React from 'react';
import styled from '@emotion/styled';
// OR import styled from 'styled-components'

const StyledGreenThing = styled.div`
  color: ${(props) => (props.color === 'RED' ? 'red' : 'green')};
`;

const MyComponent = (props) => {
  return (
    <StyledGreenThing color={props.color}>{props.color}!</StyledGreenThing>
  );
};

As of 2020, Emotion and styled-components are evenly matched performance-wise. Contributors to styled-components worked hard to bring their performance up to Emotion’s level, so deciding which one to use isn’t as much of a big deal any more.

Emotion does provide some extra options for styling, such as the css prop, while styled-components tries to keep a single, standard way of doing things via the styled API.

Utility-first CSS

A guide to styling React apps wouldn’t be complete without mentioning utility-first CSS frameworks such as Tailwind. You don’t actually need React to use utility-first CSS, but in my opinion, it makes for a better developer experience when you add React and CSS in JS.

In short, Tailwind lets you style your components one class at a time. Here’s what it looks like:

<div className="md:flex bg-white rounded-lg p-6">
  <img
    className="h-16 w-16 md:h-24 md:w-24 rounded-full mx-auto md:mx-0 md:mr-6"
    src="avatar.jpg"
  />
  <div className="text-center md:text-left">
    <h2 className="text-lg">Erin Lindford</h2>
    <div className="text-purple-500">Product Engineer</div>
    <div className="text-gray-600">erinlindford@example.com</div>
    <div className="text-gray-600">(555) 765-4321</div>
  </div>
</div>

Which creates a component that looks like this:

You might be thinking that it’s not a particularly re-usable solution, however it’s possible to use Tailwind class names with your favourite CSS in JS library using twin.

You can then have styled Tailwind components:

import tw, { styled } from 'twin.macro';

const Input = styled.input`
  color: purple;
  ${tw`border rounded`}
`;

export const MyStyledInput = () => {
  return <Input />;
};

Styled System

Styled System takes the styled API supplied by styled-components or Emotion, and adds utilities as props, rather than class names.

The Styled System approach is particularly powerful when it comes to theming/white labelling, as changing the entire appearance of your app can be done by replacing the theme.js file you provide.

Your components end up looking like this:

import styled from '@emotion/styled';
import { typography, space, color } from 'styled-system';

const Box = styled('div')(typography, space, color);

const UsedBox = () => {
  return (
    <Box
      fontSize={4}
      fontWeight="bold"
      p={3}
      mb={[4, 5]}
      color="white"
      bg="primary"
    >
      Hello
    </Box>
  );
};

Statically extracted CSS in JS

The trouble with CSS in JS is that it takes JavaScript to load your CSS. This slows things down big time, so people started looking for ways to extract the CSS from CSS-in-JS during build time.

There are a few libraries that can do this:

Compiled and linaria let you use the styled API that you know and love, while giving you the performance benefit of not having CSS in your bundle.

(This is an article from MaxRozen.com. You can read the original by clicking here.)

A Guide to Commonly Used React Component Libraries

Max Rozen — Thu, 13 Aug 2020 21:37:42 +0000

Ant Design

Project link: Ant Design

Bundle Size (from BundlePhobia): 1.2 mB minified, 349.2kB minified + gzipped, less with treeshaking

Pros:

Ant Design comes with a huge amount of supporting documentation, community, including a separate project (Ant Design Pro) with pre-made templates
The kind of UI library you’d use to quickly throw up as a back-office/internal app design

Cons:

Accessibility is lacking
It’s huge. Expect a sizable performance impact when using
Pollutes your CSS (expect to add !important to prevent it styling your non-Ant components)

Bootstrap

I actually rate Bootstrap relatively highly as a UI library. It’s not going to win you any design awards, but it gets the job done for side projects and minimum viable products.

It depends what you want to use it for, though. If you’re new to React, it’s a great library to use to get started. As a more experienced developer, chances are you’ll want to look into styled-components/Emotion.

There are two popular libraries with React bindings for Bootstrap, I’ve personally only used Reactstrap.

Project links:

React Bootstrap
- Bundle Size (from BundlePhobia): 111kB minified, 34.4kB minified + gzipped, less with treeshaking
Reactstrap
- Bundle Size (from BundlePhobia): 152.1kB minified, 39.4kB minified + gzipped, less with treeshaking

Pros:

The Bootstrap library that you know and love, with React bindings
Easily customised via CSS-in-JS
It’s been around long enough with widespread usage that bugs/issues aren’t a worry
Quick to get started
No jQuery dependency as it’s been reimplemented entirely in React

Cons:

It’s Bootstrap: your site will look like everyone elses if you don’t customise it

Bulma

Bulma is different to most libraries presented here because it’s purely a CSS framework, no JS required. You can choose to either use the classes from Bulma directly, or use a wrapper library such as react-bulma-components.

Project links:

Bulma
react-bulma-components
- Bundle Size (from BundlePhobia): 179kB minified, 20.1kB minified + gzipped

Pros:

Doesn’t have the Bootstrap look and feel
Good for getting something up and running quickly
Modern features (Flexbox/Grid under the hood)

Cons:

Accessibility: there’s some, but doesn’t follow WCAG guidelines as strongly as other libraries

Chakra UI

Project link: Chakra UI

Bundle Size (from BundlePhobia): 326.2kB minified, 101.2kB minified + gzipped, less with treeshaking

Pros:

Accessibility: follows WAI-ARIA guidelines and components use aria tags
Discord server for support
Easily customisable (with theming support)
Highly modular, so treeshaking actually removes code you don’t use

Cons:

Quite new.

Notes:

Very close to v1 release, so be aware of breaking changes coming from v0.8.0

Material UI

Material UI is one of those libraries that I love to hate. It has helped me get through some extremely tight deadlines for clients in the past, but I always end up removing it in favour of almost anything else as soon as possible.

In the past you could only customise Material UI’s styles by writing JSS, but thankfully it’s now possible to override styles with styled-components and Emotion.

Project link: Material UI

Bundle Size (from BundlePhobia): 325.7kB minified, 92kB minified + gzipped, less with treeshaking

Pros:

Comprehensive documentation
Icon library is massive
Simple to use (at first)

Cons:

Customisation is difficult, and painful, yet necessary (to improve visuals)
Performance: known to render excessive DOM nodes
Your app will look like Google made it (which could be a pro, for some people)

Semantic UI

Project links:

Semantic UI
Semantic-UI-React
- Bundle Size (from BundlePhobia): 300.8kB minified, 80.9kB minified + gzipped, less with treeshaking

Pros

Composable (using the as prop to pass components)
Easily customisable
Helpful docs
High profile users (Netflix internally, Amazon publishing)
TypeScript support

Cons

Potential uncertainty about the open source project.
- See issues: https://github.com/Semantic-Org/Semantic-UI/issues/6109 https://github.com/Semantic-Org/Semantic-UI/issues/6413
- Community-run fork exists: https://github.com/fomantic/Fomantic-UI

Honourable mentions

Reach UI

Reach UI is a low-level component library, focusing on allowing developers to build accessible React components in their design system.

There’s no bundle size available as each component is exported individually as its own npm package.

Reakit

Reakit is another low-level component library. It’s technically a UI library, but doesn’t come with CSS. So you still need to come up with a styling solution.

Bundle Size (from BundlePhobia): 119.9kB minified, 32.1kB minified + gzipped, less with treeshaking

Rebass

Rebass has been on my radar for some time. It’s an extremely powerful component library that doesn’t come with a theme, but can be themed easily. For an example of how this works in practice, see their demo.

Project link: Rebass

Bundle Size (from BundlePhobia): 43kB minified, 14.4kB minified + gzipped, less with treeshaking

Notes

In making this list, I’ve attempted to avoid corporate design systems, however some (Material UI) have achieved such widespread adoption that this list would be incomplete without them.

I’ve also intentionally left out CSS-in-JS such as styled-components and Emotion, and utility CSS systems such as Tailwind, as they are not explicitly “React Component libraries”, but rather tools with which to make your components.

Am I missing any? Tell me on Twitter!

(This is an article from MaxRozen.com. You can read the original by clicking here.)

How to use SVGs in your React App

Max Rozen — Mon, 10 Aug 2020 21:37:42 +0000

Trying to render an SVG in your React app, and getting errors? You’re not alone - it’s a relatively common issue.

There are two ways to do it, and both have tradeoffs.

Using `<img>` tags, and passing your SVG’s URL

Here’s a basic example:

import React from 'react';
import logoSrc from './logo.svg';

const MyLogo = () => {
  return <img src={logoSrc} />;
};

The benefit of this approach is that your logo will not end up in your bundle, but rather exported as a static file when you run yarn build (assuming you’re using a standard webpack config, such as the one found in create-react-app).

This then gives you the option of aggressively caching icons that you know won’t change.

You would typically use this approach for larger company logos on your marketing site, or for illustrations in your app.

Creating a React component, and passing props

The other option is to create a React component containing your SVG. Also known as “inlining” your SVG.

This done by pasting your raw svg markup into a new React component.

There are a few ways to achieve this:

Manually, byremoving/replacing all HTML props with the React equivalent, and adding {...props} to the main svg element),
CLI via SVGR - a utility to automate this process
Webpack config via SVGR

If you’re using create-react-app, it already has SVGR’s webpack config built-in, so you can already use your SVGs like React components:

import Star from './star.svg';
const App = () => (
  <div>
    <Star />
  </div>
);

Here’s what a manually created SVG-based React component looks like:

import React from 'react';

export const DeleteIcon = (props) => (
  <svg
    xmlns="http://www.w3.org/2000/svg"
    height="24px"
    viewBox="0 0 24 24"
    {...props}
  >
    <path d="M6 19c0 1.1.9 2 2 2h8c1.1 0 2-.9 2-2V7H6v12zM19 4h-3.5l-1-1h-5l-1 1H5v2h14V4z" />
    <path d="M0 0h24v24H0z" fill="none" />
  </svg>
);

This approach lets you easily access props on your SVG icon. For example, changing the fill color:

<DeleteIcon fill="#fff" />

The downside being that your icons won’t be as easily cached, so I would use this approach for smaller icons, such as the Material Design Icons.

(This is an article posted to my blog at maxrozen.com. You can read it online by clicking here.)

Should you use functional components + Hooks over class components?

Max Rozen — Fri, 07 Aug 2020 23:51:22 +0000

If you're new to React, and you've been working through tutorials, chances are you've run into examples of both functional components with Hooks, and class components, with no strong indication of which one you should be using. Even as a seasoned developer, you might still be using class components, wondering if its worth the rewrite.

Heck, you might even be thinking:

I've been digging for answers, but I just can't find a clear answer for this

That's fair enough, even the official documentation didn't have a strong recommendation until the middle of 2020.

Which one should you use?

The official React team stance (according to the docs), is:

When you’re ready, we’d encourage you to start trying Hooks in new components you write. [...] We don’t recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs).

To summarise:

New code should use functional components with Hooks, when you're ready
Old code can keep using class components, unless you want to rewrite

Should I just focus on hooks then?

It's not that simple.

You still need class components to build Error Boundaries.

On top of that, most code written before 2019 will likely still use class components, as there is no immediate need to rewrite them to functional components with Hooks. If you want to understand existing code in a codebase, you'll need to also learn class components.

You'll also find that companies that ask React questions during their interviews will still ask you about classes.

Should we rewrite our old class-based code to use Hooks?

As with all good things, there are tradeoffs to consider here.

Hooks result in much cleaner, easier to understand components compared to class components of a similar complexity.

To illustrate my point, compare this component that fetches some data from The Star Wars API, written first as a class, then as a functional component with hooks:

import React from 'react';

export default class DataDisplayer extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      data: null,
    };
  }

  async componentDidMount() {
    const response = await fetch(
      `https://swapi.dev/api/people/${this.props.id}/`
    );
    const newData = await response.json();
    this.setState({ data: newData });
  }

  componentWillUnmount() {
    // if this was a subscription, we'd need clean-up here
    console.log('CWU');
  }

  render() {
    const { data } = this.state;
    if (data) {
      return <div>{data.name}</div>;
    } else {
      return null;
    }
  }
}

A pretty standard class component.

As your app grows, the lifecycle methods grow larger, and the context switching involved just from scrolling through the file increases.

I don't know about you, but my thought process when scrolling through classes is like:

Okay so I'm in componentDidMount, so we'll be fetching data here

Okay so here we're rendering, so this code runs every single time

I need to add some extra functionality... hmm which lifecycle method does that go in again?

On the other hand, you have Hooks:

import React, { useEffect, useState } from 'react';

export default function DataDisplayer(props) {
  const [data, setData] = useState('');

  useEffect(() => {
    const getData = async () => {
      const response = await fetch(`https://swapi.dev/api/people/${props.id}/`);
      const newData = await response.json();
      setData(newData);
    };
    getData();
    return () => {
      // if this was a subscription, we'd need clean-up here
    };
  }, [props.id]);

  if (data) {
    return <div>{data.name}</div>;
  } else {
    return null;
  }
}

With Hooks, writing code that follows sequentially is much easier, and I find reading functional components with Hooks requires less context switching, as you're not jumping around the file to find which lifecycle method you think something happened in.

That's the main benefit of rewriting to Hooks - your codebase's developer experience improves as it takes less time to understand what each component does.

The main drawback is time - time spent rewriting is time you could have spent building new features.

Where to from here?

When introducing Hooks to my team in the past I recommended the following approach, and it worked quite well:

All new code should be written as functional components with Hooks
Existing code should only be rewritten if it gets touched (for example, if you're fixing a bug or adding functionality, take the time to swap the component over to Hooks)

(This is an article posted to my blog at maxrozen.com. You can read it online by clicking here.)

It's not always greener on the other side

Max Rozen — Wed, 05 Aug 2020 22:50:56 +0000

I started my career having finished a double Bachelor’s degree in Software Engineering and Commerce, thinking I could just get a finance job, and automate the boring parts with my Python skills.

Then reality hit.

Roughly a year of job hunting later (including one call back, in which the recruiter asked me why I didn’t also have a background in accounting), I realised I should probably rewrite my resume to be more Software Engineering focused.

Eventually a friend from university suggested I pitch his hedge fund a dashboard built in D3.js - this cool new technology (at the time) that made their Excel dashboards look ancient.

So I started learning JavaScript

I spent a week learning just enough JavaScript to make a convincing dashboard of all stocks trading on the ASX 200, with data fetching from Yahoo Finance. I didn’t get the gig, but I ended up getting the attention of the agency that worked for the hedge fund.

I ended up working for the agency, building data pipelines, learning more Python, building sites in Django and (some) JavaScript. After about a year, I started longing for more work directly with clients, so I started interviewing with the Big Four (EY, PwC, Deloitte, KPMG), and found myself with an offer for a role at Ernst and Young (EY).

I was so keen for a “big name” on my resume, I was willing to take a 10% pay cut to work there.

So I became a consultant

The consulting job didn’t quite turn out as planned.

You had to wear a suit, most clients already hated you before meeting you (presumably due to the cost of hiring the firm). To top it off, it felt strange being told to perform manual tasks in ancient drag-and-drop software after having spent a year writing Python to automate that sort of work.

I started hatching a plan to escape after three months. I wanted to go back to being a software engineer, but jobs in Python were rare in Sydney.

So I started learning React

I had written enough JavaScript to know React was probably going to be a big deal, so I hit the tutorials.

I found the official documentation at the time to be quite dense, it almost felt like you needed to already know React to be able to finish the tutorial.

A couple of tutorials really stood out, (and are amazingly still online):

React From Zero
The Road to React - I used the pre-hooks version (since they didn’t exist at the time), but I’m told the new version is still good

After the tutorials, I started building IndieHacker style side projects in React and GraphQL while job hunting for a React job.

It took about four months to find a job, but what I found almost doubled my salary.

So I became an IndieHacker

I never really stopped building side projects while employed, mainly out of imposter syndrome, as I felt I really needed to catch up to my colleagues to be a useful member of the team.

I personally wouldn’t recommend it, unless you’re really good at managing burn-out.

Over the years, I’ve built:

a job board
an appointment scheduler
a room booking system
a GraphQL snapshot monitoring service
a REST API monitoring service
a frontend performance monitoring service (PerfBeacon - I’m currently working on this one)

After a few years of being a React developer I finally got a job at Atlassian, as a frontend developer on the Growth team.

What’s next?

I still think React (or something like it) is going to be the next big thing. The numbers tend to agree with me, React was #1 for hiring on Hacker News in both 2018 and 2019.

It has greatly improved my quality of life and my job prospects, so I want to help others do what I did.

I plan on writing and releasing lessons to help people to:

Learn enough JavaScript to get going with React
Learn enough React to build useful software

I use Twitter to share what I’m working on, so you can follow me there if you’d like to see it first.

Keeping your sites fast with regular performance tests

Max Rozen — Tue, 04 Aug 2020 04:40:02 +0000

Do you have clients, or stakeholders asking about improving their site performance, or wondering why their site seems to have gotten slower over time?

It happens to everyone: you deliver a fast website from the start, but then over time you get feature request after feature request, deadlines get rushed in, and the next thing you know you’ve got a client asking why some pages are taking up to ten seconds to load.

It doesn’t have to be this way.

It’s actually a simple fix: regularly check your site speed.

There are several manual tools you can use for free:

Pro tip: Export the numbers, and use Excel or Google Sheets to graph your performance over time.

Once you start checking your site speed daily, it becomes easier to notice your performance slipping over time.

(This is an article posted to my blog at maxrozen.com. You can read it online by clicking here.)

DEV Community: Max Rozen

8 Months of OnlineOrNot: From MVP to Stable Product

The Numbers

What I Built

What's next

Building a SaaS in one week: How I built OnlineOrNot

Background Info

Tech Stack

Approach

Building the SaaS

First, a blog

Uptime Checker Test

On Auth

Using Tailwind for UI

On SSR and Emotion

Forms!

Latency troubles

Docs

Stripe integration

Shipped!

Where to next?

Guidelines to help you avoid losing your domain

Enable 2FA

Check that your domain is set to auto renew

Lock your domain from transfer

Check your payment details

Use a reputable domain registrar

Be sure you own your domain

Extend your domain registration

Be aware of any TLD-specific rules around renewals

Indiehacking: a review of my 3rd year

How I Indiehack

Investing in tooling

Books I Read

Year in review

Mercenary for hire

Day-rate contracting

Startup Tech Stack

PerfBeacon on the side

Back into stable full-time work

Trade-offs, trade-offs everywhere

Writing weekly

Taking notes

Writing a book

Financials

Learnings

Keeping up with React Libraries

Table of Contents

Accessibility

Animation

Browser Features

Data Fetching Libraries

Data Visualisation

Forms

State Management

Testing

Understanding when to use useMemo

What useMemo does

When to use useMemo

Why not use useMemo everywhere then?

What about stable references?

Potential mistakes when using useMemo

A Guide to Styling your React App

Quick note

Global CSS

CSS Modules

CSS in JS

Utility-first CSS

Styled System

Statically extracted CSS in JS

A Guide to Commonly Used React Component Libraries

Ant Design

Bootstrap

Bulma

Chakra UI

Material UI

Semantic UI

Honourable mentions

Reach UI

Reakit

Using `<img>` tags, and passing your SVG’s URL