Frameworks don't magically make your code good
Why using the latest cool stacks doesn’t (always) mean you’re going to write better code
Since the beginning of this decade, Front End web frameworks have dramatically changed the way we build applications, with both pros and cons.
Since the time I read the todos example on the old Angular website, I have been ever since a huge fan, as you may know if you read some of my previous articles.
I loved everything about it: custom elements, routing, services, pipes/filters, and so on. Everything started to be more fun to work with and made more and more sense.
And the more I loved these tools, the more elitist I became. And looking back, I am certainly not proud of myself.
While I feel I got past these feelings in the last few years, I can see the same thing happening every day at places where I have worked, and obviously to an even greater extent online on websites such as Github, Reddit, chats, etc.
Tech elitism is bad
It really is.
What do I mean by that? To me, Tech elitism is the feeling of an individual to look down on stacks he doesn’t know or doesn’t like and basing their opinion on that and only that.
Type caption for image (optional)
A tech elitist will:
- laugh at you for using Angular instead of Vue, or for using React instead of Inferno (or vice-versa).
- judge your choice for (still!) testing with Jasmine rather than Jest, Protractor instead of Cypress
- complain about you using semicolons (shame!)
- … generally, look you down as a developer without knowing what code you work with and what your product does
… but web frameworks are great, right?
Yeah! As I said, I’m a huge fan too.
Despite the controversial Javascript Fatigue, it’s undeniable that the newest tooling available brings awesome features and functionalities that we love.
Yes, frameworks provide:
- tooling for reusing code like never before
- better testing options
- a vast amount of third-party libraries
But… it’s important to remember that frameworks provide only a part of the many lines of code that make up a project.
I have seen React projects coded way worse than some using jQuery. Or Angular 1.x projects written way better than others using the latest Angular.
Why?
That’s probably because the developers who wrote the project were just not as good at architecting and designing large, complex codebases.
They weren’t using:
- design patterns
- tests, of any sort
- code reviews
- … just basic software engineering practices
That, frameworks cannot teach you. They help a lot, they provide guidance, and examples, but only so much. Large-scale projects need more thinking than that — and it’s not an easy task.
Some of us think that by just using the latest piece of tech, we are spared from thinking, and architecting, and designing every keystroke. But, as it turns out, that’s wrong.
What are the things that really matter?
I am not ashamed to say that I would not pick up an old project nowadays if I wasn’t sure that a plan was in place to move forward with newer technologies.
But other than the stack used at a company, I nowadays have a larger set of questions for prospective employees or people I meet networking:
- do you write tests? unit, functional, end-to-end tests? how important is that to you?
- what design patterns do you use? [please don’t say you use none, PLEASE]
- what’s your pipeline like?
- how do you do Agile?
- how much legacy code do you have? what plan is in place to fix that?
- do you contribute to open source at all?
- what are code reviews like?
- what’s the business strategy?
Is your cool stack accompanied by decent software engineering practices?
Do you care at all about it?
