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

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

marmelab.com

Post reply on HN
Print view View original

561–570 of 574 posts

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

#561

Post by postalrat »

iLoveOncall wrote: post #385
postalrat wrote: post #165

Earlier quoted context omitted.

Funny because every time I need to work on anything angular I'm constantly thinking how over-engineered everything is and how much simpler it is in react.

Sure, if you have only a very basic 1 page website with no routing, no backend calls, no components to reuse, etc. React will be a simpler and better choice. If you have anything more complex than that, like a real web application, Angular is an actual frontend framework, where React is just the modern jQuery. Angular is for software engineers, React is for web developers.

Thanks for confirming Angular is over-engineered.

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

#562

Post by acemarke »

engineeringwoke wrote: post #545
acemarke wrote: post #525

Earlier quoted context omitted.

You're very much misreading what I said. It's not about "optimization" in the sense of "how fast can the v8 interpreter execute lookups on the class instance" or anything like that. It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?

> It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"? You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks exist…

I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?)

I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification.

If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.

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

#563

Post by suction »

rukuu001 wrote: post #453
daveguy wrote: post #355

Earlier quoted context omitted.

> I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my... Then you exactly describe MVC... > state data in one object, This is your model. > save it on each user interaction, This is your controller. > and use it only on page refresh. This is your view…

Yes I was confused by this. It’s MVC, but without React’s benefit of having the GUI update without a page refresh. edit - fwiw I too am another heartbroken React dev

No post body was provided.

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

#564

Post by suction »

FinalBriefing wrote: post #202
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…

Vue has been my favorite since Vue 2. It hits the right balance for me between the opinionated Angular and "you figure it out" React. It does what I want a JS framework to do: binds values and renders views with minimal setup (computed properties solve so many common problems). Also, it has amazing ESLint rules that really help keep all your code aligned and following best practices.

No post body was provided.

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

#565

Post by autorun »

I'd like to know how a newcomer would feel after reading the tutorial of the monster you created, React.

Take React hooks at its purest for example. I can't imagine the WTF feeling in a newcomer's mind, when the useState() helper function returns the "reactive" variable and a function you have to use to update it (!) do you realize how tricky you end up with your technical DOM optimizations?

Same with useEffect(), where you probably will have your whole function defined right into the first argument, and a list in the second one, very lost in your IDE. Who would expect that an empty array of dependencies would trigger it once? Why we should track all those dependencies at first place?

When recommending a frontend framework, I found Vue to be more dev friendly. However, it's currently in a long migration crisis, because documentation shows the 2 different APIs you can choose. I know that the differences are well explained (although they don't even say that's to be retrocompatible with Vue2 mindset), but for a newcomer's mind, it's like asking: which pill do you want to take? red or green? Choose your own adventure!

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

#566

Post by reducesuffering »

collyw wrote: post #555
reducesuffering wrote: post #101

Earlier quoted context omitted.

> 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.

Django temples are pretty simple. They are basically HTML with a a few constructs that you can put variables or loops in. Way simpler than React and Typescript.

So is React, but React also provides hooks to manage state in a sane way that is left to ad hoc interaction between random js funcs and django

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

#567

Post by reactspa »

ncann wrote: post #113
reactspa wrote: post #104

Earlier quoted context omitted.

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?

Class component is still fully working as of latest React and won't be going away (at least according to the React docs). The main issue is when you work on a codebase that's full of function components and hooks it's hard to mix in class components.

I really liked the old model where Class Components were used when there was state, and function components were used when there was no state.

Hooks have always seemed so weird. And turns out it's the same for many others.

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

#568

Post by geewee »

azemetre wrote: post #203
nightpool wrote: post #24

Earlier quoted context omitted.

Yeah, I agree that react-hook-forms feels much more natural and straightforward to use compared to Formik. It's just a shame it's so poorly documented.

What is poorly documented about react-hook-form? I like the documentation a lot, and it's creator is EXTREMELY responsive regarding github issues & discussions and on their discord as well.

I think the documentation is usually pretty great if you can find it. Somehow I never seem to be able to.

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

#569

Post by coffeefirst »

itake wrote: post #390
BilalBudhani wrote: post #277

Earlier quoted context omitted.

I don't agree with you. I have been doing Rails development for past 10 years now and I never faced a dilemma where the framework took a direction which isn't aligned with its core vision. I have been just trying to find a similar tool for frontend where I don't have to keep rewriting the entire codebase.

What about the webpack rails7 situation? I feel like rails has guessed wrong too many times about FE (coffeescript, asset pipeline, websockets) that I don't trust them to deliver their own stack.

This is kind of a great example because Django did the opposite: insist on having no frontend opinions.

As a result, Django left its users completely on their own, while Rails made choices that wouldn't last the test of time.

Given how chaotic the frontend ecosystems have been over the past decade, I'm not sure there was a "right" answer in hindsight.

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

#570

Post by augzodia »

rav wrote: post #15

Regarding the Inspector/isVisible complaint: When you want to have "early return" in a component, it's possible to just split the component into two to introduce an "inner" component that contains whatever comes after the early return point in the original component. Any local variables from before the early return then need to be passed as props to the new inner component. However, naming this inner component is alw…

This is exactly the use case for HOCs and why I continue to be old man yells at cloud about how the "hooks replace(d) HOCs" zeitgeist is missing a key benefit.

Wrapping components lets you have layers that don't have to care about what's going on inside. HOCs just let you write those layers in a way that can be composed. In your example, `isVisible` could be its own HOC, and then the inner component can have whatever name it needs.

Post reply on HN