Published on 2020-09-12
Over the last decade, I've been fortunate to spend the last 6 building UIs for web applications professionally. The ecosystem has evolved rapidly, and navigating it can be a minefield of outdated information, illusions like "best practices" (I don't think they exist), and unnecessary debates. Personally, I think the trade-off is worth it. The Web is hands-down the best platform for rapid UI development.
I generally work on teams that use React, but this article is intended to be framework agnostic. I commonly end up building (or contributing to) reusable component libraries within a company, so the advice on infra will only be useful if you do the same.
Nothing here is presented as fact, it's what I've personally found effective when building UIs in teams. I hope my future self reflects on any incorrect assertions I've made here :)
Once this post is 1 year old, a warning will show on this page indicating that information may be outdated.
It's important to understand that the Web is a series of hacks built on a series of hacks. Its current form is not what its founders had envisioned. Instead, it's become the most ubiquitous platform as a result of diverse ideas. The Web has expanded to cover an overwhelming amount of use cases.
Use this to your advantage. If you want to build something, someone has probably already done it before -- that means it's supported by the platform! If enough people do it, it'll likely become a standard part of the platform (remember implementing border radiuses before border-radius was in CSS?).
I find it effective to skim over lengthy documents, which plants metaphorical seeds in my brain. In the future, I may be tasked with implementing a feature that I haven't before. My hope is that I vaguely remember reading about something, and I can go back and look it up. There is comfort knowing what I don't know.
It's much better than the alternative, not knowing what I don't know.
Example: building a newspaper like text layout. In CSS, this is very easy to do, but depends on knowing that
columns exists. This property is really difficult to come across unless you've heard about it before.
To have this kind of intuition, I recommend:
This is a weird one. I don't like it when people to tell me, "go read the docs!" when I ask a question about software that I'm unfamiliar with. It's not a good way to learn new concepts. Specs are especially difficult because they are meant as documentation for browser vendors, not UI engineers. In order to not go insane, I suggest starting with the MDN docs for fundamental CSS properties, and following the links at the bottom to the relevant spec section.
One starting point: the docs for display. At the bottom, there's links to specs (usually W3C). If you click through, you may notice some confusing notation. Luckily, most specs have their own specs.
When reading through a spec, I open a new tab for any new links that sound interesting. I repeat this process until I'm exhausted, and hopefully I'll have a slightly crisper understanding of how a feature works. I'll also have learned some trivia that may be useful in the future.
with keyword, or how exactly the Temporal Dead Zone (TDZ) works, but knowing its existence helps me troubleshoot random things.
Native DOM APIs are quite powerful, and overlooking these causes unnecessary work. Most things in CSS are doable with 3 properties or less. When working with forms, HTML attributes are extremely powerful.
If you feel like you're writing hacks in CSS to achieve basic functionality, ask yourself if there's a better way. There usually is. If you can drop IE11 support, this is especially true. CSS is really big, so focus on finding your own personal workflow. It will become much easier. There's a lot of things that I rarely use in CSS anymore:
Things that I always do when starting a new project:
box-sizing: border-box;globally. I like Eric Meyer's reset.
Infra means learning the right tools for the job, but also mistakes that you may inherit from previous engineers. These mistakes may not have been apparent during the initial implementation, so it's rarely the fault of the original implementer; just a by-product of a fast-moving ecosystem.
There's massive mind-maps out there depicting what a front-end engineer "should" know in order to be effective. I'm not a fan of these. Here is my toolkit for building out web infrastructure. There are three major components:
You should adjust it to your preferences.
Infra moves really fast, and new tools are easy to miss. My recommendation is to check a few resources every now and then. Here are a few that I like:
You may also find interesting open source projects, which can be interesting to review.
Personally, I find the chat-based communities distracting. They're much more difficult to search, and they're flooded with low-effort questions that often cause people to ignore your questions, even if they're well-formed. Your mileage may vary.
My preferred combination of tools for the past 3 years has been: Webpack, Babel, ESLint, Jest, PostCSS, and CSS Modules. The first 3 tools are all only as useful as their configurations, which means you need to learn the basics to be effective.
I wanted to point to specific repos because the ecosystem is quite overwhelming. It's likely that this information will go out-of-date, please keep that in mind if you're reading this from the future.
If you're just starting a project, the main webpack documentation is reasonable. You set up a few entry points, define some outputs, and you're good to go. I explicitly configure loaders for:
tschere. Microsoft is collaborating with the Babel team to work on this plugin.
css-loaderresolves CSS imports inside your CSS files. It allows CSS
urldeclarations to be recognized by Webpack. Without this, imports won't work properly as webpack mangles URLs when combining/splitting modules.
style-loaderinjects CSS as style tags. This is great when using fast-refresh, it allows it to work seamlessly under the hood.
postcss-loaderallows you to apply complex transformations that will deliver a better user experience. For example, you can apply autoprefixer, postcss-flexbugs-fixes, and even extend CSS by using postcss-preset-env.
.otf/: file-loader. I might have missed a few file extensions here; any binary files like images and font files apply here.
.svg: Any svg-loader that's relevant to the framework you're using. For React, I use svg-react-loader.
Once you've got a baseline set up, you can explore things like code-splitting, etc. I recommend getting fast-refresh working right away with all of your different modules (such as React, Redux, CSS Modules).
Another good way to learn webpack is to use a scaffolding tool. For example, you can eject from create-react-app, inspect the webpack config, and try and learn what each line does.
I start with babel-preset-env, and babel-preset-react. I find myself occasionally wanting to write a Babel plugin. The most common case is resolving circular imports transparently. If you have a root file that simply re-exports a bunch of other imports, you don't want people to accidentally import files from here (this is very easy to do on accident when using auto-completion).
The advantage of writing your own plugin is that it can be customized for future optimizations. Once you get the hang of it, writing Babel plugins isn't too bad. You can usually find someone else's open-source work and fork it.
One caveat: Writing a Babel plugin utilizing newer TypeScript or ESLint features is not a great experience. These are often not adopted by parsers right away, so be prepared to submit a PR.
ESLint is the most subjective of the bunch. I've significantly reduced my dependency on ESLint in the past few years. I mostly use it for custom lint rules. I use Prettier instead to resolve any style issues, and the TypeScript compiler to catch any errors (like undefined variables) but I generally do a few things right away:
I mainly use ESLint when I need to enforce new patterns. For example, if we want to disallow importing a certain module when writing new components, a lint rule can be written for this.
For Babel and ESLint, a basic understanding of the AST is necessary. You can copy-paste some code into AST explorer, and click through the data structure to get a basic grasp on how code is tokenized. I've written some compiler at every job, so I've found it useful to explore this a bit more.
At the time of writing, I primarily use React, but I've also had great experiences with Vue. Both ecosystems are vibrant and there are tons of npm packages for both. I like experimenting with less popular frameworks in smaller projects. If you're looking to do the same, I'd recommend checking out Svelte, Crank.js, Mithril.
For websites (not web applications), I typically use Next.js. For sites that don't benefit from server-side rendering, such as this site, I use Gatsby.
If I want full control over the entire stack, my go-to tools are: Node.js, Express, PostgreSQL, and React.
If I want to build a product while learning something new, I limit myself to adding only one "new" thing. Currently, I'm experimenting with Deno, Rust, and Phoenix, but I wouldn't push these on a team yet. I would spend too much time debugging basic issues instead of building the product.
Catching errors early has been critical to my productivity. However, it requires adding infrastructure which takes time, effort, and resources to maintain. If you have infinite resources, then you should tackle all of these problems! If not, choose your battles.
I always seek to have some process involved in each of these phases:
Getting feedback while you're editing a module catches silly mistakes before they cascade into bad design choices. For example, you may not realize that you're passing null to a function that doesn't handle null properly; using TypeScript helps with this. At a simpler level, you may simply have a typo in your exports. ESLint can catch this, but TypeScript does an even better job.
Tests warn engineers when they change to the component. An example workflow for updating a module:
Tests (except for end-to-end tests) are generally run in simulated environments, so complex maneuvers. To avoid this, stick to your tools avoid mocking (as much as possible). Jest utilizes JSDOM, which supports operations that don't depend on layout calculations. Tools like testing-library make you to write tests from a user perspective, so you're less tempted to mock modules.
When communicating with third-party APIs, it's difficult to test locally. This is a use case for mocking, but mocking doesn't give you confidence that your user-facing application is running properly.
Instead, you can run tests before code makes it to production. You may opt for a staging environment, or a canary strategy; it doesn't really matter.
At run-time we can catch errors, but ideally this is just to catch bugs. I use Sentry for most projects, it's fairly straightforward and can be self-hosted if needed.
Writing code is a large part of the process, but debugging is also another part. Tools like react-refresh make a great developer experience. You can manually verify whether your changes worked or not. I've found that the most worthwhile investment is DevTools, as it's part of every web project you'll work on. Learn how to use it effectively in another blog post.