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 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.
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
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.
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
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).