JavaScript
Article
By Mark Brown

Forget Angular & Ember, React Has Already Won the Client-Side War

By Mark Brown

This article was peer reviewed by Nilson Jacques, Chris Perry and Thomas Greco. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

In SitePoint’s forums I stumbled across a thread entitled So Many Frameworks where Guido, confused at the sheer number of options available, was asking which JavaScript framework he should adopt to make his application more dynamic. Given what I’ve been seeing in the industry and having used it myself, I stated that React had already won the client-side war. Fighting words like those need a bit more explaining, so here goes.

React is not just the hot new kid on the block, but a unifying paradigm. It can serve as a foundational technology for web applications that we can build on top of with confidence, knowing that it will not be replaced next month by its hotter cousin. Let’s take a look at React’s place among the current crop of MVC frameworks, exploring its strengths and ending with a prediction about where JavaScript development is headed in the future.

Client-Side MVC

For the past few years many smart people have been trying to build the perfect framework for making single-page apps — applications rendered by JavaScript which have improved perceived performance by responding instantly to user input and data changes over time. Guillermo Rauch’s article 7 Principles of Rich Web Applications is one of the best rationales for why this is important and the things we should consider when building them.

You can find examples of how these types of applications are built at TodoMVC, as the name suggests they have traditionally been made up of Models, Views and Controllers.

React enters from left of stage

When React was first announced it looked a little odd. It focused solely on the View layer, and had no Models or Controllers. The code examples were written in a strange syntax called JSX which appeared to many like a backwards step towards Ye’ Olden Days where it was common to mix HTML and JavaScript together.

No information was given on how you should structure your application other than that of a component hierarchy — composable chunks of UI that could re-render efficiently whenever state changed. React took a few notable stances against popular ideas that existed in this space, features like two-way data binding and templating were blasted as bad ideas that are best avoided.

Widespread Adoption

React quickly achieved critical mass. It’s hard to find JavaScript related mailing lists, conferences or meetups that don’t mention React these days. All of the local development teams in my city seem to be adopting React and contrary to other popular frameworks the verdict seems unanimous — everyone who I’ve spoken with has touted the merits of one-way data flow, component hierarchies and simple explicit renders, making the task simpler and the code more predictable.

React’s adoption has been surprising to me because of how volatile the JavaScript scene is. We rarely so broadly agree on anything. There are pockets of people loyal to one framework but most of us have jumped from framework to framework getting frustrated along the way with certain patterns that introduce complexity and bugs. I haven’t yet heard of a single case of people moving away from React due to these frustrations, not since jQuery has it seemed like we have had such a clear winner out in front.

You Had One Job React, One Job.

Its focus on the view layer means that it’s considerably less opinionated than other frameworks that attempt to solve every problem. Its wafer thin API means that there’s really not much to learn and it doesn’t warrant more than a handful of pages of documentation. This is a great help to those learning and it makes development simpler too, as you don’t have much cognitive overhead. Wherever possible, React opts for plain JavaScript constructs and language features rather than custom APIs or templating languages.

This design is also attractive to JavaScript developers who seem to favor focused utility libraries such as Underscore and Moment which do one thing well, very much the Unix philosophy. Doing one thing well has also allowed room for people interested in the project to contribute their own pieces to the React ecosystem. As a result of this projects like React Router, Redux and CSS Modules have arisen.

React Components Are Simple

Components are responsible for small isolated chunks of UI, they accept data and render consistently, every time. Front-end developers, back-end developers and designers can easily understand and contribute to components because they look like HTML and the minimal API footprint means that you can learn what you need to know about components in a day and start contributing right away.

Server Rendered HTML

React makes server-side rendering trivial because components can be thought of as functions that take data and return HTML. This design makes it easy to integrate server-side rendering into any server-side programming language or framework.

In the early days of client-side MVC we broke the web with things like hashbang routing and huge loading times before anything made its way to the screen. We also broke search engine crawlers by rendering everything with JavaScript when the page had loaded. Since then we’ve learned from our mistakes and are taking these core tenets of the web seriously again — URLs, server rendered HTML and fast load times. React shines here where other frameworks have struggled.

DOM Updates Are Messy

Backbone was an important milestone for JavaScript. As the first and most prominent effort to bring MVC to the client-side, it showed us a new way that we could structure our applications. One of the first things it mentioned in its documentation is that it’s a bad idea to maintain your state in the DOM. When the DOM remains the source of truth your app quickly becomes brittle and hard to follow. It becomes impossible to know which piece of code changed which element. Backbone encouraged an ideal of always re-rendering views based on the current state of the world, React enforces this same idea with it’s pattern of one-way data flow.

React components don’t define the transition between states. Instead, they explicitly render the view based on their current state, completely eliminating this task of manually tweaking the DOM. Its one-way data flow prevents the DOM from being the source of truth.

Admittedly, this makes certain tasks such as animation more difficult because those are cases where you do want to define transitions between states. For the vast majority of cases though, it’s much simpler to only concern yourself with the final state of how the component should be rendered.

The Future

React will continue to grow in popularity and we’ll see more supporting tools and projects. As the ecosystem around React matures, the library may change but the core ideas of one-way data flow, component hierarchies, explicit renders and virtual DOM reconciliation will live on.

React Native has shown how a simple view layer can be re-purposed to construct other types of UI as well. There’s been a shift in the industry towards this pattern of building UI’s and it’s not going away any time soon.

In short, React has won and the future is bright.

Thoughts?

Do you agree that the principles of React will live on, or will we find a better idea next month?

Have you started using React? What are your thoughts so far?

Be sure to let me know in the comments below.

  • Gerard Sans

    What war? Tools are only tools. Remember that any skilled developer can use any tool to successfully build whatever they need. What are you trying to say? People is building applications that help other people using Ember or Angular or plain JavaScript every day. Is fine to have personal preferences but they are only that.

    • markbrown4

      Don’t be too concerned with the title, I agree with you and there’s nothing wrong with using other or no tooling. If there’s a war it’s the fragmentation of frameworks that makes learning JavaScript and joining other projects difficult. It seems to me that React has already changed the direction of Ember and Angular and that those frameworks will start to look more like React as time goes by.

      Much like Rails won the server-side framework war and frameworks in every other language started to look like Rails. Many people still prefer alternative tools but once in a while something comes out that has a huge influence over tool makers, React is doing that for JavaScript at the moment.

      • pauleveritt

        “Don’t be too concerned with the title”…perhaps you could talk to the person responsible for the ridiculous click-bait title. :)

        I disagree with the premise that Angular 2 looks just like React. In some ways yes, in some ways no. In some ways it (and Aurelia) has leapfrogged React, which is normal for something new. And I firmly disagree with the premise that “Angular has been defeated” in some kind of war. Geez. What is this, a GOP primary?

        • 1jpablo1

          I’m curious about your statement that React 2 has leapfrogged React. Can you elaborate?

    • pauleveritt

      Indeed. Any article that starts with “Forget Angular and Ember” and casts things in war terms is intentionally provocative. I wonder what it hopes to accomplish by leading with a poke in the eye. Certainly not “take my ideas seriously.”

    • gwhosubex

      the “war” is a metaphor for market dominance and majority adoption. don’t read so much into the animosity notion of the term.

      Would using the term “non-violent, non-confrontational, creatively-destructive, friendly competition” have really changed anything? Or simply using “competition”?

      This is all understood that products compete. In that sense it’s a war. Bread store A and bread store B compete and are “at war”. But we don’t need to clarify this metaphor, since it’s pretty obvious.

      • Gerard Sans

        Being obvious doesn’t make it any more right.

      • Chlonak

        It’s silly to go with something simply because “it dominates” the market. It’s not always the best that dominate, think widows 98. Suggesting that something is better because it “dominates” and calling for a mass movement of dumb adoption only makes flocks of sheep run in a same general direction.

  • I think Polymer is an alternative to React. It is also based on components and uses standard web technics. The drawback i see is the lack of server side rendering in polymer.
    But if i had to choose, i would take polymer because it is natively integrated in browsers and so more performance efficient.

    • Ani Bal

      Hi, in which way do you think polymer is more performant than react?

      • Because the native implemented shadow dom is native, and so faster from the start.

      • Because the native implemented shadow dom is native, and so faster from the start.

  • martinczerwi

    This is a bit like comparing oranges an apples. I’m with Angular, because it offers a full solution. I have to say, I didn’t really get React on first sight, though I’ll probably visit it again sooner or later.
    For people being comfortable putting their frontend together by hand (think routers, models, DI or containers), React is probably the better solution. Like you say, “Does one thing well”). But for beginners in that whole clientside MVC thing, Angular or Ember offer more guidance, and a more complete solution.

    • Artemiy

      I honestly was quite overwhelmed by Ember (didn’t see too much Angular), and I don’t particularly like React because it’s not that easy to integrate it with CoffeeScript. My personal favourite right now is Knockout, because, in the end, it’s just JavaScript.

      • markbrown4

        React does work well with CoffeeScript because it’s just JavaScript. If you’re referring to the JSX syntax there’s CJSX which gives you a seamless mix of JSX syntax with CoffeeScript.

      • markbrown4

        React does work well with CoffeeScript because it’s just JavaScript. If you’re referring to the JSX syntax there’s CJSX which gives you a seamless mix of JSX syntax with CoffeeScript.

      • Qasim57

        I like CoffeeScript but I have a hard time debugging it in the Chrome Dev Tools..

        How do you get around that?

      • rbrtsmith84

        Not much use for CoffeeScript now we have ES2015 / ESNext

        • markbrown4

          I understand where this comes from and agree that es2015 has more features than coffeescript. The features were always a secondary motivation for me though.

          The big difference is now the syntax – significant whitespace, everything is an expression, implicit returns and helpful aliases are things that make coffeescript much nicer for me to read and write. It’s still worth learning, even now in 2016, though the future of the language is hard to predict.

  • The same thing was told about Internet Explorer years ago – he was the winner of the browser war. Look what happens now. Tools, utilities and programs come and go. We might as well forget completely about React in 5 years. The ecosystem is in continuous flux.

    That being said, it’s good to know your point of view and the details you highlighted. Thanks for the update!

    • Jim Dawkins

      On the continuous flux comment I can agree.

    • markbrown4

      Occasionally there are clear winners that become psuedo standards like jQuery, it’s almost 10 years old but is still massively popular. Only now that most of it’s well loved features have been implemented natively are people moving away from it.

      Part of me hopes that there’s a clear winner for rich client-side apps, that way we can collectively move forward and it would make learning and moving from project to project easier. It feels like React may be the one to unite the clans.

      • I hope you’ll forgive me if I don’t share the same hopes. As someone who followed the web standards movement from the very beginnings and strived to code his CSS accordingly, I don’t really like the way React plays inline with CSS. I guess it is the same thing that happened when cloth stopped being weaved manually and was replaced by machines.

        • markbrown4

          React doesn’t really promote using inline styles, it’s absolutely possible to use classes as you normally would with standard CSS. It’s other projects like Radium and JSS which are going down that path of inline styles, they’re not part of React itself.

        • Gerard Sans

          I was at React Europe and the Facebook guys did a talk promoting inline CSS. That’s something to be concerned about.

  • Dusan

    Vue js

    • markbrown4

      I do like the look of Vue, it seems to be borrowing a lot of ideas from Angular, Ember and React. React does oppose some of it’s ideas like a special template syntax you need to learn and two-way way data binding though.

      Where do you find Vue shines above the others?

      • Dusan

        What I love about vue is you can create custom components that allow you to create view templates or you can have it all inline. The template is completely optional. Which is great because for some components i just need basic 2 way binding but other are more intense. I always found backbone and angular too be full on mv* frameworks and found react to be a lot simpler for smaller one offs on a page and not the whole page. Vue allows me to hit both ends. I found react to be too simple for the more complex parts and isnt as easy to use as vue.

      • Harry Pujols

        The beauty of Vue is that it doesn’t force you to adapt to it, or unlearn stuff you know. It doesn’t reinvent the wheel. If you know object-oriented Javascript, you already know Vue. Its simplicity is exactly what Angular promised, but failed to deliver.

    • markbrown4

      I do like the look of Vue, it seems to be borrowing a lot of ideas from Angular, Ember and React. React does oppose some of it’s ideas like a special template syntax you need to learn and two-way way data binding though.

      Where do you find Vue shines above the others?

    • SUDOisEvil

      All single page app frameworks are lipstick on a pig. The Vue, React, Angular method of building a new super-car is to start with a bicycle.

  • Owen Densmore

    Has React converted to es6, and in particular, es6 modules (import/export). And if so, how are the modules loaded (SystemJS). If these aren’t answered, then no, the war wages on.

    • markbrown4

      The React team have definitely embraced es6 and use it’s language features over another implementation where ever possible, the class implementation of components is an example. The docs still recommend using CommonJS modules with webpack or browserify but there’s nothing stopping you from using es6 modules with SystemJS.

    • markbrown4

      The React team have definitely embraced es6 and use it’s language features over another implementation where ever possible, the class implementation of components is an example. The docs still recommend using CommonJS modules with webpack or browserify but there’s nothing stopping you from using es6 modules with SystemJS.

  • I think that vue.js will play a big role as well.

  • Jim Dawkins

    It seems these days there are new frameworks coming out monthly. First you find frameworks break standards with a mess of non standard tags (angular ng anyone), or swinging away from keep the logic and view separate to going back and combining the two. We developers sure are manic depressive.

  • M S i N Lund

    Yeah…
    I have been planning on getting into that Google-Wave a while now.
    I hear its really really amazing, and that you will never get a job soon if you’re not using it for everything.
    Ill get right on it.
    Frameworks like that are the future.

    Other peoples code, and its syntax and terminology, is the most important thing in ze hole vide welt!

  • Narsqt

    The click bait title is real. 1/10

  • chris1712

    Hey Mark. Nice article. I am an angular developer that has this feeling that React is a better option, but I can’t wrap my head around how it should fit into my workflow. Can it replace Angular entirely? Can they work together? As React focuses on View in MVC, How do I implement MVC with React as one of my tools. Thanks

    • rbrtsmith84

      You don’t need MVC when you use react. All the front-end cares about is displaying data and managing state. React when combined with something like Redux for managing state is all you need.
      In my opinion MVC itself is outdated.

  • belisarh

    Vuejs more than deserves to be ecognized as the new cool kid in the block.

  • GGG

    Such a not professional article.

  • newz2000

    All of the parts have good and interesting supporting references except “Widespread adoption” and “Server rendered HTML.” I’d love links to more information related to these points.

  • newz2000

    All of the parts have good and interesting supporting references except “Widespread adoption” and “Server rendered HTML.” I’d love links to more information related to these points.

    • markbrown4

      Widespread adoption is an observation I’ve made but I’d challenge you to find a JavaScript related mailing list, meetup or conference that hasn’t covered React.

      You’ll need access to a JavaScript runtime and can run ReactDOMServer.renderToString() to render a component with data(props). That means using Node or a package like ExecJS in Ruby or Python which give you a JavaScript runtime in other environments. https://facebook.github.io/react/docs/top-level-api.html#reactdomserver

  • Harry Pujols

    My thoughts? I’m working with Vue.js, and React, Angular, Ember seem now so… needlessly complicated. Give Vue.js a shot, and all these other frameworks will look outdated.

  • Lasse Rafn

    I see no war. I use the tools that I feel fit for my project.

    Recently I used VueJS for a project, sometimes i use Ember and sometimes I write it Vanilla style (or with a piece of help from jQuery)

    I see no reason to implement an entire MVC for simple functionality that other libraries or frameworks may grant me. Just as I wouldn’t include the entire Bootstrap for using the grid alone.

    I wouldn’t ever rely on a single framework, language or similar. Why limit ourselves?

    There is no war; there’s preference and what fits our projects.

    I have yet to try React in a real-world project; and I don’t feel the need to do either. It’s great – indeed! – but I’m perfectly happy with many other tools.

    It’s like saying that LESS won over SASS – it’s a tool, not sportsmen.

  • Kenneth Davila

    Kendo UI …. full of widgets and MVVM architecture.. but there are some many tools out there, it’s like choosing Snap-On wrenches over craftsman…. tools are tools and there are many out there in the market, in the end it’s what the tool handler can do with them that matters.. and if his current project requires another tool, then he goes and gets that tool and uses it….

    • mithlond

      “The right tool for the job” makes sense. However, very few people today who want to make a shirt reach for a hand loom. I think the author is making the argument that the ideas that make React notable represent as major a shift as the introduction of automation in manufacturing. As people realize the benefits of reactive programming they’ll reach for non-reactive tools less precisely because they’re an order of magnitude less efficient and effective. I think that’s why the other tools in the toolbox have begun to look more like React – not because React itself is special, but because of the underlying architectural ideas have a substantial advantage.

      • Kenneth Davila

        To assert that React has one is ridiculous, as the author has done. Your analogy is also wrong. We’re talking software not hardware. And automation has been around before react, think templating. React just places your HTML within the Javascript, so it’s going back to what was at first discouraged by the industry way back when people were starting to understand JS development and the DOM and the dangers of explicit instantiation vs declarative . So to me this is just another fad in the industry that will go away in it’s time. I’m not opposed to React, my current employer is leveraging Angular with the ambitions to migrate to Angular 2. So, there is not a one all be all toolkit. That’s ridiculous to assert. We should understand JavaScript in general and design patterns and what architectures are out there, and you pick what you need that fits your design goals.

        • mithlond

          To assert that React has one what? Substantial advantage? What makes you think it hasn’t?

          As for my analogy the point is that for tools in general (automated looms being a hardware example, reactive programming being a software example) can see new ideas that approach problems in ways that obsolete older approaches. It happens in hardware and software tools. To say the analogy is “wrong” is like saying “the publish-subscribe design pattern is like subscribing to a newspaper” is a wrong analogy because one is software and the other is a physical thing.

          React appears to mix HTML and JavaScript, but it’s all JavaScript. JSX is sugar that is completely JS under the hood. The maintainers of React posit that the argument isn’t one of separation of concerns, but separation of technologies for a given presentation concern, and that by putting all the code related to a concern in a module you actually do have separation of concerns (as opposed to the JS for many disparate concerns in one file, the CSS for disparate concerns in another file, and the markup for disparate concerns in yet another file).

          I, too, think there’s not one end-all be-all toolkit. If there were then npm and github could close the door for further projects and we could just get down to developing with that one tool. React isn’t the ultimate tool, and it is being constantly refined. What I am saying is that the reactive programming and immutability ideas it centers on represent a step forward which leave the old ways of imperative coding for the browser behind. This is similar to how OOP left procedural programming as an option used by relatively few. I think it’ll take time, but as people begin to grasp the ideas behind reactive tools they’ll largely pick those tools precisely because they will fit design goals better than imperative tools.

  • > This design is also attractive to JavaScript developers who seem to favor focused utility libraries such as Underscore and Moment which do one thing well, very much the Unix philosophy.

    I guess it depends on how you look at it, but I would argue that while Underscore is really very useful, it’s rather a counter example of the Unix philosophy. Underscore does not do one thing well, it does a lot of things (well or not well, that’s up to discussion).

  • Ds

    I would use react; if it wasn’t a product of facebook. But it is so I won’t. Full stop.

  • simon codrington

    Thanks for the article. Haven’t really focused on React but I’ve heard several good things about it recently. Hopefully it doesn’t turn into another dead framework after I’ve put in effort learning how it all pieces together.

  • mbokil

    I looked at it. Beautiful! Plan to use it on next project.

  • Samantha Atkins

    Why the heck do I want server side rendering? That is stuff from back in the aughtites. Seriously, server side rendering burdens the server, you mess around with state or not, it is slower, etc. You spoke of the advantages of client side then you start talking about server side rendering. I would rather not have my server know anything about html pages as much as possible. I would rather have the server respond to persistent data requests and do backend processing. Then that server can have many different frontends, some web frontends, some desktop or native mobile, some just other servers. I feel like extolling server side rendering is a huge step backwards. What am I missing?

    • tkane2000

      If you need SEO it will come in handy. Also, the initial page rendering will be faster.

      • _Might_ be faster. There have been some experiments on this that actually show better numbers for huge table renders when doing client side rendering. So this might or might not be true, depending on page structure. There are more valid concerns, like SEO.

    • brownieboy

      “What am I missing?”

      Just about everything that’s been going on in this space for the last three years!!

      Yes, “server side rendering burdens the server”. That’s the whole point. But you can throw hardware at it, and get an nice, quick html page downloaded so the user sees something on their screen in second or two.

      Client side rendering burdens the client. Which is fine if it’s an internal app, with a big fat data pipe and you’re all running on the latest desktops. Not so good if it’s an internet app, and you’re on a crappy 3G data connection on an equally crappy $100 Android phone. Those users will be forced to wait for all your client side stuff to download before they see even a bare bones page appear on their screens. Assuming they can be bothered to wait at all. Many will depart to one of your competitors, whose devs have been keeping up with current events.

    • Because that enables much better SEO than what you can achieve with pure client side rendering. And SEO is king for the client. It also enables better experiences on low bandwidth, mobile networks, as the client can start rendering the page as soon as the html reaches the browser – assuming that you bundle critical path css of course (which you should).

      As for burdening the server. No. There is not much more of a penalty on the server generating html than there is for serializing an object structure into json. And you can cache both – in Varnish and/or on the app server.

  • Samantha Atkins

    How the heck does one both keep up with the all the tools and have enough proficiency in each and have a good general proficiency in enough jobs is a very fast changing opinionated world of just what the job should be in order to ever “use the right tool for the job”? Enquiring minds want to know.

    • That’s what we get paid rather comfortable sums for.

    • markbrown4

      A good strategy is to be a table with legs, the “table” being a broad base of knowledge so you know where different tools fit in. The few areas of expertise that really interest you that you know inside and out. Know a little about a lot of things, and a lot about a few.

    • What Mark Brown said. Javascript fatigue is a thing, but I have actually made my peace with it in the last year. I have found that if you focus hard on the core of your subjects, then all the moving parts around it may well change as they like, you can still dig in and understand them if and when you need to.

      I’d say to hell with trying to be good at everything. Most libs are siblings or at least seem familiar if you know one other tool well. Focus on being excellent at Ecmascript as that is the main thing keeping everything together. The last year I have seen tons of React clones and variations of the Flux pattern. They don’t matter. The important thing are the principles that are left when the tech dies: Virtual DOM diffing, component thinking, reactive programming, prefer dumb components

    • mithlond

      The best answer to this question I’ve heard was given by Kathy Sierra in a keynote address at the O’Reilly Fluent conference in 2015 (it’s available on the Fluent 2015 site and I think on youtube as well). She talks about the one meta-skill to rule them all: the ability to quickly and easily learn new skills.

      When we decided to be developers, we signed up for a life of constant retooling. Getting really good at that is both challenging and important.

  • Remco Vlierman

    How can you speak about a war being won without making any real comparison? Title seems a bit like clickbait to me (sorry). I won’t go into details here ( I think that is the job of the article itself ) , but many new versions of the main frameworks now have the features that you mention.

    I agree there’s a war, I don’t think there is a winner…. not for a long time

  • Remco Vlierman

    How can you speak about a war being won without making any real comparison? Title seems a bit like clickbait to me (sorry). I won’t go into details here ( I think that is the job of the article itself ) , but many new versions of the main frameworks now have the features that you mention.

    I agree there’s a war, I don’t think there is a winner…. not for a long time

  • Júlio César Ködel

    Yes… Oranges are better than cars.
    You can’t even realize that those things are completely different?

    • markbrown4

      Of course there are differences, they’re all tools for making web apps though.

  • markbrown4

    To quote Princess Bride they are only mostly dead, mostly dead is slightly alive.

    I don’t mind describing technologies in a descendancy as dead technologies but I can understand why others find that harsh or misleading. CDROM’s are dead, Sass beat less, typescript hasn’t suckerpunched anything yet, jQuery killed prototype.

    Death is a natural part of life.

    React may not be the most used, but it’s in it’s ascendancy to the top.

  • Nikos

    Having used ember and angular I agree. I also think Vanillajs is also winning ;) Keep watch on cycles.js though!

  • Ravi Kanth

    I started looking angular and react pretty much around the same time and picked angular, coz I felt it’s more complete with its code organization, dependency injection etc.. React on the otherside only being the view part and with its jsx made me to stay away from it. I started loving angular as the project progressed ,and was a lot comfortable with it in later projects. But learning about Angular 2 and its changes is a little disappointing though , with its monumental shift from 1.0 it’s is like learning something new from scratch , I believe its way easier to learn react than learning angular 2.0

  • Dmitri

    React still has signs of immaturity. For instance, the mandatory `key` attribute in the loops. Pushing framework’s complexity onto the user.

    • I use react in production with rails. Sometimes it is real pain but the overall result is overwhelming . Here is my experience from last 9months with react
      React seems easy to learn but when you start developing things and plan to focus on it as your view part then you will feel tricked by facebook. We have broken views due to react immaturity to handle certain situations and complete non-sense way of handling the routes .

  • jordan

    I have found that Backbone with an MVP architecture just dominates in every way.
    Simple, dev friendly, flexible, one-way data flow, server or client, plays very well with others, scales nicely, loosely-coupled and event-driven, testable, super fast, and still very very lightweight.

  • SUDOisEvil

    No matter how much I upgrade my Edsel, it will never be a Ferrari. No matter how much you hack at the browser with Javascript frameworks, they will never create real full applications – just myriads of form style report based, slow un-apps with some animation in place of features with all the real work being done by remote servers. Replicating “just enough” of a real application online to be useful in a pinch (web based word-processors and spreadsheets, and a ropey to-do list demos) is still all just a second rate hack. If we want to create informational pages, HTML, CSS, and a smattering of Javascript are fine, but if you want to create real online applications, the technology just does not exist yet. Or to be clear, it does, but the current crop of jumped up graphic designers are not capable of building with it.
    It strikes me as odd that the very companies which produce React and Angular don’t use it for their flagship products in any form resembling the downloadable open source version. If I were being cruel, I would say they release these frameworks to nobble the competition.

    • markbrown4

      This is a pretty funny post, what’s an example of something that you consider “real full applications”? You’re not clear at all about the technology that you do think is capable of creating them either, what are you referring to? And React *is* used on facebook.com.

  • SUDOisEvil

    WTF? Reactibot in action.
    There is not point in saying one is better than the other when they are all shit.

  • Bishnu Rawal

    This comparison irrelevant, Webforms vs react/ember/angular? Webforms is not only about client side things.

    • Tim Goyer

      To be fair, React isn’t only about “client-side things” either. React can be server-rendered, client-rendered and/or native (Android/iOS/WinPhone) rendered.

  • Tarlton

    This statement in the post was interesting,”Admittedly, this makes certain tasks such as animation more difficult because those are cases where you do want to define transitions between states.” Disappointed that it wasn’t expanded on. So, how does React deal with animation?

  • Mariano Cavallo

    Hell no.

  • Harry Pujols

    Considering the complexity of the workarounds, the answer remains no.

Recommended
Sponsors
Get the latest in JavaScript, once a week, for free.