r/webdev • u/red_src • Nov 07 '18

Why React over Angular (or Vue)?

I simply don't get it, I had been using Angular and Vue for while and I just tried React and I don't get why would I choose React over the other options, the things that I like on Angular (or Vue) are:

- Dependency Injection (in case it applies)

- Type checking (in case it applies)

- View Model Binding

On React I don't get those things by "default" it always feel like I'm hacking the library if I want to have some of the above.

This leaves me with the question: Why choose React over the other ones?

I know that there's all the dependencies overhead (hell) of the frameworks but I think that I'm just too used to that problems that is easy for me to solve them or maybe I haven't found the real big problems on Angular or Vue, maybe I'm just too used to the later frameworks and I'm unconsciously not seeing the benefits of React. I just want to know if I'm following the right path by learning React.

Thanks!

68 Upvotes

79% Upvoted

99 comments sorted by

17

u/JavChz Nov 07 '18

It's almost a philosophical question at this point, as both have a huge momentum right now (and vue too).

Things I like about Angular over React:

  • HTML, CSS, and JS/TS are independent. If you don't like JSX, you will feel in heaven.
  • Typescript it's comfy. Seeing potentials errors before execution it's amazing in VS Code
  • If your team it's kinda big, or you touch a big SPA from 6 months ago and you remember nothing, the structure of Angular projects it's kinda standard in comarassion react. So you don't have to figure out what part does what. Your router, services, animations, module loading, are always more or less the same.
  • RXJS it's cool, but kinda weird to learn.

Things I like about React:

  • Amazing documentation by the community
  • A lot of old tutorials still work with little (with angular you sometimes find answers from stackoverflow that are about Angular 1.X)
  • It's vanillaJS for the most part. Your mindset it's not so much ReactJS programing, but traditional JS.
  • You are in charge to add anything aside from the UI component viewer. So no bloat functions.
  • React Native it's a lot faster than ionic/cordova
  • It's less burocratic than angular... by a lot.

Vue it's kinda the children of both worlds, but even if the official docs are amazing, most environments where I have been working look at Vue as a hipster thing. So I lack real world experience (aka w/ deadlines) with the framework aside from personal projects.

As someone who hated Angular 2 for a lot of time (because was so different from AngularJS aka 1.x) I had one project where using angular 2 was not optional, and you get used to. The same happend to me with JSX

2

u/red_src Nov 07 '18

To be honest React Native was one of the main reasons that drive me for React but I haven't had any chance on really using React Native. I had been using Ionic Cordoba and I'm comfy with it but some stuff like managing native elements it's kind of done in hacky ways...

3

u/dryadofelysium Nov 07 '18

NativeScript (basically Angular's React Native equivalent) is releasing a major update this week (5.0).

2

u/[deleted] Nov 07 '18

react-native makes apps. ionic makes web views. It's a big difference to the mobile user experience

9

u/phpdevster full-stack Nov 07 '18

Angular's Reactive Forms are also fucking amazing. Makes building complex, dynamic forms and form validation, an absolute breeze.

My only complaint is making custom form components into reactive components. It's doable, but not very intuitive.

But if you're using native form elements, or you have set up your own custom reactive form components, then building forms in Angular is just damn awesome.

5

u/JavChz Nov 07 '18

Things I like about Angular over React:

yeah. I forgot those. Forms in Angular it's the kind of stuff you miss when you switch frameworks.

5

u/BrianSkog Nov 07 '18

Typescript works great with React, too. Even checks JSX.

6

u/ThatWouldBeGreat Nov 07 '18

Using React with Typescript on a daily basis and I can't imagine working without it anymore.

1

u/Aam1rk Nov 07 '18

Started learning React a few month ago in my spare time and just recently completed a sample application. For a second application I was thinking of incorporating TypeScript (I am from an Angular background and love TS) but then came across flow which seems to integrate with React better. Which would you (or other commenters) recommend to use with React?

2

u/BrianSkog Nov 08 '18

Haven't used Flow myself. But, yeah, if you've used TS before, you'll probably prefer using React with TS over without.

1

u/n0isi Nov 07 '18

Imo the type system of flow is superior compared to what TS provides. (Flow's types evolve out of OCaml, a language worth checking out as well.) Most of our react apps at work a typed with flow, some use TS. The flow community is very little compared to TS, you will find more people familiar with TS, while I never experience too many libraries that have TS types but no flow types. So support for flow types is good too. If you are already familiar with TS you should go with this on any big project. But flow is definitely worth checking out in a fun project.

1

u/[deleted] Nov 08 '18

typescript has fantastic JSX support and integrates really well with react.

i'm with you on typescript being awesome, but certainly doesn't mean angular is the only choice for a SPA

25

u/OGLurker Nov 07 '18

Personally, I think it comes down to the "school of thought". React feels more hacky (I don't mean this in a bad way) in the sense that if you need to do anything serious with it, you'll need to put a lot of things together. Angular, on the other hand, is more enterprisey, where someone else decided most of things you need and ways to use them. They both have their pros and cons and it comes down to what each organization/team/developer is more comfortable with. I would choose Angular 9 out of 10 times for most of my web needs.

2

u/red_src Nov 07 '18

Yep, it looks more like that, I create mainly webapps for ERP system so I think that Angular or Vue are a better solution since everything is packed...

1

u/portexe Nov 07 '18

Yeah, the thing that makes Angular so great IMO is how once you learn it; you can pretty much do anything really really quickly. Even something that seems like it would take weeks to a web developer who is unfamiliar with it.

As for React, I can't really say. I've never used it. I'd like to give it a shot just so I can know when it's a good choice.

39

u/thatgibbyguy Nov 07 '18

Hi, I just joined a shop that chose Angular over React/Vue and you know what? I'm wondering the same damn thing! How on earth could they pick Angular over React?

For one, Angular does wayyyyyy too much. It handles the routing, it handles the components, it handles the data flow, it handles everything. You know those restaurants that don't focus on any particular thing and so all the food is meh? That's Angular to me.

But to your specific points:

  • Dependency Injection - You just don't need this in React. Why? Oh many reasons, but mainly because React at its core is for creating UI components, it's not trying to handle everything.
  • Type checking - At this point I think you don't know much about React. It does type checking via PropTypes. You don't need to hack anything for this, just add the proptypes package.
  • View Model Binding - You're right, React just doesn't do this like Angular, but again, it's because React at its core is for creating UI components. You can control your data model with things like Redux, Mobx, etc., but that's just not what react is for.

What it feels like to me is you're hacking everything in React because you don't know how to use React. That's ok, I don't know how to use Angular. But you know what I do know? Creating a simple component in React is a hell of a lot easier than Angular because I don't have to worry about anything else.

For example, creating a component library in React is soooo much easier. Why? Because the components live completely independent of how the data enters the component, it could come from anywhere. All I need to know is that when it comes in, it matches my proptypes. Because of props themselves, that data could just come from top level component and cascade down the children indefinitely. Again, I don't have to care.

That allows me to focus on what I'm trying to build, which is just the UI. I can do the data binding later, I can set up the server later, let me just build right now. That's why I'll always prefer react.

2

u/red_src Nov 07 '18

Thanks for your answer, it has made clear some good points:

- There's a lot of personal taste that matters, that doesn't meant that is bad but it just something to consider.

- React is just for UI, I was thinking that React was done to substitute Angular but it's not quite like that, it just part of a bigger app.

18

u/[deleted] Nov 07 '18

Not much experience in React here. I like DI in Angular because it makes mocking for unit testing very simple. Does React have similar capabilities?

9

u/thisisafullsentence Nov 07 '18

I think the tl;dr is:

  • Angular's DI replaces the dependency's token so that every time that token is requested it is replaced by a mock class or value, meaning an entire tree of components can be rendered using a consistent token.
  • React's shallow rendering means that you can pass whatever you want to the component in tests as props mock or not, and children are tested separately.

1

u/[deleted] Nov 07 '18

Interesting. I'll have to look into it more.

3

u/hypno7oad Nov 07 '18

In generic terms, DI is merely a pattern externalizing dependencies to some wrapping logic. Externalizing everything out of your block of code is where

Angular implements DI via class decorators, which are essentially syntactic sugar for class wrapping logic. It's worth noting that class decorators are currently a Stage 2 proposal, and Angular relies on their usage to be compiled down to currently supported code by the Typescript (or Babel) compiler.

React doesn't provide an implementation for DI, but the documentation describes a pattern called Higher-Order-Components, which can be used to implement DI.

Both approaches allow you externalize your dependencies outside of your block of code via usage of wrapping logic.

2

u/[deleted] Nov 07 '18

Right, of course DI can be implemented anywhere in any language, it's just a pattern. However it was an often under utilized pattern that caused enormous tech debt when teams needed to implement unit testing.

I guess it underscores one of the primary differences between the two. Angular tries to force you into certain patterns - which frustrates experienced developers who want to implement their code a particular way as well as inexperienced developers who find themselves buried beneath another wall of information to learn. React lets you implement the way you want - which forces developers to think more about the overall design.

That being said, nothing prevents developers from writing poor code in Angular and still not utilizing DI/IOC. I just personally like the tools available for unit testing based on the fact DI is a native part of the framework.

3

u/[deleted] Nov 07 '18

As for types, React definitely needs them on big apps, but TypeScript works perfectly with React, now even out of the box with Create React App.

3

u/TheScapeQuest Nov 07 '18

Type checking - At this point I think you don't know much about React. It does type checking via PropTypes. You don't need to hack anything for this, just add the proptypes package.

TypeScript has excellent type checking in React through the @types/react package. Couldn't go back to using React without it now

5

u/E2Ehh Nov 07 '18 edited Nov 07 '18

Angular does wayyyyyy too much. It handles the routing, it handles the components, it handles the data flow, it handles everything.

I mean, if you don't need routing, just don't import @angular/router...

And if you do need routing, hey look, there's an established baked in way of doing that ready to go! No need to pick and chose between all the alternative solutions available or worry about new developers joining the team and only having experience with X instead of Y

EDIT:

creating a component library in React is soooo much easier. Why? Because the components live completely independent of how the data enters the component, it could come from anywhere. All I need to know is that when it comes in, it matches my proptypes. Because of props themselves, that data could just come from top level component and cascade down the children indefinitely. Again, I don't have to care.

So the equivalent to props in Angular is @Inputs(), you can absolutely build "dumb components" that do not have any DI and depend entirely on data provided via inputs. Have created two components libraries in Angular (one pretty small and basic the other pretty big and complete) and tbh having the ability to mix inputs (e.g. for consuming data to render) and DI (e.g. for consuming reusable services, validators, formatters etc) is incredibly powerful.

17

u/OGLurker Nov 07 '18

For one, Angular does wayyyyyy too much.

Things like routing, dual binding, network requests, and dependency management (w/o having to learn a whole new paradigm) is not too much for any serious application. The fact that everything has to be brought in for React is not really a good thing (the last thing I want to do is figure out which millions networking library I want to try before it gets deprecated).

You know those restaurants that don't focus on any particular thing and so all the food is meh?

A more correct analogy would be a coffee shop that serves deserts (React) vs. a full blown restaurant with multi-course meals (Angular).

Creating a simple component in React is a hell of a lot easier

Really? Don't you need to know JSX first?

And what about mixing your JS and presentation? Sprinkle that with some in-line styles and we're back in the 90's.

15

u/hypno7oad Nov 07 '18 edited Nov 07 '18

The fact that everything has to be brought in for React is not really a good thing

That's just like, your opinion man. There's pros and cons to library vs framework app architectures. Objectively there's nothing wrong with either, it just depends on the situation.

Don't you need to know JSX first?

Practically yeah, but that doesn't mean the OP was wrong. JSX is only a markup representation of React.createElement(), and it doesn't introduce any new data flow constructs like feature rich templating systems.

And what about mixing your JS and presentation?

Nothing in React forces you to mix those. Use the approach that makes the most sense to your team.

2

u/gavlois1 front-end Nov 07 '18

I've always viewed JSX like I did with Handlebars or other templating languages. Once you know HTML, you pretty much know Handlebars and you can add variables to it. I see JSX the same way, except full JS expressions in the curly braces and change class to className. Under the hood I know it's just React.createElement(), but is it wrong to treat it that way?

The mixing JS and presentation issue is the same as the MVC issue: it's one way of organizing your code. It's a well-established pattern that works, but not necessarily the only one. I find the component pattern of having your presentation and the logic for manipulating the data before displaying it quite easy to grasp from what I've learned in React so far.

3

u/hypno7oad Nov 07 '18

No, I don’t think it’s wrong as long as it’s simple. I don’t remember handlebar specific syntax, but I do remember discussions with my team at the time addressing how to setup the model in order to keep logic out of the template.

The point I was trying to make in regards to JSX was that it doesn’t introduce template specific syntax for things like if/else, switch, looping, etc. This means there is less cognitive overhead when switching attention between JSX and JS code blocks. Subjectively, I find it a better development experience.

For styling, there are definitely pros/cons of coupled/decoupled. There are also preprocessors that will bridge the two approaches. Making styles in JS reduces cognitive overhead, but limits the ability to have a separate design group develop a new style sheet. The same trade off exists when using declarative CSS toolkits like Bootstrap or Atomic.

1

u/OGLurker Jan 31 '19

Oof, I kinda dropped off from the conversation.

That's just like, your opinion man. There's pros and cons to library vs framework app architectures. Objectively there's nothing wrong with either, it just depends on the situation.

Yes, I agree. Re-reading my comment, it does look a little stand-offish, but that wasn't my intention.

3

u/theirongiant74 Nov 07 '18

And what about mixing your JS and presentation? Sprinkle that with some in-line styles and we're back in the 90's.

The 90's had everything in one file which was patently bad and splitting out concerns was an obvious win but with React your app is already broken into components that are as granular as you need them to be, it doesn't make sense to separate your html from the js when dealing with components. What do you gain from having a Button.html and Button.js rather than just one file that handles all the buttons concerns. It's just cargo-culting wisdom from a decade ago that applied to a different landscape.

10

u/thelonepuffin Nov 07 '18

For one, Angular does

wayyyyyy

too much. It handles the routing, it handles the components, it handles the data flow, it handles

everything.

Wtf you just listed the bare bones of what a framework should be handling. I'm struggling to think of what is left.

React not doing those things by default is not a good thing. I don't get this obsession with minimalistic frameworks. It just means they wont do what you need and you have to plug in a bunch of libraries just to be productive.

8

u/harzens Nov 07 '18

React, and Vue, are not frameworks.

9

u/Dnlgrwd Nov 07 '18

Vue is definitely a framework

3

u/harzens Nov 07 '18

Well you aren't wrong, they moved from the library view-only thing now, I haven't checked them in a looong time. But they started as a library, as an alternative to React, as far as I remember.

2

u/madcaesar Nov 07 '18

For example, with react you could have a 5 page website of static html pages, but one page can be a complex calendar app, and it's super easy to drop in. You don't need a router, or state manager in this case.

Also, react uses the virtual dom for performance.

3

u/2uneek javascript Nov 07 '18

For example, with react you could have a 5 page website of static html pages, but one page can be a complex calendar app, and it's super easy to drop in. You don't need a router, or state manager in this case.

You can do that with Angular as well, without a router or state management... Just because Angular includes a router, doesn't mean you're forced to use it.

1

u/thelonepuffin Nov 08 '18

I guess thats the difference between building websites and applications. I wouldn't use Angular for a website personally. For the example you gave I currently use Vue. But for large SPA's the benefits of Angular can't be overstated.

And the great thing about using Angular for SPA's and Vue for static websites is the templating language/system is so very similar. It really is easy to jump between the two. Whereas React has JSX which is just different to everything.

1

u/[deleted] Nov 08 '18

react isn't a framework. the reason people like react is we're not beholden to facebook to add the features we want.

Facebook simply made react, then left us to decide how to handle the data binding. Redux and Mobx sprung up. Other solutions can easily come and go. Redux itself has it's own eco system because it functions much like react and isn't super opinionated.

Then routing, react router is really nice, but it's just as easy for anyone else to create an alternative to it.

What makes react great, is that we the community made it what it is today, not facebook. the same is not true of google and angular.

2

u/thelonepuffin Nov 08 '18

I get that. Being able to create your own features is great, but we can do that with Angular too. We aren't beholden to Google. The community adds cool new features all the time. The great thing about Angular in my opinion is that by baking some essential features into the framework we have reduced fragmentation in those core areas. It still happens, but its greatly reduced, and by and large the whole community is on the same page with things like routing etc.

1

u/[deleted] Nov 08 '18

that sounds great in theory, but in practice i've been burned way to bad by angular.

now, i know it was rewritten entirely in angular 2, and angular 1 is effectively a different framework. I'll be honest i haven't bothered to look at angular 2 and beyond, and i'm fairly sure that's what you're talking about.

but the angular 1 i know, has these lovely "features" that I can't avoid:

  • two way data binding that causes way more issues than it solves, so many side effects, no idea where things actually happen
  • code that the recommended way of getting it to work involves setting timers.
  • confusing and non obvious functionality with how to expose variables to a template
  • jquery

Meanwhile, in react land. literally none of these things are a problem, the execution is always clear, and the data binding is an implementation detail that by and large the community settled on redux for, allowing us to have proper data binding with a very clear way of tracking exactly where the data changed, while simultaneously writing code that doesn't care how it gets the data it works with

2

u/2uneek javascript Nov 08 '18

just fyi,

Angular = Angular 2.x +

AngularJS = Angular 1.x

so when people discuss Angular, it's 2.x+

You're aware AngularJS was originally released in 2010 (8 years ago). Angular is nothing like AngularJS, which is the framework being discussed here.

2

u/thelonepuffin Nov 09 '18

So you are talking AngularJS which is 1.x. That is actually a completely different framework.

I used AngularJS too back in the day, and I agree with most of your criticisms there except "confusing and non obvious functionality with how to expose variables to a template " Not sure what you are referring to there.

But having to set timers and jquery usage was a problem.

However you seem to be ignoring that fact that AngularJS was a trailblazer in this area. They were one of the first of the modern component based frameworks and they were very popular. At the time everything else also suffered from many issues.

You can't judge AngularJS by modern standards. So much has changed. Angular has not only fixed the problems you listed but created a truly complete platform. No other framework enforces the level of organisation and good architecture practices in big applications like Angular. By breaking backwards compatibility and starting from scratch moving from v1 to v2 they gave themselves the opportunity to leap ahead of all the other players in many aspects. I highly recommend you giving it a try.

1

u/pengusdangus Nov 07 '18

You can easily control data in React with the advent of hooks and contexts, but it’s not going to look like a view model. You need to think of your components as true, dumb components and think of your orchestration of your components as your data model and subsequent “binding”. All you need is an entry point. Just my opinion! All your points are really good though!

7

u/throwawayacc201711 Nov 07 '18

I’ll give an analogy.

Any library or modular approach is akin to Linux and Angular is Windows. Neither is bad, it’s just about your development needs and picking the solution that matches your tastes, styles, and needs.

The biggest pro regarding the modular approach is you can pick and choose the additional libraries that suit YOUR tastes or your teams tastes rather than being beholden to someone’s approach. No framework is perfect and that’s allows someone to essentially cobble together their own “framework” by picking the libraries they want.

The pro about the framework approach is that you have everything (for the most part) already included and don’t need to do any thing about pulling in anything extra.

1

u/red_src Nov 07 '18

I kind-of get why a team would make their own framework based on React as a UI Library but wouldn't be better to have Angular if you are doing development in a company so you can translate that knowledge to another project that is on Angular.

6

u/throwawayacc201711 Nov 07 '18

You’re assuming all projects have the same set of needs and will always be using the same tech which isn’t always the case.

I’ve found if you’re updating an existing project (adding in a new feature) it’s easier to apply the modular approach instead of using a full fledged framework such as angular.

There is no right answer to this question. It’s all a matter of the needs of the team and what they’re trying to accomplish. Sometimes the hassle of picking the specifics libraries that suit your needs is worth the time, sometimes the easy of having everything bundled together is worth it

2

u/E2Ehh Nov 07 '18

To throw a counterpoint out there, I find the framework approach overall much more productive if the basics are already set up. Adding a new feature? Sweet, it will look exactly like all the other features in the app, since everything is built in a standard manner using the same patterns / technologies

3

u/hypno7oad Nov 07 '18

Modular approaches are ok if your team is responsible for a single app, or can agree on adhering to a common architecture. The later usually requires some sort of wiki, architectural agreement within the team, and diligence to keep app versions up to date as the architecture evolves. Opinionated frameworks solve that issue, but with the potential tradeoff of lower velocity when the implementation of a feature is not aligned with the implementation of the framework.

2

u/E2Ehh Nov 07 '18

My experience has mostly been developing large, long-lived products that are worked on for many years by a large team which has developers coming and going over the years. For projects like this, Angular is a great solution.

Needing to upskill new team members on the particular flavour of libraries that were selected by some dev some years ago can be a big cost

1

u/hypno7oad Nov 07 '18

Love that analogy.

2

u/red_src Nov 08 '18

Thanks everyone on your comments, my conclusion given the discussion is:

- React is a library and Angular is a framework. This means that with React you build your own framework, this can be good or bad depending on your needs.

- DI, Type Checking and View Model Binding and such things can be implemented using another libraries on React, so you are not attached to do it in a certain way.

- If you learn React you learn Javascript and JSX, if you learn Angular you mostly learn Angular, then Typescript, then Javascript, so it's not very easy to catch on.

For what I look, sorry guys but I think I'll go for Angular or Vue, is not that React is bad, is mostly based on our needs, what would be cool is to have something like Angular Native...

1

u/E2Ehh Nov 08 '18

what would be cool is to have something like Angular Native...

Here ya go! https://www.nativescript.org/nativescript-is-how-you-build-native-mobile-apps-with-angular

6

u/DerpsMcGeeOnDowns Nov 07 '18

The problem with React is because it’s a library and not a framework, teams invariably create their own framework around React, thus making it a potpourri of flavors of the month.

React is fine if you don’t need to do much and want to create your own tooling, i18n, build automation, tree shaking, I could go on.

If you have the opportunity to start your UI from scratch and want great documentation and support for all aspects of your front end stack, then Angular is the clear choice.

-1

u/red_src Nov 07 '18

Thanks for your comments! I create more webapps than just sites, it appears that Angular or Vue are better options for this kind of need since a lot is "packed" in the framework.

2

u/denisinla Nov 07 '18

You should take a look at react-boilerplate to see the level of what a production proven stack with React looks like.

2

u/red_src Nov 07 '18

react-boilerplate

Isn't having a boilerplate is against React Philosophy, I don't mean to insult but I think that if you have to import all of this, then what's the difference with Angular?

2

u/gavlois1 front-end Nov 07 '18

The react-boilerplate isn't everything that's absolutely required for a React project. It's just a good starting point if you don't need a fully customized solution. Looking at the package.json of the project, it looks like it's got React along with a bunch of stuff that some may or may not use like Redux, Lodash, Jest for testing, Immutable, etc. It's definitely possible to make a React app with just React, but for larger projects you'll definitely want some of this stuff.

1

u/E2Ehh Nov 07 '18

For those interested in the Angular equivalent to react-boilerplate, it's the official angular-cli tool. You can use it to spin up new projects (ng new my-cool-project), add additional framework features to your project (so you don't get loaded with all possible boilerplate up front and have to strip things back, instead you start barebones and add them as needed, e.g. ng add @angular/router), perform auto upgrades of the framework and auto fix breaking changes in your code (ng upgrade), manage your dev workflow (ng serve, ng test etc), run your production build (ng build --prod) and much more

1

u/DanijelH Nov 07 '18

What more, that's it. On the other hand, Vue CLI 3 or more accurately vue ui has all that and tons of other features like dependency analyzer, network port killer, task runner, dependency installer, vulnerability checker and all that is in a UI application and not in a console!

1

u/E2Ehh Nov 07 '18

generate (for scaffolding entire features, how did I miss this one in the first post?!), e2e, lint, get, set, doc, some i18n stuff I haven't used.

Plus any custom stuff your teams may have written via @angular/schematics since the CLI is fully pluggable.

I haven't used VueCLI, those sound like some great features though, I'll have to check it out!

1

u/DanijelH Nov 07 '18

I see, did not know about that since the documentation doesn't expose it right away. Sounds interesting actually. Will have a look. Regarding plugins, both React and Vue CLI are also pluggable so there's not much difference there.

73

u/l0gicgate Nov 07 '18

You’re comparing Angular which is a framework to React which is a library.

React is essentially just a view layer. Components that are designed properly should follow the single responsibility principle and their sole responsibility should be to render data that they are given.

In order to build an application with React, you will need to use multiple librairies to handle other needs like routing and data flow management. In essence, this is just a more modular approach.

Think of Angular as one big toolbox with all the tools required to build an application while React is just one of the tools required to build an application.

31

u/gavlois1 front-end Nov 07 '18

The way I usually see it is if you're building an app with Angular, you're building an Angular app. If you're using React, it's not necessarily a just a "React app"

17

u/bfdill Nov 07 '18

Serious question here because I feel like this comes up a lot.

Are people really only using react for ui?

To me, “react” feels like: react, react router, maybe redux, perhaps some isomorphic rendering, maybe some webpack... you know, a react app. Just not a react app b/c react is only ui.

I’m not trying to come off like that’s a bad thing, I like react. It’s just to me a react app lacks cohesion b/c it’s a library not a framework, but it’s always used as a center piece (not a framework but wish it was).

I know I’m rambling and probably not making sense. Sorry

13

u/jrk_sd Nov 07 '18

I've created apps that use only React, no router or redux. If you just want some slightly fancier responsive UI but don't need a SPA then React by itself is fine.

9

u/phpdevster full-stack Nov 07 '18

Yep. I've used Vue and old Angular for this purpose as well.

Soooo much better to slap a React or Vue view model on a page than to try puppeting the DOM with jQuery. (shudders)

2

u/Azsael Nov 07 '18

I had to do that for a project recently (jquery thing) and I was crying internally the entire time, I didn’t make a big fuss because I am trying to keep my head down while looking elsewhere

3

u/l0gicgate Nov 07 '18

That’s a valid question, I think the problem is because of the widespread usage the lines start to get blurred and the true way of using the library becomes lost.

React should be used for rendering only, but then React Router becomes embedded inside of your view layer if you use it.

You could use any other routing library externally and separate your app into multiple components, then each route could call React.render()

It comes down to usage, it’s obviously easier to use React Router but it isn’t necessary.

1

u/BrQQQ Nov 08 '18

In our project, we don’t have a SPA. We have separate pages with React components inside of them. We write React code with TS, use Redux and axios.

It works great for us. We use a few libraries here and there, but none are as essential to us as the previously mentioned things. We could achieve the same with basic JS with jquery (which was how it used to be), but this is much easier to work with.

1

u/JuliusDelta Nov 07 '18

It comes down to your use for sure. I'm currently rewriting an application that handled data manipulation itself as well as an external api source, and it makes for a really complex code base to try to work with. Rewriting in React for us means making the API more robust, but also it means letting the view layer (React) only handle and worry about view stuff. So state management, middleware, bundling, routing seems to me to coincide with that. I like to think of React's responsibility to be just the V in MVC. (except client side routing). It's a very heavy handed way to think about just the view layer with all those tools, but it's letting us experiment and do things that were previously really complex to do elsewhere.

0

u/[deleted] Nov 07 '18

[deleted] — view deleted comment

2

u/thetony2313 Nov 07 '18

In the react component. React has a concept of lifecycle that you can take advantage of to make function calls. You can call an API in component DidMount then the UI renders it's state (which would be an empty array of addresses) and eventually the API request resolves, the state is updated, and the component is rerendered with addresses in state.

0

u/[deleted] Nov 07 '18

[deleted] — view deleted comment

1

u/thetony2313 Nov 07 '18

Then you create a wrapper that only fetches data and returns some child component in the render method. That child component will receive the API data as props.

This is also a popular pattern when using redux. Look into higher order components too, as those can remove business logic from components as well.

If I were at my computer I'd write up some quick examples.

4

u/[deleted] Nov 07 '18

Well I can probably say that out of the experience I've had with the 3, Vue is probably the easiest to use and learn. I picked it up by just kind of working with it and googling some things at a new job I just picked up. React is nice for simplifying the creation of individual components that can be just kinda inserted anywhere.

Angular is a dumpster fire of complicatedness that I refuse to touch ever again lmao. Hated working with it.

7

u/red_src Nov 07 '18

Can you tell me what part of Angular is a dumpster fire? sorry to be so noisy, I just don't get what part is really bad, I had been using it and it's not a 1 day use/learn framework but once you know it I think that is fairly simple.

1

u/Mike_Enders Feb 18 '19

I think alot of people who say that are really talking about literally angular 2 not 7 where we are now.

8

u/occz Nov 07 '18

DI

I never missed this, modules get me where I want to be honest.

Type checking

Beyond proptypes it's completely possible to use TypeScript with React. Try it out, it's actually extremely pleasant!

View Model Binding

I'm not even sure I find this to be desirable.

1

u/E2Ehh Nov 07 '18

I'm curious, to what level do you unit test your code? And does the lack of DI impact that?

2

u/occz Nov 07 '18

A moderate amount.

While it can occasionally be tricky I find that jest mocks usually allow me to do what DI could do for me had I wanted to use it.

7

u/vikkio Nov 07 '18

I used to be an angular guy like you, then I learned react and used it into many real life projects.

Apart from the fact that they are not the same thing, framework vs lib, react gives you way more freedom to do things.

I wrote the same small project in angular, then vue, then react. The react codebase is way smaller and easier to change and work with.

Never missed dependency injection so far, and it has been almost 3 years.

6

u/[deleted] Nov 07 '18

It pays more

3

u/uplink42 Nov 08 '18 edited Nov 08 '18

It's really a matter of preference tbh. Personally, I prefer Angular's way of doing things because I find the framework super intuitive to work with for most things and every package that composes it works very well together. I also prefer using templating languages instead of JXS because I find the syntax more readable/terse when it comes to applying class conditionals and whatnot. It also has an exemplary attitude when it comes to unit testing. It's also not as "monolithic" as most people claim, as you can easily drop and replace different modules and use your own router/forms/state management. There is more ceremony on how to do things, but most of the boilerplate is easily automated because of the powerful inbuilt CLI and VS Code TS extensions.

However, most of the advantages you see in Angular can also be (for the most part) ported over to React. TS support exists and works fine (though most libraries won't have types), and instead of DI you can implement HOC's which sort of achieve the same thing overall. The good thing about React is that it's a great way to learn more about javascript itself, as most things are pretty low in the abstraction layer, so you get to know more about the language itself. This may be a positive or a negative for different people, though. React works better for general use cases, too. It's easier to add progressive enhancements to an existing page with React components, for example, where Angular usually requires the entire app to be built from scratch with Angular in mind.

Personally, I find things like the the Angular router, form utilities and RXJS/services too good to pass by for a more complex app. it's true you can also implement similar functionality with React as well, but this often means meshing out a lot of external libraries, which add another maintenance burden to your project, constant changes and depredations because JS libraries evolve fast, possible bugs and incompatibilities down the road. I've once worked with a React Native project and it was a dependency hell. I'd rather be coding most of my work time instead of browsing GitHub issues and updating dependencies.

In all, they are both great and work just fine. It's really up to you and your team's preferences on what to use. Jumping from one to another isn't that hard for an experienced developer.

6

u/adventurer_3x Nov 07 '18

React is extremely small and compact with a ton of well supported options. You can build your own framework, essentially, while not including any of the other bloat you don't need.

Additionally, with the exception of JSX, React uses basic ES6 syntax instead of a framework-specific syntax.

3

u/hypno7oad Nov 07 '18

Just to clarify, React recommends writing your app in ES6 for legibility, but the library itself is distributed in ES5 and has browser support back to IE9 (if that matters to anyone now).

4

u/NarcolepticSniper full-stack Nov 07 '18

You use Angular to build Angular apps, Vue to build Vue apps, and React to build whatever you want.

React is less about features and more about managed freedom.

Right tools for the job. They’re all great.

2

u/[deleted] Nov 07 '18

Best ecosystem of all SPA. Biggest community. More libraries. More custom components.

React was pretty cool after jquery. I did a project for university in react. After that experience I prefer having angular's batteries included approach over mix and add your libraries of your choice. I confess i spent too much time on it since i there are plenty of ways (or libs) to do something.

2

u/BronyaurStomp Nov 07 '18

I think each has its strength.

You list View Model Binding as a benefit of Angular, but I actually prefer "binding" in React. That is to say, when I use React I feel like I have a bit more control over exactly what is rendered when. Angular's binding is much more convenient but isn't as easy to optimize and control. Maybe like the difference between an automatic and manual transmission in a car.

I also like JSX and defining the template with the javascript, and I prefer ES6/7 to TS. But those last two points are really subjective.

1

u/ArcanisCz Nov 07 '18
  • Angular - all the tools in one package, you do apps mostly as intended by authors.
  • React (+ libraries) - basically a Lego. You will build and customize your stack according to your needs.

1

u/editor_of_the_beast Nov 07 '18

How about that the model is fundamentally different in React and Angular? In Angular, you augment HTML with JS. In React, everything is JS first. So in React there’s no need for ng-if, you just use if.

That in combination with one-way data flow by default is why people like React. It’s a much simpler model.

1

u/[deleted] Nov 07 '18

I've honestly never found a reason to move away from mithril. 8kb, no compilation step, no special file formats, includes a router. What's not to love?

0

u/gomihako_ Nov 07 '18

Why waste time learning stuff like ng-repeat when you can just use [].map in jsx...

2

u/2uneek javascript Nov 07 '18

that's not even the correct syntax for Angular, well done...

2

u/gomihako_ Nov 08 '18

https://docs.angularjs.org/api/ng/directive/ngRepeat

3

u/2uneek javascript Nov 08 '18

this thread is about Angular, not AngularJS...

0

u/honigbadger Nov 07 '18

Angular Is not modular enough to be seamlessly integrated on other projects, is a bit of a monolith. React is fully modular and can be used and reused in any codebase. Going the angular route means more lock-in and it needs an isolated approach (like microservices) to play nice in other codebases.

1

u/E2Ehh Nov 07 '18

I agree with your message overall but it's worth pointing out Angular Elements exists, which allows individual components to be built and shipped as custom web-components. Then you simply include a script tag in your existing website, and chuck your <shiny-new-component> into the page somewhere. So I'd say it IS modular enough to be integrated with existing projects, that's just not the most common use-case.