At some point, we need to stop focusing on the next shiny thing. The web ran for decades without frameworks, then it ran well with jQuery, and now many websites use outdated frameworks. But who cares if you're not the developer working on the codebase? If the age of the framework doesn't break regular navigation and native browser behaviors there's no reason to switch to a new framework unless you are working on a big increment.
There's a recent update showing off new (upcoming) flows via mouse/keyboard/screen reader that emphasize their work on accessibility. I've never tried something like gitlab/github in a screen reader - so don't know how that would compare.
https://community.taiga.io/t/taiganext-update-livestream-acc...
There's also the "next" announcement and a follow-up:
https://community.taiga.io/t/announcing-taiganext-and-much-m...
https://community.taiga.io/t/important-update-on-taiganext-a...
Ed: I'm guessing this is "next" - I see the other front-end repo has a taiga 6.5.x tag in main branch:
The problem are security bug fixes, which usually are only backported to supported versions, regardless of when they were introduced.
E.g. version 1.5 introduced a vulnerability, but it’s not found until after the release of 3.1. At this time only 3.1 and 2.5 are supported. If you’re using 1.5 you need to upgrade. Most probably at the least convenient time possible.
You probably know this already. I still wanted to address it, because at one time in my life I was young and naive and thought similar to you. There might be people out there who can learn from that.
I'd say the bigger problem is having a stack that a very limited amount of people want to work on. This is true for a company where you want to hire specific people to work on your outdated stack (hard and expensive), but even more for an open source project where you need contributors willing to work on an old stack in their free time.
My comment was more in the direction of "the project is done, deployed, and will not change anymore". Somehow software seem to be subject to weathering over time. And what seemed like a secure piece of software can become insecure over night, when someone is fuzzing it and publishes a PoC.
Please tell me in which scenario a frontend issue is a security issue because I'm more the backend architect, not a naive developer.
Your server can remain perfectly secure and uncompromised while your front end drags your company or project's reputation through the mud.
Your argument might be true, but angular would be an exception as it's is pretty backward compatible and even provides you with automated upgrade scripts (ng upgrade)
I never worked with Angular 1.x., but try running `npm install` on an Angular 9 project and watch the deprecation and security warnings scroll by.
I'm in the process of upgrading a complex mono-repo from Angular 9 to 15. The biggest issues are not Angular itself, but all of the other tooling built around it.
Are you sure you used the upgrade scripts or did you just yolo style increase the angular version in the package.json to latest?
The project I'm upgrading is a library used by other downstream projects. My goal was to release a working version of the library for each Angular release. However, I could never resolve this particular issue and just had to skip that version of Angular.
Another common problem I ran into - dependencies that support, for example, ng11 and ng14 but not ng12 or ng13. So your options are to skip that version of Angular, try to replace or remove the dependency, or beg the author to add support for a version of Angular that is years out of date.
And material components version 15 has a breaking change around custom themes that means either I cannot upgrade to that version, or I have to completely rewrite the entire theming functionality within my project. So yes, I can run ng update @angular/material@15 and migrate the code easily, but that doesn't mean "it just works".
To be clear, I'm not complaining about Angular, or anything else in particular here. In my case, the decisions of the original authors caused upgrading to be more difficult than it needed to be. My point is, without knowing the details of any particular project, it's easy to see how upgrading across several major versions can quickly turn into a nightmare of rewrites.