Hacker News Reader

Comment by nodesocket | Hacker News Reader

I as well gravitate toward Vue.js for its simplicity, but I wonder if React's mind share and community size "trump" simplicity. For example, if you're hiring for a front-end position, you'll probably get more candidates familiar and experts in React over Vue.js.

View on HN

The thing is that most React developers don't actually think React is that complex at all.

I think react has a steep initial learning curve but once you grasp the concepts it's not complicated. It is more verbose than vue though and requires more setup and boilerplate to get started.

I don't think it's more complicated so much as different from what people are used to. Once you think of JSX as functional expressions, it becomes easier... and there are far fewer gotchas at play, imho.

I think react combined with a unidirectional state management has a relatively difficult initial learning curve, but overall, I find it's not as steep as say Angular is.

React is very simple. You need to understand only its basic life cycle. Rest is just JavaScript.

I disagree as soon as you write more than a single nested child/parent component, that requires a different way of thinking (should I use state or props?). And that you can't "just uses react". You kind of have to use redux (or similar) as well as a bunch of other stuff.

People keep saying you 'have to use redux' but I think that's hugely misleading to a large section of potential React users who don't need the highly complex state management that redux facilitates, and could get by just fine with setState+props.

I'd hope that people who are being exposed to this idea at least also get the chance to read 'You Might Not Need Redux': https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Amen to that. Seems like everybody is cargo culting Redux but really you can get pretty far with just React plus some wrapper components to hold state.

You don't need to use redux. But it's very useful to manage state. I went from using simple components to flux to redux all in same project. For me State management is a very part of client ui.

React alone in itself is pretty small library but the pieces that you put together to it (redux, react-router, react-redux, webpack/browserify) might be a big hurdle for beginners.

I spent weeks learning Angular, Ember, and other last-gen frameworks. The todo equivalent was simple, but once you got into their render cycles on a moderately complex project, the wall was very steep.

I started off with simple React apps and it was easy, but I expected to hit a wall. That wall simply never comes like it did last generation. I find it interesting that someone would consider it too complex only a couple years later.

Couldn't you just ask for JavaScript in the job description instead of React? Because if a dev knows JS s/he will handle Vue easily. Most React devs already write something else: JSX. Of course you can skip using that but won't it be like coding with your hands tied?

I tend to ask mostly JS questions in interviews, and very few "angular" or "React" questions when screening candidates... if you're good with JS and know at least 2 other languages, you'll be able to handle pretty much any modern JS framework without much difficulty.

If you pair React with something sane like MobX, the React API surface that devs will need to use will be tiny.

I get that you can do some cool things with Redux but I'm not sure it really should be the go-to state management tool for React apps. It requires so much ceremony to even do simple things and the async story is pretty complex.

I haven't tried Mobx yet but it looks like a saner solution that don't need Redux's more advanced state management tricks.

Could you expand on what you mean by ceremony and state management tricks ? From my use of Redux there is a bit of set up cost in making the types and actions and getting the store into the components that need it, is that what you're referring to ?

Yeah that and then also the stuff you have to do to get async working like redux-thunk and redux-saga.

I haven't actually built anything with these yet so maybe in practice it's ok but it definitely looks ugly.

Abstractions should be chosen carefully. Too little and devs step all over each other. Too much and the cognitive load and ceremony get in the way of progress. When your team will never be more than 2-3 people, redux may be a little too much ceremony (especially for applications smaller than 10-20K lines of code). When there are more people, it seems like the perfect amount of boilerplate to keep people out of each others way while its opinionated flow makes it easy to find bugs in code you've never even seen before (another large team problem).

It's been my experience that learning redux without a teacher takes some time if you aren't familiar with the one-way data flow mindset. If you have someone to pair with for a couple days, you'll be off to the races very quickly.

That said, I think redux itself is too barebones. EVERY redux app uses the thunk middleware (even the official docs spend a long time on it) and most find themselves recreating a multiple dispatch one too. If 95+% of your users need the same extension, then it's not really an extension (and in this case, both together are less than 15 lines of code).

Redux never really gelled with me and I couldn’t really understand why until I settled with MobX: all the boilerplate and some idiosyncratic names you need to know to really understand and use Redux was too much friction for me.

Simplicity means that you don't need a framework-specific expert.

Reply on news.ycombinator.com