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

541–550 of 574 posts

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

#541

Post by sibeliuss »

unconed wrote: post #506
sibeliuss wrote: post #386

Earlier quoted context omitted.

Sorry, to clarify: What I'm suggesting is that React 18's changes were substantial enough to have been broken off into a separate library, not maintained inside of React. I don't mean to diminish the teams amazing work here, but they're overkill for 90% of the developer community who are already having a hard time understanding all of the abstractions that have made it in since hooks were added. All of this is _overw…

Amen. React 18 was the moment where they forgot they started as the V in MVC. Concurrent React was a mistake, and the hooks they had to add to make it work too. The main example I always cite of where the React team is naive is mousemove handlers: - there is no guarantee that react will re-render between two mousemove events - even if it did, creating a new mousemove handler after every move is ridiculous - avoiding…

> Amen. React 18 was the moment where they forgot they started as the V in MVC.

Yep, exactly.

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

#542

Post by cutler »

divs1210 wrote: post #505
cutler wrote: post #441

Earlier quoted context omitted.

I don't know why Clojurescript's Reagent/re-frame aren't more popular given that they completely obviate the need for hooks or classes.

I think someone should make a Reagent for JS.

But Reagent is built on top of React.

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

#543

Post by pas »

dntrkv wrote: post #343
pas wrote: post #272

Earlier quoted context omitted.

Because HR (and IT strategy) nowadays is a farce, managers, decision-makers and the actual organizational units that do hiring rarely have the necessary systemic big-picture knowledge/information, foresight, experience, longitudinal thinking that would allow them to venture out of their preset suboptimal ways.

Are you suggesting that requiring React experience for a job where you will use React is not a reasonable ask?

It's usually perfectly reasonable, but not really optimal. In this job market requiring React seems worse than hiring someone that is a good frontend developer and has the wits and eagerness to pick up React and whatever tools the team uses, and the job requires.

This has the advantage that when - inevitably - tool1 gets deprecated and tool2 arrives you'll have someone that can adapt and learn, and likely you'll also have someone who can teach.

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

#544

Post by exclusiv »

cercatrova wrote: post #538
tikiman163 wrote: post #530

Earlier quoted context omitted.

Graphql does not address the problem he's describing. When he says "transformation" his meaning is similar to transformation in an ETL process. What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be. This is very dangerous behavior for any application. You don't…

> What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be. But you don't have to do it like this at all. I don't understand what this has to do with GraphQL, you can make the frontend never update local state and only fetch from the server if you want. That's an i…

I wasn't referring to trusting the client's logic and state changes and then sending it back in an update and storing it. But certainly some devs do that.

As a simple example, you may send an entity to be updated and then the frontend makes a decision to say, you changed this value, then alter this other value so that the update request has the values we want (ie: one property may need to be blanked if another property has a certain value). Your frontend has logic it shouldn't and you should be enforcing your data on the backend anyway.

However, I was referring more to a situation where a frontend dev has an API request that it can work with but needs in another format or structure. And then logic is added to that data based on the user inputs or to simply do client side aggregations. Maybe it takes the user's chosen store location and filters out the out of stock products from the API on the client side.

Instead of sending the inputs to the API and have the API's logic handle it and provide you with the dumb data for your frontend to render - here are the products you should render; don't think about anything. So your frontend isn't growing into this brittle thing that is doing too much and is more likely to end up with dupe code as multiple frontend devs get tasked with new but similar components and recreate the wheel.

> In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway.

I'd argue that it in many cases it promotes frontend devs adding more business logic. Because your devs can query for whatever they want on the schema, transform the data, do whatever logic in the components instead of relying on an API contract for said data.

It means there's really no thought into: what does this client actually need?

So the frontend devs don't have to involve a backend dev or team to get most of their tasks done, which may be a great thing for their situation.

But the business logic gets pushed more and more into the frontend and gets bloated and brittle.

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

#545

Post by engineeringwoke »

acemarke wrote: post #525
engineeringwoke wrote: post #412

Earlier quoted context omitted.

> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance. So `this.state` is hard to optimize? > Hooks had nothing to do with v8 optimizations or `this.state`. Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.

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 existed obviously. It's secondary to the discussion because function components have existed for a long time.

None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.

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

#546

Post by spopejoy »

cercatrova wrote: post #482
edgyquant wrote: post #481

Earlier quoted context omitted.

Right so, again, what exactly is the purpose of graphql? It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism. What can graphql do that an ORM can’t?

You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table…

> If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.

Obligatory note: this really is just supposed to be REST. GraphQL seems to be the final expression of throwing in the towel on REST's original capabilities.

As such it's not clear of it's a step forward (REST as it should be) or a step back (let's just use a crippled SQL and ship)

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

#547

Post by chrisza4 »

jasongi wrote: post #468
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.

You aren’t the only person, I’ve certainly heard it before. But I’m yet to hear a convincing rebuttal to Mixins Considered Harmful [1], the hooks talk [2] or the Motivation section [3] on the announcement. The arguments I’ve heard is that it is “cleaner”, “more understandable” or the OO style is preferred. Some developers feel uncomfortable with hook magic because it introduces a more niche programming concept than O…

I think there is more footgun in the hooks, especially rules of hooks. I worked with Junior dev and I can see unexperienced dev misused hooks more often than lifecycle.

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

#548

Post by phendrenad2 »

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.

Well, unfortunately treating hooks like they're the worst thing since the devil is just the latest (and most humorous) in a long trend wherein a new syntax is added to something, and every developer thinks "okay, the preexisting alternative is now old and bad". I've been scolded many times in code reviews for absent-mindedly making a class-based component instead of using hooks (mind you, this was a legacy codebase FULL of class-based components. Are react developers just undereducated? Considering how many developers I've seen spend MONTHS "learning hooks" I think so. (Not to mention, every single React project I've been on in the last 7 years has been me and some developer who's never used React before, but has a lot of shallow blogpost-driven opinions).

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

#549

Post by phendrenad2 »

buscoquadnary wrote: post #147
BilalBudhani wrote: post #97

Earlier quoted context omitted.

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…

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…

After a few trips around the wheel you'd think that people would realize "hey, we rewrote our entire react app, we were good little developers, we did the right thing,.. but that path led nowhere"

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

#550

Post by collyw »

thex10 wrote: post #155
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…

I feel the same! I work on regular ol' websites, that have some pages containing some moderate interactivity – so a few years ago the project adopted React to handle the frontend. I've found the experience mostly OK, but I sometimes get the urge to simplify things by leaning more on server-rendering / maybe using the URL to capture state... and then realize I can't, and that this is Just The Way It Is Now. Because no…

It just makes adding simple stuff so slow. Instead of a query, and and HTML template, you have a query built on top a shambles of a system that outputs JSON, passes it to another monstrosity that is our Dojo frontend. I have tried to create some static pages, but everything is so baked in to the mess we have, getting around the login is a major obstacle.
Post reply on HN