11 ms·

I've worked on more React projects than Angular, and am very competent in both. I'll take an "opinionated" framework any day of the week over what I see in the

I've worked on more React projects than Angular, and am very competent in both. I'll take an "opinionated" framework any day of the week over what I see in the React ecosystem. Every React project that I've walked into has looked completely different from each other. One common complaint about Angular is that it is "bloated." Yet every React project I've seen pulls in a million 3rd party libraries to solve the most trivial problems, and I've seen very few React apps that implement code splitting of features. So you have massive bundles being pulled into the client and the majority of code contained in those bundles are not going to be needed for a given user session because no user is going to use all features when they login. 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. Give me Angular any day of the week. - Give me view encapsulation so I can write straight-up SASS and have it scoped to a component. - Give me a template language to keep my view logic separate from my markup. - Give me dependency injection. - Give me code splitting / bundles right out of the box. Let me configure my routing without having to use components. - Give me a sane, reactive forms module out of the box. Form controls are the standard way of interacting with the end-user and so the typical front-end application will work heavily with forms in some shape or form (no pun intended). I have yet to find a decent forms solution for React. - Components should just be views. I like a framework that encourages developers to separate their concerns and get integration code, routing config, state management and the like into a separate layer of the app (and no, react hooks are not a good solution for this. They introduce tight coupling between the view and other app layers - I use them a lot, but they're no substitute for dependency injection). - Give me pipes. Formatting and manipulating string data is a very typical problem that views need to solve. In React apps you'll typically see low-level JavaScript code doing this type of stuff inside of markup.

Oddskar 5y ago
> 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.
- flyingchipmann 5y ago
  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.
  - agrippanux 5y ago
    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.
    - flyingchipmann 5y ago
      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?
      - steve_adams_86 5y ago
        I think they actually agree with you, unless my reading comprehension is terrible today (I’m prepared for that to be true)
        flyingchipmann 5y ago
        My bad, misread.
        steve_adams_86 5y ago
        I do it every day :)
mgkimsal 5y ago
> 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.
- deleted 5y ago
  [deleted]
Sammi 5y ago
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/ 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.
- anthonypasq 5y ago
  the vast vast majority of people arent doing things so unique that you need to diverge from what Angular expects you to do.
- gspencley 5y ago
  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.
88913527 5y ago
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.

Oddskar 5y ago

> 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.

flyingchipmann 5y ago
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.
- agrippanux 5y ago
  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.
  - flyingchipmann 5y ago
    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?
    - steve_adams_86 5y ago
      I think they actually agree with you, unless my reading comprehension is terrible today (I’m prepared for that to be true)
      - flyingchipmann 5y ago
        My bad, misread.
        steve_adams_86 5y ago
        I do it every day :)

mgkimsal 5y ago

> 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.

deleted 5y ago
[deleted]

Sammi 5y ago

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/ 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.

anthonypasq 5y ago
the vast vast majority of people arent doing things so unique that you need to diverge from what Angular expects you to do.
gspencley 5y ago
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.

88913527 5y ago

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.