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

441–450 of 574 posts

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

#441

Post by cutler »

divs1210 wrote: post #250
bobbylarrybobby wrote: post #127

Earlier quoted context omitted.

Yes, there is something very weird indeed. Functional components are called every time they're rendered (that's not weird). But they have to maintain state between calls; they can't start over again fresh for each call/render (still not weird). So how do they do this? `const [state, setState] = useState(initialValue)`. You might look at that and think, I see useState being called, so it must be called on each render,…

That is bonkers, to be honest. I've used React a lot, but only via Reagent in ClojureScript. I think the JS people are being scammed.

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.

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

#442

Post by exclusiv »

edgyquant wrote: post #423
exclusiv wrote: post #411

Earlier quoted context omitted.

True and I like GraphQL but in many cases your UI needs data in a way that isn't available on your existing endpoints. Ex: summary data / aggregations for reports or analytics. Or simple things like fullName on a user entity, a displayAddress, a display greeting based on their user group, you get the idea. You can do all of this on the frontend but it just becomes messier. This is what I'm referring to. So you still…

Graphql fans will attempt to convince you the way you’re querying data is wrong. You can do triggers if needed but graphql to me seems like a solution to internal enterprise data wrangling ootb. I don’t see the benefit of using it over an orm when you add in multiple databases, a working data store, etc

Yeah I'm not entirely sold on GraphQL but I think it shines in some cases.

Ex: you are building on top of third party ecommerce software.

You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data.

So it's nice to be able to extend a framework and data access in that manner.

In general though, I do prefer REST APIs and then writing custom endpoints if I need data for a specific UI, like for visualizations.

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

#443

Post by swyx »

As someone whose career success was very tied to React, I will say that "quiet quitting React" (or, nonjudgmentally, realizing my longterm interests were broader and taking action on it) has been one of the hardest career transitions I've ever had to do. The money and social validation and temptation to stay within the React-industrial-complex (explaining React to developers who just want the default thing is a very very profitable business) was very strong and I've had private conversations with many folks who got into it not having fully examined their beliefs and now feel trapped in the local optimum of React specialization as a career (which is then a self reinforcing loop as companies see it as a recruiting advantage, leading to devs optimizing for it because companies advertise for it, etc).

React is doing innovative, groundbreaking stuff with React 18 and beyond. I've done several talks on them and will use React when I have those needs. but other folks (I went with svelte in 2019, but i'll also acknowledge qwik, solid, and vuejs) are doing cool stuff too, and most people are usually not building facebook. Ecosystem for React is strong but size isn't everything; once you identify the 10-20 things everyone shouldn't DIY you're basically done (I ended on this at last week's Svelte Summit https://www.youtube.com/watch?v=A8jkJTWacow)

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

#444

Post by spartanatreyu »

ch_sm wrote: post #3

I think the title is a reference to this wonderful song by LCD Soundsystem: https://www.youtube.com/watch?v=-eohHwsplvY

How did you manage to share the song without also sharing that amazing mashup?

One of those rare exceptions, where overlaying another song improves the original: https://www.youtube.com/watch?v=huEtJw7pfLk

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

#445

Post by the_gastropod »

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.

I'm not sure this is a fair representation. Rails didn't "guess wrong" too many times. They chose the best option available at the time. Remember, CoffeeScript was used in Rails in 2010! Brendan Eich even borrowed many ideas from CoffeeScript in subsequent versions of JavaScript. Ditto, the asset pipeline solved a great number of problems for many years. With recent advances in web browsers, many of these problems aren't really problems, so it's less relevant, and Rails has to take advantage of import maps as an alternative.

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

#446

Post by cutler »

shaunxcode wrote: post #98
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…

Yes! CLJS + Reagent (and thus react).

Seconded. All the benefits of Clojurescript and React's core proposition without any of the classes/hooks madness.

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

#447

Post by zhouyxamp »

CharlieDigital wrote: post #262
zero_shift wrote: post #183

Earlier quoted context omitted.

Vue is mostly used in China, where there is a preference for Chinese tech.

That's probably not the reason why it's heavily used in China. More likely there was some early draw based on Evan You being the figurehead and eventually a community that built up Chinese language documentation around it that made it more accessible to Chinese developers.

This is true. I'm a Chinese developer and I have saw too many developers here using Vue because of it's good Chinese documentation. I used both Vue and React in my projects, I think one advantage of vue is it makes some concepts explicitly. Like the computed property, its more obvious than the way you do it in React. Vue's document is simple at the early days of the framework, that made it more accessible to new comers, especially people who was trying to migrate away from AngularJS, and didn't want to take Angular 2.x.

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

#448

Post by llanowarelves »

swyx wrote: post #443

As someone whose career success was very tied to React, I will say that "quiet quitting React" (or, nonjudgmentally, realizing my longterm interests were broader and taking action on it) has been one of the hardest career transitions I've ever had to do. The money and social validation and temptation to stay within the React-industrial-complex (explaining React to developers who just want the default thing is a very…

Timestamp ?

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

#449

Post by exclusiv »

edgyquant wrote: post #420
cercatrova wrote: post #400

Earlier quoted context omitted.

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

This is why I dislike graphql especially with react. It’s gets set up as a half assed ORM (but without joins!) and then all but the most senior of engineers end up using it as your application state which slows the whole app to crawl forcing a big rewrite. Using an orm and building a proper data model in your code using a store like redis takes very little additional time (especially with sequelize!) and it has the b…

Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient!

One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want".

To me, if your application doesn't need to have the flexibility in querying, then it isn't worth it. Is your dataset so large you don't wish to overfetch data (you can do that without graphql anyway)? Do you need ad-hoc querying in your UIs?

Think about your data, how you will need to expose it and expose it.

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

#450

Post by tcgv »

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…

I believe what you're describing is called "Backend for fronted" (BFF)
Post reply on HN