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

401–410 of 574 posts

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

#401

Post by rurp »

stevage wrote: post #397
throwaway0asd wrote: post #173

Earlier quoted context omitted.

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.

While I don't doubt your specific experience, I'm wary about drawing firm conclusions from a single project. Vanilla JS projects can vary wildly in how verbose and complicated they are. I would bet that there are plenty of examples of both types: those that would be much more concise with a framework and those that wouldn't.

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

#402

Post by PaulStatezny »

shadowgovt wrote: post #234
PaulStatezny wrote: post #32

Function components are a useful tool, but for the life of me I can't understand why the community currently builds everything with them. A lot of React code I run into these days would be simpler and less verbose with a traditional (non-function) React component.

Mostly because functional components are understood to be the direction the framework is headed, with class components still supported for backwards compatibility reasons only. They'll almost certainly never go away without a major version bump because it would break way, way too many sites, but at some abstract level people feel class components will have a shorter shelf-life than functional. And certainly, any give…

Thanks for commenting about the community sentiment.

Interesting that you didn't comment at all about my take on functional components not being the best tool for every job in React. Curious – do you have an opinion?

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

#403

Post by youssefabdelm »

nophunphil wrote: post #128
egeozcan wrote: post #39

Earlier quoted context omitted.

I'm also a TL (which makes me a teaspoon here in Germany, which I like more than the tech lead title). I understand how the development can be faster with Svelte, but ecosystem argument really hits home. You'd get to 80% with Svelte perhaps much faster than React, but that missing library for, say, drag-and-drop makes that last 20% itself plus "hey let's develop our own drag-and-drop library in-house which should be…

All excellent points. Yes, the package ecosystem has been a pain point. We’ve turned this into a slight positive by pushing the business to allow us to make open source contributions. The developers seem to enjoy this a lot, and hopefully our work helps others in the space.

Someone needs to invent a way to import React/Vue/Angular packages to Svelte and still use Svelte syntax somehow. Sounds crazy but I wonder if even remotely possible.

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

#404

Post by skydhash »

mind-blight wrote: post #28
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…

I think a lot of the problems the author highlighted become more apparent as the number of devs in the codebase goes up. If one member doesn't understand all of the nuances of useEffect or paint useCallback, they can write a component or custom hook that another team uses and gets subtle bugs from. For example, I need to look inside of a hook to see whether the callback it provided was wrapped in useCallback. That me…

Pretty much this. I've owned entire applications and it's really fun when you're working alone. But adding a new developer that does not grok hooks (mostly because they are more use to imperative patterns than functional ones), and you will have bugs to deal with almost every single day. In a project, I was using Firebase as the backend and hooks allowed me to nicely abstract it away and use a language closer to business domain (like `useEntity(entityId)` and `useCreateEntity(entityData)`). Everything was more modular from changing the backend layer to breaking up bigger components.

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

#405

Post by nirvdrum »

ajmurmann wrote: post #370
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.

I think Rails was able to avoid this because of its modular structure and ease to write gems that extend the framework in a way that fits your project's circumstances and needed tradeoffs. As DHH famously said Rails is omakase, but you can also make reasonable substitutions.

It partly became modular because it merged with Merb, which was an alternative modular web framework that competed with Rails for a little while.

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

#406

Post by skydhash »

PaulStatezny wrote: post #32

Function components are a useful tool, but for the life of me I can't understand why the community currently builds everything with them. A lot of React code I run into these days would be simpler and less verbose with a traditional (non-function) React component.

It's less code. And if you add hooks (for the reasons specified in the docs), you can have a smaller and more manageable codebase. But hooks differs so greatly from the easier to grasp lifecycle methods and state as component object's property that it's easy to have bugs if you do not grok it.

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

#407

Post by shadowgovt »

PaulStatezny wrote: post #402
shadowgovt wrote: post #234

Earlier quoted context omitted.

Mostly because functional components are understood to be the direction the framework is headed, with class components still supported for backwards compatibility reasons only. They'll almost certainly never go away without a major version bump because it would break way, way too many sites, but at some abstract level people feel class components will have a shorter shelf-life than functional. And certainly, any give…

Thanks for commenting about the community sentiment. Interesting that you didn't comment at all about my take on functional components not being the best tool for every job in React. Curious – do you have an opinion?

If I understand correctly, the team is pretty clear that if they had written React from scratch today, they would have gone with functional components and not class components.

The major issue is life cycle. When is a class component instance created or destroyed? The answer is "whenever the framework feels like it," and that's a really ugly model for instance life cycle. Additionally and most importantly, it means that member variables on a React class component instance don't work the way that members are expected to work; you just can't rely on them having any particular value because the framework can create or destroy an instance when it feels like it for performance reasons. What good is a class and instance abstraction if when you try to use member variables (one of the key features of object-oriented programming) you're highly likely to just break the model in hard-to-debug ways?

Because the framework isn't using class component instances like instances are supposed to be used, the React team is tossing that model to the curb.

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

#408

Post by exclusiv »

iLoveOncall wrote: post #383
exclusiv wrote: post #375

Earlier quoted context omitted.

I have an Angular 1 app I built in 2015 that's still in use today. Went back to it and it was refreshing in so many ways. A lot of people really hated it but it's opinions and structure helped promote a more maintainable codebase. I don't miss tuning watchers and the digest cycle though. All the React projects I've inherited are nightmares. I'm comfortable working on them but they are harder for junior and mid-levels…

Have you given a try to Angular 2 and above? Angular (Angular 2+) is honestly lightyears ahead of what AngularJS (Angular 1) was, so if you already preferred AngularJS over React, Angular will be a walk in the park. I feel like a lot of people who talk about Angular being bad are actually talking about AngularJS and have never tried the newer versions. For collaboration and onboarding new people, it's hard to do thin…

Have not tried it yet but curious thanks for the info.

I kind of just shifted into Vue and then React after Angular 1.

Most of my team has never used Angular and the components available for React are so nice I'm a little hesitant to invest in Angular.

I also have yet to inherit an Angular codebase so I have to weigh the time investment.

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

#409

Post by theteapot »

phailhaus wrote: post #54
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.

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. I've been able to support much more complex behavior easily with hooks (e.g., connection…

> I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable.

That's not strictly true. You can implement "hooks" on top of a class based components. It's essentially the strategy pattern.

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

#410

Post by lexx »

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…

Amen
Post reply on HN