My problems with React:
- They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms.
- They put too much functionality into a single framework.
- Frameworks are a bad idea anyway. It is much better to divide functionality into self-contained libraries.
- They try to redo what the web, a huge standardization effort, is doing.
- React does not fully support all HTML/CSS constructs.
Now all of this isn't really a problem right now. But if React grows and gains more traction, then it could become a problem (just like Internet Explorer became a problem after a while).
It's just JavaScript wrappers for native UI toolkits. Much in the same way there are Python wrappers, Ruby wrappers etc. The only difference between React Native and someone else's JS bindings is that React Native makes use of a virtual view hierarchy and several other React-isms - which have absolutely nothing to do with the web except in-so-far as that they were first implemented on the web.
Yes, React Native supports an API based on the web's Flexbox API, and view styling similar to CSS - but these are applied to native views. React Native doesn't implement any rendering of its own. However, if anything this is bringing web technologies to native development, they're in no way conflicting with browsers - React Native has nothing to do with a web browser.
As I said, React Native provides bindings for native UI development. Now, whether or not you think that's a good idea is up to you. Swift and Cocoa are generally pretty good, so I can see why iOS devs might steer clear. However, the Android SDK is a complete joke, React Native is significantly more efficient to develop with.
Are there any other reasons for choosing one over the other? Are they similar in terms of what you can do/the performance? With libraries like phonegap/cordova, you have to sacrifice some APIs and the resulting app may be more sluggish. I was wondering if it's the case with React Native.
React and React Native are framework/libraries/whatever made by Facebook to solve Facebook engineering problems (they're cool in the way they unashamedly only open source what they actually use).
They have their own paradigms they prefer and it works well for them and many others. Why should Facebook cater to every programmer's favorite paradigm?. You could honestly say the same thing about most frameworks—do people complain Rails makes it hard to do functional programming?
React is in no way a layer over Javascript. React is just an API to write UIs with pluggable backends. The backend can be HTML, HTML Canvas, iOS UIKit, Android widget toolkit, Winforms, GTK, QT, etc etc. It's just a higher level API for writing UIs in Javascript. It's not a platform for application delivery. Browsers and application run times + stores on iOS/Android/Ubuntu are are platforms for application delivery.
React is not even a framework. It's just a library which you can include in your bigger framework.
> - They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms.
Programmers who don't like how React works can use something else. There are lots of choices out there. Angular2, om, cyclejs, mithril, ember, backbone are some of the choices. You make it sounds as if React is a browser with a limited set of APIs.
I'm not saying React is perfect but the arguments you make are totally invalid IMO.
I was thinking about JSX here. It is translated to Javascript, so a layer, imho.
Layers are not a bad thing. What is bad is that React tries to lump together many layers into a single framework.
Not clear what you are referring to by the "many layers" or indeed the "framework".
(disclosure: I've been an Angular 1 dev for a bit over a year and only skimmed some React material, but I have also done other stuff for the last 30 years)
Check out this project to see how people use React without JSX:
While it might sound redundant, it's more about making UI layout simpler, faster, and all in all more "native".
There's already plenty of browser view-based layout frameworks, and in general they run into the same limitations (performance, lack of native components, etc). This is an alternative solution to that. Think of it as a middle ground between Xamarin and Phonegap.
I'm tired of websites trying to be apps just so they'll have a better distribution model or once in a lifetime use site that wants me to install it's app.
The fact that they are making all this with Open Source is even better.
Besides, the standard protocol bodies we know from the web today (and that many of us don't like at all) were created after Netscape or IE created the foundation upon which they work on alone.
Exactly. Therefore, in my opinion, Facebook should instead try to get the web back on track of being the application delivery standard. If this is not possible (google/apple not cooperating), they should imho give ReactNative an API that is compatible with the web. Of course, they can build their virtual dom etcetera on top of that (but it should be optional).
And as far as I know, FB actually tries hard to improve web by participating TC 39 actively. Web is still big part of them.
I meant that React Native can become a replacement for the parts of the web (or just html, the web is bigger) that try to be an application inside what is essentially a document viewer.
I think the web (or rather html) is wonderful for what it was intended for - document viewing and editing (sometimes collaboratively).
Blogs, newspapers, Q&A sites and anything built around content really, should definitely still be in built using html/web , but the various SaaS products should be built using a tool built for apps.
In the end, I do believe Facebook - as a company that can't really move fast anymore (and doesn't have to) - knows this imposes the same restriction on smaller companies by taking away their agility and maxing out developer resources for work on what used to be trivial stuff. Rationally, from Facebook's perspective, React has to serve two functions: priming and funnelling programmers into their enterprise, and suppressing development efficiency elsewhere. It's positioned very well to achieve both.
The fact that it continues to enjoy high popularity despite being designed, as you seem to think, as a tech debt Trojan horse.... maybe you have to consider all those other companies out there know something about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't.
> If other shops felt the same way you did about React [...] about the folly of developing apps with "vanilla HTML/CSS/JS" that you don't
I'm fairly confident that almost nobody shares this opinion, so personal attacks on my competency are expected, yes. The problem with all tech fads is that support for them is absolutely ardent, until the pendulum swings in the other direction.
It was unwise to post an unpopular opinion and I accept people's judgement that it was a net detriment to the discussion. But I posted it and now it's out there. If it's any consolation, I wouldn't do it again.
http://www.joelonsoftware.com/articles/fog0000000339.html
The idea that big companies keep throwing out new technologies to keep little companies churning, even if it didn't exist when Joel wrote about it, could have been adopted after. Of course, some of his calls were wrong in that article, but that's a different discussion.
I know that sounds like a copout, but it's just my personal experience. We just rewrote a slow React app some person that didn't know what he was doing did at work and it's fast and fine now.
They have no reason whatsoever to think or act like you described.
People facing problems with regular JS/HTML are looking for React or other solutions. Just a hip factor can't justify its popularity.
Not true. Application complexity has increased over time for the web, that is the effect you are perceiving. React actually helps cut through that complexity like a hot knife through butter.
> Performance is abysmal,
The above response applies here as well. What performance are you talking about specifically? There are a ton of large scale, production applications that are running React ...
> and as is the case with many frameworks, you're soon reaching a point where your people spend more time (and in the end: computing resources) tricking the framework into doing what they want it to do.
React is not a framework, it is a very basic view library. There are literally only seven public API endpoints that developers use:
* componentWillMount
* componentDidMount
* componentWillReceiveProps
* shouldComponentUpdate
* componentWillUpdate
* componentDidUpdate
* componentWillUnmount
That's it, that's all you have to learn, the rest is generating markup and learning about setting properties and state within a component. The only exception that I will admit is that integrating react with d3 is awkward.
Having built large web applications before React came along, there is a very good reason why it is so popular and that is because it moves the focus from dealing with transitions between states and simply dealing with the state as if we were building the app from scratch.