Live data from Hacker News

What I wish I knew about React

bitsofco.de

51–60 of 301 posts

Re: What I wish I knew about React

#51
post #15
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result.

In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc.

I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.

Re: What I wish I knew about React

#52
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

[deleted]

Re: What I wish I knew about React

#53
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

> "Everything an HTML tag" is an insane mantra to have. I don't think this is a React mantra at all. Maybe "everything is a function" would be a modern React mantra? Seeing how React code is mostly hooks and components, and both are nowadays generally written as functions. JSX is not even required when writing React, by the way. It's just syntactic sugar. > It's crazy to me that it's normal now to have like 3-4 compi…

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML).

While not required, most people use JSX + bundler, at least for anything that resembles a serious application.

Re: What I wish I knew about React

#54
post #19
post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.

I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle.

In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc.

Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.

Re: What I wish I knew about React

#55
post #38

Earlier quoted context omitted.

It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.

What kind of features require you to use react?

None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.

Re: What I wish I knew about React

#56
post #15

Earlier quoted context omitted.

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result. In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of c…

Higher order components haven't really been a thing since hooks were introduced though.

Re: What I wish I knew about React

#57
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

In the context of a website, I completely agree with you. No blog needs react. Reddit is worse because of react.

However, given websites aren’t the only use of react I strongly disagree with your overall sentiment.

My organisation uses react in place of desktop apps, and it’s been a game changer for us. We work faster, we train devs faster, deployment is easier, we can painlessly hit everything from desktops through iPads, and we make far fewer mistakes.

I really don’t see an alternative, at least outside SPA-land.

Re: What I wish I knew about React

#58

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code.

So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize.

If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.

Re: What I wish I knew about React

#59

Earlier quoted context omitted.

> "Everything an HTML tag" is an insane mantra to have. I don't think this is a React mantra at all. Maybe "everything is a function" would be a modern React mantra? Seeing how React code is mostly hooks and components, and both are nowadays generally written as functions. JSX is not even required when writing React, by the way. It's just syntactic sugar. > It's crazy to me that it's normal now to have like 3-4 compi…

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML). While not requir…

But what's so hard/bad? Literally zero config and two commands:

    npm install -g parcel-bundler
    parcel ./index.html

Re: What I wish I knew about React

#60

To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff". The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood. [0] https…

This is a critical point to understand. If you're not doing declarative programming with React then you're swimming upstream. Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple. And this is where React loses beginners who jump to more intuitive programming models.

Are you implying that only beginners can dislike React?
Post reply on HN