When third party needs a forth party it becomes a crowd

anchorBootstrapping

To guarantee the order of events in a responsive web app, a bit of boilerplate is understandable. Angular has clear entrance points, and server injected tokens, that guarantee the app is not loaded before some specific events are done. In addition to explicit providers for almost everything that can be configured:

// the Angular bootstrapper

export const appConfig: ApplicationConfig = {

  providers: [
	// ...
	// this needs to resolve first
	provideAppInitializer(someFactory),
	providePlatformInitializer(),
	// just to name a few:
	provideServerRendering(),
	provideBrowserGlobalErrorListeners(),
	provideZonelessChangeDetection(),
	provideRouter(),
	provideHttpClient(),
	provideClientHydration(),
	provideEnvironmentInitializer(),
	// more custom providers
	 { provide: ErrorHandler, useClass: OlErrorHandler },
	 { provide: AnalyticsService, useClass: someSpecificService},
	 { provide: 'stringValue', useValue: 'Medrid'}
  ]
};

bootstrapApplication(App, appConfig);

In Svelte, explicit file names guarantee lifecycle hooks on server, client and somewhere in the middle. In addition to the built in load function on the every .server.ts and .ts file.

// sveltekit provides:
// hook.server.ts
export const init: ServerInit // ...
export const handleFetch: HandleFetch // ...
export const handleHook: Handle // ...
export const handleError: HandleServerError // ...

// hook.client.ts
export const init: ClientInit // ... 
export const handleError: HandleClientError // ...

// hook.ts
export const reroute: Reroute // ...
export const transport: Transport // ...

// +layout.server, +layout.ts and +page.server and +page.ts
export async function load({fetch, data}) { // ...

There is nothing in Svelte that guarantees order of events, so you find yourself often using tricks like loading on handle hooks, passing to specific load events down the branch of a route, using #await,  setContext and await parent(), until it becomes tired.

You have what you need for basic functionality, but once you get into managing multiple balls and SSR, external configuration and your own internationalization solution, it quickly gets out of hand in Svelte but almost never does in Angular. Angular just won't let you. Which also comes with the price of heavier boilerplate. and more stubborn and opinionated environment.

anchorLifecycle hooks

Svelte has a set of App hooks for both client and server. In addition to two major Component hooks, a tick hook, and three Navigation hooks. (Documentation is not Svelte's strongest quality.)

Angular provides a good amount of Route hooks, Component hooks, a couple of buried Browser Render lifecycle hooks in addition to the events and interceptors that come along with the different out of the box solutions, like HttpClient interceptors.

The distinctive difference between Angular's OnInit and Svelte onMount was in observables. In Angular, once an observable is created, it can be fed and initialized on initialization

// OnInit in Angular
products$: Observable<Products[]>;

ngOnInit(): void {
	// start watching
	this.products$ = this.route.paramMap.pipe ...
}

In Svelte, you cannot use $state, or its siblings, nor store Readable inside onMount, unless you intend to subscribe once to a store.

let products = $state([]);
onMount(async() => {
	// state is never in onMount
	products = await someHttpService.GetProducts();
})

Another twist that is painful in Svelte, is hooking to initialization of content, projected in a parent content. Angular's AfterContentInit is a whole of unpredictable trouble in Svelte.

Generally speaking, Angular is much richer in available events and hooks, that does not make it easier to figure out the dark corners, but it gives you options to break free.

anchorNutshells

Few more points to rant and badger:

anchorDocumentation

No question that you start writing Svelte quite quickly because it's basically JavaScript. But once you start adding more specific features, the documentation of Angular is way ahead in the game. Many times did I go searching Svelte docs for something I knew I read before, just didn't remember where any more. The docs are found wanting.

anchorOut of the box solutions

When I decided to jump into the SPA frameworks, I binge coded three options before I settled on Angular 2.0. One of the major drivers was that it had an out of the box solution for most of the issues covered in SPA. That matters because one third-party framework is one too many, I need to feel confident that source of truth is one, documentation is one, developers working on it are working together, they update together, and they backward-compatible their features together.

When Vite updated the other day, I felt trapped in Svelte. Did not feel the pain in Angular. And I still get bugs in my solution that matches routerLinkActive directive.

If you opt into having third party libraries (or better dubbed forth party libraries), you will have to continually watch and update those libraries, which in this day and age, isn't to be taken lightly.

anchorPotentials

They both have potential for sure, Angular has much better support, which makes it too big to fail, it will end up like ASP.NET one day, not many use it, but those who do, swear by it. It won't die any time soon.

In terms of small-scale projects, with little or no SSR, single language, they both rank the same, but Svelte is simpler, I would say VueJs is the real contender in that department.

As the project gains complexity, state management, multilingual, hydration, extra features and complex routing, or when you have more developers working together, Angular is the way.

anchorSide note about AI completion

I use Windsurf for code completion, Gemini, Copilot and paid Claude for coding. But I did notice that in Angular, the code completion is almost always correct, and the solution is almost much easier to understand. Svelte usually takes a while to teach the AI to pick up a pattern, and the solution is harder to explain. I don't know the real reason behind it, except that Angular is older, and the documentation is more thorough. And AI are just parrots, aren't they!

anchorHTML sanitizing

I always used Angular's [innerHTML] to sanitize the HTML output, and I thought Svelte's @html does the same. Boy was I wrong. This brings me to the final odd conclusion:

Angular, somehow, makes you dumber, because you become lazy. But then again, where you around the times when we had to make buttons into table elements to create the illusion of rounded corners? We definitely wasted a lot of brain tokens on that!