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

31–40 of 301 posts

Re: What I wish I knew about React

#31

Post by gherkinnn »

irrational wrote: post #22
efdee wrote: 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.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

I will never ever go back to the jQuery or vanilla js days.

It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.

Re: What I wish I knew about React

#32

Post by andrewstuart »

zappo2938 wrote: post #9

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.

Re: What I wish I knew about React

#33

Post by sunaurus »

dvt wrote: 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 compilation/transpilation steps when working on a simple JS-based app.

There's nothing about React that requires this. You can simply include the react.js script at the beginning of your HTML document and write all the React code you want, no transpilation required.

If you want to use JSX, then you need transpilation, but again, JSX is not required to use React.

Re: What I wish I knew about React

#34

Post by noahtallen »

dvt wrote: 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…

Hooks, to an extent, improve some of your complaints. For example, with hooks, lifecycle methods are gone and you’re forced to use “useEffect”. This helps you rethink if you needed that side effect in the first place. Additionally, it allows you to remove HOCs. Today, I just refactored a lifecycle-side-effect-filled HOC into a simple hook and I think it reads much better. Plus, it doesn’t confuse the fact that the hook has nothing to do with rendering and so it doesn’t abuse markup tags.

> from an architectural point of view, jQuery is by far their superior.

What do you mean by this? The architecture of the sites I’ve worked with has been much improved by React. jQuery mostly seemed to be used for direct, script-style dom manipulation, which you can do with plain JS these days. You did it in so many places across your app that it was impossible to tell what caused what change and it isn’t immediately reactive to data source changes either. So from an architectural point of view, it certainly didn’t help your code. React is solving a problems that jQuery doesn’t claim to solve.

If you’ve got a basic website that needs a tiny bit of interaction, definitely use plain JS. But if you need to build software running in the browser, you’ll run into the kinds of problems that jQuery and plain JS don’t solve out of the box. If you don’t use a modern library, you may end up writing your own state management and reactivity later anyways.

Re: What I wish I knew about React

#35

Post by ma2rten »

veeralpatel979 wrote: post #13
dvt wrote: 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…

I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

Maybe something like svelte?

Re: What I wish I knew about React

#36

Post by lumens »

irrational wrote: post #22
efdee wrote: 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.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

You know it's real when it hits you in the feels.

Re: What I wish I knew about React

#37

Post by runawaybottle »

veeralpatel979 wrote: post #13
dvt wrote: 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…

I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

The long term hope is regular old ES7/Next.

One of the reasons the virtual DOM exists is because it really tries to get around the browser limitations on DOM rendering. We were also all trying to manage templates and data binding. If you remove these three things, most of us could architect very simple JS apps with a singleton object.

It’s as soon as you need to define the dynamic template structure, bind data to it, and do everything in a browser performant way, is when we started trading away the simplicity for off the shelf complexity that solves mostly these three problems.

Re: What I wish I knew about React

#38

Post by baddox »

irrational wrote: post #22
efdee wrote: 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.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

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.

Re: What I wish I knew about React

#39

Post by colordrops »

veeralpatel979 wrote: post #13
dvt wrote: 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…

I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

web components when they finally mature.

Re: What I wish I knew about React

#40

Post by superice »

prodave wrote: 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.

The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components.

Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update.

The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one.

(Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185)

Post reply on HN