This article was originally published to my newsletter.
There is a common joke in the JavaScript community that a new framework or library gets ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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:
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.
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.
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.
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.
Very good statement.
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.
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!
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.
“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!
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".
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.
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.
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.
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.
A few years back, I would have been that hype-driven developer. I grew-up. Today I stick to technology and practices mostly based on ROI, resource availability and a few other technical constraints I impose on myself. It's pretty easy for side projects. A few years back I found my self struggling with choosing the stack for a pet project than actually doing it.
Today I have a side project that I run, which is significantly large in terms of users and volume. I keep it pretty simple, I chose Laravel / PHP. I make it so that the framework is upto date so I don't mess up with any security patching issues. I just used plain old views. The reason being the product core component is the APIs. The API's get consumed by a few hundred thousand devices. And regardless of how shitty it would feel on the frontend/admin side of things. It's functional. Most of the users are not giving a rats arse if the admin is SPA or not. They just want it to be functional. I have had the urge to go off the hook and invest in the frontend. But the ROI so low, it prevents me from investing in something that is not generating value.
So instead I invest in stuff like automation, test coverage etc to speed up pushing features out and ease refactoring process when I quickly which up features or bug fixes for the users.
I know this might be a challenge when it comes to a company setting. But, this is what works for me.
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