Web development is a field that moves fast. Real fast. The tools you learned three years ago are not the community favorites anymore. "Are people still using X?" is common to read on Twitter or Reddit tech discussions.
So the question is, when should one adopt a new piece of technology? This can be a new framework, build tool or utility library.
(Of course, the answer is not "the Twitter thought leaders said so")
My first experience with Redux was in one of my previous jobs. It was hyped, the library everyone was using in the React ecosystem. The first thing in "Bonus points for.." in lots of job applications. So we had to include it somehow - try it out. We couldn't fall behind.
But we didn't have any need for it in the project! Hell, the contact form didn't even have to use React, let alone
redux-form. The majority of the data would be obsolete after a few minutes, but we would put them in the store nevertheless.
Abstracting, discussing folder structure and writing these careful-not-to-mutate snippets. We were on the bleeding edge. Everything was as it should - web dev done right!
The reality was somewhat different. We were contributing to the problem. Bloating the web, overengineering, and adopting blindly the flavor of the month.
We focused on the wrong priorities, tried the new tool and not the right one.
🙎♀️: The contact form is slow. Actually, the whole thing feels a bit laggy.
👨💻: At least it's not using jQuery. We have Redux, colorful logging, the ability to time-travel and restore any state.
Disclaimer, Redux is awesome. The tool isn't at fault if our implementation was bad.
- Had a clear idea which was the breaking point that we had to adopt this library.
- Had fully understood what we sacrifice and gain by adopting it
- Remembered we're working on a project, and not a Redux showcase
Knowing what is floating in the ecosystem is mandatory. There's no way around that.
This doesn't mean that every 30k started library should find a place in our projects.
It's good to know which problem it tackles and how its approach makes people buzzing, but we shouldn't make up problems just for our entertainment. Positive procrastination is still procrastination.
Having a CI build fail because an import was not in order is just lovely <3
Take for instance the landing page of balena. People were quite surprised that I didn't use Typescript.
...But why? Why would we need type checking, when it's essentially a collection of presentational components glued together? There are some asynchronous calls and calculations, but still, it's a marketing website. The data flow is minimum.
Our dashboard on the other hand, does quite a lot of stuff, and Typescript helps us add features and refactor with confidence.
The right tool for the right job.
I sat down and tried to decide if learning Svelte is worth it or not.
For the record it's super interesting but..
- My company isn't using it
- My company is investing in React instead and has its UI library built with it.
- I enjoy working with React
- I don't have the time to study Svelte
- If I had I would rather be playing Warcraft Classic
- I have spent time learning Vue before and I don't use it anymore.
So I don't need to dive in Svelte. It's a great tool that I'm now aware of, but I won't make any money out of it at the moment.
And there's nothing wrong saying that out loud.
I love bullet lists so I'm going to use them again.
- The focus should always be on user experience
- The users should never receive a playground app
- Libraries are just tools. Overthinking it just creates problems (Framework flame wars for instance)
- It's ok to be a late adopter
- It's ok to never adopt something new if legacy pays the bills. Better yet scarcity should drive the prices up.
- Web developers are entitled and these golden days won't last long. Create something valuable.
When it makes sense really. When there is a clear breaking point that forces your hand.
But If you're styding something "just in case", it's probably not worth it. Your time is precious.