Live data from Hacker News

A mostly complete guide to React rendering behavior (2020)

blog.isquaredsoftware.com

31–40 of 56 posts

Re: A mostly complete guide to React rendering behavior (2020)

#31

Earlier quoted context omitted.

It isn't needed. Teams could develop complex web applications before React existed and they can still do so. If the developers have experience with other languages and native UI frameworks then they probably won't want to use any of the Javascript frameworks when developing a web application as they already have a mental model for how to setup the structure of function callbacks for handling user interactions and sta…

The problem with using the DOM or similar UI frameworks is that you have to code the delta from any state to any state by hand. This is exceedingly complex, error prone (because you might miss parts of the state that should change) and often slow (because you tend to overcorrect).

Well, yes and no, it depends...

It does require a lot of thinking before hand about the user interactions and their impact on the application state, user workflows, etc. However that thinking should already be happening regardless of the choice of implementing technology (granted it doesn't in a lot of cases :| )

Re: A mostly complete guide to React rendering behavior (2020)

#32

ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.

It's the same thing with every technology for me. C++ is pretty absurd, same with Java/Spring framework, ditto for Linux and the whole TTY system/file descriptor hell. Anywhere where someone spends their whole life is probably going to be a big mess.

With all due respect, I believe there is a certain demographic in IT that just has a way too trivial working model of how stuff they don’t work on directly operates.

Like, they know how to do a simple HTTP query in C/go whatever, and then don’t understand why would you need the whole complexity of spring.

It just turns out that the real world is more complex than what they assume - and they are often more than aware of that in their specific subfield.

Re: A mostly complete guide to React rendering behavior (2020)

#33
post #13

Not a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?

Nope we don’t, but it solves a lot of the problems people frequently encounter while building web pages without too much of a downside. It’s a big trade off space and react sits in a very nice spot in that space.

Phenomenal answer. No, you don't need it, but if you build something long enough you'll avoid a couple categories of common problems by starting with it (and choose a different set of common problems)

Re: A mostly complete guide to React rendering behavior (2020)

#34
post #23

Not a critic to the article itself, in fact I know nothing about React and learned a lot from the it, but...do we REALLY need all of this to render web pages? Even if it is a web application and not just a page, doesn't this ecosystem seem too complicated for the problem it solves?

I made my career on open source web technologies before both GitHub and Stackoverflow were a thing. I love the web! And I love making UIs and I can spend untold hours with CSS even! And I agree the state of frontend is completely bonkers. React absolutely improved things from spaghetti jQuery. The zero-to-one productivity for interactive UIs goes through the roof, but growing and maintaining your project for any seri…

Spaghetti jQuery has become the boogie man to peddle the ridiculously overcomplicated solutions like React or Angular. Which, ironically, also have got spaghetti, but in a different form.

Re: A mostly complete guide to React rendering behavior (2020)

#35

ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.

What’s absurd about it? What’s a better option in your opinion? Asking as someone who mostly knows the React approach

Just generate a web page on the backend.

Sprinkle it a bit with some simple JavaScript/jQuery code for animations, forms checking etc, if you want. That's it. That's how it was supposed to work and that's how it works best. JavaScript was made to make the monkey dance. The end result, either made with overcomplicates frameworks like React/Angular or with simply generating the web page on the backend, is irrelevant to the user.

Re: A mostly complete guide to React rendering behavior (2020)

#39

ya'know, everytime there's a post with react in the title, I open it with the best positive attitude I can muster, holding back my knee jerk reaction. I then read it, and come out thinking "why, why, why do people put up with this absurdity?" and always stop at the same conclusion, cz they don't know any better. I then quietly move on with my life, sometimes leaving such comments as hints to those who might catch on.

It's the same thing with every technology for me. C++ is pretty absurd, same with Java/Spring framework, ditto for Linux and the whole TTY system/file descriptor hell. Anywhere where someone spends their whole life is probably going to be a big mess.

Though the TTY system is clearly historical accident: Hacks piled on hacks on early Unix system to make actual teletypes work, then enshrined in POSIX and need for compatibilities sake.

C++ always seems to me pretty absurd just because C++ people don't seem to know better ways, and seem to think to much about squeezing out the least little bit of performance instead of aiming for simple abstractions that are performant enough. Also, the last 40 years of programming language development seems to be unknown to them, or at least doesn't influence their decisions, or if they pick up a new idea, it's implemented in the most possible awkward way (because, again, performance).

Re: A mostly complete guide to React rendering behavior (2020)

#40
post #23

Earlier quoted context omitted.

I made my career on open source web technologies before both GitHub and Stackoverflow were a thing. I love the web! And I love making UIs and I can spend untold hours with CSS even! And I agree the state of frontend is completely bonkers. React absolutely improved things from spaghetti jQuery. The zero-to-one productivity for interactive UIs goes through the roof, but growing and maintaining your project for any seri…

Spaghetti jQuery has become the boogie man to peddle the ridiculously overcomplicated solutions like React or Angular. Which, ironically, also have got spaghetti, but in a different form.

React by itself is not "overcomplicated", or even "complex" at all.

The majority of the complexity is in the ancillary tools and ecosystem extras, which are not strictly necessary. You don't need bundlers and transpilers, for example. The only reason they are popular is because JSX is a good convenience, though.

You can get away with very basic React for the majority of cases. Things like advanced lifecycle shenanigans are also not necessary, unless you’re doing something extra-smart, or inherently complex (due to browser APIs, third-party APIs, or just complex design patterns). But those are also not necessary: just nip complexity in the bud if possible, but if something becomes impossible to avoid, the complex side of React will have your back.

The main difference between jQuery and React-the-library is that React handles a lot of the complexity around state and component abstraction all by itself.

With jQuery the complexity and spaghetti appears much earlier than in React. It's even difficult to compare, it is much simpler to keep a React codebase cleaner than a jQuery one.

Of course, if your app is simple enough, you don't need the "extra complexity" brought in by React, and jQuery will serve you well.

But this is also true even for "simpler things" like jQuery and Ajax: if your app is simple enough, you don't need Javascript at all, you can handle 100% with server rendering. And so on.

Post reply on HN