Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

151–160 of 301 posts

Re: What I wish I knew about React

#151

Post by sametmax »

dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

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.

Re: What I wish I knew about React

#152

Post by sunaurus »

conmigo wrote: post #138
arvinsim wrote: post #128

Earlier quoted context omitted.

const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.

> It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;

You can't do that. Just like you can't do:

    const [count, setCount] = useState(0); 
    count = 1;
In both cases, const is const.

The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React.

Here's the exact same scenario without React to show why you're wrong in your original comment:

    const foo = () => {
      const bar = getBarFromDatabase();
    }
Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?

Re: What I wish I knew about React

#153

Post by emerongi »

villuv wrote: post #122
ivan_gammel wrote: post #94

Earlier quoted context omitted.

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on build…

Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 9…

Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on.

Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it.

The standards committees for the Web have seriously dropped the ball.

Re: What I wish I knew about React

#155

Post by chrisoverzero »

conmigo wrote: post #138
arvinsim wrote: post #128

Earlier quoted context omitted.

const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.

> It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;

Your example is a bad one.

  const a = { prop: "value" };
  a.prop = "different";

Re: What I wish I knew about React

#156

Post by aylmao »

conmigo wrote: post #138
arvinsim wrote: post #128

Earlier quoted context omitted.

const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.

> It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;

You don't. The closure ends, the stack is popped, `a` is disposed, and then, in another closure, you have this line:

    const a = 1;
`a` was never re-assigned, but the value of the variable we call `a` changed. I think the key here is knowing that if you have the following:

    function Foo() {
      const [a, setA] = useState(0);
      return {a}
    }
`Foo()` will be called on every render, `useState` will only use its argument the first time it's called (and then after that just remember its value), and `a` will be a "new `a`" every time, after which, like all variables declared in a function, it's discarded when the function returns.

Re: What I wish I knew about React

#157

Post by conmigo »

sunaurus wrote: post #152
conmigo wrote: post #138

Earlier quoted context omitted.

> It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;

You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const…

> This is really basic programming

No, it's not. React is iterating that piece of code of your function internally to modify the value of the const, there is no other way to do it. And it is especially confusing because you can use that const 'variable' in the scope representing a changing value. And the change is magically made by its 'setState' method.

If you do this yourself in a loop then it is of course totally clear what's going on, but now we're writing functions where parts of it are being iterated by React, and that's not functional at all, IMAO it's a hack.

Re: What I wish I knew about React

#158

Post by tarkin2 »

React isn't a library.

You can't drop a bit of it into your project. It distorts how you build the webapp.

jQueryUI is a library. You can add it in and your code is still vaguely the same.

React is a framework pretending to be a library so people can't say "Oh, what? another framework?"

As soon as you use React, you're in the react universe, not the normal webdev universe.

With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).

Re: What I wish I knew about React

#159

Post by sunaurus »

conmigo wrote: post #157
sunaurus wrote: post #152

Earlier quoted context omitted.

You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const…

> This is really basic programming No, it's not. React is iterating that piece of code of your function internally to modify the value of the const, there is no other way to do it. And it is especially confusing because you can use that const 'variable' in the scope representing a changing value. And the change is magically made by its 'setState' method. If you do this yourself in a loop then it is of course totally…

React does not "iterate over parts" of your functions, it simply calls the entire function. There is no magic happening.

You've already received a lot of responses explaining how both const works (which you still seem to misunderstand) and how React works, I hope you can take this as an opportunity to learn and perhaps not be so confident in the future when criticizing something that you clearly haven't taken time to even understand at a basic level.

Post reply on HN