This article was originally published to my newsletter.
There is a common joke in the JavaScript community that a new framework or library gets released every single day. True or not, it's funny because it definitely seems like that is the case. With so many new things to learn, how can you possibly keep up? Or should you?
Learn patience, not a new framework ⏳
I love keeping up with the latest technologies. In fact, I built a site called DevNews a few years ago in which I still use today for finding new tech and software related articles and products.
However, there is a big difference between reading up about a new framework versus actually investing time to learning and potentially even migrating your current code over to it. A lot of the time, it's not worth it because that framework becomes obsolete or even non-existent in a few years.
I've been bitten by this problem many times in the past, and the best advice that I can give is to simply be patient.
For any big projects that you expect to stay around for at least 5 years, you probably want to observe a framework's community long enough before making the decision to learn and use it. Consider the time that you put in to learning a specific framework or tool to be an investment. That return on investment should be a positive one.
The story of AngularJS and React ⚔️
Do you remember AngularJS? Many developers were using it around 5 years ago, and it was deemed the go-to framework for making a dynamic website or entire web app. It was even backed by Google, so what could go wrong?
Angular 2 was announced and it was completely different from the first version. In fact, backwards compatibility was not an available option early on. Thus the usage of React, a competing option from Facebook, grew.
I personally worked on an AngularJS project, but I never invested into it deeply. I was skeptical and continued to build my own projects the traditional way (a monolithic Laravel backend with a jQuery and Bootstrap frontend). Fast forward and I am now building multiple React apps.
I believe that this is the correct approach. Use the tools and technologies that work well for you until you know for sure that there is a better way.
Cool cool... but how do I know when there is a better way?
— Avid DEV reader
Ah, I'm glad you asked. I did an entire podcast episode about this topic! While I talk about React specifically, the principles (community, efficiency, and longevity) apply to any framework or tool. Recommend you check it out 👇
In general, a large community size means more resources available to you for debugging issues and finding accompanying libraries. Even in the case of Angular, there are still tons of resources out there to continue maintaining those projects.
Question: How do you manage to stay on top of technical debt, or how have you been bitten by it in the past?
Oldest comments (35)
I think to be slow and focusing on your fundamentals is more important than just picking up another framework.
Like for me GraphQL and Web assembly are great but I will just play around till I know this is good to switch over or till there are not enough developers for it which makes it expensive to maintain.
Yep exactly. There is some stigma between developers to constantly stay up to date, but that doesn't mean you have to implement every framework that gets released daily into your project.
REST APIs will stay around for a long time and is still a safer choice. I do love me some GraphQL though, depends on the project.
I really love this article and insight. When I first started on my engineering journey, someone told me don't be invested in frameworks, they are forever changing. Know the fundamentals, everything else you can learn on the fly or even on the job. Not saying, you can't learn programming languages on the job as well, but it's a lot easier transition if you know the fundamentals and you're just coming behind learning the frameworks at your particular place of employment. That's why I don't really like companies that insist on hiring only Angular or React developers, as if JavaScript isn't the fundamental language behind it.
Thank you Donita! I agree, fundamentals are way more important than knowing the trendiest framework.
As a young developer, I always get caught up in wanting to learn the next new thing without really knowing the fundamentals. This was a great wake-up call for me to stay focused and to be good at what I know. Thank you for your insight!
Super happy to hear that Miguel!
Sometimes it is also important to avoid grass is always greener syndrom.
It is not a technical debt just because you aren't on the latest hottest framework. It is technical debt when you didn't design your software well.
The reason that front end code change often is because, where every few years, the management or market pressure to need to do redesign, in which case, often times you have to rewrite the front end, since design changes will change all the code anyways. So front end frameworks changes often.
But for backend it is less change often. I remember I went to a startup meet up, and each startup talked about their tech stack, their front end may be refreshened, but their backend is almost always the hottest "framework" around the time they started. For example, companies that started in 2006 to 2010 tends to be ruby on rails, before that Php, after that, a lot of Node.js, etc.
Learn all the things (that you want to learn).
I suggest people play with new frameworks, new tech, new languages.
Learn them, learn FROM them, make yourself overall better.
But that doesn't mean you have to shift your entire life over to them, refactor everything, and destroy productivity. And balance this with your life of course.
Don't get stuck in analysis paralysis on what to do next. Go with your gut. Learn, adapt, move on. Your cumulative knowledge will grow and you'll be a better developer/engineer/sysadmin/etc.
It's always worthwhile tinkering with a new framework when it appears. It'll help give a good feel for what it's good at, the problems you'll encounter with it, and when to use it.
However, the decision to use a particular framework for a non-trivial application should be made carefully. I'd never choose a framework I had little or no experience with for anything other than a small application, because you simply don't have enough information to decide if it's a good fit. For something small it won't matter, but for a large application you'll be maintaining for a while it will matter.
I think there's no magical trick, it's the sum of all your experiences as a developer which guides your decisions. I have had to learn the hard way on this very issue. Fortunately, I had an architect at a previous job who suspicious of all new technologies (iirc he had a very successful startup and framework hype led to a major refactoring which brought the company down), and it really pissed me off at first when he told me that he didn't want any of this "crap" in our codebase. We both definitely could have communicated more neutrally on the topic, but in the end, he was right. Many of the libraries I wanted to use are no longer maintained. Sometimes I had absolutely no reason to pull in a tool, it was just shiny. I think NPM has made us all a lot more aware of dependency hell, although I don't think it's causing us to question our actions as much as it should.
Nowadays, I just pick things up that are intuitive to me. I really like functional programming, it seems very logical and it just clicks with my brain. It took me several years to get to he point where it licked; at first I was doing it because a lot of programmers I respected were dong it, and I wanted to follow in their footsteps. Eventually, I realized that I had slowly picked up enough over time that I was naturally coding according to FP principles without even having to think about it. Therefore, a lot of technologies that adapt FP concepts click with me and I am drawn to them.
While there are realistic questions that need to be considered with new technologies (the community aspect you mentioned probably the biggest one), you also have to remember to f*** all the haters. There's always going to be someone out there on the Internet waiting for a chance to crap all over your preferred technology. If it works for you, it works and that's all the evidence you need. I can't blame them for doing so, I have to admit that sometimes being a judgmental snob can feel pretty self-satisfying in the moment. At these moments, I have to jump back to my experiences with these individuals over the years and remember to keep an open mind. Not everyone does things the way I prefer them to be done, yet the sun still rises every morning and the Earth keeps spinning.
100% agree with you Scott, well said! Experience is a huge factor in this because I learned a lot of these principles and the ones you mentioned from dealing with problems in past codebases.
And yeah, ignore the haters and definitely don't be one of them. Use what feels best to you and respect others' decisions.
“In fact, backwards compatibility was not even a consideration ” is not 100% accurate. NgUpgrade is a thing. There is at least one book about upgrading from AngularJS to Angular. Backwards compatibility wasn’t possible because of security holes in AngularJS which they took seriously at Google. But the Angular team at least provided a bridge for upgrading from AngularJS to Angular.
I will make an update to the article to address this. Sorry for the misinformation!
Agree, I made the same experience with a project that was migrated from JQuery to AngularJS and was updated to Angular just one year later, the ROI was super negative. And I face this problem everyday with older projects that use old tech-stacks. People always discuss about new technology, but in many cases it does not really make sense to migrate, especially if client does not care.
I myself used Vanilla JS for years because I did not like JQuery. I skipped Angular, tried React but did not really like and now I use Vue. So my receipe is:
First React is not a framework its just a library unlike what Angular is. Angular is a complete framework with routing, material and other built in features. I like react but for small projects but for large projects I prefer Angular than React. Great insight but lack on research. Angular is better than react. Please see the new updates on Angular and you will be astonish on how Angular came to be.
I'm aware it's a UI library. I use the term loosely as many in the industry do because of the way real world apps are built with React Router, Redux, etc. Plus all of this is moot as semantics of what is considered a framework or library isn't the focus of the article.
I respect your opinion and I love what Angular, Vue.js, Ember, and other frameworks are doing. Framework choice is not a war and again goes against the point of the article.
I guess I'll take a compliment where I can get it.
I've found that react only folks are the ones that love this library argument. But all that matters is load time and render time. Load times with lazy loading makes that point mostly a non argument.
Finally run time rendering times are about the same for both.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.