21 ms·
On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph
by dragonsh 7y ago
On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products.
Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it).
Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it.
React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work.
Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.
- crubier 7y agoMaybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management). It feels cleaner and more solid.
- Cthulhu_ 7y ago"Built on shaky grounds" needs a citation and additional explanation. I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.
- crubier 7y agoThe churn between angular versions, stemming from the limitations and inconsistencies of two way data bindings and others, are what I mean by «shaky grounds». Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.
- tashoecraft 7y agoThere is so little churn between angular versions. Angular 1-2 was a big change and they should have renamed the framework. But you have to understand how angular 1 came into existence. It wasn’t planned to be used by everyone, it was just solving some problems experienced by a couple devs and it spread like wild fire. The team that eventually took it over and grew around it recognized it had some problems scaling and being used for large applications. They knew they couldn’t just change angular 1 to be what it needs to be, so they made a big switch. They put in patterns that benefit large apps, typescript, observables, the choice of two way binding or one way binding, better DI system. Everyone says react isn’t opinionated, and for developing an enterprise app that just sounds like a nightmare.
- IggleSniggle 7y agoI'm not sure what churn you are talking about, unless you mean the Angular 1 - Angular 2+ split? ng update is ridiculously easy, and the automatic code rewriting is generally sensible and easy to follow. When there are breaking changes, Angular takes care of the modifications for you. Generally I've felt like those changes resulted in a better expressed codebase (eg RxJS syntax improved massively from 5 to 6, lazy loaded routes are expressed with arrow functions now, etc). I assumed the React community was also migrating versions with codemods, but maybe React does not introduce any breaking changes?
- ghego1 7y agoYour argument is flawed with a very opinionative starting point, which is that Angular wouldn't provide a solid foundation. This is, at the very best, very debatable. In my experience, it's the very opposite. Angular gives you very solid foundations as it's a proper framework that ships everything you need to build scalable apps. So you start from something small, and as you grow you know you can do so without rethinking the foundations of the app, as they are provided by the framework, which is Google guys, which means most likely people with a lot more experience than the average front end dev. On the contrary, react leaves basic choices (the bricks you mentioned) to the user. While freedom can be good, it also implies that errors will be made, so you are a lot more likely to build on shaky foundations.
- JMTQp8lwXL 7y agoThe real difference between the two frameworks boils down to developer happiness. In Angular, all of the choices are made for you. For some, the lack of autonomy and agency when writing Angular applications makes those developers sad. It's hard to take pride and ownership in your work when 90% of everything has been decided for you, and if you try to eject from the "Angular" way of doing this, you end up just writing bad Angular code. Choice to pick the best of breed solution to each smaller problem within the context of building an enterprise grade web application is at the heart of React. I get to look at all published routers and choose the one with the most intuitive API to me: I get to look at bundle sizes, and consider trade-offs.
- tashoecraft 7y agoThis is the biggest “meme” about angular and it’s so unbelievable wrong. It shows that you haven’t used the framework if you think all the choices are made for you. Instead of spending all my time analyzing different open source packages for every single thing you do, you just have access to a first class supported solution. IMO, lots of the react ecosystem is built on engineers trying to show off. They get fancy coming up with a solution, writing a unique library, and there’s no reason for this. Everyone likes to think their code is unique and special and great, but it’s not. We don’t need to reinvent the wheel all the time. So many of these apps are going to need to be rewritten in a couple years because of how poorly architected they are. That’s not a problem of react, but it’s a problem of react devs who take a small view library then build a framework on top of it.
- gridlockd 7y ago> You add state management, templates, router and 1000's of npm packages to do anything simple... You don't actually have to do that. React just turns your data into DOM elements, most of the time it's a simple transformation. Otherwise, how you architect your application is up to you. You don't need to overcomplicate things by following the latest trends, you don't need a ton of dependencies to do simple things. You don't need templates at all. Angular is complicated by default. It makes design decisions for you that you probably wouldn't have made, and then sometimes it reverts those decisions, making you clean up the mess. React code very rarely breaks. > Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons. Angular bundles are huge by default, it has a long way to go. Tree shaking already works with React, you just need to set your build up that way. Also, don't assume that a compiler will make your build smaller, it may well inline a lot of stuff and end up larger.
- hmcdona1 7y agoAlthough Ivy will bring nice improvements all around, you won't see the 12kb bundle sizes you are talking about in this initial release of Ivy. `renderComponent` is the key that will enable that down the road in some fashion (you can play with it now), but I appreciate the teams approach to easing the framework into major changes like that.