Live data from Hacker News

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

marmelab.com

211–220 of 574 posts

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

#211

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…

They mostly encourage bad practice by design and people do what these tools give an affordance for which is why the results are broken.

People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason.

The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend.

Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.

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

#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.

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

#213
post #29

I prefer Angular. I never could accept writing css/html in my javascript. To be fair, my background is from XAML, so declaring the state separately and simply binding to it in my html template felt natural. The whole functional approach in React is overkill imo. It's okay if the state mutates in 90% of scenarios. Where there is really benefit from immutable states, I can enforce that on my own.

Yes yes yes! I´ve done some React at my job and also done some Angular/Ionic before. What I never understood of React is why did the creators decided to throw DECADES of Software Engineering development and comingle presentation layer with logic... To separate Views from Logics was an agreed good practice in Software Engineering since I was in undergard school 20 years ago.

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

#214

Earlier quoted context omitted.

> How can a replacement for lifecycle methods be called useEffect? Seriously? Yes, seriously. Have you used it for more complex components? You can split your effects across multiple useEffects, and have a guarantee that they run completely independently of each other (especially since you know what their dependencies are). Compare that to lifecycle methods: you only have one per component. All your effects concerned…

Fair enough. Though, the first question is - why does the component do so many things? Do they all need to be in a single component or can you break them apart? For the cases when this is not possible, I agree, useEffect works better than classes lifecycle methods. But do you really want a system which caters to a small percent of use-cases at the expense of readability in others? And the improvement, to my eyes, is…

I find hooks make it easier to break apart components. With a class component, there are tons of hidden dependencies on those huge components. Maintenance programmers add them relentlessly. When it comes time to refactor, it's often easiest to just translate to hooks and then start breaking things apart. Why? hooks are small and self contained by nature, and they compose nicely, so you can start with a ball of hair and use regular refactoring tools (extract to function, move to file) to decompose them.

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

#215

Earlier quoted context omitted.

Formik hasn’t been updated in years, is riddled with bugs and performance issues, and very likely will never be updated again. Not what I’d want in a JS library.

What are the bugs and performance issues? I’ve been using it for years without problems.

a library that has re-render issues due to its architecture. but there are solutions for this like FastField https://formik.org/docs/api/fastfield

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

#216
post #157

Earlier quoted context omitted.

In 5 years if no one else is using Hotwire I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating…

React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.

React changes best practices every few years prompting many rewrites.

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

#217
post #76

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…

> Has anyone else here successfully left for greener JS pastures? I've simply stopped doing any frontend development contract work *. Until the whole JavaScript world pulls its head out of its bottom, I'll leave that niche to other people. * I'll do JS and React if I really have to, but I'm actively avoiding any client-side focused projects.

It's a wide open web with millions of developers, and 25 years of language and ecosystem development, so there will always be 27 1/2 ways to solve a problem. Client side dev is hard. Especially on the web. It's understandable that anyone would avoid it for easier work.

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

#218
I define myself a backend engineer, I am not super skilled in javascript and frontend framework. That said through out my career I did some front end work and I went from jquery, angular, react and vue. I must say that Vue was the one library easy enough for me to be productive in few days: I built an entire application in just a couple of weeks. It has now become my go to choice when I have to do fronte work.

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

#219

Earlier quoted context omitted.

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases

Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React

It would be funny if it were true. Hooks were made for composable behavior for components.

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

#220
post #3

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

OP here. I'm glad at least one reader noticed that. You're my hero!

By the way, all section titles in this article are song or album titles.

Post reply on HN