ReactJS vs. AngularJS
freezeprosoftware.com
freezeprosoftware.com
| metric | AngularJS | React |
|--------|-----------|-------|
| speed* | 1.35s | 310ms |
Also, the OP recommends AngularJS for "Experienced developers and coders", while React is for "Casual developers and designers"
edit:
The narrative text is not much better. This sounds like something generated by a Markov chain:
> I’ll just mention that “one-way binding” in AngularJS 2.x and in ReactJS isn’t the same thing. The binding mechanism is completely different. It provides wider functionality in AngularJS 2.x compared to ReactJS. We’ll have to wait and see how it works in AngularJS 2.x. In ReactJS, the one way rendering flow is very straightforward, fast and easy to understand, debug and trace in comparison to “two-way binding” implemented in AngularJS 1.x.
Yea, I'd like the author to explain why.
It's just so much easier to build large projects when the framework solves common problem for you in an opinionated way. Saves a whole lot of arguing among developers and reduces the need for education when transferring between projects.
Every time I've tried to pick up and learn Angular or React or etc, I've gotten the impression that it is wildly over engineered and ultimately just bloat. Like if I tried to do something with it, there would be 100 different unnecessary things going on in the background.
I've been happily and successfully building javascript heavy apps for the client side which work very well and are quite functional without the need for a giant framework. I never feel this way about the server, on the server frameworks seem elegant.
Why is it as soon as I move client side I'm overcome with the feeling it is over engineered? My theory is that none of these things are even necessary there.
Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days.
I just don't see it.
[1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-...
> Wouldn't it be easier to draft a set of design principles for the project?
I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.
I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users.
All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.
I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.
I would really appreciate it if you'd share the application structure you use when building a client side MVC with vanilla JS/Jquery.
I know there wouldn't be a single structure to rule them all, but I think if developers start sharing structures that work regardless of frameworks used, it would be much better than sharing frameworks that are very complex and get replaced every year.
Views are very simple. There is generally a class instance which is using a DOM element somewhere. So I store a reference to that element on the instance. Then I have a simple object containing references to all of the important elements within it. I have a function which generates the element if it hasn't been created yet and adds it to the page. Now I can change whatever I want to about the element or any important elements within it. I use classes like "is-hidden."
Sometimes I'll decouple the UI from it's functionality. In which case I usually implement a simple eventer system on the underlying code which the UI connects to for status updates.
Bingo bango. I haven't run into a circumstance yet where any one file was longer than maybe 200-300 lines total. It's simple to read, it does anything I want.
I have never needed to construct anything client side that warranted laying it out like a server implementation. But maybe that's my issue, I'm thinking too small and other people have a better idea of what the future of the web looks like than me.
I still prefer having control.
I started web development in the 90s where small size and high speed were key. I try to do the same now. I'll only use jQuery where possible, but if I do use a framework/library it will be to prototype something or to get something completed as I am under time constraints. If I get a chance I'll port it all over to plain JavaScript.
Modern webpages are just too big.
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).
It has one way data binding, like React, that is simpler to reason than 2-way in Angular. Riotjs is the framework that I recommend.
In Angular 2 there are multiple data bindings syntaxs: There is one way up, one way down, or 2 ways. In Riotjs, there is only one, and you can use it with the Flux architecture or similar for a simpler, easier to reason about, and proven architecture. In my opinion Angular 2 is over enginered, with a lot of stuff that you can easily do without it. See React. And by not having over enginered stuff, you benefit of a simpler architecture that is easier to learn, and simpler to use. I have found that simplicity makes many people more productive. And React and Riotjs both are simpler than angular 2.
I used React for a year now and would probably consider Preact for new projects. I can use most of the React stuff I already know with a smaller and faster framework.
The social share widget makes the text very annoying to read ! It's ON the text
Well.. I wish I could approach every tech choices with this simple mindset.
I would like to point that with ReactJS you have a suggested way of implementing the data-part of your application by using Flux-like architecture ( Redux, Fluxible, AltJS, etc. ). This combined with the views itself also brings more complexity to the application.
Still I believe that 5-6 years ago ( when Backbone was the way to go, most cases ), the current state of front-end is far more complicated ( in terms of build tools, css / html defined in JS files, hot-reloading, isomorphic code libraries, etc. ).
I'm still missing a front-end workflow, supported by a big company, which reduces the complexity and increases stability.
That's a wonderful idea /s