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?
Latest comments (35)
Challenge everything! new frameworks are great, it's fun, they aim to fix issues that exists in other frameworks and make our lives better.
However, community matters, scale matters and framework maturity matters.
These 3 points are key to understanding if the new framework should be tested in production.
Some questions we should ask:
There are lots more questions that we should ask ourself before breaking everything and moving into using something new and unknown.
I do encourage everyone to learn and play with new tech! it's fun, it's educating, it keeps us curious and open-minded.
Create personal projects, demos, write about your findings, open tickets to fix bugs and stay active!
As it seems, life long learners is the best attitude for working in tech.
Along with empathy 🤗.
Stay humble, stay curious!
This is an amazing response, I wholeheartedly agree with you. It's all about the balance between challenging current practices while healthily maintaining technical debt by tackling the 3 things you mentioned: community, scale, and maturity.
This is very simple solution to this: C and ASM have ruled for the last 40 years and are still the state of the art. They offer superior performance and ultimate simplicity, and will not be displaced for decades. They are the right technology. Lamers may disagree, but that's why we built more dynamic displays on 7 MHz Amigas than developers today manage on gigahertz multicores. Snap out if it people, learn about real programming.
I think the important question, and the one we tend to forget, mainly because, let's accept it, we are nerds and we like to learn new things, and we make things and what maker doesn't like to have new shinny tools; "why" is the key question to me. Is just because is fashionable and cool? is that a good reason?, well, who I'am to judge, but in any case you should be aware of your reason. Maybe that means more hiring potential. Another things I think are important are: How specific is a tool and how flexible, how resiliant is the ecosystem, what would happend if the parent company or head dev drops the project? how likely is to survive and thrive and no less important, specially if you have control over the tech you use, do you like the new tool? we will learn quickly, work better and enjoy more if you like the tool, talking about productivity without the enjoyment factor is unrealistic. We hate the tool, we wont use it, we will avoid working and learning and we will learn just enough to make it work and rush things.
I really like this article! Especially with the heading "Learn patience, not a new framework"
I suggest every developer to spend some time learning whatever technology they are interested in. I am a firm believer that a company should give their developers this space for creativity and learning. Although, I think it needs to be mentioned that it there is no promise that the learnings will be directly used in the company's business. However, there have been times that a developer on their exploration time brought some great new ideas & tools that were implemented into the business software.
In terms of introducing change in the business's software, I think it highly depends on the trade off between risk & reward. I usually inquire about what would happen if things go wrong with the change and what problems do we seek to solve making this change. For example, I would be more okay with adding a dependency than changing/adding the framework for a project.
My 2 cents :)
Thank you, that means a lot. I'm quite proud of that heading honestly.
Completely with you on risk & reward. You don't want to introduce too high of a risk if the reward isn't great. This is why incrementally introducing changes makes for an ideal compromise, especially in preparing for an eventual framework change when needed.
:). Looking forward to more of your writings.
I would also add that I think there is an unspoken amount of entropy that it takes to get new developers to utilize a new tool + practice. This should also be included in risk assessment of introducing a new tool.
One of the worst things that can happen is that your software is filled with various tools that various people. Bloat :O
Either that or developers creating their own utilities that duplicate existing functionality, simply because they don't like the current solution or didn't know it existed. This is of course mostly a problem in larger codebases but still plays to your point, installing a library is simply step 1 to adoption/integration.
The framework that wins will be the one that bridges the evident gap between the 2 front-end development disciplines: JS everything vs HTML/CSS/JS devs.
React has won
Too much focus on the technical stuff! No truly end user give a damn about design patterns, variable names, libraries and frameworks. The non-technical people, the ones that in the end pay for the technology want - ux, speed, simplicity, value (business logic) etc. Simplicity is the most complex thing.
Very good statement.
Totally with you, although I wasn't for a long time. It's hard as a developer to step away from the code to consider the bigger picture, but we really are just building software for other people. Providing them a good user experience is most important.
Indirectly, efficient developer practices allows building out good user experiences, but only until you get into diminishing returns of over engineering. I try to consider the ROI of an improvement in development workflow to the end user.
Quality unit tests with decent code coverage, keeping dependencies to a minimum and vetting them prior for community/financial support before installing/using. When dependencies are being used, I constantly check/scan/read the change-log and I make the effort to constantly update.
opinion: I really think the word choice oftechnical debt, emphasis ondebtis the perfect name/term (naming is hard), because it really does accumulate compounded interest of pain over time; just like in finances if you let it accumulate too much you usually file for bankruptcy.Kicking the can down the road, ie:
we'll fix it in the next release/versionHaving good code coverage definitely helps with ensuring an upgrade won't break something critical.
And yeah, procrastination can kill maintainable software.
I agree that it is important to be patient when it comes to new and exciting things. Junior developers may come onto a team wanting to use new tools, but the more senior team members may seem opposed to change. It isn't always because they are old, scared, or do not want to put in the effort. It is because they have experienced the pain of switching to something too soon. When you use unproven technology, there are risks. You will have to figure out issues that have not been answered by the community. If the community fades away, there won't be an abundance of answers out there. This can slow development time a great deal. You will not be faulted for sticking with something stable, but you will be faulted for choosing something new and running into problems delivering the project.
Using new tools also does not guarantee you won't run into the same issues. Using React will give you an effective way to render UI and manage state, which may solve some of your team's problems. If you are working in a legacy PHP application and there was a lack of team standardization, chances are you have spaghetti code where the back-end logic is coupled with the view, JavaScript, and CSS. It works, but it isn't pretty. If you start using React and your team is not trained on it, or it is not introduced into the application in an appropriate way, similar things are likely to happen. There would be changes in the build process, a change in the programming language, and a change in the structure of the application code. Not every developer is not up to date on the latest and greatest in the JavaScript world, so their solutions could create problems. You could end up a similar mess like the PHP app but in React. Other developers may feel like this new technology was supposed to solve all of the problems, but it is just a hurdle to productivity and another mess to deal with. That is how technical debt is created.
The other side of it is being too patient. Do not let highly-used, highly-rated, production-proven, and stable technologies pass you by. You may have chosen a tool 5-10 years ago and made the right choice, but sticking with it for new projects may also lead to the technical debt due to a lack of maintenance, support, and a smaller community around that technology. This involves analyzing when it is appropriate to move on to something new in an incremental way to minimize the risk and set your team up for success in the future. Re-writing your entire existing application is unlikely to happen, but you can get started in a controlled way.
Definitely something that I don't see enough companies consider when upgrading to new tech. It's important to offer proper education, documentation, and also architecture that allows any level of experience developer to jump in to the codebase with confidence that they're doing things "the right way".
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'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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.