I’ll give you some examples, but I’m sure you could come up with this list on your own.
- Many of us built large AngularJS (a.k.a. Angular 1) apps, only to have the Angular team deprecate the “old way” and rewrite the framework from scratch
- “React is great!” – 2015… “React is great, but we all use Redux instead of Flux now” – 2016… “Which of these 20 starter projects do I model my React app off of, and do people still use these libraries? I have no idea what all these config files mean!” – 2017
- The hardest part about starting a new React or Angular project is setting up the dev environment (things like starter kits and angular-cli help)
bowernpm! But yarn is better, even though it’s like npm, just faster.
- React and Angular 2 are nice, but what about Aurelia, Elm, Vue.js, etc.? Are those going to make React and Angular 2 obsolete in the next year?
- This post sums it up quite well
If 2018 you reads this post, I’m sure you will notice that it’s outdated. The bleeding edge people are probably moving past all of these tools already.
The reality is that this is the world that we live in, and I don’t think people are longing to go back to the MVC + jQuery days. We complain about this, or we can adjust the way we work so that we can succeed in spite of it.
Write small apps
Let’s face it – your code is going to get obsolete a lot faster. You are going to spend a couple years creating a large app and then want to use a different framework. You’ll want to recruit and retain developers who want to use new stuff.
This doesn’t mean that you’re going to rewrite everything every two years, but if we write modular applications, we have a better chance of switching frameworks incrementally and start building modules in a new framework while keeping the old code running. And if you do need to do a rewrite, now you have a much smaller task in front of you.
Just because there’s a new way doesn’t mean the old way is bad
I’m a fan of most of the things in Angular 2, and overall I think it’s very well structured and easy to work in. But this doesn’t mean that Angular 1 is trash. If I were building a new app, I would obviously pick Angular 2, but Angular 1 is going to work just fine. Many times these new frameworks just shuffle a few things around, give things different names, have different conventions, etc. There are many ways to succeed, and just because someone came up with a new way that worked for them doesn’t mean that we can succeed with the old.
Get used to learning
I hope you’re already used to learning, but in software development things are always changing and we need to keep up. I think we should develop a healthy fear of getting behind in the times. Not that you always need to be using the latest and greatest everything, but you can learn a lot from learning new ways of doing things, and many times you can apply the ideas to your existing applications. Also, you’ll have a better idea of when it’s time to start moving to a new framework. If you don’t know where to start, sign up for Pluralsight and see what’s new. You’ll find all kinds of great content to help get you started.
Avoid company standards
You don’t always need to be on the bleeding edge. Remember, the goal is to provide value and create working software, even if you’re using last year’s framework.