-* "based on loading 1500 rows [according to some 2014 blogpost]
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.
I'd love to see the percentage of AngularJS or ReactJS applications that actually render 1500+ rows at a time. I feel like we're benchmarking (and talking about) the wrong things.
Every time I've noticed I'm on a page using Angular or React the experience feels terrible. Like there are 100 different unnecessary things going on in the background. Though to be fair these are only the times I've noticed I'm on a page using one.
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.
Completely agree (read this after posting my comment above). Having rules about structure & organisation rather than frameworks that would have their own rules seems much more pragmatic.
> Wouldn't it be easier to draft a set of design principles for the project?
Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years.
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 suppose in a sense, it's easier to enforce policies through a library than it is to tell a dev "do this" or "don't do that'".
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.
Wow I never thought I'll see someone else with my same concern. I really hate using too much third-party code (to the point that I need a generator just to start), and I like knowing what each and every file in my project is for/does.
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.
I create a separate file for each concern, and I dump them into the same directory together. If the files list become significantly long I separate them into subfolders of more general concerns. For example a folder for everything to do with "recording" functionality.
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 have to agree with this. There is just so much unnecessary stuff going on in modern webpages. All too often I see relatively simple webpages with jQuery/Angular/React/Bootstrap/Telerik and numerous other libraries references in the header.
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.
I have used react and angular2. Plus some other frameworks like polymer and vuejs. And have studied a few others. The one that makes me more productive is riotjs. Simple, minimalist design, yet it has the best implementation of components of them all. Components are custom tags written in html, with scoped javascript and css styles, in a single file. This is easier than React because your html is actual html, not trapped inside of render jsx functions. It is easier than angular, because it is simpler, faster to write and read.
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 Components are also custom tags written in html, with scoped javascript and css (you can choose the scoping) in a single file (also optional). So how is it different?
The base structure may be somewhat similar. However Angular 2 makes things more complicated with more stuff: dependency injection, class decorators, services, etc. Riotjs takes a simpler approach, inspired by React, but improved with better design. In Angular 2 inline html templates that are not syntax-highlighted by code editors. Full html templates require spliting the component in separated files.
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.
Angular2 also felt a bit over engineered to me. With text templates and component decorators.
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.
Cars and motorbikes are two different things but they can be compared as means to get from one place to another. It isn't very hard to use the same analogy with angular x React concerning the development of web interfaces.
While I'm totally pro-React for my own development projects, I appreciate the fact that Angular 2 comes will a full set of predefined practices, so that people who work with in are more "interchangeable" than in case of React. If two different developers write a project in React, the project will likely have very different sets of libraries and approaches. With Angular 2, it's the opposite: two different developers will write their Angular 2 projects more or less the same way. This can be valuable in enterprise environment.
Yes, I think this is what will make Angular 2 win out over the long run. Unless an ubiquitous React bundle comes along to solve that problem with the React ecosystem.
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.
Considering my arguments above, I can conclude that React and Angular 2 have niches that only moderately intersect, so it's not going to be a single winner out there.
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).
I've never used AngularJS, so I would stick my comment to ReactJS.
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.
42 comments
[ 3.2 ms ] story [ 92.8 ms ] threadThe social share widget makes the text very annoying to read ! It's ON the text
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.
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-...
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.
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.
That's a wonderful idea /s
Well.. I wish I could approach every tech choices with this simple mindset.
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.
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).
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.