> React becomes counterproductive when developing apps that aren't mere demos.
I have developed big apps in Backbone, moving very the same apps to React and the productivity went up madly. Facebook does develop apps which certainly cannot be considered "mere demos" and you can see them in action, for example Ad Manager for Facebook on iOS (written in React Native). Facebook invests a lot in React development and there is a reason for that - they use it internally intensively.
> It's marketed to developers by billion dollar Facebook, a company historically intent on squashing startups.
This is not an argument at all. I would be really surprised that's the reason for React to exist. Also React is more a way of thinking, the library itself can be replaced if Facebook should enforce it on a successful startup.
> The utility gained by using React's ecosystem is significantly outweighed by its overhead.
This is certainly not my experience. React has very little overhead and from my experience it's pretty easy to grasp the concept for new developers.
I have no idea where does hate for React come from, it's >> just << an open source library and I wonder how people are willing to start flamewars about a few lines of code. If you don't like React, don't use it. There are a few alternatives like Ember, Angular or even Backbone (although I would say Backbone deserves much more hate than React).
React itself is pretty simple and very nice to work with. The whole react/redux/react-redux/react-router/react-router-redux/webpack/babel/flow agglomeration on the other hand is a lot more complex and subject to a lot of api churn. But you can actually get pretty far just using React by itself. Don't adopt other parts of this stack until you actually really need them and you can go pretty far with just a few concepts.
And yes, React is as much a technique for building UI as it is a particular implementation. Learning and using React has also improved the iOS code I write.
Fully-agree. From the start, Netflix was talking about React being useful because you can drop it in to various pages without affecting other UI views.
I use it at work on a page-by-page basis-- it drastically reduces the mental overhead of class naming, JQuery spaghetti, maintaining the DOM etc. Sometimes I even surprise myself when something "just works" because of React's well-controlled model.
>Fully-agree. From the start, Netflix was talking about React being useful because you can drop it in to various pages without affecting other UI views.
This is Reacts greatest strength and a huge design constraint they had from day one. On the other hand it's a tradeoff and as everyone mentioned not having the whole stack under "one roof" brings a lot of tedious crap.
If you need something to incrementally rewrite parts of your frontend React would probably the best choice. If you need something to start your project on I'd consider other options, Angular 2 and Aurelia for example.
Why not take your comment a step further? That is, you can get pretty far using plain js `createElement` and similar functions. In fact I've created a fairly complex SPA without using any external libraries. Don't use react until you absolutely need it!
Back in the day, jQuery was amazing because it made selecting and manipulating DOM elements easy. But now, plain JS has mostly caught up to that functionality, to the point that it rarely makes sense to use jQuery over plain JS. I wonder if in a few years the same will be true of much of the functionality in react.
Before with libraries like jQuery every potential action had to perform it's own UI modifications.
As the projects grows you have the same UI element being controlled from many different sections of code. States and state transitions not clearly defined.
With React you set the state and the UI will always match, no matter how the current state was achieved.
The purpose was to get rid of ad-hoc DOM manipulations.
The Flux architecture just takes this a bit further by formally defining who holds onto the state/how it's accessed (stores) and the availible possible state changes (actions).
Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.
It might not have a explicit opinion stated anywhere but in any library or framework, the API provided influences how those APIs are used.
By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations.
Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function:
"The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:"
And then goes to show a DOM selection followed by a chained mutation.
> [...] I feel implicitly encouraged DOM manipulations.
That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues.
"All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly.
It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives.
At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl.
You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even less. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now.
While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.
Take an average developer (or two) and sit them down in front of React and jQuery for the first time. My bet is anything based on React will be better built than that of jQuery.
Of course you can architect those flexible, extensible, testable and clean projects. But straight out of the box you do not get that with jQuery. It requires planning and architecture engineering.
Whereas every React project starts off with those principals.
In other words, the ways people can use jQuery wrong is worse than the ways people can use React wrong.
I both agree and disagree. If you code yourself into a corner with React it can be harder to understand and untangle: it's much easier to understand jQuery under the covers than React, especially if you're using other parts of the React ecosystem.
None of this is related to what I said originally, which is that jQuery doesn't encourage shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it.
> [Good code in jQ] requires planning and architecture engineering.
Precisely what I said.
(That said, if you don't do that with React, you'll still end up with a mess.)
My point about planning and architecture was to contrast it against what I believe React is better at.
Personally I think React is easier to understand. Honestly the vDom is an implementation detail people get stuck on. Pure functions, well defined state owneeship and transition, and so on are the real benefits.
The other main criticism is JSX which is totally optional and mixing implementing with presentation; the "correct" which I believe to be a outdated but still accepted belief that went out of style around Web 2.0. This separation is not required either, you can rewrite render() to pull from any templating engine or whatever. Or use HOF/HOC via the presentation/containener design pattern.
I realize I went off topic but I've been wanting to compiler my thoughts on this.
React is better at enabling planning and architecture; that's part of its job. That was explicitly not part of jQuery's job. jQuery was a tool to be used as part of a larger strategy. Lots of people chose to ignore that part of their code, and paid the price.
I like JSX quite a bit as well; IMO creating an artificial separation between presentation and behavior is not a useful way to think about web apps.
Separating data from presentation and behavior is fine, and is a long-standing GUI tradition.
I think we're really in agreement about everything. The tools have intended jobs; some people use them incorrectly or without regard to best-practices. Both have different strengths and failure modes.
I would say JSX and the separation of presentation / behavior is orthogonal.
JSX is just a Javascript powered embedded SGML-like document.
The combining of presentation and behavior is caused by render() being defined inline with implementation.
You can not use JSX by using ReactDOM directly or a templating library while still keeping render() inlined.
Or you can move render() to another class (or subclassed, or HOC, whatever) and separate the presentation and behavior with or without JSX.
We're moving closer to having real GUIs in the browser (e.g., Java Swing) but that's not a function of the language, but the plumbing around the language. Swing isn't Java, Swing is written in Java.
If you use createElement, appendChild, and innerHTML, you can replicate a lot of the functionality of react. In fact react probably uses a lot of that under the hood. Of course for more complex applications, react is cleaner. But for relatively simple components, manually manipulating the DOM like this might be worth skipping the overhead of react.
Yep, agree entirely, although I wouldn't advocate mixing the two in a single application--mixing mechanisms is added cognitive overhead.
But again, JS is just a language, that happens to have an interface into a DOM (in some environments). It's not a framework that guides you in how to organize and architect an app.
It's possible to write maintainable, high-performance, complex apps using plain JS. Adding a few simple layers makes it a lot easier, though, and I'd argue that the current crop of client-side frameworks make it easier still. Simple apps == simple code. Complex apps == complex code, regardless of the tools used to create it. Underneath everything, after all, is still just plain JS.
Well then to return to your original point that redux/webpage/flux/blahblah are overkill and you shouldn't use them until you need them, you can make the same argument. They are more layers that guide you in "how to organize and architect an app." The tradeoff is that you get simpler code in exchange for more architectural overhead and a more complex build process.
I never said they were overkill (and I'd argue Redux or similar pattern is useful even for fairly simple apps).
For an app of any reasonable complexity you'll have "architectural overhead" whether or not you're using your architecture or someone else's. That's just a given. (And if you don't, you have more overhead trying to figure out what you were doing.)
More complex build process? Yep, if you're not writing all the code yourself, and you want to distribute a single file, and ES2015 (or other) transpilation, and minification, sure. But you can use all the libraries in question without much of a build process at all, just load 'em all up and use ES5.
Complex build processes are a result of wanting to distribute and write code in a certain way. They're not a requirement.
> Don't adopt other parts of this stack until you actually really need them and you can go pretty far with just a few concepts.
Redux is very core concept. You'll have to rewrite half of an application, unless you use it from the start. Routing is essential for any serious web site, so you have to implement it one way or another, and not using working libraries looks strange. Same about babel — either use it from the start or rewrite half of code later (or have a mess). Also I think that babel currently the way to process JSX, so unless you avoiding JSX (which would be very strange), you have to use it anyway.
I don't agree, that you can avoid all this stuff, unless you are just learning on throwaway pet projects or willing to reimplement a lot of things which are already have good enough implementation.
I'd tend to agree with the parent here. Then appeal of React is that it's one piece where everyone else is trying to develop a full stack. Your needs for that single piece will be more consistent across projects that are either legacy or new.
A full frontend stack is total overkill for the vast majority of projects that fall under the "open, check, close" use case. So many of the perks of those frontend stacks, such as keeping data in the browser and only reloading certain parts are based on the slow load times of a full frontend stack if you don't do all of those things.
Being able to use pure React both client and server side without anything else is a fairly significant perk.
What I need in every project is react for the UI, babel for modern JS and webpack. (I went through combinations of gulp, browserify, requirejs and brunch. Webpack finally solved the packaging-mess for me).
Redux is something you can implement yourself easily, I never understood the need for a library there.
The good idea of redux is to have a serialisable state which is changed through events. This gives you unidirectional data-flow and the ability to pause/restore your application.
Complete immutability and funneling everything through functions on the other hand often just obscures readability, and, in case you are using immutablejs, gives you terrible performance.
If I want to have purely functional programs I don't use Javascript, but Haskell or something. If I need time-travelling debugging, which I never found very useful when dealing with complex states, I'll implement it by copying my state using serialization.
> React becomes counterproductive when developing apps that aren't mere demos.
I also just don't understand statements like these. React is used by very smart engineers at Netflix, Uber, Lyft, Airbnb, etc and a ton of startups. It's well documented by these people that using React has been a productivity boost and they love it.
I know "argument by authority" but come on, you can't just say "React is bad for real apps!!!" when this list[1] exists.
> I have no idea where does hate for React come from, it's >> just << an open source library
I think most developers (at least seasoned ones), come to appreciate tools as a solution to the problems that they solve.
There's always going to be a vocal minority that is strongly against whatever has the most hype at any given moment. Their reasoning is probably as varied as the people themselves, and a some of the criticism may be valid, but this is the nature of developer culture.
Well, React has one huge disadvantage: It requires you not suing FB, even if they abuse some of your own patents.
That patent license they have in their project basically means you can only use React as dev in a company if your company does not have patents or noteworthy IP.
The important point is, you don't lose FB's license grant if you counter sue them. You lose the grant only if you initiate a lawsuit.
Here is the relevant section from the PATENTS file:
if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminated under section (i) of this paragraph due to such counterclaim.
It is an opinion held by many (many here) that Software Patents bring no value to the community and need to be abolished. I agree with them, and hence I disagree with you. I did not down vote you.
I really don't give a shit what anyone says, for me personally ReactJS makes front end great fun to program and an absolute blast and empowers me like never before to build powerful, interactive front end apps with a code base that is well structured, understandable and makes sense.
Until React I dreaded front end development, painful, weird, quirky, hard to organise and generally problemtic. With React I feel like a front end guru.
AngularJS felt like some sort of weird computer science project developed by Phd's who had spent their university days studying Java - it hurt to learn it.
Call me a hipster fanboy if you want but I choose technology to work with because it is easy and make sense. I don't have much time so I have to commit my limited resource to the optimum set of technologies. At the front end that is React.
-Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome.
-The system is poorly documented, making it hard for a dev to get started.
-The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?).
-But most importantly, it implements stuff that has no buisiness being in an SPA web framework. It re-implements scoping, modules, part of JQuery, DI, and a programming language, complete with parser.
React, however, did the responsible thing, and stuck to a specific domain. Even if nothing else React did was good (and I have some arguments there), this is a major win over Angular.
Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree.
See vue.js and ractive
But is also true that 2way double binding take more memory that virtual dom.
Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow.
And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't.
VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever possible, or minimized by catching multiple bind events at a higher up element on the tree (see http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...)
Just spraying it everywhere, the way Angular encourages, with no optimization (like the aforementioned asymetrical bindings), should be considered an antipattern.
Are you talking about Computed Values? Because Data Binding has nothing to do with that. Not really.
In any case, Computed values make 2 way binding more expensive, because you have to run a depgraph on all the vars that are part of the binding network, every time an event fires. This is O(n). This is only one reason why Computed Values, as implemented in JS, are a Bad Idea. If you have to update a var on event fire, okay, but leaving the things everywhere is slow and ungainly. If you instead change the var to a function call, you can optimize far better, because you only have to update when the value is read.
In conclusion, if you want to polymorphism between functions and variables, treat everything as a function, not as a variable.
At least, I think that's a response to your question. Your English is pretty broken, so it's hard to tell. Sorry.
Not sure what you mean "rerun all the tree", if you change a a state variable that is added as a prop in another component it has to rerun refresh on those components, but only those components, so not all the tree. Also not sure how this relates to atomic updates, with a flux pattern each state change is associated with ui changes propogating down, the difference to angular is, they aren't supposed to be allowed to propogate up, which you can do in angular since there isn't necessarily a central state store and since there is two way binding children or parent can change the variable.
It's easy enough to write two way binding into a react state variable, it's just nice to not have it happen by default since having state able to change anywhere in the app can get confusing.
A virtual dom is stupid about the view is only an algorithm that diff 2 trees. A data binding can create a graph of knowledge about the view and can create the best and fast mode for update the view.
Library like ractive and vue are the best tools for create animations in svg or where there are many updates of view
Yes but generally speak you must do all this things manually and also optimizatio s and binding you must know what updates. In a real 2way db this is automatic also for performance.
No, the perf's pretty bad if you do a lot of binding, and the manual binding gives you a better sense of what your app is doing, the performance tradeoffs you're making, and more control over an area where you'll probably have to optimize.
Mmm no sorry i don't agree. For me virtual dom is only a tree generated from code,diffed and batched. Speaking only of the algoritm.
For me databining templates libraries are vue and ractive.
See this 2 links for comparison.
https://vuejs.org/guide/comparison.html
That's true, but what I meant was that all VDOM based systems have binding to some degree, and where optimization is required, explicit is better than implicit.
With Angular, you're basically having to learn an entirely new MVC framework, complete with a mess of its own methods and definitions, which is built on an already existing MVC framework (a web browser).
When I took some time maybe four years ago or so to study Angular, I came to the conclusion that it's just the wrong way to go about web development. I started thinking hell, I'm just gonna write my own library which strictly handles the view portion. Low and behold, I find React, and it's everything I was hoping for.
If anyone is thinking about trying out Angular, save yourself time and headaches and use React or Vue.js
I don't see if it makes much sense to compare Angular with React.
Heck, it's like a Pythonista would go comparing Django and Jinja. One's a framework, another's a template library. Same goes for Angular and React - Angular's a framework that tries to be do-it-all solution (UI rendering, validation, data model description, data persistence and communications with server, and more), React's an long-distant ancestor of templating libraries that essentially does only one thing - takes a data structure, a component definition and renders (and maintains) a DOM tree.
Seems that many are calling non-React pieces that are frequently used with React (e.g. Redux, Flux, Immutable.js, Restful.js) to be "React" as well, while they don't seem have any ties to it.
But, yea, loose coupling's great. And React is a very nice library.
Well, I have to say, I had the feeling already when using ExtJS4 and Emberjs.
Even more than with React, because they both felt much more full featured.
But yes they were harder to grasp than React and I prefer the tiny API of React over that convult that ExtJS is. And yes, I prefer JS-as-templates over that whole HTMLBars stuff Ember throws at their devs.
I see some point-missing arguments being made here.
React isn't for scale. And it isn't to side step learning about html and css. It's main reason for existence is to make complex UIs easy to manage.
Pretty much the only argument I can think of against React is that it's a boil-the-ocean system.
Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its model. Having different interlinked components mixed between react and query and what-not is asking for trouble.
But. Building your UI as a description of your current state is so incredibly useful to reason about and prevent bugs, that it's usually worth it to go completely into the system.
The only other major gripe I have is getting time-based elements like animations to play well within the system.
React is for scale, just not the way you think: React is designed to allow lots of journeyman web developers implement parts of a web page together, such that every component can work by itself and that one component's failure does not break other components, allowing pages consisting of multiple components that may have been dynamically assembled from dozens of different authors to work together.
This seems to be a central point that the "I can just do this in CSS/HTML/JS" crowd continually misses. It really doesn't matter that you can do it... It matters that you can dynamically compose your work with hundreds of other people.
IMHO, most expert devs don't meet this bar with pure web tech, but unlike the W3C, I don't blame the webdev for poorly composing solutions, I blame the web standards themselves for poorly defined compositional properties.
But the platform has at least risen to the level where we can define its behavior ourselves. So I think it's healthy for other sources to push innovation because React upped the ante for Web Components and Web Assembly. The W3C will eventually understand the need for composition and isolation at scale, but they would have taken a lot longer to recognize the use-case without a competing concept like React.
"Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its model."
In my experience React is quite ideal for cases where some parts of a site or an app need dynamic behavior. I'm currently working on an e-commerce platform's admin panel, and for us a complete rewrite would have been nearly impossible. With React we can keep the old HTML + jQuery codebase, and implement/refactor stuff as small or as big as we need (e.g. a live-search component or a whole new dashboard view). We're doing something very similar to this: https://github.com/reactjs/react-rails#rendering--mounting
Right - it does work and we have incrementally introduced react as well.
But that works if the various existing components on the page don't have strong multi-directional data flows between them. At least that's what I've experienced.
> It's marketed to developers by billion dollar Facebook, a company historically intent on squashing startups.
Except when they are buying them for billions (WhatsApp, Instagram, Oculus). All things being equal, Facebook is probably more likely to buy your startup if you use React.
I don't believe React to be mostly hype. It's so frequently being used by skilled and informed teams that I would consider anyone who make this claim to be ill-informed.
But the claim and current consensus around web development is that "you should absolutely use a framework built by someone smarter than you or you'll end up shooting yourself in the foot" I find equally ill-informed.
Consider these popular libs and then consider how poorly they integrate with each other: jquery, bootstrap, require and knockout. If you are off by a version or two in jquery, then bootstrap will not work. Up the version of jquery and parts of your app will break down. Try to fit libs that aren't modularized or that use hard-coded deps with require. You'll end up rewriting those libs (to get rid of deps you don't need).
I feel javascript should be mature enough to use without frameworks. Remember the cutting-and-pasting of the javascript.com era? We're back to that, I feel. I mean, surely there are lots of smart snippets of code or even libs that you want to use in react but can't because the code-snippets or libs aren't following the react architecture. What do you do then? Cut-and-paste those parts that you need and that will fit into react, perhaps?
Yeah, really cool website! I'd like to see more arguments laid out this way. Of course that doesn't necessarily mean the points are substantive. :) But it would be nice to collaboratively edit all the common arguments (vim vs emacs for example, which is on this site) so that we have one canonical place to link to when the same argument inevitably arises time and time again.
No thank you. None of the other "discussions" are worth wasting time over. Just people bringing feelings, sophisms and misinformation to an argument fight. It's no better than a reddit thread.
You got heavily downvoted, but the linked argument-story is an example for this. Less emotions would be nice.
Some day we may have a forum (in the broadest sense) that uses a sensor, like a webcam, and "emotion recognition" AI. You are not allowed to vote if you are too worked up about a comment, and if you post it will be held for a few hours and you have to acknowledge that you still mean it after that "timeout" period before it gets published. This should/could take care of some hot-headed responses. I think digital discussion needs more ideas, just "post your comment here" and "votes" don't really cut it. It's better than nothing (pre-Internet), but we've seen the disadvantages by now, why not try something new?
Internet discussion and collaboration software could be (should be?) the most exciting thing, instead everybody just copied and barely modifies the core concept in use since the very first web forum software was first published.
React is a pretty simple concept (with, perhaps, a complex implementation) reified in a library. It's basically componentized state machines for UI rendering. Comparing it to general "web frameworks" is completely missing the point. Granted, some people do [often needlessly] install a lot of react-whatevers for everything from routing to mysql fetching (yep).
I can see it being replaced by another library with a similar underlying philosophy that just does it better, but I don't really see how the general idea would vanish soon.
And btw Facebook uses it a lot on the web too (not just the often mentioned Ad Manager), messaging (and messenger.com) is basically all React and other components are a mix. Download the React Devtool to check it out, they don't obfuscate the React tree at all. Pretty fun to browse.
Whoa. I have been working on larger web apps at pre- react\ angular\vdom time and i'm really glad i don't have to read tons of tutorials about what might cause my Browser to repaint or even reflow the entire doc to get some Good enough performance. And react really shines for bigger projects since you only care of locale components.
I'm still undecided as to whether React is up to snuff for large-scale development projects. I work in a medium sized company developing enterprise-targeted web software. We have been using ASP.NET + jQuery + whatever JS design pattern to artificially namespace our JS for about five years. This summer we moved to React + Redux for a new product and it has been pretty amazing. Productivity did not go up (immediately), in fact, learning the React way and constant adjustments to what we were storing in Redux slowed us down considerably. However, we are across that hump and it FEELS like we have some really good, reusable components that will save us lots of time going forward. At this point, extension and composition should be really trivial and the next few months will really form my opinion on React as a tool (and of course, myself as a user of that tool ;) ).
However, the ecosystem, not just React but the npm ecosystem in general, has been a bit disappointing. Things move very quickly in some places but not others. React itself has broken or generated warnings numerous third party packages that, hopefully, will catch up. It's disappointing because it basically forces us to not update our main dependencies until everything has moved with it. Perhaps that's my fault for placing the npm/js world on a pedestal, but then again, I think I've only done that because, while .NET is generally favorable today, the inertia of past criticisms had led me to believe that the .NET ecosystem was somehow inherently deficient or broken when compared to the JS ecosystem. At this point, they seem fairly similar in terms of quality and choice.
One big plus with moving to any npm-centric development is that, coupled to a move to Windows 10 and using bash, a lot of the dev workflow has moved out of, say, Visual Studio and into a command line. This is great because as we move build and deployment configurations between machines and tools (say to Jenkins), there aren't lots of details hidden in our project and solution files. It offers a clarity I didn't know I wanted.
I find all the recent negativity around React-related posts to be very frustrating.
I'm a frontend engineer, and I greatly enjoy working with React. But I think that's because I've invested the time needed to learn and navigate the ecosystem.
It's true that React doesn't solve all the problems you deal with when building a web app. But I don't think it has ever marketed itself as a "batteries included" solution. It gives you a strong ecosystem and a great abstraction for building UI's.
Our team of seasoned AngularJS developers recently tried out React for its small enough footprint and the huge community support. We loved it, our client loved it. I don't really see such bad things about React at this time.
React is _just one framework_. Popular, sure, and occasionally annoying (for very small things, the overhead of building a gigantic workspace vs just using Zepto and ending up with three JS files is... well... pointless), but we should be looking at the broader picture.
I did one medium sized SPA in react (using alt.js) last year and wasn't really convinced, maybe i did something wrong but i did not feel the amazing productivity boost that so many people mention. Managing a lot of dependencies of the modules i used for various things like forms, file uploads etc has been painful and in general the module quality felt very alpha in many cases so i ended up reinventing what has already done pretty well in angular in terms of functionality.
Code organization and best practices also wasn't easy to come by because of the many ways of doing things and in the end some solutions felt more like hacks than a solid implementation.
Angular1 is certainly not perfect but i found the whole thing to be much more consistent and Angular2 using Typescript is what i prefer most right now.
I don't really see the difference between most modern JavaScript "frameworks". It's mostly in the details, and any of them would work just fine. At this point it's like arguing which of X number of programming languages are the best.
Part of seems to be: "How dare people not like the tool I prefer", or simply that people don't want to be bothered to learn yet another JavaScript library (which I can understand, but I'm not being prevented from using the tools I like, just because React exists).
One "mistake" I see React make, others do too, is mixing JavaScript and HTML. I'm still firmly in the camp that believes in progressive enhancement as the correct way of developing for the web. React, Angular and most other modern libraries doesn't seem to share that view.
This is the best comment in the thread. And as if tech hiring wasn't bad enough already nearly every company hires with the expectation that you have hands-on professional experience with the framework as if it would take years to jump from Angular to React. If you're comfortable with at least one JavaScript framework, I don't see it taking anyone very long to acquire the knowledge to start working on another.
First time I read a blog post about react and saw it's artifacts so to speak I threw up in my mouth. Js AND HTML, mixed! Wtf? I spoke about this to lots of front-enders who laughed and called me old. I agree with your point. If markup and UI code can be separated, why wouldn't you strive for such a solution?
I am not fan of React. It is great to have something like React for people that aren't primarily into software development, because of html and css and js (many designers and hobbyists got into programming with those) but I do not appreciate it. The fact that I do not have (nor want) any single Electron app installed on my computer tells something. It is okay to be there as a choice for app development but I want to see less of it. It doesn't come close to native apps. And Qt is getting really better and better each day, and right now is pretty portable, so you don't have to write 3 different versions of apps for different operating systems. Just not my cup of tea, and I hate that it is hyped, because it is reflecting bad on some developing habits and community.
> The fact that I do not have (nor want) any single Electron app installed on my computer tells something
Not really. Besides, React has nothing to do with Electron.
I am into software development, and I use React daily for frontend-applications. While I'm not swooned as much as most people, I still thinks it has great value.
> And Qt is getting really better and better each day, and right now is pretty portable, so you don't have to write 3 different versions of apps for different operating systems.
Assuming you want to write an app in C++ that doesn't need it, and are comfortable with not having any of Electron's sandboxing features. While JS isn't my preferred language, it does beat doing everything in native code with full filesystem access.
And apparently Qt is so much better, which is in the process of integrating a full browser engine for Qt Quick, which is… somehow better than using a full browser engine directly? Okay.
Neither React or Angular are mostly hype. I posit that SPA's, whose implementation is made less painful by React, are mostly hype.
I liken it the Lisp macro analogy. Never write an SPA unless absolutely necessary--stick with a web page with some dynamic js-driven features as needed.
SPAs can be a good thing when used internally in a business (ease of distribution, sandboxing, etc.), but I agree that any public-facing web site is probably best served by static HTML with minimal JS where it is absolutely necessary.
I've been using React for a side project for a while. Generally it's been pretty easy to understand the concepts behind it and get productive. A couple of things that have confused/irked me a little:
- Having to figure out babel, browserify and/or webpack before you can write hello world isn't a great first experience. I'm glad to see much of this has been moved to a separate page outside of the getting started guide now.
- The main React page emphasises that JSX is optional. Even looking at the trivial examples, nesting createElement statements looks horrific. Does anyone use this approach in a large-scale project? If your components are fine-grained enough, perhaps it's passable, but it looks far from ideal. Having used other frameworks, even building up a template in JSX in a return statement feels dirty. I see there are some suggestions around on splitting out JSX, but it would be great if this was the default.
- I wasn't really sure what to do with CSS. There's a brief comment on inline-styles at https://facebook.github.io/react/tips/inline-styles.html. For a library for building user interfaces, it seems like this deserves more attention. I would've expected the CSS (styling), javascript (logic and state management) and JSX (layout) to be a little less interwoven.
There are like 3 or 4 different ways of doing it, each with their own pretty big drawbacks.
Personally we ended up using CSS Modules with SASS in our "main" react project, but it feels clunky.
The biggest issue we have is determining which element "owns" the styling. Should a widget style itself, or should it let it's container style it, or should it provide some simple defaults and let the container overwrite them (which gets ugly because with CSS Modules overwriting means using !important or doubling classes (like `.button.button` to overwrite `.button`).
All that being said, it's actually working out really well for us despite feeling wrong. And it might not ever become an issue because our largest stylesheet is like 100 lines long since everything is so compartmentalized.
I've used React in four projects (after many projects in Angular[1])
1. In terms of best practices, React for serious development is a disaster just by itself. Read on.. This is what happened in my first project (when I didn't use Redux). By itself it is only good(and great) for POCs. And React-ecosystem is complex to start with. React-Redux, Router, Axios, Webpack make React complete for use in any serious project.
2. React makes web-componenting pretty easy. However it is counter-intuitive when you start thinking about the all important Smart Vs Dumb components separation. I don't know about others, but I like to see components as behaviour-complete stuff and not just view-complete. React with its ecosystem does things in a view-complete way. Yes, it does result in much much lesser bugs.
3. React is hyped because of its simple examples. As I said earlier, it makes it easier to create behaviour-complete web components. But then the ecosystem says "NO. NO.. Think in REACT way". That is not wrong but its complex. The first project in React was a disaster because of the complex state management I did without using redux or flux.
4. After working with React - when I tried Angular2, I moved back to React again. And I did React+TypeScript which makes coding even easier. The only thing I still like in Angular2 is now-not-default two-way data binding.
Do I love React? May be not so much - but its the best I have seen. But I love the way my apps remain bug free without a lot of front-end testing code. And once you add TypeScript, development is just a bit more easier and bugs get thrown up at compile/transpile time
No kidding. These aren't arguments, they're claims. Making an argument involves using reasoning to support claims... you can't just draw boxes around five claims and say it's an argument.
I think this submission is more to promote the Arguman service than anything else. Because most of the submissions come from just two people, who both joined the service less than 24 hours ago.
React is good for complex app desktop but not if you need performant and fast interface with 60 fps otherall in mobile.
Last virtual dom like snabbdom preact and inferno are really fast also on mobile.
And inferno and preact are compatible with react component.
Vue.js 2.0 use an intelligent mixin of reactive data graph dependency and virtual dom separating the static and dynamics parts of template.
Monkberry.js translate a template in pure javascript function with createElements and update nodes. Function that can be optimized from the jit
I don't know about the React model and APIs themselves, but VDOM is the Right Thing, from a performance perspective, as well as from the ease perspective. And the advantages are far from academic.
Offtopic, but HN usually talks about the value of ideas vs. their execution... well I have had this website's idea, literally, in my notepad for a couple of years as a possible side project, never getting down to implementing. And here it is! Also clicking on the domain I see that it has been sent here periodically during the last year...
I better get to work on my actual project so I'm not overtaken :/
From reading more, it appears that Facebook can just terminate your right to use their patents, but not React. However, it isn't clear to me what is patented and what rights you lose.
Right, if you look at the contents of the license in the discussion, they are variants of "if you try to fight us with patents, we will deny you a license/patents".
So you can compete with FB without losing a license. The first blog post you quoted shows a misunderstanding of the license (the word "compete" doesn't show up in the license).
So the correct representation is "If you claim patent infringement by FB, you can lose the license.". This is what the linked comments say, but what your summarised statement didn't properly capture (hence my comment).
The excerpt in the article is more accurate; if you initiate a patent infringement claim against FB, you forfeit your rights to use react. Seems fair to me.
Generally downvotes are best used not to indicate disagreement, but to punish comments that detract from or add little to the discussion. If we downvoted everyone who disagrees with us, discussion wouldn't be very meaningful. But if we downvote those who do not add to the discussion, we can maintain high signal to noise ratio.
I understand that this is the intended policy on HN, but I have seen far too many cases where a greyed out/downvoted comment has obviously been downvoted for disagreement to believe that the policy holds in practice.
Maybe there should be an 'are you sure?' prompt on pressing the downvote button reminding users of the policy.
> React becomes counterproductive when developing apps that aren't mere demos.
I have developed big apps in Backbone, moving very the same apps to React and the productivity went up madly. Facebook does develop apps which certainly cannot be considered "mere demos" and you can see them in action, for example Ad Manager for Facebook on iOS (written in React Native). Facebook invests a lot in React development and there is a reason for that - they use it internally intensively.
> It's marketed to developers by billion dollar Facebook, a company historically intent on squashing startups.
This is not an argument at all. I would be really surprised that's the reason for React to exist. Also React is more a way of thinking, the library itself can be replaced if Facebook should enforce it on a successful startup.
> The utility gained by using React's ecosystem is significantly outweighed by its overhead.
This is certainly not my experience. React has very little overhead and from my experience it's pretty easy to grasp the concept for new developers.
I have no idea where does hate for React come from, it's >> just << an open source library and I wonder how people are willing to start flamewars about a few lines of code. If you don't like React, don't use it. There are a few alternatives like Ember, Angular or even Backbone (although I would say Backbone deserves much more hate than React).