React I love you, but you're bringing me down • Hacker News Board

Re: React I love you, but you're bringing me down

#101

Post by reducesuffering » Tue, Sep 20, 2022, 4:33 PM UTC

collyw wrote: post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

> Does anyone do server side rendering these days?

Yes, in React, with Next.js.

I'm going to have to dynamically create html and attach event handlers based on data either way. Much rather do it all in Typescript than remember Django templates DSL and still do javascript, for the result of worse UI's, poor 3p library support, and awful state management between frontend and backend.

Re: React I love you, but you're bringing me down

#102

Post by svachalek » Tue, Sep 20, 2022, 4:34 PM UTC

root_axis wrote: post #30

kansface wrote: post #17

Earlier quoted context omitted.

That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…

Hooks are not a "language", they're just react API calls.

"Just" is not really fair here, they're a window into global variables. Global state is awful to deal with but a necessity in the real world, so having some sort of constrained global state is something we're always trying to solve in new ways, singletons, monads, etc. Here we have hooks, which is an interesting experiment but something I personally would have played with in some new framework rather than dropping into the most popular and mainstream one.

Re: React I love you, but you're bringing me down

#103

Post by pier25 » Tue, Sep 20, 2022, 4:34 PM UTC

jitl wrote: post #11

Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted. > Form libraries are portly maintained or documented The two-way data binding in Svelte saves ~4 lines of reusable hook function but doesn’t come close to covering defaults, validation, errors, dependent fields etc - all of that is essential complexity. Write your own form field hook. The state model for a form is simple - what is a…

> The two-way data binding in Svelte saves ~4 lines of reusable hook function

Based on the RealWorld projects, Svelte saves you around 50% in loc vs React.

https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

Re: React I love you, but you're bringing me down

#104

Post by reactspa » Tue, Sep 20, 2022, 4:35 PM UTC

nonethewiser wrote: post #46

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

Is it possible to continue coding in some early version of React that only had class components?

Has anyone branched that into its own thing yet?

Re: React I love you, but you're bringing me down

#105

Post by kirse » Tue, Sep 20, 2022, 4:35 PM UTC

As an early beta user, I also agree. I think the issue with many modern libraries is that they don't know when to stop. Like that guy who keeps adding visual mods to his car, or that TV show that keeps creating mediocre seasons.

I took a risk on React back when there were minimal components and zero form libraries and started fading away from React once hooks were added. Redux is still pretty nice, and overall still use React because I much prefer it to anything else. But we're definitely in the long-term bloat phase which you can tell by the popularity of things like Vue, "React Lite" libraries being built, etc.

Re: React I love you, but you're bringing me down

#106

Post by acemarke » Tue, Sep 20, 2022, 4:35 PM UTC

fabian2k wrote: post #5

The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. State management in React is a topic discussed to death, there are plenty of options if you have specific tastes or requirements but plain old React state works perfectly fine as well (especial…

Yep. The article has some good points overall, but Context was definitely never intended as a replacement for Redux. Redux and Context are different tools that solve different problems, with some small overlap.

Honestly, this is a point of confusion I see folks ask about _every_ day.

Context is a Dependency Injection tool for a single value, used to avoid prop drilling.

Redux is a tool for predictable global state management, with the state stored outside React.

Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc).

I ended up writing an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them:

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

Re: React I love you, but you're bringing me down

#107

Post by pier25 » Tue, Sep 20, 2022, 4:36 PM UTC

collyw wrote: post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

Yeah actually the front end world at large has been moving away from the SPA pattern...

See Next, Nuxt, Remix, SvelteKit, Astro, Qwik City, etc.

Re: React I love you, but you're bringing me down

#108

Post by todotask » Tue, Sep 20, 2022, 4:36 PM UTC

BilalBudhani wrote: post #97

nonethewiser wrote: post #46

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…

I haven't got the ideas why many frontend jobs require experience in React whether it's for a new or existing projects, maybe I need enlightenment.

Re: React I love you, but you're bringing me down

#109

Post by y-c-o-m-b » Tue, Sep 20, 2022, 4:36 PM UTC

irrational wrote: post #71

throwaway284534 wrote: post #10

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

Well, I work for a fortune 100 company and we use Vue. After using React, I strongly prefer Vue, so I would say it is the greener JS pasture ;-)

Agreed. Vue is the best of all worlds in my opinion. Here's my take on the whole thing from a Svelte post a couple of weeks back: https://news.ycombinator.com/item?id=32763509#32767905

> I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and JS/TS and how it encourages clean separation of concerns and clean code. JSX/TSX is absolutely the worst for the latter, it's like the wild west. "But you don't have to write it that way" - yeah ok, but when you work in a large organization it's going to get written that way by your peers; good luck trying to stop it. Angular is just a clusterfuck of pipes and observables that require higher cognitive load to unravel when trying to understand a semi-complex block of code. Contrast with Vue where I can near instantly understand what it's trying to accomplish.

> This shit right here - {#if } {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code? This is one area where Angular also pisses me off: *ngIf for example is just as hideous. With Vue: v-if, v-else. You add it as an attribute to native html, it's dead simple. No weird symbols, no braces or other oddball shit I have to look up when I step away from it for a few months and come back. It just makes sense right away.

Re: React I love you, but you're bringing me down

#110

Post by yamtaddle » Tue, Sep 20, 2022, 4:37 PM UTC

wpietri wrote: post #93

jwlake wrote: post #82

Earlier quoted context omitted.

I use functional components only for things without state. If anything has state I use class components because otherwise you go mad. ;)

Could you say more about this? I'm not a React user, but to me one of the OO fundamentals is "object = behavior + state". What you're saying sounds so obviously correct to me that I guess there's something pretty weird going on in React-land?

React added "hooks" which are basically methods and properties implemented as FIFO queues instead of lookup tables, with terrible syntax that requires you to declare them inside their constructor (the "functional" component's... well, function).

No, I'm not kidding.

Unless something's fundamentally changed about the code since release, they even end up attached to an object representing the UI component, by the time the heart of React's runtime code considers them. It's some real Rube-Goldberg shit. I read the code because I read the announcement docs and was like "wait, it looks like they... but no, surely they didn't" but yeah, turns out, they did.