70 %
Chris Biscardi

Working Faster

When building a startup (or similar new product) it is useful to be able to get as much done as possible. These are some of my current preferred starting points for new services.


Create React App

Create React App is the canonical starting point for a new React application. It comes with a great set of defaults and a handy user guide. For me, this is the default starting point for any new web application. Later on you can eject from Create React App if your needs aren't sufficiently met or use the react-app-rewired scripts which have saved me from ejecting recently.

Preact CLI

Fro applications that need a more central focus on performance and how heavy their JS bundles are, Preact CLI is the right choice. It comes with a useful auto-generated Service Worker setup, employs the PRPL pattern, and makes your starting bundle size a low 4.5kb.


Backpack is a minimalistic build system for Node.js projects. It is built on Webpack and Babel and gives you the ability to override any configuration you want. It is, in effect, a good starting point for building and iterating on a modern node.js service. The developer experience is similar to Create React App.


Most people don't need Universal apps but when you do, there's Razzle.

Create server-rendered universal JavaScript applications with no configuration

Compared to something like Next.js, Razzle gives you control over the core of your app. You don't need special techniques to integrate with Apollo, for example.

Razzle starts you off with universal hot module reloading and an app built on

  • react
  • react-dom
  • react-router-dom
  • express

You can then add on Apollo, Emotion, or whatever technologies you want.


Nothing is quite as productive as CSS-in-JS for me. Emotion is my preferred library as it includes the set of major CSS-in-JS APIs (styled, css, and the css prop).

For larger concerns (such as building and maintaining design systems), the CSS-in-JS ecosystem has no equal. styled-system, theming, and styled-theming allow you to turn a JSON spec for a design system into a fully functioning React component library implementation.

Data for UIs

GraphQL is the only approach for UI data in my mind. Using REST forces you into a number of different client-side solutions that waste time with a lot of setup and complicated team-based scaling issues.


I base my GraphQL servers on the canonical GraphQL implementation graphql-js by using apollo-server, graphql-tools, and dataloader. I am looking forward to seeing how the ecosystem around GraphQL servers shapes up, especially with the Elixir and Go ecosystems. For now, JavaScript is still the best bet for me since there is a lot of development happening in the JS libraries first.

Also useful is optics, a monitoring product for GraphQL servers.


Apollo Client is the most flexible GraphQL client I know of and progressing as a rapid pace. When using Apollo with React, the react-apollo package makes querying and mutating data easy (especially compared to the ceremony required to use REST APIs).


Go gets it's own section because I am amazed at how useful the community of packages is. I ported an entire Haskell service in about two hours (mostly because I was writing libs that didn't exist for the Haskell service and they came free with Go). There are useful libs for routing, configuration, postgres, SQL, CLIs, kafka, and more (including awesome stuff like honeycomb).


Get rid of any style debates and use tools like prettier and gofmt.

For prettier, I use a precommit hook powered by lint-staged and husky as well as editor support.

For go, check out gometalinter

Native Apps

I haven't had a good experience with create-react-native-app because I tend to use react-native link a fair bit, but luckily react-native comes with its own cli that includes new project scaffolding. I prefer this solution especially for apps I intend to make cross platform and don't need a lot of custom native code and layout (which is pretty much all of the apps I build).