4 ms·
The article seems to be biased in favour of Angular. The option of using any flavour of JS or compiles-to-JS is presented as a negative for React, compared to
by happyslobro 10y ago
The article seems to be biased in favour of Angular.
The option of using any flavour of JS or compiles-to-JS is presented as a negative for React, compared to Angular's decision to go all in on Typescript. I would say that being able to stick with standard JS, for varying values of "standard", is a good thing for library developers and very large corporate teams. Having options like Elm or Clojurescript are good for small teams or individuals who are looking for some advantage over their larger competitors, such as a higher chance of building a correct system on the first try, or being able to build faster than me to a smaller, more expressive codebase. It was this line of reasoning that led me away from JQuery back when everyone seemed to think JS = JQ. When I made the jump to Clojure/script, I scored an auto generated Swagger interface for the back end, which saved a ton of effort on documentation and Q&A, and the test suite has stayed very simple and small - I ended up not needing anything like Sinon's mocks and spies.
The infographic suggests that because Angular tries to take on larger role in an MVC framework, the complexity that resulted from that decision makes it better suited for advanced developers. React, with it's tight focus on the View, is better suited for amateurs, who will then have to make a bunch of architectural decisions (Redux, Immutable, React Router?). I would say that the opposite is true; an all-in-one framework is best suited for younger developers who have the humility to know that they do not want to make these types of decisions themselves. If you are going to build a large application, then the ability to integrate a selection of third party solutions for various architectural concerns can save you a huge amount of risk, in the greater scheme of things, but evaluating those options and designing solutions for the issues that come with multi-way integrations is a task for experienced developers (although there is plenty of low hanging fruit in banging out UI components and wiring up CRUD APIs for junior devs).