Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle.
I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style.
Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org in order to fully achieve Satori. I mean, if you're going to drink the Kool-aid, you might as well down the whole pitcher.
I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And there will be numerous small isolated parts of your codebase that are unrelated to the aforementioned goals, where sticking to FRP would be masochistic and pointless.
A major part of mastering a technology or paradigm is knowing when to apply it and when the costs of it outweigh the benefits. Then again, I prefer hybrid-friendly languages like scala, so maybe the haskell and clojure people are onto something that I'm missing.
I agree with you. I also like being "closer to the machine" so to speak. One day, my dev browser will support ES6/7 and I won't need babel + webpack/browserify while doing locally development, debugging will be done on unmunged code and TDD will be easy to practice as the feedback loop will be back to normal.
Agreed... about the only thing from ES7 that I feel the burning need for is await/async, which I've been using for some time via Babel, and it makes the code so much easier to reason with... the hardest part is explaining to people that an async function returns a Promise and can be wrapped/used as such.
From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.)
Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump.
React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier.
However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different".
The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.
I think a lot of attention is given tot he DOM diffing... I don't think it really means that much in practice as far as understanding the flux-like workflows and how applications come together.
To me, the unidirectional data flow, optionally immutable data structures and even tooling around redux (and similar) are what are nice. You have predictable, testable output without excessive complexity.
The need to understand a certain level of complexity in React+Redux in getting started is indeed a bit higher. But as features are added, that complexity doesn't grow nearly as much as with Angular.
I find the simpler node-like requires/es6-imports are easier to reason with than dealing with angular's weird DI system (though better in v2). Testing injection is supported via tooling (proxyquire and the like), and you can do full unit testing of your UI without firing up a browser.
I agree that full on FRP isn't needed... but will say that having data flowing in one direction, and events in the other can simplify things a lot. I'm also not sold on static typing for JS, as someone who really likes C#. I also think the use of classes in JS should generally be very limited.
> Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon...
I don't think most front end developers even care. React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. They'll go on to learn React and not think twice about the minutiae of "FRP" or whatever the programming paradigm de jour is because at the end of the day, people just want something they can easily grok, something that works without too much hassle and something that is going to be used/supported for the long term.
> React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need.
Not just that. Facebook uses it for their flagship website (and as React Native for their mobile apps). So does Instagram. So does Netflix. If you have the React developer tools installed you can literally go to facebook.com or netflix.com and see them using React.
Angular in turn can't really namedrop use cases like these. Yes, Google uses it somewhere in their ad manager, YouTube uses it in their video manager, Amazon uses it for something -- these are big names too, but the use cases aren't nearly as impressive and they're not as integral to the relative companies' core business. Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React).
The difference between React and FRP in turn is that React simply builds on well-understood ideas that already exist in mainstream front-end programming: modular components and one-way data flow. You don't need a CS degree to understand the benefits of having your views not directly manipulate your state.
FRP isn't bad. It's just that React is good enough, which is what really matters at the end of the day.
> Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React).
Excellent point. Here's another "smell" with angular: http://angularjs.org versus https://angular.io/. The former is AngularJS 2.0 and the latter is AngularJS 1.0... they maintain two websites for two versions of the same framework.
It boggles my mind.
Who thought it would be a good idea to separate versions of the framework onto two different domain names? While they're still owned by the same company? Why? Unfortunately, the only sensible answer that comes to mind is "AngularJS 1.0 was such a colossal, terrible mistake that we need to move away from it not just from a code perspective, but from a marketing perspective as well."
Normally, I avoid framework/language wars but I had ( and will soon again have ) the misfortune of developing in Angular. Consulting out-of-date documentation on their quick-and-dirty bootstrap site, fervently wishing that the devs didn't rage-delete the comments section which corrected the incorrect documentation... yuck.
We were over the moon about Angular in 2014, but it quickly showed its failings as we got a bit deeper in. 2 way data binding is just precarious. But the thing that really killed me on the whole idea is how TERRIBLE it is as a user of Doubleclick Bid Manager. It is SO impossibly slow that it is practically unusable on a laptop with 4GB Ram and an i5. For a few months we could only actually upload ads to the system if we used OPERA!! If their shining star UI that gives Google about a billion dollars in revenue a month is this bad, we asked ourselves "why we should try to emulate it?"
I feel your pain. I was making a case primarily from a marketing/community perspective, but the code and its ( lack of ) organization speaks for itself as well.
The reason is because Angular 2 merges Angular Dart and AngularJS into one framework.
Can't say I have first hand knowledge, but I have heard that Angular dominates internally at Google.
UI Bootstrap is also separate from Angular (if that is what is meant by quick-and-dirty bootstrap site) - I am currently the lead developer of the project, and not once in my tenure have I deleted any comments, and I know of no instance since I joined in March this year of anyone doing so. The documentation certainly can use work, but we are unfortunately strapped for resources with not much quality work coming from outside the team. File issues if you have problems, but otherwise, I can only say that usually the team responds correctly, and it is usually immaturity on the reporters' side that is the issue we have observed.
I think the jab at the "quick-and-dirty bootstrap site" was about the Angular docs (which seem to use bootstrap or at least look that way), not the UI Bootstrap project.
I'll engage because I'd like to get to the bottom of this.
> The reason is because Angular 2 merges Angular Dart and AngularJS into one framework.
One technical reason for a seismic marketing change does not inspire confidence. Is Angular, Angular JS 2.0? Is AngularJS, AngularJS 1.0? Incoherency at the starting gate will not win new converts.
> Can't say I have first hand knowledge, but I have heard that Angular dominates internally at Google.
Company wide usage is fine; the real test is in production outside of the company. Unfair, but if the framework wants to dominate the front-end, then that is its lot in life. FB probably realized how fast that moving goal post would be and resolved limit their scope with React.
> UI Bootstrap is also separate from Angular
It's not the Bootstrap that is bad, but how they use it. At the time in 2013 (and even now) the presentation of the Angular website is pretty ugly. Yes, there are coders who don't care for little UI flourishes. Yes, a pretty framework with bad code is still a bad framework. Yet, when comparing AngularJS's website with competitors like React or Ember or even Backbone, it seems their developers care more for making their software look good. Design as a lagging indicator of quality, perhaps.
> I am currently the lead developer of the project, and not once in my tenure have I deleted any comments
You probably joined after this debacle. Strange that you don't know about it:
The reason for removing all the comment threads was ostensibly for easing concerns of moderation. Yet, interestingly, the documentation was not updated for several months after the comments removal. This means that, for several months, all the fixes, suggestions, and the like were no longer viewable for the current version of AngularJS. The solution put forward by the developers for this long interim was to... use Stackoverflow.
Needless to say, Angular users were less than enthused. That the devs didn't seem to engage with the community before or after regarding the sudden change, made me question a number of things about the project.
Sorry, I was mistaken on the bootstrap comment - UI Bootstrap is separate from Angular and has little affiliation with Google other than the creator of the project being a part of the core Angular team.
I can't speak to the online interactions as to the comments, but I do recall the comments being outdated and not useful in a bunch of cases.
The Angular team is very professional and pleasant to interact with in my experience though. Igor once told me that open source is hard - I was skeptical at first, but being in charge of a major project myself now, I wholeheartedly agree. It is challenging to keep development going at a good clip, manage the team, and satisfy developers using the product, who are a ruthless bunch.
We use UI Bootstrap heavily on roadster.com and have been very happy, albeit with some customization. I hear your pain about outside contributors to OSS but am excited you're keeping up the great work.
The new Grubhub UI is built around Angular... and it shows around the edges in the types of quirkiness and bugs that show up around state/workflow. I don't fault the devs ag grubhub for this, but the types of problems I typically see around Angular are pretty typical.
Personally, I really appreciate React+Redux... it seems to be the distillation of a lot of ideas. Also, good or bad, React has actually removed features in support of a better project/application workflow. That doesn't even get into how goofy I feel that Angular's DI system is (better in 2, but not good).
React has embraced the larger JS/npm community/tools and Angular seems to be actively fighting against it.
React killed their JSX transpiler after Babel added support for JSX. Angular merely merged AtScript into TypeScript.
React had CommonJS module support from the get go. Angular1 was incredibly awkward to use with a real module system, Angular2 is only marginally better.
The difference is that React is much less opinionated. You can tie it into your existing Backbone app or you can use Flux (or one of the many Flux-like libraries out there) or you can use Redux (which is in many ways exactly like React, but for state) or you can use something like Relay or Falcor or even something entirely different.
Angular wants to own your project. That's not necessarily a bad thing because it also means you don't need to evaluate the relative pros and cons of lots of tools doing what it already gives you for free and you're more likely to find help because there are more people with your specific combination. But it also limits how much you can adapt Angular to your specific application's needs.
The more you deviate from the defaults, the more you lose the benefits of using a full-featured framework in the first place and the more you have to muck around trying to bend all the parts into the shape you want.
Plus you actually CAN use React inside Angular (or vice versa) if you really want to. It's probably not a good idea because React doesn't do anything Angular can already do (but differently), but it's entirely possible (just like how people already used Angular with Polymer or Backbone or what have you).
I wouldn't say React influences the rest of your app as much as Angular (or Ember) necessarily does but saying that a tool will influence the rest of the app is almost tautological -- every decision affects other decisions, even if it's only because of the mental models it may bring with it.
The truth is, it's not a decision between Angular or just React. You're not going to simply use React. You're going to use React plus something else. That's simply a set of decisions choosing a framework won't require you to make.
The comparison isn't meaningless because there is no either-or choice. The comparison is meaningless because it's incredibly hard to compare just React with all of Angular (or Ember or whatever).
Elm will not replace React among most web developers for the simple reason that it is not JavaScript. It's easy to incrementally introduce React to JavaScript developers. Requiring an entire new language is a non-starter for many web developers (though I think the popularity of CoffeeScript and Babel et al is changing that to some extent)
When evaluating techs to make our frontend evolve, I looked at cycle. It seems genuinely interesting, and much more FRP than React+Flux, but it doesn't seem to have a lot of traction.
I don't know about that. You can write controllers and models in react, it is just an anti-pattern. The same is true of Angular. Angular is usually used as the V, and a little bit of the C with protected controller functionality server side, and APIs for public model interfaces and public controller api endpoints.
React will be short-lived because of Web Components, not because of Elm. Either that, or React will evolve to be a Web Components framework. The days of proprietary component silos are numbered, IMO.
React goes into the exact opposite direction than Web Components. Declarative vs. imperative. (Relatively) clearly defined state vs. mixing DOM and JS state. What's your evidence that WCs are replacing React?
>Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org in order to fully achieve Satori
Lot of ppl do server side rendering with react so elm is not going to cut it.
Maybe React core is in ES5 but most React components are now bejng written in ES6/7 with things like decorators and async functions, not to mention immutable data structures, and you may use Flow to substitute for static typing.
I can't believe in the team behind Angular 2.x they STILL have the same basic flaw in their thinking about UI development: their ideology is in contradiction to the idea of keeping it simple yet flexible.
1. You can use types with React, either via Flow or in TypeScript with TSX. Unlike with Angular, with React you can also get type checking even in the JSX template (checking for valid component property types included, even with TypeScript)
2. You can "externalise" your render method if you really want to by simply writing
import MyComponentTemplate from './external-template.tsx'
let MyComponent = React.createClass({
..
render: MyComponentTemplate
..
})
then in external-template.tsx
export default function render() {
return <template goes here>....
}
Most React users think its unnecessary, but it doesn't mean its not possible.
React v0.14 adds "stateless functional components" syntax, which essentially makes your external-template.tsx a valid component on its own (with the caveat that no state or lifecycle methods are allowed): https://facebook.github.io/react/blog/2015/10/07/react-v0.14...
There seems to be progression into breaking apart components that have decision trees with components that are simply rendered... I've had a tendency to favor this myself.
Also, simple components can defer events to prop/parent binding.
For someone who hasn't had to do much work on the front end JS technologies like Ember, Angular, React, etc. What is a good resource to start learning Angular 2 (even though its not out yet)? I came across ng-book2 [0] but I've heard mixed reviews about their first book.
With a major framework in alpha like Angular 2, your best bet is to try diving into creating a major project, and to figure out how to build components. Reading the source code is important at this stage, but there is also https://angular.io/cheatsheet
I should mention that it is still rough at the moment. There is a major problem with component API design currently with the lack of a good mechanism to flow changes from the child components to the parent and vice versa for interoperability, but the Angular team is aware of this and working on a solution. I would highly recommend against using Angular 2 for production code currently - it is alpha after all, and it comes with all of the pains of breaking changes, and flawed APIs.
Testing is not as straightforward to figure out either - I believe we on the ng-bootstrap team are the only third party library to actually be testing in Angular 2 currently, so if you want to see how tests work in Angular 2 & how to implement the infrastructure, I would recommend checking out the repository here: https://github.com/ng-bootstrap/core .
The team I'm apart of started a project 2 months ago. We chose React and Redux over Ember, Angular, et al. A main decision factor was that we needed the server to render our initial HTML, neither Angular nor Ember can achieve this easily, we'd most likely have to lean on a third-party service. Angular looked particularly unattractive with Angular 1 being as good as dead and we didn't feel confident starting with Angular 2, there we're simply too many unknowns. We loved the hot loading & the redux-devtools features, turns out these have given us a decent productivity boost.
2 months into the project I'm confident we chose the best tools for the job, there's been absolutely no regrets from the team members.
The problem is that the surface of Angular is incredibly complex.
With React, you have components, which are just things (classes or functions) that convert a set of properties to a subtree of more components (ideally mostly ones that directly represent DOM elements) and do so deterministically and reproducibly.
With Redux you just have objects ("actions") representing changes to your application state and functions ("reducers") that convert an action and the current state into the future state. There are also functions ("action creators") that help you create the former and functions ("middleware") that affect how Redux processes them.
With Angular1 you have templates and directives and components and models and scopes and controllers and filters and injectors and services. And services can be constructors or factories or providers or values or constants or decorators. And scopes can be isolate or nested and there is the digest cycle and there are watch functions and if you do anything async outside of Angular you need to make sure to trigger the digest cycle (but not if you're already in the digest cycle) and I haven't even talked about interpolation yet.
Angular2 is slightly better but the docs are pretty sparse and many people's brains will still shut off as soon as they hear "dependency injection" and have you fucking seen what they have done to HTML to maintain their false illusion of "it's just HTML and JavaScript, designers can understand this"?
React doesn't need you to think. Initially the API made you define components by using a magical function, then they extended it to allow just using ES2015 classes, now you can even define simple components as plain old functions. The surface has shifted from minimal to nearly non-existent.
Redux has more conceptual overhead than React ("Wait, reducers can't have side-effects? Where does my AJAX go?") but most of the learning time is spent un-learning concepts you take for granted (e.g. you shouldn't mutate state, your components should ideally not have any state at all and it's perfectly fine to normalize your state because you only need to derive it when it actually changes). The number of actual concepts Redux brings to the table is fairly low.
Angular is a battleship. React+Redux is an attack submarine.
> Angular is a battleship. React+Redux is an attack submarine.
> The value of the battleship has been questioned, even during the period of their prominence.... battleships were increasingly vulnerable to much smaller, cheaper weapons...[11] https://en.wikipedia.org/wiki/Battleship
I'm not sure if your metaphor was intentional, that Angular is like a flashy, seemingly powerful but ultimately archaic, dead-on-arrival platform, but I appreciate it nonetheless.
I found it useful to actually read the Redux docs page-by-page (at least the introduction and basics) but it also links to some tutorials.
I actually had to read the basics and advanced sections several times before it fully clicked. It helps if you don't expect Redux to be super complex -- like React it does just one thing: manage your state by responding to actions. If React is the V in your MVC, Redux is the M.
This is a very noob question. I started with React. Its just great. While I was working on the "component" thinking, I just thought react does provides "states" concept in which we can store the component's state. Which is ( for me ) looks like React does provides the model too (what I'm thinking right now is setState as a model and render as view of React lib). Probably my thought process is wrong over here. Am I wrong here?
But if one can store the component state in React setState, why one should look for "Redux" or any Flux libs?
Ember has a solution for server-rendered HTML, called 'Fast Boot'. It can be used both for speedup (quite obvious, given the name) and for e.g. SEO-purposes (though I think Google is pretty good at crawling JS these days).
It's still at a very early stage though (alpha), but I think it has great promise. More details in the recent 2.3 beta changelog:
(Not saying you made the wrong choice, it sounds very reasonable -- Ember's solution isn't ready for use just yet. But thought I'd note this here in case others have the same thought)
We did take a look at Fast Boot and if I remember correctly it came with a big caveat that it's only suitable for the most brave. If Fast Boot were stable then Ember would have been a real strong contender.
I'm really excited at the rate of pace of change on the front-ends. My last project was in Backbone and React & Redux feel a gigantic leap forward. I'd love to experiment with Elm and Cycle.
yep, i'm also working on a react/redux project (where i'm only js senior and rest of the team are rails devs with only basic js skills) and big advantage is, how easily and quickly they became productive. We have other project in Ember, where logic was to take advantage of similar concepts & conventions as in rails, but in reality it's incomparable.
But what about angular being a framework and react being a library? Ido hate to invest time in react only to find out that when working on some project it doesn't provide all I need. By project I mean some backend api and front end SPA
React is less full-featured than Angular is less full-featured than ExtJS and so on.
You're not going to use a single tool to build your project. You're almost guaranteed to using different tools to build your frontend and backend (even if some of the tools may be the same or some of the code may be shared). You're extremely likely to use more than one tool for either of them.
Nothing will "provide all [you] need". If it did, it wouldn't be a library or framework, it would already be the finished product you're trying to build.
React does one specific thing and it does it incredibly well. If that thing is what you need: great, you can use React as one of the tools to build your product. If it's not what you need: don't use it. You shouldn't worry about whether something provides everything you need, you should worry about whether what it provides is actually what you need or not.
Angular does a lot more things than React does. Logically that means it's less likely to be a perfect fit for your project. You're more likely to find out that it does something in a way that doesn't work for you, simply because there are more things it does. But it may also do enough things in just the way you need them to be done to be worth the few places where it doesn't fit your project perfectly.
It's always a compromise. Unless you have unlimited time and can develop the perfect tools yourself, you're going to have to make a few sacrifices along the way.
If it doesn't provide all you need then it's easy to involve other non-React code to make it all work. That's what's so great about it being a library - you're free to implement whatever pattern you'd like around it. For me, that's Flux/Redux (I use actions to call to well defined services) but it really doesn't matter.
I think there's a list somewhere of patterns that are difficult / non-ideal for React but I don't have it in front of me. For 99% of use cases React really isn't going to be a detrimental choice as long as you choose a good pattern to surround it with.
I found Build Your Own Angular [1] gave me the most understanding in the least amount of time. It's geared more towards understanding (and Angular 1 not 2) and not so much towards building stuff though so YMMV.
I have to say that it does not start from scratch when it teaches angular 2, it expects you to have some understanding of angular to understand what's going on.
I, myself, tried to learn it by generating a sample project with Yeoman. Only to find myself in a project where so many things were already done for me that I couldn't make sense of all the pieces that allowed it to work correctly.
I would make a couple of changes and if one of them broke something, I was not able to quickly identify what I had done that was a problem. I'd recommend that you go step by step a build a small app from the ground with tutorials.
Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have found by far the best approach is to start off with just the basics (i.e. React alone), and only add in additional libraries when you start hitting problems you feel could be solved in a more optimal manner (e.g. Redux when state management starts getting messy, then redux-form when you realise form onChange handlers etc. are a bit tiresome to write, etc.).
It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter.
The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack.
One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.
I've had exactly the same experience. I tried bootstrap generators like yeoman, cloned "starter kit" repositories, etc... And they would all have ~1 kilolines of code and a bunch of dependencies. If I tried to do anything (like, say, add react-bootstrap), everything would stop working.
The best way is to follow a tutorial and build a small project from the ground up. Stay away from prefabricated solutions until you understand what's going on.
IMO, if you need to generate a lot of boilerplate code for your React app, the app is likely incredibly boring and generic, or your code is unnecessarily bloated, or both.
It's not just boilerplate code. It's choosing your build system, your hot-reload plugin, whether you want to use jsx or something else, whether you want isomorphic rendering (so that the server will render the initial state of the page, instead of delivering a blank page with a <script> tag), etc.
True, but normally for React that should boil down to an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started) but not much actual code.
>an opinionated set of defaults (e.g. React+Redux and probably react-router using Babel and probably Webpack) plus a small number of files (e.g. Babel and Webpack config files, maybe an ESLint config file, the obligatory package.json file, and a few empty folders for components, actions and reducers to get started)
See, but all of that is highly non-trivial and everyone has different opinions.
The principal designer and maintainer of the Elm Language (a functional reactive lang that compiles to JS) did his Master's Thesis on FRP, and that's a great resource if you want the big picture:
If you ignore the whole thing about how frp is not FRP, and how javascript developers really only mean frp, then a good place to start would be learning about RxJS.
FRP is deterministic and referentially transparent, frp is not. Key concepts in FRP are behaviors, events, signals; key concepts in frp is streams, observables, subscriptions. Although I'm not expert with either, there's a lot of overlap and term overloading, and I might be explaining this all badly anyway.
AFAICT, the simplest way of explaining the difference between FRP and "popular frp" is that in FRP things are described as functions of time, whereas in popular frp they are streams of events.
The "real" FRP is great for describing non-interactive things. They can be used to describe anumations: e.g. a FRP behavior can describe the position of a ball as a function of time:
ballPosition :: t -> Position
whereas in "quasi" frp, the ballPosition is a stream of Position values:
ballPosition :: (Stream Position)
Basically, quasi FRP is what you get when you sample real FRP at certain times :)
A small part of it is that your events are basically constant streams of data (think arrays) you can map, reduce, and filter (among other functions) and then present. Here is a short article on it:
It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams.
Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.
I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subjects.
I am hesitant to spend time learning on react because of this:
"
SomeCallMeTim:
I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year.
But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity.
On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better.
And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance.
The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development.
I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3]
Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :)
[1] https://www.pandastrike.com/posts/20150311-react-bad-idea
[2] https://github.com/Matt-Esch/virtual-dom
[3] https://www.nativescript.org/
"
I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style.
Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org in order to fully achieve Satori. I mean, if you're going to drink the Kool-aid, you might as well down the whole pitcher.