New year, new tech stack
An update on the state of Ueno’s starter kit in 2019.
Starter Kit 1: The Phantom Menace
When I arrived at Ueno two years ago I got an introduction to all the different tools we were using and how to set up new projects. At that time we had a homemade starter kit based on React that was the entry point of each project.
That’s it. One command and we were ready to go. It was easy and fast to work with.
As we worked on client projects, we might improve some core files, like webpack configurations, and add new features. When a project was done, we would update the starter-kit with these changes, essentially using what we learned from each project to make the starter kit better.
Starter Kit 2: A New Hope
Still, maintaining the starter kit was hard. Every week a new update broke the build. So we decided to move on. We stopped using our old starter kit, and instead forked react-universally, a popular community-based project as a new starter kit. At that time it was actively maintained, and our own Birkir was one of the maintainers.
We modified it to include our own configurations, Sass files, BEM conventions, webpacks files, svg-loader, and a lot more. Setting up projects was faster than before and everything we needed was inside. We kept adding new features, and from time to time we would fetch updates from the upstream repository and merge into our starter-kit. We were happy.
But over time, maintenance on react-universally slowly ground to a halt: no more dependencies updates, no more bug fixes, no happy, no hope anymore.
We were still using our starter-kit on new projects, but our frustration with it grew.
- Build time was slow (omg so slow)
- Hot reloads were somewhat broken
- Dependencies were outdated
- Too many features by default
- Too heavy for small project (like a one-page website)
- Too many issues on small dependencies that were not fixed
At the end of some projects, an app could take 100 times longer* to build and deploy than at the beginning. (*Not the real number, just developers time feels).
We needed to do something. Our good old starter kit had become obsolete.
Starter Kit 3: The Revenge of the Starter Kit
We came to the conclusion that maintaining our old starter kit would actually take more time than building a new one (and it would still not be stable). So we went for a fresh start.
We decided to try out some new tools to see if they could handle our main requirements:
- SASS and CSS modules
- Root resolver (import
components/fooinstead of import../../components/foo) - Server-Side Rendering
- Code splitting
The React community really moves fast and a lot of tools popped up: Next.js, Gatsby, create-react-app, Preact, Razzle, and a thousand more. With these tools, creating client projects has now become faster and easier than ever. No more hassle of webpack config to handle by yourself, no more 20 folders in your root project, and everything fast to load and build. That sounds good, doesn’t it?
Gatsby
Gatsby generates static builds that you can deploy. It gives you a local folder with HTML, JavaScript and CSS files and you can simply run it on your machine or hosted server without any particular environment.
We like Gatsby because we work a lot on marketing websites, and in most cases, we only need to fetch content from a CMS, Prismic, for example, without any server side.
We forked gatsby-starter-default and added our default plugins and configurations to get ready to work fast. Take a look at the source on Ueno’s Github.
Next.js and create-react-app
Gatsby loads and builds fast. But when we need a custom server Gatsby isn’t enough. In those cases we’ll use Next.js, unless we only need a client-side app, in which case we’ll use create-react-app.
Take a look at Ueno’s Github for the source for Next.js and the source for create-react-app.
Both Next.js and create-react-app are great tools, but maintaining both of them is complicated, and there’s a lot of overlap in what they do. In the future we’ll probably only keep one of them, depending on how things go.
Code style
We’ve also changed a couple of things to make our code style more in line with modern React conventions.
TypeScript
First, we moved to TypeScript. It makes the development process faster and more fluid. We can quickly see what props a component will allow. It takes a bit of time to get used to, but when you start using it, you enjoy it a lot (at least in my opinion).
Named exports/imports
We moved from default to named exports/imports, for many good reasons. It’s also faster to build.
React Hooks (v16.8.x)
Hooks are a new addition in React that went live with react@16.8.0, letting you write a stateless function with states. Wow, awesome. In short, it makes bundle file smaller, build time faster, and components simpler.
Deployment tools
Heroku and Netlify
We have been using Heroku for a long time to deploy our apps in production and development pipelines. With Gatsby’s static builds, we no longer need Heroku’s server-side capabilities, so for static websites we use Netlify. For apps that are built with Next.js and create-react-app we’ll keep using Heroku.
Bootstrapping tool: create-ueno-app
We were missing only one thing: a way to very quickly create projects with one of our three stacks (Gatsby, Next.js and create-react-app).
So we decided to make create-ueno-app. It’s similar to create-react-app, but you can choose between using the three stacks, and even react-native. Behind the scenes, we have a common folder to bootstrap the same layout, devtools, Sass mixins, and grid. We clone it, install the dependencies, and voilà, you are ready to go.
You can read all about create-ueno-app on Github.
Testing the waters: our first project using the new setup
A few weeks ago, we celebrated Ueno’s fifth anniversary. Our old friend Tory Satins made a song and a video, and we devs built a site for it. With subtitles so everybody could sing along. (Watch Tory Satins sing.)
We used this little project to test our new create-ueno-app, Gatsby, and the new React Hooks.
To show you that we know how to code, we open-sourced the whole thing. Check out Tory Satins on Github.
We used React Hooks a lot on this project, to try and see how performant production-ready it was. It saved us a lot of time and allowed us to simplify a lot of code to avoid duplicating the same logic between multiple components.
We also did an example app using Prismic, a content management tool, and Next.js. Take a look on Ueno’s Github.
That’s all folks
So now you know everything: where we came from, where we are now, and how we arrived.
Here is the list of our new tools, with links to them on Ueno’s Github:
Jérémy Barbet is a French developer at Ueno in Reykjavík. When he’s not at the office he probably up in the mountains somewhere, taking photos of Iceland for you.
Want to work with Jérémy? Because Ueno is hiring.
Want more email? Because Ueno has a newsletter.
