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…
React I love you, but you're bringing me down
231–240 of 574 posts
Re: React I love you, but you're bringing me down
#232Earlier quoted context omitted.
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 fr…
This isn't that. My hostile working definition of a framework is something that
. breaks core assumptions about a language or system
. limits what a user is permitted to do
. increases complexities by adding new abstractions
. has non-specific specifications by using unclear and imprecise language
At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions.
Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution.
Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration.
Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable.
Given a product:
. Systems should not continue to function without the programmer
. Code has to constantly be rewritten in order to achieve the same ends
Also it permits the users to go on constant employer funded vacations to conferences and training sessions.
From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following:
. Job security by ensuring brittle applications
. Endless tasks by ensuring endless complexity
. A sense of elitism and entitlement
. No expectations of deliverables
. Be vague enough so blame can get shifted if things break
By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done.
The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible.
In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power.
People adopt the patterns because they want to have the perceived protective properties of the obscurities.
Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic.
...
Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
Re: React I love you, but you're bringing me down
#233Earlier quoted context omitted.
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.
Ultimately hooks are probably the way they are for the same reason Redux is the way it was(pre RTK I suppose)..
Re: React I love you, but you're bringing me down
#234Function 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.
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 given third-party integration to React in the future is allowed to just say "We only support functional components" (with the corresponding hit to popularity, of course).
Re: React I love you, but you're bringing me down
#235Earlier quoted context omitted.
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'…
This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?
Re: React I love you, but you're bringing me down
#236Earlier quoted context omitted.
They absolutely do not have their place. Just about everything is worse with class components. I’ll take a dozen useEffects over a single class component any day. That said, the hooks model is far from perfect. They give you a lot of rope to hang yourself with and were badly introduced. Within weeks the internet was ablaze with terrible advice. When so many people get it wrong, the library is to blame. And I wish hoo…
I don't think hook themselves are a bad thing. But the way react implements hook probably is. The react team invented their hook format the suite themselves the most, but that probably isn't for other. Vue 3 also has hook now. But none of these defects in the article exist. In vue. To use some value in a effect, you just use it and it is tracked. If you need to clear up your code. You cut some code into a useXxx func…
I’m even more impressed with the extended Vue ecosystem like Vite, Vitest.
Re: React I love you, but you're bringing me down
#237I 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.
And how much logic you put into a component is up to you. Your components can be almost entirely view logic, with any other data fetching or computation offloaded to other regular js files.
Re: React I love you, but you're bringing me down
#238Re: React I love you, but you're bringing me down
#239I'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…
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 feature and that - maybe not - but do we need all those features. Programmers like to write code, so every framework always gets bigger and more complicated.I understand and respect the problem react is trying to solve, I just don't see it as much different than the js world before async/await and fetch, etc.. callback hell - which I saw as much more prickly issues.
Re: React I love you, but you're bringing me down
#240I'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…