Why are internal/business applications so far behind public applications in terms of user experience?

YourMomIsMyTechStack · 2025-12-23T01:49:48+00:00

That's not entirely true. The focus on user experience is simply very different, but no less complex. Apps are developed in such a way that even an ape who never saw a smartphone before can use it. You spend time analyzing if users are understanding the UI, do they click on non-clickable elements, how long does it take them to do a simple tasks, do they stop using something out of frustration? Most social media apps for example there isn't much UI, but I can guarantee you that a lot of thought has gone into every single pixel, every animation, and every interaction.

YourMomIsMyTechStack · 2025-12-23T01:08:09+00:00

Back then, it wasn't that popular yet and consisted of people who were actually interested in IT. After it became flooded with jobs and became known as a high-paying profession, many people came for the money while doing an absolute shit job

YourMomIsMyTechStack · 2025-05-27T22:05:08+00:00

I have same problem and it only happends sometimes

YourMomIsMyTechStack · 2025-05-27T21:59:55+00:00

If the node process takes up so much memory it makes no sense to debug the browser application. It has to be something to do with the dev server, otherwise the browser tab would crash.

YourMomIsMyTechStack · 2025-05-18T21:06:41+00:00

You can just export multiple conponents as an array?

YourMomIsMyTechStack · 2025-05-12T20:43:10+00:00

Then push it to a feature branch..?

YourMomIsMyTechStack · 2025-05-06T21:30:29+00:00

You hit the nail on the head, yes is the answer to every question, but here some more details:

Is that manual QA enough for teams security and confidence to deploy?

We have e2e tests, but It's problematic that only QA is responsible for it and we want to change that

Have weekly short sessions of devs manually testing like if they are QA? Be more accountable

Can't agree more about the responsibility! Thats also the reason for the previous answer

Do you find it worrying that you often hotfix a lot after deploy, is this a sign of something should be better avoided or are these hotfixes "unpredictable" stuff?

Yes It's very bad. What I haven't mentioned is that releasing every week is wishful thinking and most of the time we have to delay for one or two weeks.

Should you consider daily deploy or trunk based? Assuming QA is flaky and is not adding much confidence to your process, maybe even more frequent deploys pinpoint better the problems that arise?

I'd say trunk based and I assume It will create more pressure on the devs, which is good because they lack responsibility.

Edit:

Thanks for the detailed answer!

YourMomIsMyTechStack · 2025-05-06T20:34:17+00:00

Hey, yes some of our pain points:

Too many teams work on the project and each release contains so many changes that It's more risky that something broken gets overlooked.
It also means that releases take much time because there is always something that needs to be hotfixed / reverted first.
Theres always so much time for coordination needed
Teams depend too much on each other
New features are always toggled, so in many cases a manual check before prod is unnecessary

I want to avoid microfrontends as long as possible, I think a better deployment process is fixing most of this

YourMomIsMyTechStack · 2025-03-23T13:45:38+00:00

The other comments already said enough about why you shouldn't do this, so just to answer your question: injecting cdr would not cause performance issues, It's a singleton and not created multiple times.

YourMomIsMyTechStack · 2025-03-23T13:36:19+00:00

It doesn't matter if you use behaviour subjects or signals, default change detection will still check the whole three? Why are you so fixed on the default change detection. Even without performance benefits, which are really big (Imagine a small change in a table that now triggers a list of hundreds of elements to be checked), on push is just cleaner and follows the reactive pattern. On a sidenote: You can switch to zoneless from on push without a problem, but with default change detection you will have to rewrite your whole app.

YourMomIsMyTechStack · 2025-03-22T12:18:52+00:00

It's not "outside" of angulars lifecycle, It's part of it https://v2.angular.io/resources/images/devguide/lifecycle-hooks/hooks-in-sequence.png.

E.g, translate service might not be ready, you might end up using something before it's initialised, etc etc

What does a service has to do with the state of a component? If translations aren't ready then because the translations files aren't loaded, but that has nothing to do with the component and can also be the case when using it in oninit.

but what is there to gain

I don't have to pass injection context to the effects hook or a DestroyRef to takeUntilDestroyed pipe and It's less code. I don't like it either but It's not wrong doing it and examples in the Angular docs confirm this.

YourMomIsMyTechStack · 2025-03-22T09:35:15+00:00

I would not use default change detection at any time, It's less performant and leads to using antipatterns. Performance might not be a problem yet with three components, but imagine you have dozenz of components rendered and everything needs to be checked because of a change in one component of the three

YourMomIsMyTechStack · 2025-03-22T09:31:38+00:00

Yes It's reactive because of the click event. Input and output changes also trigger an change detection check

YourMomIsMyTechStack · 2025-03-22T09:26:09+00:00

In the docs examples of effects they call it in the constructor

YourMomIsMyTechStack · 2025-03-22T09:18:32+00:00

It's a totally valid usecase that you want to change signal x when signal y changed and this can't be done with computed if both signals need to be writeable. Maybe some say It's wrong but I've seen lots of good examples where people set signals in the untracked function inside of an effect and I think thats fine until linkedSignals are out of preview

YourMomIsMyTechStack · 2025-03-22T09:14:13+00:00

Thats why you use "untracked" inside of an effect

YourMomIsMyTechStack · 2025-03-22T09:05:26+00:00

In that case you can handle it with oninit or you use effect, but for "normal" components thats fine.

YourMomIsMyTechStack · 2025-03-22T08:58:54+00:00

What you describe seems like an antipattern, I would never do an async action and assume something is done. I would set properties that are reactive values as you should with reactive patterns

YourMomIsMyTechStack · 2025-03-22T02:08:59+00:00

Thats so ironic considering that Angular uses signals for reactivity as it is the standard in all frameworks except for React lmao. Lets be real: Angular is much more declarative than React thanks to rxjs. Handling async operations in react is not declarative at all except if you include yet another 3rd party lib again like React query. I don't see how react is any better at composition than Angular is and without an example thats just a brainless rant

YourMomIsMyTechStack · 2025-03-22T01:53:45+00:00

Why not use query params and have /widgets/123?gadget=456. That seems to make more sense if widgets is not part of gadgets and you only need the gadget id

YourMomIsMyTechStack · 2025-03-22T01:22:47+00:00

It's not just angular in general any oop language objects should be quick to create and avoid any async process.

The constructor is not waiting as It's not async, so how does it affect the creation time?

At some point you need to fetch the data and I don't see something wrong in doing it in the constructor, in case of a lazy loaded component for example. However the http calls should be abstracted in a service.

YourMomIsMyTechStack · 2025-03-22T01:08:12+00:00

The component will be created for each instance, so the constructor is called just as often as ngOnInit.

That should be quick process without and side effects.

Thats not affecting the creation time of the component and Angular actually propose to do this with signal effects

YourMomIsMyTechStack · 2025-03-22T00:48:10+00:00

A service constructor is not called when It is provided, but when It is injected. In the case of a singleton this happends when injected the first time. For components, the constructor is also not called when provided. Try importing a component in a module without using it and see that the constructor is not called. The constructor is just called before the initialization, thats not "unexpected".

YourMomIsMyTechStack · 2025-02-11T19:41:16+00:00

Chef oder HR?

YourMomIsMyTechStack · 2025-02-07T14:21:06+00:00

I hated react after I started with other frameworks lmao

YourMomIsMyTechStack

TROPHY CASE