Is Angular becoming React? #63609

Which @angular/* package(s) are relevant/related to the feature request?

No response

Description

Is Angular Becoming React?

I've been watching Angular's "evolution" with a certain sour taste.

One of the things I like most about Angular (and have always defended) is the separation of components and services, the separation between ts, html, scss, and spec code. These separations have always been self-documenting.

From version 19 onward, there has been an evolution and an "arbitrary devolution."

If I use "ng g c feature," the files "feature.ts," "feature.html," "feature.scss," and "feature.spec" will be created. The component will be named "Feature."

If I use "ng g s feature," "feature.ts" and "feature.spec" will be created. The service will be named "Feature."

If I needed to use both features in the same component, I would have to perform an import that doesn't make sense, like:

import { Feature } from '../../components/feature';
import { Feature } from '../../services/feature';

Having to use AS for naming makes even less sense.

On the other hand, if I used previous versions, everything would be clearer, like:

import { FeatureComponent } from '../../components/feature.component';
import { FeatureService } from '../../services/feature.service';

In my opinion, we're on a path of no return when it comes to transforming Angular's good features into React, and I'd like to suggest that the architecture team consider keeping some "old" patterns for future versions.

For micro frontends, it might make sense, but for large systems, it doesn't. Saving object names could be done by the compiler, but it wouldn't hinder the smooth development process with a saving that hinders rather than helps.

Proposed solution

The proposal is to follow the KISS standard and keep it simple without saving characters because it doesn't make sense for those who are developing solutions with the most complex types of technology and solving the size "problem" in the compiler.

Alternatives considered

As a workaround, there could be CLI command line parameters that keep it simple and not simply destroy legacy.