I love the fresh feeling of setting up a brand-new development project from scratch. But beware… some of the decisions you make now are going to affect your execution and deliverables down the line.
Here are a few tips for choosing the best toolchain for the job. Explore your options and wisely pick the most suitable toolchain.
About this story
As many developers learned the hard way, there are some important questions one must answer before writing even the first line of code. My two rules of thumb are:
You should never set up a project from scratch! There are many aspects you need to integrate, like bundler, transpiler, linting, prettier, deployment, storybook and more. The community provides tons of boilerplates, tools, or templates that help you create new projects.
When looking for resources to assist in setting up the project, finding the right one is crucial because a poor choice will limit your options and might even block features just because the bundler/transpiler/you-name-it doesn’t play nicely with whatever you might need in the future.
This is a checklist of questions one should review when starting new frontend project:
- Which frontend framework to use?
- Which UI kit to use?
- Should I use Typescript or pure Javascript?
- Which browser matrix to support?
- Which ECMA version to target?
- Which transpiler to use?
- What about polyfills?
- Do I need monorepo?
- Is a design System warrant to the project?
- Should I use a live development environment?
- How about state management?
- How about theme & styles?
- Which testing frameworks to use?
- What about documentation?
UI framework
1. Which frontend framework to use?
Which frontend framework to use: Angular, React, Vue, or Preact?
For mobile native applications, you should google “javascript native application” and look for frameworks like React Native.
Preact is useful if you extend existing pages with very strict bundle limitations.
For web/mobile applications, it is a matter of preference.
I think Angular X is a great platform. It provides a comprehensive solution starting with strong DevOps tools, an opinionated technology stack that gets updates at the same time across almost all libraries, Typescript support out-of-the-box and great frontend architecture. Also, as it is very opinionated, it allows the framework to optimize many aspects and make them performant just because they can expect how it will be used.
With that being said, my heart belongs to React. Its ecosystem is amazing. I love the fact that you write Javascript/Typescript, not a made-up language as Angular does. It is flexible, it provides a beautiful components architecture, it is extremely popular, and it is fun to work with.
You probably read somewhere that comparing React to Angular is like comparing apples to oranges, as React is a library and Angular is a framework. To bypass this obstacle, when you are asked about React, say that you refer to React as a stack of libraries (React, Redux and others).
2. Which UI kit to use?
When creating a new project, you should check with the UX team (assuming you have one) and find out what are they planning for this project:
- Is this project based on material design principles? If so, you should use an existing UI kit that follows those principles like Material UI.
- Are they OK with adapting an existing UI kit to save development time or to match a rough deadline? If so, you should consider using existing UI kits like PrimeFaces or AntDesign directly in your application. Your top priority at this point is to get buy-in from the UX and Product teams since their style guides and blueprints are going to be implemented using the chosen UI kit. It is important to communicate that every customization must be tested first against the library. If that customization is deemed impossible, the UX professionals will need to live without it.
- Are they going to provide their UI components and expect the result to be pixel perfect? If so, you should consider creating your UI kit. Feel free to write it from scratch but be warned that it is going to be a tedious adventure. If you have more than a few basic components, consider basing your UI kit on another library, creating your components with your public API, and using “under the hood” components of the existing one.
Development language
3. Should I use Typescript or pure Javascript?
Are you going to use Typescript or a pure javascript? If you consider using pure javascript — I encourage you to think twice. You should use Typescript and enjoy its better tool support, (optional) typing, and powerful ecosystem. It’ll be worth the learning curve, and your future self will thank you.
4. Which browser matrix to support?
Which browser matrix should be supported? Can you politely ignore IE11? Will your application be served as a mobile web app?
Developers tend to develop into chrome only and let the QA test the rest of the browsers. I advise you to use services like BrowserStack that let you test on real devices remotely.
5. Which ECMA version to target?
Decide on the target ECMA version to be used based on the browser matrix. Don’t choose anything below ES2015. If you are required to support IE11, which is ECMA 5, you will use transpilers and polyfills to complete the missing support.
6. Which transpiler to use?
Decide if a transpiler is needed based on the selected ECMA version. For example, IE11 is using ECMA5, which is a big no-no.
If you are using Typescript, you can use it as a transpiler. Babel is another very popular choice that also supports typescript files. I suggest you leave this decision to the toolchain/boilerplate you will use.
7. What about polyfills?
Choose the library to load polyfills. This is needed only if the browser matrix doesn’t match the EMCA version you decided to work with.
Both Babel and Typescript let you set the target ECMA version. The transpiler will make sure your transpiled code is compatible, but you will need polyfills to add missing support at runtime.
Development strategies
8. Do I need monorepo?
This section is not relevant for Angular developers, since the Angular CLI creates monorepo workspace by default.
In general, if you ask people for advice, they will probably encourage you to use monorepo, as this is quite a popular choice these days. The following story is the only one I’m familiar with that goes against this advice.
https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b
It might interest you to read the story and its comments. To state one of them: "… Monorepo doesn’t necessarily mean one repo for an entire company. It could mean one repo for a related set of services and applications …"
Anyway, this topic is too complicated to try to tackle in a few paragraphs. I will assume for now that you already know if you should use monorepo. If you do plan to use a monorepo strategy, you will need to choose a library to manage the DevOps part of the monorepo, like OAO, Bolt, Meta, RushJS, or tsdx.
My current preference is Lerna and NRWL. Lerna is a very popular choice. NRWL has gained popularity since it deployed version 8, which supports many frameworks beside Angular. NRWL is a very opinionated framework that is also its strengths and its weaknesses. You should try each to figure out which works better for you.
9. Is a Design System warrant to the project?
Let’s start with the definition of a design system, taken from the article “Everything you need to know about Design Systems”: "A Design System is the single source of truth which groups all the elements that will allow the teams to design, realize and develop a product."
If you are not sure that you need a design system, you probably don’t need it. If you do need a design system, you should have a dedicated repository for the design system.
The purpose of a design system is to serve multiple applications, so don’t host it in your application repository, even if it is going to be used there only at the beginning.
Once you have a dedicated design system repository, your next task is to decide how you want to develop and test your components. You can already guess that I’m going to recommend Storybook for that purpose. For further information, read Introducing Storybook Design System and continue to the next question.
10. Should I use a live development environment?
This is not a question, as you should use live development environments like Storybook or Styleguidist.
I recommend you read and adapt a component-first approach. Start by creating a repository and add Storybook. If you are not familiar with Storybook, go on and read their documentation. Don’t forget to register the knobs addon, as it will allow you to edit the props dynamically. You will probably stumble with integration issues while trying to set-up the Storybook with all the libraries you chose. Don’t worry. It happens to everyone and will hold you back for a while, but it is worth the effort.
Implementation design decisions
11. How about state management?
This is a tough question to answer, as it heavily depends on the frontend framework being used. I decided to keep this question just because it is something you should pay attention to.
If you are Angular-ist, you can choose between observable data services and ngrx store.
If you are React-ist, you can choose between redux and hooks+context. For those who always use Redux, I recommend you read You Might Not Need Redux. Redux is extremely powerful state management, but in many common use cases, the new hooks and context features will be enough.
12. How about theme & styles?
Themeing is tied directly to the UI kit you are using. You should read their documentation to learn how to customize it to your needs. If you are creating your UI kit, you should provide your theme support. If you are a React-ist, consider using react-jss.
Styles is a bit more verbose. You should decide between using pure CSS, LESS, SCSS, and CSS-in-JSS. Many UI kits provide their support. Material-UI has great support as an example, yet I wouldn’t recommend Material-UI if you are not following the material design principles.
My current preference is using css-in-jss methodology. The following story covers nine different methodologies. Four of them are based on css-in-jss. Also, consider reading this story.
13. Which testing frameworks to use?
This is a no-brainer since no matter which CLI tool or boilerplate template you will choose, it will come with one (if not many) testing frameworks.
If you accidentally choose a tool that doesn’t come with a specific testing framework, consider the popular library named Jest for unit-testing.
14. What about documentation?
Most developers like to avoid documenting their project. They sleep well at night when they add some developer comments here and there. Some might even integrate linting rules to enforce documenting the sources without ensuring it is worth it.
A good documentation approach is one that results in a static document side generated automatically from your comments. Otherwise, they miss out on creating an awesome experience for the developers.
You can use a live development environment with some add-ons like Storybook or Styleguidist or try some other popular frameworks like Docz and Docsify.
Based on my personal experience, you should consider Storybook v.5.2.0 or above, which allows you to reuse your stories and create a professional-looking documentation site.
The following article provides useful information: https://blog.hichroma.com/storybook-vs-styleguidist-2bd93d6dcc06
Let’s recap
Setting up a new project is interesting yet extremely challenging work. Decisions you make at this phase will affect your project for its entire life cycle. You should do your homework before you set up your new project.
I will publish more stories soon that tackle concrete issues, like setting up a monorepo using Lerna, automatic deployment of libraries to NPM, setting up Storybook correctly, leveraging Github’s new CircleCI service, integrating UI libraries like ant design, creating a design system and more.
Happy DevOps-ing!
Eran.
Thank you to Itai Rolnick for your feedback.
Cover photo by Lauren Mancke on Unsplash.
This post was originally published at medium and in my new personal blog sakalim.com
Top comments (0)