A response to “An experienced JavaScript dev’s account of learning React”
medium.com
medium.com
The guy used Redux, I'm sure, because he knew he needed to manage state somehow - and the articles he found probably pointed him there (rather than vanilla component state)
He knew he wanted some sort of routing system, found react router, was got a bit scared by how quickly it has been moving lately - and also, likely, how many existing articles about it are somewhat outdated
Etc
I do think it's important to consider, however, that — contrary to the belief that React.js is a cesspool of anti-patterns — that we're actually watching creative destruction at it's best.
Yes, libraries are moving fast and breaking things. Yes, competitive solutions are releasing at breakneck speeds. But that's more or less what happens when you reinvent the way people build things, as happened with the virtual dom.
And while we're paying for it in up-front build setup, we're vastly making up for it where it counts: JS applications that can grow big (at least I am).
The React team can't be held responsible for the amount of crappy advice on the Internet. And cognitive overhead is the nature of the beast with all frameworks. Nobody is going to launch an Angular/Ember app without a significant amount of research. Hell, Rails barely requires any knowledge of Ruby at all, since it's effectively its own ecosystem.
The React team should not be held responsible, but these problems do warn people to stay away from the React ecosystem. If the React team doesn't want people to stay away, it's in their interest to do something about it.
> And cognitive overhead is the nature of the beast with all frameworks.
It is, but they vary wildly in (a) the total amount of cognitive overhead required, and (b) whether you need to deal with that overhead before you even begin, or slowly, over time, as you develop your app. Modern JS development front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place.
No they don't. There is bad advice for every framework/language that exists. Following bad advice means carefully trusting sources. It is 100% on the user to determine whether an article applies, or it's plain wrong.
> If the React team doesn't want people to stay away, it's in their interest to do something about it.
Do what exactly? Start sending take-down notices for poorly written articles? Would you use a chainsaw to make a miniature, and then saw the chainsaw manufacturers need to "do something about it"?
People are so weird about frameworks.
You're not wrong, but isn't it especially difficult for an inexperienced person to judge whether an article applies?
It is. But nobody has the time or patience to determine that for every article, so if the React team wants people to use React, then it's in their interest to insure good articles about React are easier to find than bad articles about React.
> Do what exactly? Start sending take-down notices for poorly written articles?
Write good articles & tutorials, as well as share & popularize the good articles that are out there. Ask the companies that use React talk about React and how it solves their problems. If developers like starter kits & scaffolded projects, then write some good ones and toss them up on Github. Make sure the message that they want to get out doesn't get buried under all of the poorly written cruft out there.
They're under no obligation to do any of this, but nor are most developers under any obligation to use React. If they want people to use React, and the message that React is a good, easy framework to use is getting lost, then... well, how do you think that's going to end up?
Or to put it another way: there are a lot of JS frameworks out there. React needs developers to use it, more than those developers need to use React specifically. So they should be willing to do some of the heavy lifting needed to attract people; moreso if there's a negative message already out there.
I'm somewhat torn on this. I'm currently a JS dev, using React, and I have few complaints. In particular, without regard to the specific API, I think React promotes good models of thought and separation of concerns. It can definitely be done poorly, which can make it a pain to change, but as you say, that's true for anything.
BUT - Long ago I did a long stint as a Perl dev. Perl is somewhat infamous for the ease of writing terrible code. I can say with confidence that one can write solid Perl code that is easy to understand and modify. I actually credit the lessons I learned as a Perl dev for improving my code quality in all languages ever since, and there are expressive concepts in Perl that I wish would be implemented in other languages. That doesn't mean that the Perl community (and developers of the language itself) get to ignore that Perl was EASIER to write terrible code in - and in my opinion their(our) ineffectiveness at changing that reputation was as much to blame for the decline of Perl as the Perl 6 crawlout.
React is no Perl - I'm not trying to set up a strawman here. I'm just saying that "there is bad advice for every framework/language" can be true and still not contradict the concept that a reputation for problems warns/scares away devs. (That said, I think React isn't suffering that reputation, JS is)
Bang on. I not only found the same thing but found that the unknown potential complexities, as well as known complexities, outweighed the potential benefits. And since the potential benefits (React Native, primarily) are so great, that indicates a bit of an issue!!
Do we extend this same courtesy to the PHP team? Or do we treat it as indicative of something?
PHP devs got well-deserved flak for a long time, not for the "crappy advice" (although there is plenty to go around), but for the language itself. That situation has improved, so yes, extend some courtesy.
React has done a pretty damn good job of looking at the "crappy advice" and treat it as pain point indicators, thus improving React further by fixing those. But you simply can't do that for everything, and a lot of the awful advice you find is what happens when you have a very low barrier of entry to both use something and give advice on it.
My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?
> "My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?"
Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man.
> Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
They do, with their official docs, which are well-written. What, exactly, do you want them to do about third parties?
React does as well: JSX is a bad idea that's unfortunately not going anywhere. And I never said it was the same exact thing.
> "They do, with their official docs, which are well-written."
I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise, when in fact that is a key role experts play.
> I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise
My point is that regardless of whether they do (and most of them indeed do, React devs included), you shouldn't be blaming them for "not doing enough" in that regard. It's never going to be enough. That's the thing with experts: They're rare, otherwise they wouldn't be experts in their subject, they'd have the average amount of knowledge. There's always going to be less of them, thus it's harder to educate at scale.
JSX is syntactic sugar. That's it. Not a bad idea by an stretch.
There is a lot of Rust evangelism on HN, but one ting they do seem to have grokked is that quality of documentation is important to building a userbase. If all that's out there are a series of out of date blog posts then that's the level of documentation.
Plus, I'm fairly sure I remember (but have no citation for) the Rust team reaching out to try and get the community to update old blog posts (or at least put in links to newer documentation).
In my experience whenever you start dealing with state you need it. Which is in fact quite early in the project.
For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline.
Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
Abramov has been beating this drum for a long time: there really are a lot of React apps that use Redux but really don't gain anything from it.
And even if you want to centralize state, with local state it's not even that hard to do yourself (put it at the top or in a few small containers, push everything down, have callbacks that bubble it back up. A bit verbose, but easy to abstract out, though you'll end up with something close to redux).
The main issue with all of this is that 95% of the stuff you read about all of it on the internet is wrong, namely because building a real app and maintaining it is very different from making a toy project or a Silicon Valley style MVP in 6 months. People optimize for the later, then when they start maintaining their app its shit. So all the info on the net helping you to reduce boilerplate, optimize for the first version, etc, is just hurting you (but its almost everything you find online)
We also use TypeScript though, so this more OO-style approach felt more natural. It's not particularly verbose (in the context of interfaces and static types, so YMMV) and it's been extremely easy to work with so far.
I find it especially ridiculous when people use future versions of stuff to deflect high level criticism of some ecosystem as it is right now. It is one thing when the critic has a specific issue thar is a show stopper. It is an entirely different issue when someone describes their overall experience.
Instead, this is a case of "I wrote a framework that works exactly the way I like it, and then used a framework that doesn't, so here's why the one that doesn't work the way I like is waaay worse than the one I wrote."
But my favorite part: The next React will allow returning an array of components without a div wrapper. Small change, but it annoyed me to no end that it wasn't already possible.
React is great, and judging by the growing ecosystem, many people agree. If you don't like it because it requires you to learn a workflow you are unfamiliar with, don't use it.
Unrelated to the technical side (which I haven't investigated in much depth yet as a third party to this discussion), I don't like it because of the patent license, which AFAICR is a valid concern for a non-trivial number of large firms.
I can look at external analyses, but the firms I've spoken with have had their own IP folks examine it and have each made their own decisions, so I'm merely parroting the accounts of those I've spoken to.
Edit: my initial comment (thread root) sits in the negatives but this one is high in the positives. It's interesting observing what I can only conclude is a proxy battle between the technical crowd and the crowd that understands legal realities.
But, React is still just another tool in our toolboxes.
If we're building prototypes or short-term apps, slap it together with whatever tool is fastest for you. If we're engineering something that needs to last and provide a great experience, it's important to know when to use a Philips head screwdriver versus a flathead, or either, or when we really just need a hammer.
However, my websites tend to be backend heavy and front-end light... no more interactive than Reddit.
I agreed with the original post and this reply didn't sway me. I see in this thread that people who had already disagreed with the original post agreed with this, as expected.
Seriously, nobody not called Linus Torvalds should be writing direct replies to criticism of their technology in blog posts (and he's the only exception because reading his replies is very entertaining).
Yes, people like their technology and like how it is, it makes sense for them but, that's not universal; so addressing criticism (even as an attempt of countering the criticism) only legitimizes it.
If one doesn't want to acknowledge that one's technology is not for everyone... one is better off not acknowledging it, in any way; doing otherwise puts that shortsightedness in evidence.
>Your post includes a lot of misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
I didn't reply to many similar posts before, but I felt like this is a good opportunity to jump in and provide some clarifications because there are some factual misconceptions in the post. When unaddressed, these tend to keep spreading and get a life of their own.
Also, we do take this feedback to the heart. In fact we spent time developing Create React App precisely thanks to feedback like this.
>If one doesn't want to acknowledge that one's technology is not for everyone.
We totally acknowledge React is not for everyone! I touched on this in the last paragraph, but it wasn’t the focus of my article. I do try to stress it when comparing React to other libraries in general, but this seemed like a React-specific post.
As a React developer, I also raised an eyebrow at the misconceptions given in the original article. (The worst, IMO, was definitely the part regarding Create React App and the overall toolchain).
I appreciate your take on the article and felt that you did a good job focusing on these issues, whereas someone like myself would've been a bit more biting in my response.
As for how much this actually set the record straight or how much the original post was false information, I guess I'll have to disagree.
Nothing in the original post was false per se, and I, for one, agreed with everything in it, every time I've tried to get into react since it was launched and it's always the same annoyances. It's just not for me and it's not for the author of the original post.
Two different points in OP's reply were "well yeah, but it'll be different in the next version/future!" (amusingly, another point was "well, just don't use the new version!") which means that the original post was... right.
You mean besides:
"I started my app with React 15.5.0 knowing that my code is deprecate before even starting" (addressed by dan)
"in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
"React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
I could only find one more assertion of fact, rather than opinion, which happens to be right:
"Once I understood what was the issue I was dragged into the rabbit hole being forced to add empty divs all over the place to let my app work properly"
However, it's also fixed in the next release.
If you buy into the fairy tale that a complete rewrite isn't going to break anything, all the power to you. I don't, and have no reason to, I've experienced it first hand what such a major change causes. So, not incorrect.
> "in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
So... it is possible but not when done a certain way? How that does make the point false? "well duh, you're using react wrong!" doesn't help react and doesn't address the criticism.
If it allows to do something, it does, and so it can be used to make bad code, which is where every criticism of every language/framework ever originates; none of it invalid.
That's just things one learns to live with, none of the tools we use is perfect.
> "React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
... Except it does? At the start of October, the official version was 2; at the end of March, it was 4. That's three different versions in five months.
I gotta thank you for this one, because it precisely requires a very charitable reading of that.
And even a strict reading gives us two major versions in five months, hardly all that much better.
I've never used React (but have considered it) and this post just really turns me off from even bothering.
I thought it was important to clarify the factual mistakes (such as the misconception about React rewrite), as these tend to keep spreading once they're mentioned in a few articles.
But I see now that I might have chosen the wrong venue and format to address them, as framing it as a response makes it seem personal. That wasn't my intention.
I only ask out of curiosity, it'd be good to know how FB approached testing as a data point on a major company's approach (vs. say Google)
There is unfortunately a lot of FUD that has been spread around React in general, the React ecosystem, and the upcoming React Fiber rewrite. It's a combination of longstanding complaints like "HTML in my JS? EWW!", concerns about build tools like Babel and Webpack, badly written articles and headlines like the recent TechCrunch post that claimed "React Fiber is a complete change that Facebook has never talked about", and of course lots of arguments in comment sections.
If someone has taken time to evaluate React and determined that it's not for them, that's totally fine. But, when poor articles get upvoted and spread widely, it doesn't help anyone.
Regarding the motivation, it wasn't to defend any decisions. I'm sorry I didn't make this clear enough. The motivation for replying was to highlight some factual inaccuracies that have started to gain traction. I see posts like this every other week, and I've noticed a few incorrect points shared between them, so I felt this is a good time to jump in and help clarify them. I could've done it in a better way though.
I added these two paragraphs:
>Your post includes some misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
>That is not to say that React works well for everyone, or that the issues raised are not valid. But there are a few facts that I think are important to get right before considering those problems.
Left a bad taste in my mouth when I finished reading it.
I can understand the author's frustration when the user's criticism is unfounded in many areas but his points could've been made without the tongue in cheek comments.
It's a double standard for sure, but it's the same concept as when you're responding to a potential troll on social media. You don't want to add fuel to the fire.
In all fairness, I wanted to make sure your points were heard clearly and I felt the tongue in cheek comments distracted from the clear explanation of how the author was offbase and incorrect.
Looking forward to the future releases of React!
I'm sure Dan would have done nothing with it, had the HN community not upvoted the original post through the roof.
I edited the post, is it better now?
TIL. I've been manually setting up my own configs for years now, and never touched this tool because I thought it was literally creating a sample/boilerplate app for you much like the express.js cli generator.
Dan Abramov commented a while back on how CRA differs from boilerplates: https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne... .
Also, I commented with some additional thoughts on why CRA is a better choice than "boilerplates" for someone who's trying to learn: https://www.reddit.com/r/reactjs/comments/5oem3g/recommended... .
Overall, CRA serves three primary purposes: it allows React learners to set up an environment without having to learn Webpack and Babel first; it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere); and it also provides a common starting point for instructions and tutorials. For example, my recent blog post on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...) was able to start by just saying "Create a CRA project, eject, and modify these two config values".
"You are completely right it’s annoying. It’s one of those early design decisions to align better with the DOM APIs that has proved to be confusing. We might change this in the future." - dan
i appreciate dan's honesty here. it was little things like this made the framework look a bit immature and rushed but glad to know these are in the horizon to be improved on.
I like Dan's answer and it shows that many are not really familiar with React and its trivial concept (like me before I tried). React is good and manageable even after a rewrite because it has a tiny API (compared to other frameworks/libs in this space).
https://github.com/Rajeev-K/mvc-router
Note that using MVC does not imply 2-way binding!
I keep seeing this pattern of redux as a page-level data store, whereby on each page load you pull your data from rest APIs, put it in that page's part of the data store, to be modified with that page's reducers, triggered by that page's action creators. Then it's all hooked up to one single page-level connected component which passes all the state down to other components as props anyway, making it functionally identical to just using the React state in that page component.
The justification for this is usually either "Now you can make your page components pure functional components!" (whooptee-do) or "Redux scales better" (citation needed). Pretty thin.
Because that's what easily-excited developers see on HN and Twitter, so they think they have to use it.
If you're using the words "like" or "cool" to describe your latest dependency then that's a serious red flag. These libraries exist to solve problems, if you can't describe the problem you're trying to solve with one of them then you shouldn't be using it.
There _are_ definitely a number of benefits to using Redux in a React app. I actually co-authored an article that discusses some of them: https://www.fullstackreact.com/articles/redux-with-mark-erik... . TL;DR: time-travel debugging and better hot reloading for development, easier management of data that needs to be used in multiple places throughout the component tree, and all the niceties of having centralized state (logging, state persistence, issue reporting, etc).
The pile o' reducers thing just isn't a very useful way to organize code IMO, and having everything split over several files makes following what's happening a PITA (especially without something like Typescript to let your tools give you the information you need, rather than having to keep it in your head or go look it up manually).
Redux feels... not over-engineered, exactly, but maybe mis-engineered.
... or we could just cut out the middleman and go all Actor model on this problem. Just sayin'. (yes, I know there are actor-model libs for React out there, but frankly the churn-related breakage and confusion in the most popular tools is so bad I'm afraid to step outside the mainstream, where it's probably even worse—plus we don't get to choose our own libs/patterns all of the time)
There's definitely several different schools of thought about how to organize and structure Redux-based code. Dan is a big fan of the "small independent slice reducers responding separately to the same action" approach. Others prefer to see all possible state changes for a given action in one place. And yes, while the intended use of Redux is based on functional programming, there's also those who prefer putting OOP layers on top.
I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
You may also be interested in an issue I recently opened to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 .
Finally, I'm always happy to chat about Redux (and React) over in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.
I thought the same thing. That's why I started using VueJS with Vuex. Vuex accomplishes the same things as redux in a much more manageable and centralized manner. Plus, you don't have to worry about connecting your components to the store through `react-redux` or whatever. With Vue and Vuex, you just pass the store object to the root view component and it's available in every single child component via `this.$store`. You can then `dispatch` actions which perform `commits` which call `mutations` which update the state. Then, in your component you create a computed property that uses a `getter` to return the piece of application state you want. It's a really simple top down data flow and everything is namespaced. It's so absurdly simple and easy that I don't understand why redux doesn't take a page from vuex's book.
I really should write a Vue + Vuex tutorial for beginners as I'm super happy with the way it works.
There are very different semantics at work there though. Elm is Fractal, Redux is not. Each have tradeoffs. Some stuff gets simpler, some stuff gets harder (the 1:1:1 scenario where you have a component, an action, and a reducer to achieve 1 thing gets easier. The N to N to N scenario where a reducer can handle things from all over the system, gets harder).
It's not misengineered, its just optimized to make a different set of problems easier at the cost of making others harder.
Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.
As a short version: you _can_ put your async logic right into components, but it's nicer to move that logic outside components for reusability. Middleware have access to `dispatch` and `getState`, so they act as a loophole that enables you to perform async work and then interact with the store.
My own take is that `redux-thunk` is sort of the "bare minimum" approach to async behavior, as it allows you to do stuff with promises and async functions, or complex synchronous logic. Sagas are useful for complex async workflows, and there's also some popular observable-based side effects addons as well. Ultimately, the approach you use is up to you.
If you'd like more info on what good Redux code structure looks like, you may want to read through the "Redux Architecture" and "Redux Techniques" section of my React/Redux links list at https://github.com/markerikson/react-redux-links/blob/master... . Also happy to answer any questions you might have.
The no frills way I like to think about redux is your rendered page is the result of a function operating on a state object. Changes to the state object trigger re-renders. There's obviously some subtleties in there and complex use cases, but that's the basic gist.
Redux is a modern implementation of CQRS/Event sourcing, a design pattern that existed before you even started coding. Many developers, in different languages, learned it and used it (if you want to implement an undo stack for instance, there is not a lot of other solutions around). Trust yourself and your intelligence. Our devs learn it in about 3h with our training program and get a return on investment in about a week.
MobX is nice and if it fits you, go for it. If you are a hands-on kind of guy, you may discover the limits of MobX by using it, and from the trenches finally understand why Redux, and why does it need 3 objects (a store, a reducer, an action).
As far as I can tell, that's it.
For bad reasons they've decided to stick with the terrible "action" name for their events/messages, which has made the whole thing super confusing (turning "actionCreator" into "eventCreator" immediately makes things much clearer, for instance).
There's also a ton of convention/process taught on top of it for some reason that's IMO not that great, and makes it really hard to see what's actually part of Redux and what's cruft on top of it that you can skip/modify. Redux-as-typically-presented is mostly you doing stuff to follow a (kinda painful) pattern, not the Redux library helping you do stuff.
[EDIT] I'd add that the communication pattern of the docs and various attempts to help people understand Redux seems to largely be "oh, you didn't get it? Let me say the same thing again but louder". Which is why there's SO MUCH documentation and chatter for something fairly simple, I think. Which just compounds the problem.
You are right that the majority of usage is really at the user level, than the library level. I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
If you have concerns with the docs, I'd appreciate any specific suggestions or ideas you might have for improving them. Docs issues and PRs are absolutely welcome, from you or anyone else who wants to help improve them.
Finally, I recently opened up an issue to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 . Would be happy for any feedback you could offer.
(edit: just noted I replied to you a couple different times in this thread, and repeated myself a bit. Offer of discussion absolutely still stands :) )
This is uninformative without more context. Is he saying Facebook only had 30K components, and all of them worked with the new React? Or does FB have, say, 60K components and only 30K worked seamlessly on the upgrade?
You're point might be valid if this was software that's already available, but it isn't.
means basically that it is working like previous versions and if not then there is simply a bug
I do use emojis all the time in personal communication but I guess it doesn't read very well so I removed them.
The question about components wasn’t meant to be an insult but I can understand how one could see it that way, so I removed it.
Sorry!
Don't pretend you're not fighting fire with fire with this article. You're mad and you're showing it. When you say stuff like...
>>To sum up, I love that you brought up these concerns in an article.
I don't believe you! Disingenuous.
(You should also think about whether or not the Riot.js author is worth responding to. Just because he's a framework author doesn't mean that framework has ever been held in high regard.)
To me, reading posts filled with frustration serves as a motivation to improve things. I didn't reply to "fight with fire": I see these kinds of posts every week or two. But I replied this time because I think it was also important to separate real issues from the factual inaccuracies (that get a life of their own once somebody writes an article).
Some bitterness did come through, and I removed it. But I'm not lying when I tell you I'm happy people are sharing their concerns with React. It's all for the best. :-)
Also, if I understand it correctly, the original author is a maintainer of a competing framework, heavily inspired by React. So, this is not exactly an impartial account of an 'experienced dev'. Maybe I'm reading too much into that but it's not something I like seeing in the FOSS world.
Create-React-App is a great step, but what next? How to handle AJAX and state if I have a simple app and don't really need Redux. How to structure it so it would be easy to add it.
You may be interested in several of the sections in my React/Redux links list at https://github.com/markerikson/react-redux-links . In particular, check out the "React Architecture", "React Component Patterns", "React State Management", "React and AJAX", "Redux Architecture", and "Project Structure" sections.
To pick out a few specific links related to your questions:
- https://github.com/vasanthk/react-bits
- https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- https://daveceddia.com/ajax-requests-in-react/
- https://daveceddia.com/visual-guide-to-state-in-react/
- https://hackernoon.com/redux-step-by-step-a-simple-and-robus...
Is there a great mid-size open-source project that was created with Create React App? Any input on UI frameworks? I'm currently using React-Bootstrap, but I'm thinking about using Material-UI.
I personally am using Semantic-UI-React [1] in a work project, as well as in the sample app for my "Practical Redux" tutorial series [2] [3]. I also frequently recommend a tutorial series called "Building a Simple CRUD App with React + Redux" [4] as another "real-world" tutorial/example. That tutorial doesn't use CRA, but my "Practical Redux" sample app does.
[0] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[1] http://react.semantic-ui.com/
[2] https://github.com/markerikson/project-minimek
[3] http://blog.isquaredsoftware.com/series/practical-redux/
[4] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
i.e. you can just do it inside the component: https://gist.github.com/mentrie/8632e81ae2960df8d02947b8b743...
Most of the original criticisms centers around NPM, which belies the hell that is JavaScript. Since everyone compiles JS anyway, we should stop writing in it altogether. Pick some other language ecosystem that transpiles to JS. Delenda Est NPM.
1. something about programming;
2. something about communicating with people.
1. Redux
2. React Router
3. Smart components
4. Dumb components
5. Services (This is combination of Redux, redux-thunk and axios(or whatever))
6. Webpack (CSS loader, SCSS, fonts, html, etc...)
7. And hopefully, everything with TypeScript if they can get over Flow.
Having worked on quite a few React projects, I have a boilerplate that mashes up the above combination and makes it work. With new project, I upgrade the dependencies.
But each time I start a new project in 3-4 months, something would have changed. Either its TS type defs or something in core React.
And as I discovered recently few days back - Webpack2, Router4 broke my boilerplate setup. Well, they actually improved react-router, and that made me remove some workarounds.
Every time I start, I end up spending at least half-to-one day setting up the same "Hello world" page and making sure the wiring works okay before I proceed to add functionality. That is just a waste of time. React core is cool, but I hope they had one highly-opinionated version of React that works out of the box.
For starters - yes, definitely. They should start with it
Yeah... People say that, but is it true? Lifting the state gets very messy very quickly and you end up with a spaghetti code before you know it, with the separation of concerns dying short yet painful death. For that reason I use Redux even in small projects, guarding myself against unnecessary verbosity with redux-actions. It's really that simple. I understand the need to prove that React can stand on its own without Redux, but the truth is, without Redux it's limping.
https://medium.com/@gianluca.guarini/things-nobody-will-tell...
http://guides.rubyonrails.org/
Thats it. A central place with an organised list of guides. Not a blog though. Also must cover things such as redux, mobx and routers, and how it all fits together.
I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
(The entire list has just been me working it by myself with the occasional "add a link" PR from random other people, but I'd certainly appreciate any actual offers to help improve it, especially since my own knowledge is rather limited in a number of areas.)
I guess this is one of the advantages Rails has being a monolith - as it provides nearly everything, it's very easy for them to keep up to date documentation of the 'Rails way' to do things. React and Redux have been relatively stable, but it's everything else that goes along with it that is the issue.
There are weird incentives in software ecosystems. Companies benefit by controlling one because they can hire easily, and ensure their code & tools will not become obsolete. And the more complex ecosystems become, the harder it is for devs to compare them or switch. I think there were similar forces at work in the UIs of large GUI applications like DAWs. Once you get through the painful learning process, you find you love it, and find it impossible to switch -- a phenomenon that has attracted comparisons to Stockholm syndrome.
[1] https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e...
Generally we are interested in solutions that allow us to iterate quickly, and to ship less buggy apps, and React has been helping out with this.
I don't have experience with Vue, but I also heard great things about it, so I'm glad there are many alternatives if React doesn't work well for you!
I've read this claim from FB before (Pete Hunt I think). It's not possible to overstate my disagreement.
I guess if you want to say, 'people in general can't program, but they can plumb things together, and once they learn the conventions the boilerplate becomes transparent', I wouldn't argue. But you haven't said it, and it's not a direction I think is so great for software.
In the future we want one-line applications, right? "Siri, create a calendar app with conflict resolution for the local Owl's club." Not four pages of "Siri, open angle-bracket props colon..."[1]
Re. Vue, I'm sorry I mentioned it. I don't have a horse in the race. However if I did I would definitely have taken the time to try Vue by now. And likewise Guarini, if this is really his first time trying React, has not done basic due diligence by waiting this long.
We can't improve as a field unless we compare results. That TodoMVC is the only benchmark that even exists is unfortunate.
[1] For some evidence in the meantime see http://blog.vivekhaldar.com/post/10669678292/size-is-the-bes...
jQuery is meant for manipulating arbitrary DOM nodes in a page. Assuming they share a classname, I can hide a dozen divs scattered throughout the page with a single `$(".myClass").hide()`. In React, I'd probably need to pass some state through several components, and ultimately re-render, which would be considerably more LOC.
Does that mean that React is "worse"? No. It means they're meant for different kinds of tasks. React is meant for making codebases maintainable and understandable. Sure, fewer LOC is _usually_ a good thing, but many times being more explicit makes a codebase more maintainable.
(As someone who knows Dan, I'd bet money that this smiley face is genuine. Still, easy to misread.)
I would prefer Riot.js instead.. a much less headaches
"what do you expect from a framework with more than 1000 issues on github that will let you install alpha dependencies by default (React@16.0.0-alpha.6) to develop your native app?!?"
This is aggravated in the JS world which is extremely Github-centric.
NodeJS: 730 open issues, 4323 closed issues, 324 open pull requests, 7201 closed pull requests: https://github.com/nodejs/node
Ansible: 1863 open issues, 9204 closed issues, 1084 pull requests, 11762 closed pull requests: https://github.com/ansible/ansible/issues
I admire Dan's patience and restrain. Personally, I see a paragraph like that original post scriptum, I dismiss the entire thing as a troll. The guy doesn't even talk about what problems he encountered with react native, he just says "Look! Lots of open issues, and big bad alpha software! What do you THINK happened, hmm?"
What I think happened is that he encountered maybe a couple of bugs and got pissed off at the whole thing, then tried justifying it with whatever strawman was readily available. Happens to me too. I get just as annoyed. I don't write articles shitting on the devs about it though, I generally file PRs to fix the bugs.
Also, you realize how silly that question is when the two programmers are actually one and the same, right? Like I said, there's nobody who knows the React codebase better than the React Native people.
Edit: You answered your own question better than I could have in your reply.
source: https://github.com/facebook/react-native/issues/13291
"At times, React Native will depend on an alpha version of React – this happens in part due to the fact that RN has a more frequent release cycle than React itself, and that's the correct version to use when working with React Native. We use alpha versions of React in production at Facebook so they should be pretty stable."
source: https://discuss.reactjs.org/t/why-does-reactnative-0-43-inst...
When did it become ok to use alpha versions in production? Or are they stable then? When did it become ok to call alpha something that is considered stable?
If this thread is any indication, members of the react (et al) team frequent this place so I hope one of them can clear this doozy up.
>The version of the `react` package is generally not relevant for React Native users because it contains very little code (`Component` and `createElement`). The reconciler code is synced to React Native separately. So this an artifact of the different release cycles of RN and React, and doesn’t at all mean that RN apps are using an unstable version of React. This is the same exact version we are using at Facebook in production. I agree it’s confusing though, and we hope to align the release process between React and React Native more closely in the future.
I realise that doesn't answer your question (which seems to be 'please justify React Native having a lot of open Github issues and being seemingly less stable than React') but it seems a bit misleading to conflate the two projects, and to expect the same amount of stability from each. React is a UI library. React Native comprises of a UI library, a JS <-> native binding system with wrappers for native APIs, a build system, and an implementation of CSS-like layout for native views. They are not really comparable.