1

I am looking to create a multi-page web app. I had begun the construction of this web app in angularJS when I realized this was no longer being supported. I am early enough in development that it isn't catastrophically bad to change my implementation language from angularJS (.js) to angular (.ts). Given the lack of support for the former language moving forward, is it a good idea to make the switch? Generally speaking, when something stops getting support, it is a good idea to go with a different language, right?
The reason it isn't a super obvious yes in my mind is that obviously angularJS has been a widely used language for a long time and I would imagine its present functionality/version is pretty stable so I doubt I'd run into app-breaking problems.
That being said this is my first major development undertaking and I would like to make it last efficiently as long as possible. Should I go with angular, or stick with angularJS?

Darren
  • 17
  • 2
Runeaway3
  • 173
  • 5
  • Note that AngularJS is a framework; the JavaScript language itself is entirely separate and still supported (it's a W3C standard and will not be disappearing any time soon); certainly not tied to the fate of any one framework. – Ben Cottrell Dec 30 '22 at 09:38

4 Answers4

4

When you are

  • at the beginning of a project, without too much existing code

  • the initially chosen framework is already declared as deprecated

  • the framework has a designated successor which is known as suffciently mature

  • the migration is affordable and / or you will be paid for it

  • the intended life time of the application is more than just a few months (probably some years)

  • you don't have any contractuable obligations which force you to stick to the older framework

  • you see the necessity for using newer features which are not available in the older version of the framework

  • you see some necessity for getting bug fixes on a regular basis, maybe for security issues

  • there is some risk the old framework might exclude an application from working on newer platforms (operating systems or browsers)

then the decision for switching to the successor should be obvious.

However, the problem gets a lot harder when you have already a larger code base tied to some older framework, and a migration will be expensive. Then this becomes subject to a cost/effort estimation (as well to long-term strategic considerations). For a web app facing the internet, there should be also security considerations taken into account. Even when a framework or platform is declared as deprecated, it is often technically possible to use it for a decade or longer after the date of deprecation. When the components used are not introducing a high risk of security problems, then sticking to an older framework for some years can sometimes be more cost-effective.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
3

At some point you will have to change the app. Or your successor. Discuss it with the bill payer obviously, but the best time to make the change is right now when you still know what the web app does.

Remember: First ask the person who pays for it.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • 1
    Asking the bill payers is only useful when asking them the right questions. It also depends on the specific contract, if the customer only pays for the final product, or if they are paying for source code, or paying by hour. – Doc Brown Dec 30 '22 at 09:36
  • The “bill payer” is usually your team leader or their manager. If you are paid for a final product then you are the bill payer, and the question becomes even more important :-) – gnasher729 Jan 01 '23 at 09:01
  • You probably meant something different by "bill payer" than what I (and I guess everyone else) understands by that term. If I am paid for a final product (by my customer), then my customer is obviously the bill payer, not me. Quite the opposite, I am the biller. – Doc Brown Jan 04 '23 at 10:34
  • ... and rereading this answer, it can be interpreted as *"ask someone else who is likely not to have the technical competence to make the decision"* - and that's definitely nonsense. – Doc Brown Jan 04 '23 at 10:40
  • It's technical and financially. If you are paid for a final product, then any effort for extra work comes out of your pocket. Client pays for product, you pay (yourself) for development. – gnasher729 Jan 04 '23 at 18:20
  • If you meant "the ones who pay the OP's salary", and not "the ones who pay the bill for the app", then you should write exactly that. I am employed, but never send my employer a bill for my salary. – Doc Brown Jan 04 '23 at 18:29
2

The reason it isn't a super obvious yes in my mind is that obviously angularJS has been a widely used language for a long time and I would imagine its present functionality/version is pretty stable so I doubt I'd run into app-breaking problems.

The successor, angular, was released over 6 years ago. That's more than enough time to get stable and fix "app-breaking problems" ...

In addition, angular features significantly better developer tooling that significantly speeds up development. On the other hand, rewriting existing code can be a lot of work. The deciding factor therefore is the proportion of development work already done. Early in a project, switching to newer, mature version of a framework is nearly always a win, but if most development work has already been done, switching only makes sense if the old framework presents significant problems, for instance because it no longer runs on new platforms, or can not accomodate new requirements.

Since you're saying that you are "looking to write" an app, you are probably early enough in development that a switch makes sense. Also, the life expectancy of your software is likely higher with the new version, and the skills you obtain in developping it will be valuable longer.

meriton
  • 4,022
  • 17
  • 18
0

A trick with development is trying not to solve too many problems at once.

If you're already familiar with an existing framework or environment, you're more likely to make steady progress without getting bogged down in questions about how things work and fit together properly.

Your circumstances are not entirely clear about whether you are a contractor, an employee, or developing a hobby project for yourself. This would bear on what kind of time pressure you are likely to be under, and what kind of latitude you have to write off work done as waste, or to spend working time on researching what you don't already know.

It's also not clear how much time has already been sunk, how much can be salvaged in a transition, how different the new framework is, and how long the project could be expected to take overall. This would bear on what kind of risks there are of a runaway timeframe, and how much waste there may be against any benefits to be gained.

But as a general piece of advice, the recent discontinuation of support for a mature product is not necessarily a sign that development with it should suddenly cease.

Steve
  • 6,998
  • 1
  • 14
  • 24