Hacker News Reader

Comment by nevir | Hacker News Reader

A lot of Abramov's responses do refute the original points, but they also betray how much cognitive overhead is required to play in React's ecosystem.

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

View on HN

Gianluca Guarini is the maintainer of Riot.js. It's hard to believe he just naively tried React and this is what he came up with. Riots main page has more of these questionable comparisons.

This is worth noting primarily because the original almost got me: he kept mentioning Riot.js over and over, and I thought "huh...I haven't worked with that...I must be out of date."

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."

In the general case, this a big pain point for me. Having to wade through tons of shallow subjective "Well I like it" disguised as objective technical points can be very fustrating, especially when trying to learn something new and unfamiliar, such as my next major language or framework to learn or use.

Unfortunately, you just described most of the tech blog posts posted on HN/elsewhere. It's a very big problem :-(

I agree with this point.

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).

I've never understood the whole "Don't use Redux until you need it" idea. If you're building anything larger than a toy app, component state isn't gonna cut it, so you're better off structuring your app with Redux or MobX or something from the start than rewriting stuff to include it later.

Yes and no -- you could also get away with passing the state down from a higher-level component. This does break down quickly, but if your app isn't too complicated, it can be enough for the first version. (Certainly, if I was unfamiliar with React, I would try this before integrating another library like Redux.)

There's a difference between "don't try to learn Redux until you understand React", and "don't use Redux right away when you start building an app".

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.

Honestly many developers don't have freedom to experiment with new things on their own. I got web project, I'm thinking, well, it's a good time to try out React, I've heard it's cool. I'm convincing my manager, if necessary and I'm starting to build production project without any prior React or Redux or whatever knowledge. I'm not going to do it step by step, no. I'm grabbing everything and trying to bundle it all together. I know, that my app will need state, so I'm using Redux. I know, that my app will need routing, so I'm using router. And my experience is similar to author's, I had a lot of troubles to even get build setup working. I guess, it's more about javascript development tools, not specifically about React, but point stands still. And if I'm understanding, that I just got buried under pile of things, I'll throw it out, rewrite everything on Angular I know and love and forget about it for a few years, until it matures and I could try it again, hopefully with less troubles.

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.

I'd recommend pitching it to your manager as a one week spike, and if that goes well do a presentation on it and sell technical leadership on it from what you learned. Then you can add proper tooling. Make a few trade offs to save time as needed. That strategy worked for me.

Great advice, and well articulated. I'd add that if someone is coming from angular 1 or even has just built numerous single page apps, they will immediately see the benefit of a single source of truth client side data model.

For a simple CRUD application, there's not much wrong with just passing state down from a parent component. Eventually you end up abstracting and automating it; they're values, like everything else you program with.

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.

I really love Redux, and I use it for most things, but that is simply not true. Redux/MobX is a solution to the Angular 1-style issue where state is all over the place, but you sure can make full blown apps that way (it's not even a full solution, but rather a different set of tradeoffs...which is why a lot of people start using Redux then start pushing back in the other direction and you end up with a mess).

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)

I don't quite understand it either. React and Redux play nicely with each other but they are completely orthogonal. You can use one without the other, and I've seen Angular 2 developers use Redux to great effect. As Dan himself admits, Redux is inspired by Elm architecture and I personally find this approach extremely elegant. I admit it is demanding but it also forces you to put more effort into designing your application which in my experience is generally a good thing.

You can use MobX from the very beginning. There just needs to be a better, "complete" guide / docs on how to structure apps with it.

It's entirely possible I don't know what I'm missing and/or my React usage so far mostly falls in the "toy" scale, but I've not yet felt a need for Redux or another state management system. Our strategy so far involves very little use of component state (nearly all usage is for form fields and showing/hiding modals). Everything else is in the props, and all 'app state' lives in a collection of modules that get DI'd into the components via their props. It seems like it's probably not too far from what Redux is going for at a conceptual level, but so far it's worked well and been easy to work with.

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.

It's all relative. The point Dan was trying to make was that you shouldn't be using Redux until you need it. You shouldn't be using React Router until you need it.

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 can't be held responsible for the amount of crappy advice on the Internet.

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.

The official docs are good. Create React App is great for getting started with minimal overhead. This very article is a remarkably restrained and informative reply. The React team is doing a good job.

> but these problems do warn people to stay away from the React ecosystem

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.

> It is 100% on the user to determine whether an article applies, or it's plain wrong.

You're not wrong, but isn't it especially difficult for an inexperienced person to judge whether an article applies?

> It is 100% on the user to determine whether an article applies, or it's plain wrong.

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.

> There is bad advice for every framework/language that exists

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)

> 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.

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!!

> "The React team can't be held responsible for the amount of crappy advice on the Internet"

Do we extend this same courtesy to the PHP team? Or do we treat it as indicative of something?

How about: We hold developers responsible for the things they develop, which is what we've been doing all along?

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?

I don't have a horse in this race at all, just noting the inconsistencies. Although the idea that React doesn't have some language "issues" is pretty amusing.

> "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.

> I don't have a horse in this race at all, just noting the inconsistencies.

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?

> "PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man."

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.

You're welcome to not use JSX. Really! Most people who use React like it though.

There is no absolute that says JSX is a bad idea. It's certainly not been established, and most people who say JSX is a bad idea are people who aren't familiar with the subject matter.

> 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 a bad idea that's unfortunately not going anywhere.

JSX is syntactic sugar. That's it. Not a bad idea by an stretch.

> The React team can't be held responsible for the amount of crappy advice on the Internet

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).

For the other end of the spectrum see the GWT ecosystem. It can be really difficult to find out what's the right way to build something sometimes.

It's not that the advice is necessarily 'crappy', it's more that it's no longer current. You might be looking at an article which is only a couple of months old but is already out of date because some lib (like react-router) has changed, or it's considered 'the wrong way' now (when it was 'the correct way' a couple of months ago).

Which is 100% on react-router. That has nothing to do with React. This would be akin to issues you have with some Ember plugin on the Ember team. It's odd.

In the space of making a single very simple tabbed app I found the need to use react router. I didn't want to have to "invent" a way to change urls on the fly so the back button would work. What happened with react for me was that there's no "common" pattern to perform basic tasks outside of popular libraries.

> you shouldn't be using Redux until you need it

In my experience whenever you start dealing with state you need it. Which is in fact quite early in the project.

It's easy to counter criticism if your product has no canonical ways of doing anything. Just say the critics should use some other component or approach for every single thing they try to do. Of course, those other components/versions may have an entirely different set of issues, but since you don't have to deal with those yourself or consider trade-offs or even be consistent over time in your replies, you make the original point sound completely invalid. Just throw a bunch of options into the conversation and shift the burden of proof on the other guy. Yay.

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.

Reply on news.ycombinator.com