4 ms·

But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn

But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn't provide all I need. By project I mean some backend api and front end SPA

pluma 11y ago
That's fallacious reasoning. React is less full-featured than Angular is less full-featured than ExtJS and so on. You're not going to use a single tool to build your project. You're almost guaranteed to using different tools to build your frontend and backend (even if some of the tools may be the same or some of the code may be shared). You're extremely likely to use more than one tool for either of them. Nothing will "provide all [you] need". If it did, it wouldn't be a library or framework, it would already be the finished product you're trying to build. React does one specific thing and it does it incredibly well. If that thing is what you need: great, you can use React as one of the tools to build your product. If it's not what you need: don't use it. You shouldn't worry about whether something provides everything you need, you should worry about whether what it provides is actually what you need or not. Angular does a lot more things than React does. Logically that means it's less likely to be a perfect fit for your project. You're more likely to find out that it does something in a way that doesn't work for you, simply because there are more things it does. But it may also do enough things in just the way you need them to be done to be worth the few places where it doesn't fit your project perfectly. It's always a compromise. Unless you have unlimited time and can develop the perfect tools yourself, you're going to have to make a few sacrifices along the way.
iLoch 11y ago
If it doesn't provide all you need then it's easy to involve other non-React code to make it all work. That's what's so great about it being a library - you're free to implement whatever pattern you'd like around it. For me, that's Flux/Redux (I use actions to call to well defined services) but it really doesn't matter. I think there's a list somewhere of patterns that are difficult / non-ideal for React but I don't have it in front of me. For 99% of use cases React really isn't going to be a detrimental choice as long as you choose a good pattern to surround it with.

pluma 11y ago

That's fallacious reasoning. React is less full-featured than Angular is less full-featured than ExtJS and so on. You're not going to use a single tool to build your project. You're almost guaranteed to using different tools to build your frontend and backend (even if some of the tools may be the same or some of the code may be shared). You're extremely likely to use more than one tool for either of them. Nothing will "provide all [you] need". If it did, it wouldn't be a library or framework, it would already be the finished product you're trying to build. React does one specific thing and it does it incredibly well. If that thing is what you need: great, you can use React as one of the tools to build your product. If it's not what you need: don't use it. You shouldn't worry about whether something provides everything you need, you should worry about whether what it provides is actually what you need or not. Angular does a lot more things than React does. Logically that means it's less likely to be a perfect fit for your project. You're more likely to find out that it does something in a way that doesn't work for you, simply because there are more things it does. But it may also do enough things in just the way you need them to be done to be worth the few places where it doesn't fit your project perfectly. It's always a compromise. Unless you have unlimited time and can develop the perfect tools yourself, you're going to have to make a few sacrifices along the way.

iLoch 11y ago

If it doesn't provide all you need then it's easy to involve other non-React code to make it all work. That's what's so great about it being a library - you're free to implement whatever pattern you'd like around it. For me, that's Flux/Redux (I use actions to call to well defined services) but it really doesn't matter. I think there's a list somewhere of patterns that are difficult / non-ideal for React but I don't have it in front of me. For 99% of use cases React really isn't going to be a detrimental choice as long as you choose a good pattern to surround it with.