Sep 16, 2020
Truth about JS Frameworks updating (UPDATED)
In my new job new challenge appeared. Since AngularJS will be unsupported from one point in time, there is need to update company apps to newest supported technology. Here I am standing alone as FE developer on one side and twenty-something apps written in old Angular with little or none existing documentation on other.
TL;DR: Do we need to update all frameworks ASAP as new version appear? YES (sure?). Here is mine point of view — now with update.
As I started updating some of old AngularJS apps into newest Angular 8 framework, le wild newest Angular 10 framework appeared from nowhere. So what now? Update old ones and “waste” time? Keep them as they are and loose support eventually?
As SW developer and aspiring FE Architect I should respond you YES. That’s all folks, you can stop reading now.
You still here? Here is the catch
BUT, when you have 20+ apps to do (rewrite, maintain), and custom made library of common components shared across all apps, what to do? Also you have dependency on one big monstrous framework soaking wet in tech debt?
I asked support of that framework creator how it is in reality with supporting of Angular versions. The response was somehow expected. They support Angular 7+ apps for next 2–3 years and don’t plan to stop supporting. Also they recommended me not to update angular too quickly and too often.
I need to add note here to be fair, they are also supporting AngularJS part of framework, still.
So question was? Do we need to update all frameworks ASAP? Naaaah, on big projects with big frameworks its counterproductive. Think about all bugs that are in all something-dot-zero versions. So be cool, update slowly and think before updating. Test before updating. Take your R&D investigation time, create task for it, if needed. If your PO and colleagues are senior enough, they will understand and support you. If not, and they are pushy, maybe there is right time to change team - this startup approach will always cause more problems during long run.
Here is what I did. Updated one test project to A10 and left library in A8. It worked, and it should work on bigger scale too. Today i am proud of myself, but future me can be facepalming … time will show. Future me will update this article if needed.
To be techy, you have to sacrify IVY with this approach, at this time and combination of versions. In tscongif.lib.json disable it:
“angularCompilerOptions”: {
“enableIvy”: false,You guessed right, we are using DevExpress’s DevExtreme as UI framework. Looks amazing, but it has its own perks, as everything. Hope this helps anybody in future.
UPDATE
Few discussions and with clearer mind later I realized few things. After that I changed my mind little bit and decided to update article accordingly.
As u/crab-rabbit stated: [citation]
Here is what I learned in fewer words. There are basically two approaches:
1- don’t update - and over time start on green field again (we don’t want that, unless you know you are leaving project soon)
2- update dependencies regularly and stay up-to-date (this is more pro and maintainable approach)
a) patch updates - auto, so set versioning to ~1.1.0
b) minor updates - as they are released
c) major updates - asap, when you have time to do it, and you need to find it (but when to do it? I have strategy for that, more below)
When?
On our big project we have every 4 months big planning session across all teams. This is chance to update lots of stuff, because one sprint ends and during planning there is no real coding progress done. So time well spent, right?
Why?
Simple.
a) fixes
b) new stuff
c) updating more than two versions at time is painful and breaks lot of things
Conclusion
Stay updated ;)
