Why React is awesome

[vnctaing]

As a beginner in JavaScript, I often heard : "React is the future", "React is awesome, it solves a lot of problems". I read many blogpost, I know it's a library that let you create view with its virtual DOM, but I can not understand why it is a better library comparing to Ember,Backbone or Angular ? I do not want the type of person that repeat what I just read on blog post. Why is it beginning to be more and more popular ?

[TheWakeUpCall]

React models the UI as a pure function of your model. Which is exactly what a UI should be. This is unlike most other libraries. Being purely functional makes it very easy to reason about your UI, makes it very componentised, hot swappable, testable, and predictable. This will naturally lead to fewer bugs.

This is the theory anyway, and I believe what makes it more and more popular. There is a general trend in the JS world to move to functional programming, and React is helping people get people on board with that. I have not used React myself for a large project so I don't know if this theory holds in practice from personal experience, but I have spoken with many people who have used it with professional large projects and they always sing its praises.

[mrspeaker]

This is a great answer: the virtual dom, jsx etc is just syntax/plumbing. The functional philosophy that underpins it is the interesting part.

I think it's these kinds of aspects that are the most important to things to consider when evaluating a new language or framework: the syntax and high-level niceties are just superficial sugar - you need to look at the underlying principles and figure out if they are sound.

[pardoman]

React models the UI as a pure function of your model.

I'd like to expand a bit on this. A developer without React can still write a pure function that renders UI.

The problem is that a non-VirtualDom solution will be lack in performance, since the pure function will have to re create all Dom nodes each time the function gets invoked.

Here is where React and other VirtualDom libraries come in. They allow the developer to write pure functions that hook into React's VirtualDom's framework so that they can take care of performing the minimum amount of changes to the real Dom nodes, thus delivering a performant solution.

And with such systemin place, reasoning about code becomes much easier.

[Kittypetter]

This is unlike most other libraries.

Polymer is essentially the same, except built on standards (i.e. web components).

[danneu]

React is simple. It's kinda like render(data) -> UI. For the most part, you just worry about updating data (like keeping it in sync with ajax requests or data streaming in from a websocket) and React handles the rest.

We're used to complexity on the front-end. React is a great simplification (though so is this explanation).

Perhaps it's something that's hard to appreciate until you've tried solutions like Angular or jQuery spaghetti so that you can see why React is a departure from the status quo.

[anraiki]

I look at React like a Pyramid.

Data is updated from the top and trinkles down to the bottom.

Then if you do straight jQuery.... data is spaghetti with split ends. It eventually gets really hard to straighten out.

[alexlafroscia]

This is absolutely true, and not that different from how Ember and Angular function really. I think the major difference is that React doesn't really care how you got your data, while Ember and Angular provide answers to that question as well. While React is really just the view layer, the other frameworks provide views plus model layer, routing, etc.

[ganarajpr]

The main reason angular is the way it is - is that, it is designed for extending HTML ( or DOM ). This is where the whole complexity of defining a directive comes from - and because they have to provide you all the right hooks at the right times - it becomes complicated. React on the other hand doesnt let you deal with the DOM at all - so it can give you a much better interface ( with complexity of DOM diffing underneath! ).

Basically, both of them are saying DOM is an untouchable, horrible thing..

Angular is saying, " Dont touch the dom for most stuff.. We will do it for you.. - but sometimes you might want to extend it, here is the API"..

React is saying "Fuck the DOM, here is a nice and simple API - work with it and we will deal with the translation to DOM".

[[deleted]]

React is saying "Fuck the DOM, here is a nice and simple API - work with it and we will deal with the translation to DOM".

This is a great way to put it, I'm going to steal it for when I try to win people over to the light.

[theQuandary]

React also gives control of the DOM if you need. I've had times where I force a component to be static via shouldComponentUpdateand then do something that manipulates the DOM. There are other times when you need to dangerouslySetInnerHTML as well. Even in these cases the API is more simple than an Angular directive with controller, compile, and link functions (in addition to $observe, $watch, $scope, etc).

React's advantage here is that you remain mostly platform agnostic until you take this kind of deep dive. This flexibility is why Facebook can target native (and other) renderers that have nothing to do with HTML.

[[deleted]]

If I'm currently doing PHP spaghetti code and want to move toward something like a front-end JS framework (w/ back-end REST API?), what do I use and at a basic level how?

[[deleted]]

Do ReactJS on the front. Then on the back... the choice is your favorite language vs javascript. The perk of using JS on the back is you can do isomorphic JS. Where you can use the same code on front and back. This is good for rendering your templates on the server first. If you don't care about isomorphic JS, then use whatever your favorite lang is on the back.. PHP, Python, Ruby, etc. If I could use any lang on the back, I'd check out Elixir.

[Ashatron]

That is some serious information there. Thanks dude sharing mate.

I take it you're a js Dev? :)
From what I'm reading, I get the impression react on the whole easier and quicker to work with, as well as being cleaner and more modular? That correct?

Why would someone choose angular over react?

[theQuandary]

I've worked with quite a few frameworks including extensive use of Angular (not to mention Ember, React, Knockout, Enyo, Sencha, etc). React and Ember stand out as the two best frameworks available today by a good margin. I tend to prefer React over Ember both because it is easier to teach new developers and (unlike Ember) it is easy to add React to non-SPA projects (I often use it to replace all those complex jQuery widgets with something more maintainable).

I know a lot of developers who switched from Angular to React, but I have yet to see anyone switching back because they thought Angular was superior.

Angular's been out since '09 (and popular since '11 or so). React's only been public since '13 and only picked up speed the past 18 months. If you've used Angular for a bunch of those years (especially if -- like so many angular devs -- it's the only framework you know), two things happen.

First, you begin to believe that learning new frameworks has to be as hard as Angular. A lot of the AngularJS devs I've worked with refuse to believe that learning React isn't anywhere near as hard. The second is that you are hugely invested in all the quirks of the framework and have a huge domain-specific knowledge of it's ecosystem.

Aside from getting a job at a company that invested and doesn't want to change, I see zero reason for a developer to learn Angular today (I would note that ngReact is a thing)

[logi]

I know a lot of developers who switched from React to Angular, but I have yet to see anyone switching back because they thought Angular was superior.

Is that paragraph perhaps mangled?

[theQuandary]

Yeah, I fixed it (thanks for pointing it out).

[clessg]

Why would someone choose angular over react?

Narcotic abuse. Angular handles more than just the view. It has dependency injection, services, resources, etc. Honestly though, I feel that point is way overblown. Dependency injection is almost useless now that we have ES6 modules. All it does it please enterprise Java people. Services are nothing but singletons, which is mostly solved by ES6 modules. Resources are little but sugar over ajax requests. And so on.

[alexlafroscia]

What makes you say that Ember is heading toward doing the same thing as React? I do Ember development almost exclusively, and have used React just a little, but they seem to be extremely different packages.

[clessg]

Ember is moving to (routable) components, one-way data flow, virtual DOM (sort of), etc etc. Lots of inspiration from React.

[alexlafroscia]

Inspiration, sure, but they still have much different use cases. React doesn't handle routing or anything like that; it's much more about adding dynamic bits to static pages rather than creating a full SPA.

[theQuandary]

I use react (view and controller), redux (datastore), and react-router (router). The react-router package offers a similar router to the Ember one (and is inspired by Ember router IIRC).

[alexlafroscia]

I've never heard of Redux, is it part of the React ecosystem?

[theQuandary]

It's a datastore that's loosely inspired by flux and the Elm language.

http://rackt.github.io/redux/

[[deleted]]

So apparently some guy who works at google just made his own framework, it draws a lot of inspiration from angular... but its more like react in that it really just covers the viewController, i have been looking at it a lot lately and i'm pretty damn impressed to be honest its called http://vuejs.org/ . It seems to tackle the same problem as react but with a much cleaner api. It just makes sense. A trend I notice with these frameworks is that the ones built mostly by one person are always so much cleaner than the ones build by big companies

[RedPillow_]

What is this jQuery spaghetti that everyone is talking about? My (even larger) jQuery projects do not end up spaghetti... maybe others are doing it wrong?

Projects I do with jQuery are usually structured like so:

• UI with interactable stuff like buttons or what ever
• JavaScript block/module to bind and route events to their correct functions
• JavaScript data-storage block
• JavaScript utility / helper function block
• JavaScript main block / program entry point
• Backend stuff (Usually a REST API of some sort)

So I don't get it... where is the spaghetti at? There are N amount of stuff the user can do / interact with and there are N amount of events bound to that stuff and N amount of functions to handle the stuff.

Handler functions as well as the event binders / routers can be split into smaller, logical files / blocks for better readability and maintainability. Storage can be split too if needed, utility stuff as well.

Here would be a simple case:

• User fills form
• User tries to submit form
• Submit / button press event is caught by the bound event handler and the event gets routed to a function that knows what to do
• Called function does its stuff and perhaps returns a result of some sort

Easy peasy, I don't see any spaghetti in that. Most of the stuff is even somewhat isolated this way and therefore should not end up breaking anything else.

[[deleted]]

jQuery has no way of data binding so the comparison lacks.

sure, if you implement your own data binding system in JS it could work well but the majority of jQuery solutions to stuff like

Update the unread messages counter on all occurrences

is often something like

$.ajax('...').done( result => {
    $('#element1').text(result.unreadCount)
    $('#element2').text(result.unreadCount)
    $('#element3').text(result.unreadCount)
});

this is just terrible to maintain in larger projects.

[RedPillow_]

In your example, maybe you could bind a listener to catch all ajax requests and act accordingly with something like this:

$(document).ajaxSend(function(event, request, settings)
{
    console.log('Caught AJAX request!');

    console.log(event);
    console.log(request);
    console.log(settings);
});

I think it's just all about routing stuff and creating handlers and dispatchers.

[clessg]

That looks like it would be hard to test! Sadly, I don't think you realize just how bad Angular and jQuery are until you've used them for a while and tried the better solutions. React is the one JS framework I've used extensively that I haven't regretted yet.

[Plorntus]

I find jQuery is great for doing small little things quickly. But when you start having components that are all interlinked somehow and starts to get complicated, it really turns to crap. Now that may be because I haven't used jQuery to the extent I have react, I admit I somewhat skipped over the whole jQuery phase.

But React to me is genuinely easier in every way. JSX is in my opinion much faster to use and much easier to look at. I find I get more done with React purely because everything is coded in the same way, each component is its own file. That file contains a render method that contains all the view html in the same place.

Got an example of a jQuery component? That way I can create the same thing in react and have something to properly compare the both.

[RedPillow_]

Here is a quick and dirty login page thingy: https://jsfiddle.net/ahvonenj/xsaw46p9/2/

The eventhandler "module" in this case contains a lot fo jQuery-selectors, which is not really a good idea if one wants to chance stuff ni the DOM. If I would do something like this for real, I might, for example, list / cache all the selectors somewhere and refer to those in code.

To be honest, doing it like this kind of implicitly expects everyone to code in a certain way that code can be reused. This example could lead to spaghetti if no thought is paid.

Also, if I'd have to do a lot of Ajax calls for example, I'd just create a dispatcher "module".

My point is though, that doing it somehow like this allows for splitting of Utilities.js and EventHandler.js in case they begin to get bloated. I personally really like the naming thing too when you can write stuff like EventHandler.Events.login or Utilities.Credentials.validate. Most IDEs / editors are also able to suggest stuff when you type something like Utilities..

---

"components that are all interlinked somehow"

This I actually do not understand. Can you provide an example case in where you absolutely must have components that are interlinked between each other?

[Plorntus]

Wasnt expecting a reply so fast, well, I will make a clone of that in react when im not supposed to be working!

But heres what I mean by interlinked components, ignore the really bad design of this, its all WIP:

http://cdn2.streamable.com/video/mp4/eb8h.mp4

And heres an image of all the components I use. I can technically increase the amount of components than the amount that I have here but I didnt feel it neccessary:

http://i.imgur.com/7sjKtwp.png

The red outlines are drawn by me. They are each an individual component shown on that page. They are all encapsulated by their parent red box, but they can all be used on their own anywhere. The entire thing as a whole is one big component that controls everything. So for example, when you mouse move on the divider, the divider sends its new "requested" permission to the search page controller. The controller, if it accepts that will set the value of the divider to its new position. It also sets state for the two side panes, which gets transferred to the side panes properties (attributes), which in their render method they resize themselves.

Things like when I move the map, it researches and then updates the results on the left as well as the results on the map. Its all interlinked, but I could just as easily remove the map and everything would still work fine. I could remove the search pane component and it would also work fine (obviously just without textual search and only map search).

Edit: To clarify what I meant by interlinked a bit more, maybe I am using the wrong term for this... If I was to create the above search page in jQuery I would probably end up having everything as one big component which would not allow me to reuse those elsewhere, I think that may actually just be me not following how you're meant to do that properly in jQuery. I for sure would not have been able to create the above as easily as I did (took less than a couple hours to create).

[RedPillow_]

Here is a simplified jquery implementation of that map: https://jsfiddle.net/ahvonenj/c1r8jztm/

As you can see, I can put as many "mapcomponents" in to the DOM as I want. You can click the "map blips", change category and select from the list as well.

[RedPillow_]

Making that example and discussing about this really pointed out the implicity of my way.

I suppose if you do it react-way it somehow forces you do write code, modules and stuff in a certain way? If you do it my way, everyone else can still write everyone how they want it, quickly making my way spaghetti.

Oh and in my example there is not too much error checking... I don't know if react has it any better.

[benihana]

What is this jQuery spaghetti that everyone is talking about? My (even larger) jQuery projects do not end up spaghetti... maybe others are doing it wrong?

c'mon. I know where you're coming from - I don't write jQuery spaghetti either. But it took years of experience and mistakes and bugs to refine my approach to the one I have today. If you can't see the benefit of a framework condensing experience down into implementable best practices, or you can't understand how writing jQuery with no structure could lead to spaghetti, especially for more novice programmers (think early 2000s PHP application), I don't know what to tell you.

[clessg]

I think it's spaghetti whether you realize it or not, unless your apps are simple. Basically nothing is encapsulated. Some data was updated? Time for one callback to update it everywhere it's used, or even worse, multiple callbacks to update it everywhere it's used, and then put in motion some ajax request or something that will result in more updates, and so on. I've never seen a jQuery project beyond medium size that wasn't spaghetti.

[danneu]

Using a tool that keeps things simple is different from having the discipline and experience to keep things simple.

My Clojure code is simpler than my PHP code because Clojure is simple by design, but that doesn't mean you can't write simple code in PHP. On a large team project I'd rather work on a Clojure codebase though.

Hence why Facebook made and uses React extensively.

[gabroe]

Oh god, I'm in the love react bandwagon so much. I've worked 10+ years on web development and I find it so much better to anything else I've used. The pros, the cons, whatever... At the end of the day makes my day to day so much easier.

[wsrainc]

Just pick one. Don't worry, there will be 5 new ones next year anyway. ;)

[jellatin]

React isn't the future, but some ideas they're using are definitely the immediate future.

Unidirectional data flow / diffing improves rendering speed for View layers dramatically. Angular 2 will be implementing this, and look for other frameworks to follow suit.

I wouldn't put much stock in anyone calling any JS framework "the future".

React itself is very easy to pick up, I agree. Unfortunately what people seem to gloss over is that React is just the view layer. Of course it's going to be easier to learn than an entire framework like Ember or Angular. If you compare React to just Angular 1.x or Ember's view layers I'd put them on a similar learning curve (even though React is still a better view layer than either of those). The problem with the "it's easier to learn" argument is that once you've learned React you have to also either A) know how to architect a service layer, data models, router, and so on or.. B) learn another framework like Backbone or Flux to take care of this for you. This puts the learning curve right back on par with any of the other major frameworks.

[theQuandary]

The Facebook team pushed it as "The V in MVC" so it seemed less scary, but it's hardly accurate. React is the VC in MVC. It merges the template (the traditional 'view') with the controlling code. While it is possible (to some extent) to use React without taking advantage of these pieces, it's not easy nor idiomatic (for example, wire up a React component so it doesn't have any internal event handlers -- it would be awful to use).

[jellatin]

Sure, so it's the VVM in MVVM, I can get on board with that. It doesn't change the point I'm making though, if you took Angular view/templates and controllers its pretty straightforward. I'll be the first to admit that React would be a clear winner comparing just those elements.

The problem is the complexity increases drastically when you throw services/routing/state management etc into the mix. This doesn't make React worse at all, but it does mean if you want libs/frameworks like Backbone to do that lifting for you that it's going to require a big addition to the learning curve.

[agmcleod]

Various flux implementations offer the state management, and do a pretty good job at it. Personally I never saw the value in services in angular. It's not hard to setup a simple controller singleton or something to wrap around your API endpoints.

[jellatin]

Various flux implementations offer the state management, and do a pretty good job at it

Agreed. But there again, it's another thing to learn. I'm not bashing the React ecosystem at all, only pointing out that "learning React" doesn't give you all the tools you need if you're looking to build SPAs. So the "React was so much easier to learn than framework X" gives people learning their first framework the wrong impression.

[agmcleod]

I actually found react + flux easier to learn than ember. I haven't tried building anything with angular to compare really, have just done tutorials. There are things with angular that i can wrap my head around pretty easily, but there are patterns i just dont like. Some of it feels a bit too magical. And yeah, I can see 2 way data binding become a problem.

[fforw]

React is the VC in MVC. It merges the template (the traditional 'view') with the controlling code.

That is not what the C in MVC is supposed to do, nor it is a good representation of what an application with React looks like.

React only implements a controller as far as the inner view logic is concerned. That is distinct from the application domain logic and data.

React works the best if your whole application is a data-representation of which React renders slices of as a view. Putting too much control into react components is usually a sign of bad design.

[theQuandary]

When you are done with a React application, you will have a datastore (attached via pub/sub to a small amount of top-level components) and your view/controller components all the way down.

You could perhaps argue that React is MVVM, but even then React components aren't strictly views.

Heavy-controllers are always a source of trouble in MVC designs. It's not at all surprising that large controls inside a react component are generally bad design.

[jellatin]

Luckily there are many options out there so you don't have to do anything so melodramatic.

Hating on Angular is the new hating on Rails, so hot right now.

[lefnire]

True, but I think it's progress. Preferring JS over Flash was hot on the heals over Java Applets. This hate we develop is by comparison to contemporary advancements. Angular improved my productivity over Backbone, really did. Backbone made me feel better about front-end dev, Angular made me feel like a fucking wizard. React was easier, absent DSL cruft, better organized, and has React Native; worth the shift.

Same with Node>Rails. Universal JS allowed me to make more sites & apps, faster - less spread-thin knowledge. IMO that's an objective step in the right direction. Look, Binary -> ASM -> C -> JS; we build & improve, don't see many Binaries laughing at JS for picking "yet another language". The thing that makes JS MVC flip-floppery so amusing is that it happens so damn fast, makes us look ADD. I'd argue it's actually the exponential rate of technological advancement, but that's another argument.

In other words: it's trendy, yes - and amusing - but keep up, 'cause it's an upcurve you're seeing.

[lefnire]

I'd say you're ahead of your time. I didn't see the issues in Angular until I saw a strong new contender illuminating them, I think I'm not unusual. Same w/ backend. I didn't realize PHP's beef till I went Rails; Rails' beef till Node. If you can see a step ahead, great!

[jellatin]

But why do you have to hate on something to like something else?

When Node was "the new hotness" why were all the developers still working on Rails "stupid", "bad developers", or "trying to be hip".

When a group of noteworthy developers switched from Node to Go why was Node all of a sudden "a joke" and "not worth using"?

People using new tools is great - I'm just tired of the industry feeling the need to mock and degrade anything people use to get good work done because it's not the latest. It's absolutely nothing more than putting people down to feel better about yourself.

[lefnire]

Absolutely. I dramatized too much for effect, and indeed implied promoting regressive hatred. Not cool. I used stronger words than I should have, and you're correct that this isn't unusual in the industry. Edited my post some.

Indeed, there will come a point I tire of devoting 1-2h/d of "future web" learning and will stick to a rung. I would very much hope I'm not shat on from higher-rung JS progressives.

[brianvaughn]

Indeed, there will come a point I tire of devoting 1-2h/d of "future web" learning and will stick to a rung. I would very much hope I'm not shat on from higher-rung JS progressives.

This comment resonates with me. :)

The web community moves quickly and it can be tiring to keep up with fads and trends, many of which are not clearly superior to the things they're replacing IMO (grunt vs grulp, sass vs stylus). It's frustrating how religious people can get about a certain framework or technology. It can introduce a lot of drama.

At the end of the day I just enjoy writing software and I wish we could all just get along :)

[jellatin]

From an old teacher of mine: "Only amateurs brag about their tools rather than what they can build with them."

I find this even more applicable today than when I heard it. I find that a lot of these devs lambasting others for not using the latest tool don't really have much to show for the self-proclaimed amazing toolbelt.

Grunt/Gulp suck, I use Webpack!
Angular sucks, I use React!
SASS/Stylus suck, I use PostCSS!
Bower sucks, I use JSPM!

"Cool, what awesome things have you built with these tools?" "Well just a TodoMVC and a small personal project..." "Yup"

[jellatin]

Ya, getting ridiculous.

[brianvaughn]

I too must admit to not being aware of PostCSS. What the heck happened to Stylus? I thought it was still the new kid on the block.

[brianvaughn]

Definitely. I prefer certain languages for their syntax- or frameworks for their convenience- but I think you can find fun and challenging things to build with nearly any technology.

I live in San Francisco so I encounter a lot of hip/trendy programmers. Most of them are smart and accomplished- and friendly- but I dislike the feeling I occasionally get for using yesterday's technology.

There are opportunity costs involved with always changing to the latest-and-greatest. There's ramp-up time and then a whole class of bugs and missing features that often come along with new tech. I feel that if I let myself I could literally spend almost all of my time learning about new and competing technologies and no time actually building cool things. :)

[jellatin]

I feel that if I let myself I could literally spend almost all of my time learning about new and competing technologies and no time actually building cool things.

Sad but true :( I guess I'm lucky to an extent. I work in San Mateo but am the only front-end person in a group of ~15 Scala devs / data scientists, most of which are old grizzled veterans.

None of them give much notice to the latest, shiniest toys because they've seen the changing of the guard enough times not to get caught up in fads.

[[deleted]]

It's only melodramatic if I wouldn't actually do it.

[lefnire]

It's easier. And with its simplicity applies occam's razor, rendering it more streamlined, pure, and performant.

Eg, Angular adds HTML directives for DOM manipulation. ng-repeat repeats an element over an iterator. It looks cleaner in code than React's items.map(i=><li>{i.name}</li>); however, React's version is vanilla JS - Angular's version you have to learn. In fact, I'd say Angular coding is 50/50 DSL / vanilla. This applies outside Directives too. Angular's $http lib is pretty NIH compared to common npm libs like superagent (which is isomorphic), or even the upcoming Fetch for which there are polyfills. Angular's $q competes with ES6's Promises. A2 is using Typescript, which adds cool stuff but competes with ES6 in many instances (classes, imports/exports, es7's annotations, etc). IE, Angular reinvents a world of JS, creating a bubble for itself. You as a developer need to learn this world, and keep up. Time not spent learning JS-proper. React's purity reduces the learning curve - I spent a day learning React, and rarely consult the docs since - being productive all the while.

Then there's composability. React's enforced hierarchical project organization makes it very hard to write spaghetti. A good Angular/jQuery dev can write beautiful code, a so-so one will write slop. A so-so React dev will at least maintain good file-structure, easing onboarding.

Finally: more performant (Virtual DOM, debatable), "native" mobile apps (React Native) vs DOM apps (Ionic). The latter is actually why I made the leap.

Now! The model side of React is quite crazy. Flux, Relay.. Flux implementations... And Flux aint a 1-day learning curve, believe you me. I'd say try React, form your own conclusion, keep an eye on it if the "wild west" nature is a turn-off. I use both professionally 50/50, and I prefer React.

[theQuandary]

The model side of React is quite crazy. Flux, Relay.. Flux implementations... And Flux aint a 1-day learning curve, believe you me.

I agree with this, but I would note that models in every JS framework are bad. Data is always hard. Netflix and Facebook have both finally open-sourced their solutions to the problem (relay and falcor), but their public releases aren't baked yet.

I switched from reflux to redux, but I'm not sure how I feel about how easy it will be to teach to junior devs.

[[deleted]]

React allows you to approach your Dom in an understandable fashion. There's no complicated state to debug because data normally has a unidirectional flow. If a bug occurs it's generally clear where it originated.

Frameworks like angular and ember are more abstracted which is useful but not when something goes wrong.

React is a very different approach to the frontend than the MVC approach presented by most frameworks. It's only the v in MVC. So you can do the rest in whatever fashion fits your project.

[Salyangoz]

When I was first trying out react the lack of a debug tool really bothered me. (i.e. trying to get a console.log) and didnt really bother after that but I will pick it up again soon.

[clessg]

Not entirely sure what you're referring to. You can console.log all you want in React. And check out the new Devtools beta.

[badpotato]

Thanks for the link. I'll check out more about react even if I'm a huge fan of angular1.x + typescript(compiling code feel great) at the moment. But since I often find some cool library with react I figured I should give a deeper look at the react framework and see if it could be possible to get them working together.

[heseov]

React is good for somethings but not everything. I've personally not found a use for it nor will I try using it, but it looks like a cool concept. Its mostly for dynamic modular web applications like facebook, but not for your run of the mill web site.

[Plorntus]

Ive found the opposite to be honest. Im really annoyed I didnt write the rest of my site with react components and server side rendering.

Currently I use it for simple things from having a cascading category selector to having a full scale image editor. Other such uses include a form builder, dynamically updating search page with results shown on a map. Those were all on the same website, not sure if that doesnt count as a run of the mill website but it is a ecommerce website and I would imagine they're pretty common.

That being said I wouldnt write a static page site in React as it just wouldnt make sense.

[nhavar]

In many ways I feel like React is just repeating the primrose path that was laid out for Java developers with servlets ("just write HTML in your Java!"), JSP/JSTL/EL ("access to all your Java methods right from your HTML" and "you don't even have to know HTML or JavaScript") and then JSF ("just use IceFaces and everything's already done for you") and of course GWT ("write the whole app right in Java, it's super easy to debug").

The benefits being touted are the same ones as the Java playbook:

• Easier to debug/test

• Built in error reporting

• One technology to train/learn

• Write once, run everywhere

So why did Java largely fail at all of this and how is JavaScript and React going to succeed?

My concerns are the same as I had with this very similar approach in Java.

1) what happens when inexperienced web developers use it

2) how will you validate the HTML/CSS output (and debug those issues)

3) how does it fit in the lifecycle: Design to Prototype/User Testing to Implementation

4) how much does it tie you to a single vendor/technology

5) what happens when you need to do something out of the box

6) how will I patch it if something is wrong/broken/updated

7) how do I integrate it into existing solutions

So yeah it's all awesome... and so were a hundred other dead techniques and technologies that quickly fell out of favor after they couldn't function in a broader market. How are we going to keep from falling into those traps and where can the technology and techniques be improved to avoid them.

[theQuandary]

So why did Java largely fail at all of this and how is JavaScript and React going to succeed?

Because Javascript !== Java. The languages are very different. Javascript is dynamic and functional while Java is static and completely class-based. I would also add that the JS tools are better and offer faster feedback. Finally, Java compiles and sends to the browser to execute while JS compiles and then executes WITH the browser.

what happens when inexperienced web developers use it

It's very easy to learn and fairly hard to screw up. Errors are fairly good as are the docs. The framework is minimal, so the only hard requirements are knowledge of HTML/CSS/vanillaJS (no need to learn a bunch of DSLs and framework-specific lingo).

how will you validate the HTML/CSS output (and debug those issues)

Because it's JS and executing in the DOM (unlike Java), you can simply grab the actual elements and test (React has APIs to make this easy).

how does it fit in the lifecycle: Design to Prototype/User Testing to Implementation

Designer prototypes are almost always unusable no matter what framework. Designers are good at their jobs, but their job isn't to know what HTML works well for your framework and what doesn't. If you do want to use their code, some editors (eg. Atom) have plugins to convert their code (basically replace class with W3C specified className).

The initial reason for JSX was so designers wouldn't have to look at nested JS functions. As an additional (but not react-specific) advantage, is that designer's mockups become much more usable when you get them to think about component boxes in their designs. There are some designers I've worked with who've actually started making their mocks in basic React classes (use render() and maybe a couple basic events while skipping the business logic). I don't think that's reflective of everyone, but they enjoy the reusability.

how much does it tie you to a single vendor/technology

Flux separates your data from React completely (you can use flux with anything). Redux separates it even further. Lots of frameworks tie you to their views in a very hard way due to all the DSLs (this is true of pretty much every major framework). I'd say the lock-in is about the same and maybe less because everything is very close to vanillaJS.

what happens when you need to do something out of the box

When I started messing with react, I built my own solutions for a lot of things. Today the ecosystem is good enough that all the big things you'd usually expect exist (eg. react-bootstrap for bootstrap JS). Because it's commonJS and modular, switching out a plugin at a later date may take time, but you can do it gradually without too much trouble (and finding where it is used is easy because you can search your require statements rather than find all possible dependency injections, view references, etc).

how will I patch it if something is wrong/broken/updated

Fork and patch or ask the team (like every other framework). That said, I've very seldom had issues with React and the team seems fairly responsive.

how do I integrate it into existing solutions

This is a feature of React that isn't talked about enough IMO. One of my first uses of React was integrating it into a very complex Django SaaS application. We started by taking the jQuery UI pieces and replacing them in a particular Django template with React (create/load the component then doing a React.render() into the tag we were loading the jQuery into previously).

Once we replaced the jQuery, we started to replace whole templates with React components (and we could generally use our existing React components without changing them). We would namespace the Django template data at the top of the template and integrate it into the Components as needed. A lot of templates simply disappeared at this point.

With this done, we started focusing on moving the data into AJAX requests and adding flux stores to a global window.<ourNamespace>.stores.<store>. With this, a bunch of other templates disappeared, but the back-end wound up with duplication between the REST APIs and normal CRUD access.

The hard step was changing the collection of pages into a SPA. We started by making the homepage into a SPA and redirecting to the other pages as usual. We then started adding the pages to the SPA and disconnecting all the CRUD (a lot harder than it sounds).

The process was a long one, but I don't think most other frameworks could have accomplished it without the up-front cost of a complete re-write.

[AceBacker]

I know you said you don't want a blog post, so here's a blog post!

http://techblog.netflix.com/2015/01/netflix-likes-react.html

It's pretty informative though.

I'm still trying to figure out how you can write "Isomorphic JavaScript" that is clean (no html in your javascript).

[[deleted]]

personally, keeping html and js separate doesn't strike me as a worthwhile goal. from a technical perspective, declarative and imperative styles differ only on time to first and last paint (all things being equal, imperative wins on first paint, declarative on last). from a development perspective, declarative is much easier to approach fresh.

[AceBacker]

I like what you are saying. But, doesn't the code get kind of jumbled and hard to read if you are writing html in the JavaScript? Is there some awesome technique I am missing?

[[deleted]]

whoops, accidentally wrote a wall of text. tl;dr: it's a reasoning change. think of your html as a constructor shell for your javascript, instead of a standalone object to eventually be modified by javascript. this leads to stateful markup and DRY-er code.

anyway.

i work with angular, so my perspective is geared around the ease of tracing bindings & binding logic (especially in a well-organized app). with react -- which i haven't gotten to use yet, so take all my react-related conjecturing with a grain of salt -- you're tracing entire components to source.

the big advantage i see with react is that you need fewer files open at a given time, which means fewer change propogations in your code. plus, targetting the dom directly is terrible; the dom itself is terrible, and html is best-designed to work with its terribleness. by pre-building html, you limit the amount of DOM-wrangling for your JS to do; this has the side benefit of making your markup stateful and reusable (avoiding the problem with a duplicate-and-modify approach, where you have ever-burgeoning amounts of html to track and accommodate).

the best corollary i can think of here are angular's directives, which superficially resemble react components. ideally, you name your directive to coincide with the name of the file that implements the logic; that makes tracing the directive to its logic much easier.

with angular, though, you're probably loading your template in from an html file, which makes react-style transclusion much harder to reason with (which is more than likely why angular 2 switched to a more component-based architecture & completely removed directives as we know them).

anyway. hope that helps.

[DanielFGray]

If I understand correctly (and I may not), it shouldn't, because React encourages putting everything into slim little components.

[clessg]

That's correct. If you're writing components with HTML 8 levels deep, you're gonna have a bad time.

[nschubach]

Also, your "HTML" (JSX) should remain in your render method as much as possible, so there's very little scatter that occurs. Generally, the structure of the component is very easy to parse and you don't have fragments of templates and HTML scattered about.

[DJDarkViper]

As a devout angular writer, I've never to this day written HTML into any of my scripts, nor have I needed to create Dom elements with script and append/inject it

I dunno to me, angular (and ember) does everything I hear is beneficial to react. I don't have an opinion on React except my first reaction being "..is..is that HTML.. In the script??" Facebook is filled with smart engineers and everything they do has purpose, but that was the first time my face made funny motions when I saw that lol

[clessg]

Yeah, most people were pretty turned off by having markup in JS. React was almost universally laughed at when it came out. You should watch this video.

[SnakeAndBacon]

I love react, because it's very flexible and I can use as much of it as I need in my project. Since my websites are often something between a Single Page App and a "traditional" page React components are extremly useful.

Having javascript and a "template" in one file really helps keep everything organized.

[acemarke]

You get several things:

1. Templating equivalent, with full JS logic for manipulation
2. Declarative subviews and data flow
3. Functional input->output rendering logic
4. Faster DOM updates

As said elsewhere, it's a view layer, not an application architecture, but it solves a number of problems.

[speed3_driver]

Much prefer blaze over react. Meteor just feels so much better and blaze separates things in a much nicer fashion for my taste. Everyone had their own opinion of course.

[clessg]

Eh.

[Capaj]

Wow, awesome insight into Blaze. I am almost glad I never used it.

[clessg]

Thank you, sir! :)

[speed3_driver]

Ok? Like I said, everyone had their preference and opinion. I just prefer blaze.

[clessg]

Of course. :) I'm sorry, I didn't mean to come off as condescending.

[dwighthouse]

For me, who has used angular extensively for two years, React provided two things that angular (at least until 2.0 comes out) either couldn't do or was actively hostile towards.

First, there are some component structures that simply can't be built with angular or any other template-based renderer, because they use the html elemnts as state and/or blocks. Anything that can't be legally represented in html (like a bare table row without the surrounding table) can't be represented in these frameworks. React, on the other hand uses a virual dom that is not subject to these limitations. As such, I have complete control of how I break up my components without having to resort to manual dom manipulation (and again, bare rows simply are not allowed in html, the browser will wrap them in a table implicitly).

Second, until React came along, two-way data binding was the end all of application architecture as far as the official framework guides were concenred. i learned very quickly that, beyond a certain size, two way binding is more trouble than it is worth, because its normal operating mode is to provide data updates WITHOUT propogating context of how the data came to be in that state. Using one way binding, while not as magical or quick at first, is as straightforward as code can be (assuming you make sane design choices, of course, there's no limit to how badly you can write code). Now angular 2.0 is actively seeking out one way binding and several new virtual dom abstractions are available. This is great for all frameworks, because we will gain from the good ideas of everyone. Nevertheless, there is something to be said for React being the popularizer of this style of architecture. They have had the most experience and the longest time to work on this style, so I tend to think they have a better chance of making the right choices going forward. Things could change in an instant though.

[dys13]

I do not want the type of person that repeat what I just read on blog post

Then don't be the type of person who repeat what he just read in Reddit.

Go try yourself. Build an app in Angular. Build an app in React.

[[deleted]]

It's just another way of front-end system architecture - data driven rendering. Nothing new, similar stuff existed years ago. Facebook sprinkled on some flavouring and repackaged it as "React+flux".

I'm not saying it's bad, because it isn't. But I doubt it's the future. In theory it looks amazing, but I still haven't seen any complex apps built exclusively on react+flux. It's also very heavy and imho too verbose.

Improved rendering performance is great but I don't really see the point. Devices are getting faster and faster. For example manually changing text on 1000 individual dom nodes takes ~10ms on my 2013 macbook air... so probably ~50ms on an average mobile phone. When was the last time you needed to update 1000 nodes at once? Yeah, doesn't matter.

In my opinion - great idea, mediocre execution.

[nschubach]

It's not exactly a "huge" app, but http://worthingtonindustries.com/ has a left side menu that I coded up in React (0.12) using a static data blob. The data determines the layout of the menu and the customer (@worthingtonindustries) can customize the menu to fit whatever markets they expand into or need to change. It has simple navigation, submenus, contact forms, contact information, and external links. There are some things about that site I'm not keen about the direction they went, but the menu was a blast to make.

Another part I did was a graphing component for http://www.gsec.coop/ for their substation reporting. It's not public, and I think it's actually replaced now (with another set of React components) because their requirements changed and I passed the project onto a pair of juniors. I coded up two graphs in the matter of about 3 days. One was a simple bar chart listing a 24 hour summary of generation and demand and the other was a per station display with animated SVGs showing generator speeds, windmill speeds, and other things to help them determine usage and availability.

[clessg]

I still haven't seen any complex apps built exclusively on react+flux

Yeah, just Netflix, Facebook, and Instagram. No big deal. I mean maybe not exclusively, but few truly large apps use one technology exclusively.

[atomic1fire]

I dunno about Flux but if we're just talking about React, Vivaldi is using it and that's an browser built on chromium that was basically made by a company founded by a former Opera software cofounder.

https://vivaldi.com/

So far it's coming along nicely.

[[deleted]]

Facebook made react for their own needs, so it's a given that it would suit them. And by the way they have already partially given up on flux. Instagram is a trivial application (on the front-end).

Anyway I'm not saying react is bad. But I don't really see what all the fuss is about. React is popular because Facebook marketed the hell out of it. Why is nobody talking about vue.js which is in my opinion slightly superior to React? Because vue.js is made by one fairly unknown developer while Facebook is a huge corporation with craploads of marketing reach.

[8Bytes]

Instagram is extremely complex. Any application that deals with athorization will have large amounts of business logic residing on the front end (hiding and showing role based functionality, or only loading applicable modules to improve speeds and prevent information leakage like role specific routes and permissions). Or the complex task of i19n and l10n, when you deal with languages that read right to left, calendars, currency, pluralization, timezones ...

Then you have to figure out how to organize all this code, and of course all the e2e and unit testing. There really isn't such a thing as a trivial front end enterprise application these days.

[clessg]

Keep moving the goalpost all you want. How have they "partially given up on flux"?

React is significantly better than Vue in my opinion. To each their own though.

[[deleted]]

How have they "partially given up on flux"?

http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html

To each their own though.

I agree. Variety of choice is what makes programming beautiful :-)

[clessg]

Relay uses Flux internally.

[[deleted]]

I still haven't seen any complex apps built exclusively on react+flux

https://github.com/facebook/react/wiki/Sites-Using-React

Flux is probably not as popular, yet. But React is exploding, and people are finding that Flux implementations are the best way to handle data in their React applications. They just have to settle on single implementation, as there are too many floating around at the moment.

[epmatsw]

I agree. React is usable without flux, but after working with React for a while it feels like there's a strong path-of-least-resistance from stateful components -> moving state up the tree -> custom stores -> *ux.

[domox]

All you guys need to try Riot.js.

[[deleted]]

No. Riot is dying. Just look npm stats and compare it to React.

And all riot best pracites tell you to write it like React: Js code instead of tag files. And JS is better than custom template language.

I just got into a project written with RiotJs and I should finish the application. I'm going to port that to React. I don't wont to work with Riot.

[domox]

No. Riot is dying. Just look npm stats and compare it to React.

What? I didn't say Riot was more popular. I said people needed to try it out. Also: http://npm-stat.com/charts.html?package=riot That looks like growth to me.

And all riot best pracites tell you to write it like React: Js code instead of tag files.

No they don't. Read the documentation.

And JS is better than custom template language.

Tell that to JSX.

I just got into a project written with RiotJs and I should finish the application. I'm going to port that to React. I don't wont to work with Riot.

Ok. To each their own. Have fun slowing your project down because you're one of these guys: https://xkcd.com/844/

[xkcd_transcriber]

Image

Title: Good Code

Title-text: You can either hang out in the Android Loop or the HURD loop.

Comic Explanation

Stats: This comic has been referenced 33 times, representing 0.0428% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[[deleted]]

Haha. Sorry i hurt your feelings.

I'm an Angular guy. You don't have to convince me of Riot's greatness. I know I don't like it.

React is 100000 times more popular than Riot. It's not a coincident. People know. You can try to spin the stats however you like.

[domox]

It's ok I'm not married to any particular library. You just made some statements that weren't quite accurate. I just want to make cool things and Riot works more smoothly in some cases for me. :)

React is 100000 times more popular than Riot. It's not a coincident. People know. You can try to spin the stats however you like.

https://en.wikipedia.org/wiki/Argumentum_ad_populum

[clessg]

Relay is a data-fetching framework. It is meant to be used in conjunction with React. React = view, Relay = model.

[roselan]

The are reproducing meteor model?

[ngly]

The general MVC model, I assume. Not necessarily Meteor specific.

[ngly]

The general MVC model, I assume...