The new things, the right things, and developer entertainment
📅 Sunday, September 1st 2019
⏱ 4 minutes read
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? LOL" 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.
- (Some reasonable person) The contact form is slow. Actually, the whole thing feels a bit laggy.
- (Us) At least it's not using jQuery. We have Redux, colorful logging, the ability to time-travel and restore any state.
- (Some reasonable person) Right..
Disclaimer, Redux is awesome. The tool isn't at fault if our implementation was bad.
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..
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.
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.