Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

> Angular is the EE of JS FX’s (inelegant and bloated), always surprised when some devs choose it over Vue, React or Svelte.

Cargo culting. There is absolutely no need for a IoC container with Javascript or any other dynamic language for the matter. It only ever made sense for compiled language in order to allow reconfiguration without recompilation.

I say that as someone who heavily used AngularJS in the past. Angular X always seemed to me like a project looking for a problem and not the other way around, trying to justify its existence with complexity and bloat.

View on HN

We use Angular for our large realtime process control application in place of a lower-level UI (like Qt). Having all of the tools you mentioned above has given us an organized codebase with components that we've been able to successfully reuse across the application itself and across different products. Having to work around "the Angular way" can be annoying sometimes, but to be honest at the same time it's nice to not have to make decisions that Angular has already made for you (routing, modules, etc)

I’ll bite. Say you have a singleton service class that needs to be accessed throughout your SPA; where would you instantiate and keep this?

Typically you'd just export:

export const singleton = new Singleton()

and import it like any other symbol, e.g:

import { singleton } from './providers'

What happens when that singleton has dependencies? And they have dependencies? Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env.

Not saying that these are impossible, but at some point you either end up reinventing dependency injection, or you end up with all the problems that cause people to invent dependency injection.

> What happens when that singleton has dependencies? And they have dependencies?

Everyone exports/imports their deps the same way as everything else.

> Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env.

Having different environment config is standard feature in most JS FX Apps, if it changes at runtime it's maintained as App state with any changes typically propagated reactively.

I've yet to run into any issue that I needed an IOC for in a client JS App (despite always using them for backend C# Servers) but they're unnecessary in JS, our Angular templates are the only ones that use them, all other premier JS FX's happily get by without them.

So in other words you have TERRIBLE separation of concern.

This was my point exactly.

Lol, you have more freedom to logically structure your code base when you’re not beholden to forced EE abstractions.

and to repay the unwanted commentary you have a bloated, overly abstracted tech-debt ridden liability that’s perfectly suited for Angular, congratz.

Reply on news.ycombinator.com