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

391–400 of 574 posts

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

#391

Post by yurishimo »

whatsdoom wrote: post #351
yurishimo wrote: post #305

Earlier quoted context omitted.

> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time.…

In case you don't know. This is a variation of the first paragraph of the Wheel of Time book series by Robert Jordan. Each book opens with a variation of this same paragraph

I’m well aware of the origins of the quote :)

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

#392

Post by sibeliuss »

randomsearch wrote: post #212

Any general coders wondering about React as their first front end framework - just use Vue. It’s easier, makes quite a lot more sense, has a “one true way” approach regarding many topics and can be comfortably learnt in a day. It’s easier for others to understand your code too. JSX yuck.

Vue + JSX is amazing

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

#393

Post by BoorishBears »

markeibes wrote: post #382
exclusiv wrote: post #357

Earlier quoted context omitted.

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

Why? What's the difference?

Backend doesn't need to deal with animations, styling, browser support, responsiveness, etc.

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

#394

Post by yurishimo »

markeibes wrote: post #382
exclusiv wrote: post #357

Earlier quoted context omitted.

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

Why? What's the difference?

You’re likely duplicating a lot of business logic between the frontend and backend. You can do it, but if you forgot to update one implementation, it could get ugly fast.

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

#395

Post by nsonha »

recursivedoubts wrote: post #27
nsonha wrote: post #7

Earlier quoted context omitted.

didn't it fail like 20 years ago, why do you think it'll succeed now?

unfortunately HTML didn't make any significant progress as a hypermedia for a decade and a half, but some folks (myself included) are trying to fix that (unpoly, htmx, hotwire, etc.) an enhanced hypermedia model offers a lot more interactivity often at a fraction of the complexity, and w/ the benefits of the REST-ful architecture (flexibility, etc.)

to draw a desktop app analogy, I guess these things need a back-end as a GUI application that has to deal with all the presentation logic, and thin client that remote desktop to that. While the current SPA model would be RPC with fat clients, your call.

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

#396

Post by skydhash »

nobleach wrote: post #378
yamtaddle wrote: post #110

Earlier quoted context omitted.

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…

What's worse, they have interesting "rules" that one really needs to use a linter so their IDE/Text editor gives them friendly reminders. One cannot conditionally call useEffect. One needs to add all dependencies to useEffect's dependency array - BUT that has potential to cause infinite re-renders (especially when using a getter/setter pattern with useState). They encourage DEFINING functions inside of other function…

I agree with the others. I've started using hooks since they were introduced and I've only hit the re-render issue only a few times, which I promptly fixed as they were caused by carelessness. My strategy is to not use a single useEffect, but multiple ones for each (which reduce greatly the dependencies). Also, avoiding dependency circles between useState and useEffect.

I've used class components and I think hooks are much better than the monstrosity that the lifecycle methods would usually become.

Also defining functions inside other functions is very much the staple of functional programming.

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

#397

Post by stevage »

throwaway0asd wrote: post #173
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…

I just use vanilla JS on the front-end just like I do with Node. I have never understood why people find state management challenging. 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 state data in one object, save it on each user interaction, and…

I introduced Vue to a plain JS project once and reduced the amount of front end code by almost half, and vastly simplified the state management.

We must work on very different kinds of projects. I really can't imagine plain JS being a viable or appealing solution compared to Vue, which gives me very little grief at all.

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

#398

Post by shrimpx »

knoebber wrote: post #19

I spent about 2 years at my last job building a greenfield react app mostly by myself (around 10k sloc). I enjoyed it for the most part. But I did run into all the issues raised here, they are valid. I think the worst issue with React is the dependency arrays that get sprinkled around everywhere - in my opinion the framework is unusable without a 3rd party linting tool that points out when your dependency array is mi…

> hello infinite render loop!

What's funny to me about this is that React people expressed so much hatred for Angular 1 for its "digest loop" and the difficulty of debugging infinite digest loops. And here we are, difficult to debug infinite digest loops in React that don't even give you the courtesy of raising an error after too many iterations.

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

#400

Post by cercatrova »

exclusiv wrote: post #357
corytheboyd wrote: post #190

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

That's why I like GraphQL, you get exactly the data you request, no transformation necessary.
Post reply on HN