Hacker News Reader

> Every React project that I've walked into has looked completely different from each other.

Which, on its own, doesn't necessarily bug me as much as the attitude I've run in to. I've come in to a handful of React projects in the past 3 years, and each team says that "their" way is the "correct" way, and whatever I was doing elsewhere is just dumb/wrong/outdated/slow/bad/untestable, etc.

"Oh, we don't do class-based here - that's so outdated!".

"But... you have 85 class-based components already, and 4 functional ones..."

"We're converting everything - class-based components are so hard to test"

"How do you know? You don't have any tests around them at all"

"Because it's so hard to test"

"But you have no tests around the 4 functional ones -"

"It's going to be easier once we convert all the legacy class -based components".

I've done some Angular (versions 1-5) but mostly Vue these days. Angular was getting overbearing for me (especially on projects where I'm the only/primary js person), but I understand the appeal. A couple of colleagues have done Angular at big companies, and the structure (and extra layers) mapped very well to their existing way of thinking. I've shown one of those colleagues some standard Vue stuff - he 'gets' it, but thinks it's way too loose.

> Also, JSX reminds me of PHP code in the 90s. While you can separate your markup from your view logic and styles with discipline, most React devs don't. Most components I've seen are a large hodgepodge of markup, styles and logic.

This is no doubt the biggest problem of React that no one talks about; “where do I put my business logic?”

The most common solution to this is to sprinkle it all over some sort of pseudo-controller components. Even worse when it’s all hook-spaghetti.

At least Angular recognises that not everything is components.

Uh, the hooks in the new versions literally solved this problem. And is backward compatible although it's somewhat painful if you work with both the class based and hook based base code base at the same time.

But if you use an current opinionated package. Next.js + pure hooks based+ typescript, beats everything on the market by miles. It's not even close.

Yes the answer to the complaints above is Next.js + hooks + Typescript. Absolutely fine if that isn't your cup of tea, but let's not kid ourselves that a solution isn't already available.

But the hooks literally solved the logic problem. I know what the complain means as I have worked on old code base. But I don't see anything better than handling cross cutting logic better than hooks. A pure hook based code base is not just the best in browser, but also better any other UI technologies in other platforms I have ever seen. This is my personal opinion. Could you show me a better way?

I think they actually agree with you, unless my reading comprehension is terrible today (I’m prepared for that to be true)

My bad, misread.

I do it every day :)

The person you replied to, agreed with you.

My bad, misread.

And how to do you structure the business logic that is connected via hooks?

What is your definition of business logic? Business logic as I know it doesn't belong in the front-end at all. Your business logic should be taken care of on the back-end and your front-end application responsible for displaying the end-result.

the same how you would do it in angular, you write a service class or function, you can structure those however you want.

Problem is that you end up spending so much time working against the framework when the framework is too opinionated.

I prefer a framework that tries to get out of the way. It just gives you what is needed to structure your code, so that everybody can find their way around the codebase, and then lets you get on about the actual concrete implementation that you need. Angular instead has sooo many opinions about how you should do everything. So much boilerplate, so much runtime, and so much accidental complexity everywhere.

For this reason I prefer Svelte these days. https://kit.svelte.dev/

It doesn't have opinions about things it doesn't have to. It's fast and minimal and lends itself to a clear common code structure. This is what a framework should do.

the vast vast majority of people arent doing things so unique that you need to diverge from what Angular expects you to do.

There seems to be a lot of confusion about what a framework is.

- React is not a framework /Angular is a framework

- JQuery is not a framework / Ruby on Rails is a framework

The fundamental difference between a framework and a library is that a library is passive. It provides reusable code that sits there waiting for the consuming application to call into it.

A framework takes the opposite approach. Frameworks apply the "Hollywood Principle" (don't call us, we'll call you). A framework is a skeleton application already developed for you, having made fundamental design and architectural decisions. It does not exist to get out of the way but to take control and do the driving for you. The idea is that you provide the unique, domain-specific behaviours that are specific to your application and delegate as much as possible of everything else to the framework.

This is a feature, not a bug. Frameworks exist to give you as much scaffolding, bootstrapping, internal APIs and up-front design decisions as possible.

That appeals to developers because it speeds up development time. But it trips a lot of developers up when they don't understand the internals and design decisions of the framework they are using. If you approach a framework with design paradigms in mind that do not align with the framework's underlying decisions and architecture, then you will feel like the framework is getting in your way.

The relationship between a framework and an application built with a framework is very much a marriage. The choice of which framework to use, and whether to use a framework in the first place, is a crucial architectural design decision that must be made carefully. If you make the wrong decision then you would be right to rip out your domain specific code and start over.

My point is there is no such thing as a framework that "stays out of the way." That would be a library.

There is nothing wrong with not using a framework and using libraries instead. My main problem with React and the React ecosystem is that this fundamental distinction between libraries and frameworks is not recongized by React developers and the community. They treat React like a framework when it isn't, complain about Angular being "too opinionated" not recognizing what those opinions have to offer, and then proceed to pull in a million different libraries thinking they're working within a framework while doing the exact opposite and putting next no thought into fundamental front-end application architecture.

I come from the era of Java OOP frameworks like Spring MVC and front-end frameworks like Ruby on Rails. That's why Angular appeals to me - because I understand what a framework is, what to expect from a framework, how I would go about designing my own and what to look for when choosing one.

If you don't then any framework will feel oppressive. The best thing you can do at that experience level is to learn as much about system design as possible, read a book like Building Application Frameworks (Fayad, Schmidt & Johnson), and think about how your ideal React framework (if one existed) would look. Then you will understand the different opinions of different frameworks and will have well informed and defined opinions of your own.

When you write a React component, there are all kinds of ways where React calls you, e.g. the hook mechanisms. And that can be considered a framework in my opinion.

It also tells you how you should write your components, which is another sign that it's a framework and not just a library.

I may not have been clear enough in my opening sentence discussing the differences though I did go into great detail following it and so I don't think my comment was unclear.

By the logic you just demonstrated, if you call a function that accepts a call-back as a parameter, when it evaluates your callback you are consuming a framework. Or any React component that receives a callback as a prop would suddenly be a framework. Promise libraries would be "frameworks."

Just because a framework executes your code primarily via the application of the Hollywood Principle, and operates primarily through the application of the HP, doesn't mean that any application of the hollywood principle automatically indicates that you are working with a framework.

When getting into discussion about definitions, there is a lot of room for nuance, opinion and degrees. The key part of my definition that you glossed over was [paraphrasing myself]: "skeleton application that provides as much scaffolding, bootstrapping, internal APIs and design decisions as possible leaving you free to focus only on the pieces of your application that are specific to your domain problem."

Yes, you are right it's very nuanced and also a bit subjective. So it doesn't actually make much sense to argue about it, much less here. Anyway, thanks for your comments, they are insightful.

Re: Pipes.

The problem with DSLs -- compared to just writing JavaScript/TypeScript -- is the IDE experience is incredible. It takes a formidable team to create both the software for parsing the DSL, and the language service to provide intellisense and ordinary language-feature goodies. At that point, why not just use a conventional programming language? Formatting a string is an extremely normative thing to do; it doesn't seem to necessitate the DSL plus all the tooling that elevates the developer experience of using the DSL.