11 ms·
I've been coding and training people in react for a while now, and here is my experience: - if you learned react by yourself years ago, you had to go through a
by sametmax 6y ago
I've been coding and training people in react for a while now, and here is my experience:
- if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier.
- if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation.
- react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it.
- the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen.
- there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs.
- so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house.
- then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them.
- when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?".
- integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently.
- react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to.
- the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one.
Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team.
The teams that can manage React correctly are not that many outside of our bubble.
And for the ones that can, the price of using react may just be not worth it.
When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.
- partyboat1586 6y agoReact native code re-use is possible just not in the way people imagined. You can reuse your Redux code, you can reuse higher order components you just can't reuse the atomic UI elements. React native performance is good too it just doesn't come for free. You need to know how to do native animations and you need to do late binding and all the other performance optimisations you should be doing with React anyway. The only thing that lets React Native down is the tooling. I've had the debugger repeatedly push stale code on refreshes, the source mapping is atrocious and sometimes the network debugger just refuses to work. Also sometimes the app fails to load and you need to reload the app and or restart the debugger and or restart the packager in the right order.
- iainmerrick 6y agoIs React Native performance really good? Compared to what? I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI. I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components. Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)
- karatestomp 6y ago> Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.) My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.
- 6y ago