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

461–470 of 574 posts

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

#461

Post by lofatdairy »

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.

Class components were/are fantastic for training new devs because of how easily abstracted the mental model is compared to memorizing all the hooks and their use cases. Obviously, the syntax tends to be a bit more verbose in general, and I won't deny that hooks making improving performance easier, but at the end of the day I prefer code that's readable whether it was written yesterday or 5 years ago - even if it costs like 20 more lines of boilerplate.

I also think the fear of verbosity in this post is why I can't take it too seriously. Solo maintaining a not-so-old Expo application which uses React Navigation, I constantly have to rewrite large sections of code due to constant refactorings to match whatever coding style is hot at the moment, as the 6 month deprecation deadline is constantly at my doorstep because I have bigger fish on my plate. SO answers being out of date isn't a problem because React is too old, it's a problem because of everyone wanting it to be shiny and new again, and React acquiescing to those demands.

The author does have a bit of a point with libraries, but I counter with Nessim Btesh's fantastic article regarding proper React style[^1]. In short, you shouldn't really be depending on libraries for production needs, just for prototyping.

[^1]: https://nesbtesh.medium.com/how-i-write-react-after-8-years-...

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

#462

Post by not_kurt_godel »

pdntspa wrote: post #337
not_kurt_godel wrote: post #204

Earlier quoted context omitted.

> your comment perfectly encapsulates my experiences > feels like so many people actually writing in React are just effing CRAZY Same here. We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms with a max of 4 simple inputs and a 3-column data table view. To this day it makes my head spin how it is even theoretically possible to write that much code for so l…

> We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms Holy moly. I've seen some bloat but that takes the cake.

They essentially created a unique type for every. single. variable. I'm talking like, if you needed string constant for an error message on Input 1 on Form 3, there was an ErrorLoadingMessageForInput1OnForm3 type declared for that instead of defining it as a string. The types were never reused - like if you had the same error message on Form 2, there'd be a separate ErrorLoadingMessageForInput1OnForm2 type for the same string. And then every interaction between any 2 variables had its own type of types. Like if Form 3 was displaying the error message, there'd be a type for Form3DisplayingErrorLoadingMessageForInput1OnForm3. Which of course, is distinct from Form3DisplayingErrorLoadingMessageForInput1OnForm3AndErrorLoadingMessageForInput2OnForm3. And then those types were combined to create even more types, and so on until you had literally tens of thousands of lines of _just_ type declarations for variables and every possible permutation of UI state sitting atop a recursive pyramid of smaller subsets of the permutations (and so on until it eventually got to actual variable declarations). An then all that was piped through the craziest clusterfuck of redux butchery imaginable with a similar dynamic of explosively exponential growth of references and types and states and properties and so on. Like I said, it still hurts my brain thinking about it.

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

#463

Post by fud101 »

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…

my front end is 50k loc, is that medium or small or what?

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

#464

Post by earthboundkid »

jstummbillig wrote: post #342
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…

> when I need to develop a reactive piece of UI I reach out for Svelte I never used Svelte, but I feel that "develop a reactive piece of UI" is basically Stimulus' job description. Can you explain a scenario/task where Stimulus does so poorly, that you flip the switch and use Svelte instead?

Stimulus was made by people who hate JavaScript and deliberately and pointlessly avoids JavaScript conventions. If you hate JS, you might like it, but I like JS, so I hate Stimulus. My preference is for Alpine.js, but Svelete is cool too.

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

#465

Post by hellohowareu »

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 liked classes to-- their lifecycle methods were so clear to work with.

That said, learning how useEffect replaces lifecycle methods is pretty quick to pickup. As is useState.

The lesser known hooks are what are difficult for me to understand. useRef is pretty clear. useMemo? I'm not quite sure what it's for, but I imagine it's not too tough to figure out if I spend a bit of time learning & experimenting with it.

So, although I liked the simplicity of class components, functional ones aren't too bad. They bring in some additional complications, but with a bit of effort it seems to all be learnable to me.

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

#466

Post by cercatrova »

exclusiv wrote: post #449
edgyquant wrote: post #420

Earlier quoted context omitted.

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 do…

Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component.

This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M

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

#468

Post by jasongi »

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 OO (e.g stateful functions). I don’t find these arguments compelling. What the React team managed to do was reproduce the same functionality as class components while decreasing the footguns associated with them.

1. https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu...

2. https://youtu.be/dpw9EHDh2bM

3. https://reactjs.org/docs/hooks-intro.html#motivation

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

#469

Post by hunterloftis »

tomphoolery wrote: post #429
dpweb wrote: post #239

Earlier quoted context omitted.

I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this featur…

Last time I used them, web components were incredibly slow. They were so slow to render, after using maybe 2 or 3 of them I realized why nobody is trying to build apps this way. Just isn't there yet. Probably won't be until HTML Imports are merged with JS Imports.

This is a surprising perspective, since we're using web components top-to-bottom to build photoshop on the web, & some of that decision was driven by performance comparisons where web components outperformed react.

It's possible that very naive implementations of web components would render as slowly as you describe - like if you rebuilt the whole DOM tree at every level on every change.

Here is a performance-oriented talk about rendering web components via browser-parsed template literals via Lit (which is how we do it):

https://youtu.be/CJYkwDTaHzY

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

#470

Post by edgyquant »

cercatrova wrote: post #426
edgyquant wrote: post #420

Earlier quoted context omitted.

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…

Not sure I understand because I use GraphQL with an ORM, Prisma with Postgres and Pothos which converts the Prisma schema into GraphQL types. It even has the ability to use Redis as a store. So we get all the features of an ORM and also typesafe queries.

Right my point is that

1. It incentivized using it as the data model which is both inefficient and lossy in regards to transactions.

2. what’s the purpose of graphql in this context? You have to use an ORM anyway with which you can do all delegations to servers etc your heart desires and with typescript you can ensure proper column types regardless. You can trivially autogenerate objects or any kind of descriptor from a database as well.

Seems to me people decided graphql was a perfect solution to nicely hit multiple data stores with the now added caveat that we have a worse query language that lacks joins to boot.

I’ve still yet to see an actual technical argument for why we should add another (less efficient) layer between the actual data stores and the ORM/Application DataModel.

Is it resolver logic between stores?

Post reply on HN