Bathtimer

This isn't going to be a shocker, but I chose Next.js over create-react-app to build out the Bathtimer landing page for (primarily) SEO reasons. But... I did find other DX niceties that don't have to do with SSG/SSR:

• Routing. Next.js makes routing a first-class feature, and is, in my opinion, much easier to work with than React Router.
• API. Just convenient to not have to set up a separate codebase for server-side code. Eventually, it will behoove me to set up a dedicated server/API, but it's nice to have for small needs at the beginning. There are many more features that I haven't worked with that I know are DX improvements over create-react-app. Some include auth (via NextAuth.js), scoped CSS, and magical optimizations for images, links, etc.

What's your Next.js adoption story? If you're still sticking with create-react-app, what's the rationale behind your decision? Thanks for reading!

Whaaat? Another app written in TypeScript? Not very original of me. I used to write React/React Native apps in plain Javascript, and thought I had no use for TypeScript, but I shamelessly admit that I am a convert (I even use TS for interviews, since I don't have to spend mental effort recalling the structure of some variable).

The primary reason I switched to TypeScript is that it's a real snitch. I remember I once had a global state that I needed to refactor. A lot of different components and utility functions referenced this global state, but now that the state's structure has changed! Updating how the state was used across the entire codebase was going to be a nightmare.

I eventually made the updates everywhere in the codebase, but the process was a game a hide-and-seek. It's no life to live where you have to do a full-text search on your own code to find references to variable a, b, c. When I made the switch to TypeScript, I realized that this refactor would've been easy since TypeScript would do the snooping-around-the-codebase for me and tell me exactly where I needed to update.

So I hear the buzzword "scale" a lot when people describe the benefit of TypeScript. I don't like that word because it's a platitude that most people tune out. But I learned a valuable lesson that TypeScript's ability to tattletale would be massively helpful when refactoring code.

Are you a TS convert, or still a skeptic? If you're looking to migrate a small-/medium-sized codebase to TypeScript, I'm going to make a post about how I did it.

Also, check out Bathtimer if you want to shorten your showers! https://www.bathtimer.com/

Full transparency: Bathtimer has been ejected from expo for a few months, but since a good portion of initial development is still written in expo, I want to share (1) why I started out using expo, and (2) why I decided to part ways with it.

When working with React Native, no developer is a stranger to Expo. I'm sure a lot of people started their journey using Expo, since even the React Native team advocates its usage for beginners. I started out with Expo because it gave a few advantages over going with plain React Native:

• It abstracted out the underlying Android/iOS code, config, etc. and allowed me to develop 100% in Javascript/Typescript. I just wanted to get an app made as quickly as possible, so I didn't want to get bogged down in the nuances of Andriod/iOS programming. Plus, it was nice to stick with JS/TS, since I personally enjoy working with it.

• It has a better development experience than plain React Native. You can test the app on your phone without plugging it into your computer. You can build and publish in a more streamlined fashion. Even something like setting the app icon or splash screen is much easier to do in Expo than in pure React Native. Here's a video by Evan Bacon, one of Expo's maintainers, that does a great job highlighting the strengths of Expo: https://www.youtube.com/watch?v=YjJ0NG9MFkg

Alas, as with most upsides, they're packaged along with downsides. Expo has one glaring weakness: there is a wealth of libraries you can't use. Namely, libraries that use native code (I think Expo has a new feature called Expo Native Modules. I'm not sure if this fixes the problem entirely, so I'll have to check it out on my next mobile app project). I came to a point where I needed to install a library that had native code, and there was nothing in the Expo ecosystem that supported what I needed. The feature I needed was a timer that continued running even in the background, i.e. if the screen is off, the timer needed to continue counting down. Expo didn't have such a library, so I turned to react-native-background-timer. It was a difficult choice to make, since it's difficult to even consider parting with a such a useful tool. Ultimately, I decided to eject from Expo and into bare React Native.

Was it the right choice? Since I've ejected, I've installed many native libraries that have helped immensely. On the flipside, I had to work directly with Android/iOS code and config (which, admittedly, isn't as hard as I thought it would be, but is still an extra chore). Also, publishing to the Play Store is always a tedious task that Expo would have made easier.

What do you think? Have you ejected an app from Expo? Why, and do you wish you could go back? If you're still using Expo, do you think you'll stay in the managed workflow forever, or is there something that could push you to eject?

A few reasons I chose to build Bathtimer in React Native:

1. It's cross platform. At the moment, there's only an Android app, but it's very comforting that I can instantly product an iOS version when I'm ready. I would hate to rebuild everything from scratch and re-track all of the features, including those I forgot existed.

2. I enjoy Javascript. I know it's not everyone's favorite, so I'm lucky to have this tool.

There aren't only upsides to React Native. Two of its biggest criticisms is the slower performance and larger bundle size for apps built with it.

1. Performance. Bathtimer is a fairly small and simply app. There isn't anything computationally intense happening in the app, so I can take the performance hit without it becoming a huge concern.

2. Bundle size. This one kind of sucks. Bathtimer is ~33MB in the Play Store, and I know it could be <10MB (15MB, worst case estimate) if I built the app natively. I have to go back at some point and try to cut out as many unneeded packages, etc. This is admittedly a negative with using React Native.