Hacker News new | ask | show | jobs
by apatheticonion 1065 days ago
Having worked extensively with the major frameworks in multiple orgs, I have largely found that templates synced with state via change detection (like Angular) result in more readable/maintainable projects.

While I personally like React, it's pretty tricky to use in reality. I have found that its idiosyncrasies make it less resilient to suboptimal contributions from engineers that are still early in their careers.

Broadly, the projects I have entered using React tend to be pretty wild, messy and unreliable.

There is cross over though, Angular projects using Redux (ngrx) are horrific. The criticism of Angular for me is the lack of control you have over the compiler, dependency versions and testing strategy.

Svelte and Vue are both interesting, but they use custom file formats (.vue, .svelte) which can add an extra layer of unreliability to projects using TypeScript and testing frameworks.

The advantage of Angular is that it's an ergonomic abstraction that allows optimisations to occur at the engine level. It's more like an ORM, where React is more like writing SQL queries directly.

2 comments

I’ve only ever touched React as a “so and so needs a hand on this bug” or “we want this feature added to legacy while the React team works on the new version”, so I was already going into a codebase that had long been abandoned in all but usage.

That said, it was a nightmare. I think we had state managed by vuex, and I just needed to add a new data point to the component and display it. But the data needed to be added to state…so I think I touched 6-7 files, adding mutators and updating definitions etc.

The experience put me off of React, though I do imagine a lot of that comes down to how the code is initially structured and maintained. It’s clear that whatever they were doing was more “make it work now” and it so much worrying about the future.

Have you tried the model view update pattern?

If you haven't I recommend having a look. If found it amazing for maintainability.

You have to be carful to structure everything well. If not you blow up the number of messages in one file. But once you get past that it's really amazing.

Yeah I have, personally I like it but the issue I have found was that I am not the only one who works on projects.

> You have to be carful to structure everything well.

This essentially sums it up. I can be careful, but it's impractical to review code to ensure it's also structured correctly when working on a team with lots of contributors with varying experience levels.

In my experience, It's also more difficult to teach MVU than it is to teach templating with automatic reactivity.

Sadly, I have to agree with everything that you've written there.

For simple use cases templating is much better as well. It's only in complex state management that I find MVU is worth it.