We asked web builders that we admire the same question: What is one thing you learned about building websites this year?
Here’s what they told us.
We would like to thank our ❥ sponsor Automattic for making this site possible. They make many great software products that we use, like Jetpack, WooCommerce, and WordPress.com.
In our wide world of building for the web, we have every opportunity to talk about tools. We lunge to fill every gap we find in our projects with a definitive technological approach. Some of us are given “a seat at the table” feasting on even the most minuscule of technological debates. This marketplace of opinion is founded upon a desire to arrive, at least for the moment, at an optimum. We postulate about tooling so that we might achieve efficiency, extend our exploratory reach, or pave the quickest path to viability.
If you have read anything on this website, you are likely more than aware of the notion of Imposter Syndrome—the debilitating reflection that you do not deserve to be in the position you hold or know what you think you should know. Those of us that have learned to deal with Imposter Syndrome are at risk of slipping into (what I recognize in myself as) Relevance Syndrome—a mid-career complication of Imposter Syndrome. It is what happens when you spend years repeating the mantra, “I deserve to be here,” but have never truly accepted its premise. It happens when you attempt to counteract the softening of your hard skills and end up hardening your soft ones. Maintaining relevance sure is a great reason to opine about tooling.
With that, I will casually lean against this brick wall, slide my shades to the tip of my oh-so-relevant nose, and dismissively mention that yes, I too, have learned TypeScript. One year into the experience, and I can say that I have grown quite fond of it.
I’d like to use TypeScript’s purpose to make a separate point, so if you will, please bear with me through this quick example.
TypeScript, among other things, enforces the types of things you send around. Take this JavaScript function that multiplies two numbers:
Imagine you broke your rules by calling this function without numeric arguments like, product('A', 'B'). There are many ways you could validate this function to catch this scenario, but your validation would only occur at the time of execution—while the script is running, often in a browser. You can’t really debug this until those events occur. What TypeScript can do is tell you that you are breaking the rules before execution — as you are writing your code. To do this, you state which types of things you are using.
Here, we specify types for the two arguments, saying that variable x and y are both a number. Now, if you were to use this function with the wrong types of arguments, your application script would loudly fail to build. Because your script must work before it can be built, you never need to worry about these sorts of errors ever occurring in the wild. It takes a lot of effort to achieve this, however. You must define your types, everywhere.
You may find writing TypeScript types to be like organizing a bookshelf. You set some rules that, when followed, achieve an optimal organization that is easily-referenced.
Or, you may find writing TypeScript types to be like forcing your child into extracurricular activities against their will. It is rigidly unforgiving and doesn’t let your code figure out who it is and where it is going! You’re stunting its development by imposing your will upon it!
I’d like to think there is as much capacity for value in a well-organized bookshelf as there is for ingenuity in an independent spirit, and there is so much to learn from both.
Let’s end with considering relevance again.
You may feel pressure to know what you are doing before you do it—to type yourself before your code executes. You may feel pressure to account for all your failures and learnings before you give it a go in public. That, my friends, is an immense effort you have taken on to maintain your type. It is a pressure and rigidity that, at times, is great to put upon our software, but is unfair to apply to yourself or others.
We all have our "1" + "1" = "11" moments. They are relevant and entirely human, if not a form of genius. Embrace them. To strictly prevent them is unscalable.
I feel in this moment that I may have learned how to learn TypeScript this year, and hope to hold on loosely to whatever type that makes me.
Frontend Masters has a comprehensive course on TypeScript 3 from Mike North, one of LinkedIn’s deepest TypeScript experts.
You may write comments in Markdown thanks to Jetpack Markdown. This is the best way to post any code, inline like `<div>this</div>` or multiline blocks within triple backtick fences (“`) with double new lines before and after. All comments are held for moderation. Be helpful and kind and yours will be published no problem.
The related posts above were algorithmically generated and displayed here without any load on my server at all, thanks to Jetpack.
CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. The tech stack for this site is fairly boring. That’s a good thing! I’ve used WordPress since day one all the way up to v17, a decision I’m very happy with. I also leverage Jetpack for extra functionality and Local for local development.
*May or may not contain any actual “CSS” or “Tricks”.
CodePen is a place to experiment, debug, and show off your HTML, CSS, and JavaScript creations.
CSS-Tricks is hosted by Flywheel, the best WordPress hosting in the business, with a local development tool to match.
ShopTalk is a podcast all about front-end web design and development.