TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

696 pointsby fzaninottoover 2 years ago

67 comments

corytheboydover 2 years ago
I&#x27;ve worked in a few roughly-the-same-size (~50 engineers) web development shops. It&#x27;s always the same. Doesn&#x27;t matter if it&#x27;s React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc.<p>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 other, half-finished move-to-new-framework initiatives.<p>I just mean to say that when I hear &quot;it&#x27;s because React&quot; or &quot;it&#x27;s because rails views&quot;, any other of the infinite variations of this, I kind of just tune out. Some part of your organizations chaos is going to reflect in code, and honestly I&#x27;d rather it be in a big ball of frontend than in the data models, infrastructure, etc.
评论 #32917747 未加载
评论 #32915332 未加载
评论 #32915274 未加载
评论 #32914892 未加载
评论 #32919638 未加载
评论 #32916428 未加载
评论 #32917517 未加载
评论 #32920197 未加载
评论 #32917953 未加载
评论 #32916845 未加载
评论 #32918557 未加载
throwaway284534over 2 years ago
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.<p>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 solve a complex DOM state issue with custom hooks wrapped around refs.<p>Newer tools like Svelte and Solid do look promising as far as removing boilerplate, but they personally feel a step too far off the path of “it’s just JavaScript.”<p>Has anyone else here successfully left for greener JS pastures?
评论 #32914694 未加载
评论 #32912963 未加载
评论 #32914897 未加载
评论 #32912941 未加载
评论 #32914272 未加载
评论 #32913757 未加载
评论 #32913788 未加载
评论 #32914373 未加载
评论 #32916868 未加载
评论 #32914454 未加载
评论 #32913912 未加载
评论 #32917414 未加载
评论 #32920790 未加载
评论 #32914351 未加载
评论 #32913731 未加载
评论 #32913361 未加载
评论 #32914075 未加载
评论 #32915186 未加载
评论 #32914572 未加载
评论 #32916619 未加载
nonethewiserover 2 years ago
I must be the only person in the world who likes class components in React.<p>Sure, it&#x27;s often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you&#x27;re doing something more complicated then stop treating class components like the fucking devil. They have their place.
评论 #32914071 未加载
评论 #32913890 未加载
评论 #32914718 未加载
评论 #32914447 未加载
评论 #32914765 未加载
评论 #32920216 未加载
评论 #32913604 未加载
评论 #32913590 未加载
评论 #32914326 未加载
评论 #32914478 未加载
评论 #32914099 未加载
评论 #32913850 未加载
评论 #32914225 未加载
评论 #32913799 未加载
评论 #32920506 未加载
评论 #33001577 未加载
评论 #32934605 未加载
评论 #32914633 未加载
评论 #32914486 未加载
评论 #32916134 未加载
评论 #32922489 未加载
评论 #32920873 未加载
评论 #32926965 未加载
评论 #32914190 未加载
评论 #32948363 未加载
评论 #32914424 未加载
评论 #32913573 未加载
jitlover 2 years ago
Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted.<p>&gt; Form libraries are portly maintained or documented<p>The two-way data binding in Svelte saves ~4 lines of reusable hook function but doesn’t come close to covering defaults, validation, errors, dependent fields etc - all of that is essential complexity.<p>Write your own form field hook. The state model for a form is <i>simple</i> - what is a 3rd party library bringing to the table in terms of state management? I have more pain explaining what I want to a 3rd party library than I do writing a bit of code myself to do the same thing. I reach for open-source input components from a vendor for things like credit cards, but manage the state myself.<p>&gt; useContext and useEffect have annoying dependency tracking; I prefer Solid’s mutable state and automatic dependency tracking.<p>React’s built-in hooks are positioned as building blocks with clear-cut contracts. Why dump Redux for bare useContext if you prefer Redux’s selectors? Just use Redux. If you like the Solid style of automatic dependency tracking and mutable state, just use Mobx - it’s a mature library for that style that’s been around for 7+ years, and is used in production by products like Linear and Cron.<p>Overall I agree that function components in React are difficult to get right for developers and a bit too verbose. There’s an onboarding tradeoff to every abstraction you layer over the framework’s APIs, but there’s large advantages too. Do so judiciously to find the sweet spot for your team &amp; scale.
评论 #32914176 未加载
评论 #32914695 未加载
评论 #32915431 未加载
fabian2kover 2 years ago
The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. State management in React is a topic discussed to death, there are plenty of options if you have specific tastes or requirements but plain old React state works perfectly fine as well (especially when coupled to server-side state libraries like React Query). But Context is not about state management, it does not seem useful to complain that it doesn&#x27;t do a job well it was never meant to do.<p>The part about the Inspector component and the rules of hooks I don&#x27;t understand. I would have put the visibility state outside the Inspector component, and then there is no need for any conditional calling of hooks.
评论 #32912870 未加载
评论 #32914195 未加载
评论 #32913105 未加载
评论 #32916528 未加载
评论 #32914435 未加载
knoebberover 2 years ago
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 missing something. If you accidentally add the wrong value in there, hello infinite render loop!<p>One of the biggest level ups I had was extracting complex hooks into their own .js files instead of stuffing next to component code. This helps a lot with readability&#x2F;reusability.<p>Overall I liked what I came up with, but it felt like a lot of inventing stuff on my own, which I&#x27;m not sure if the next developer who comes along will appreciate.
评论 #32913176 未加载
评论 #32918971 未加载
molszanskiover 2 years ago
Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years.<p>React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result.<p>First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.<p>I’ve given the same demo day (task) exercise to ~50+ react devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside react components. The sad part is this app doesn’t need react at all. Or could implement 99% of the BL in pure JS and just call one function from React.<p>React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singletone instances of a business logic because we’ve “forgot” how to do a DI without a framework. People write `&lt;IF&gt;` components for christ…<p>Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way, beyond todo examples. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.<p>In a nutshell, the we should critique ourselves, not the framework. IMO the framework is doing it’s job just fine. Unless we learn what really goes wrong with react projects we are doomed to repeat the same mistake again and again with next (pun intended) framework.
评论 #32914583 未加载
评论 #32914732 未加载
评论 #32920025 未加载
评论 #32916612 未加载
simon83over 2 years ago
I was a huge React fan myself but when I started to use Vue and its Composition API one year ago I had tears of joy in my eyes. You have a setup function that is executed exactly once. Inside this setup function you setup your life cycle callbacks, reactive state variables and so on. This is how I wish React + Hooks should have been. Nowadays I won&#x27;t even accept projects that use React anymore, exactly because of all the pain points OP mentioned.<p>SolidJS is following the same principle like Vue + Composition API. I think Svelte is also in the same boat. This kind of pattern is so much easier to use and reason about. React Hooks become really painful and annoying really fast.
swyxover 2 years ago
As someone whose career success was very tied to React, I will say that &quot;quiet quitting React&quot; (or, nonjudgmentally, realizing my longterm interests were broader and taking action on it) has been one of the hardest career transitions I&#x27;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&#x27;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).<p>React is doing innovative, groundbreaking stuff with React 18 and beyond. I&#x27;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&#x27;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&#x27;t everything; once you identify the 10-20 things everyone shouldn&#x27;t DIY you&#x27;re basically done (I ended on this at last week&#x27;s Svelte Summit <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=A8jkJTWacow" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=A8jkJTWacow</a>)
评论 #32919901 未加载
rafaleover 2 years ago
I prefer Angular. I never could accept writing css&#x2F;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&#x27;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.
评论 #32915042 未加载
评论 #32913679 未加载
ch_smover 2 years ago
I think the title is a reference to this wonderful song by LCD Soundsystem: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-eohHwsplvY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-eohHwsplvY</a>
评论 #32919804 未加载
评论 #32915093 未加载
Patrol8394over 2 years ago
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.
Waterluvianover 2 years ago
Been using React as the view library for 8 years worth of applications that real-time manage fleets of robots worldwide (think config CRUD app + Google Maps + Dashboard + live camera&#x2F;lidar views + joystick controls).<p>I generally empathize and see what a lot of authors are saying when they have these commentaries. But I just cannot get past the reality that for all its issues and things worth complaining about, React has never really been &quot;in my way&quot; when it comes to the only goal I really care about: shipping a maintainable product on-time.<p>I think that comparing a 10 year old library to much younger libraries can be useful in some cases, but is still apples to oranges, given that younger library still has to survive growing up and not having the same claimed fate.
randomsearchover 2 years ago
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.<p>JSX yuck.
评论 #32918624 未加载
评论 #32917889 未加载
评论 #32918749 未加载
collywover 2 years ago
Does anyone do server side rendering these days?<p>I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It&#x27;s a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django and a little bit of JQuery.<p>I ask at my work why we are doing this and no one seems able to give me a decent answer but we carry on down this path regardless.
评论 #32914558 未加载
评论 #32913759 未加载
评论 #32914156 未加载
评论 #32914826 未加载
评论 #32915112 未加载
评论 #32914202 未加载
评论 #32917460 未加载
ravover 2 years ago
Regarding the Inspector&#x2F;isVisible complaint:<p>When you want to have &quot;early return&quot; in a component, it&#x27;s possible to just split the component into two to introduce an &quot;inner&quot; component that contains whatever comes after the early return point in the original component.<p>Any local variables from before the early return then need to be passed as props to the new inner component.<p>However, naming this inner component is always an issue for me. Typically I just name them Inspector2, Inspector3, etc. until I have an implementation that works. Then I can start thinking about how to refactor the implementation into something that I can give sensible names.<p>It&#x27;s really a code transformation similar to async&#x2F;await where you derive a state machine from a block of code by identifying transition points. In async&#x2F;await you have transitions at the await points; in components you have transitions at the early return points. In async&#x2F;await, no one is forcing you to name the individual states or even write them out explicitly - the compiler takes care of it. Then why do I have to write out the state machine explicitly and name the states explicitly for function components with early return? I would love for React to have some facility like &quot;Consider the rest of this component as a new sub-component; as if this component now returns a single Element pointing to whatever is in the rest of this component&quot;. But it&#x27;s probably a Hard Problem™.
评论 #33001037 未加载
holistioover 2 years ago
...and that&#x27;s why I switched to Vue nearly four years ago. Best professional decision I&#x27;ve ever made.
评论 #32914287 未加载
qprofyehover 2 years ago
One could argue that it&#x27;s not that React can&#x27;t handle increasingly complex situations for you and that&#x27;s why you spend more time on them, but that frontend as a craft has evolved due to React having solved the easy parts and has raised the bar, and therefore these complex situations belong to the next breeding site wherein the community is arguing about new solutions all the time, at the current time. It&#x27;s healthy to retrospect how we got to this breeding site, yet there&#x27;s always a certain doubt or even bias that what brought us here today is not what takes us forward tomorrow. It&#x27;s like the reverse of Shiny Object Syndrome.<p>In time, I believe React can still take us forward.
评论 #32913020 未加载
kirseover 2 years ago
As an early beta user, I also agree. I think the issue with many modern libraries is that they don&#x27;t know when to stop. Like that guy who keeps adding visual mods to his car, or that TV show that keeps creating mediocre seasons.<p>I took a risk on React back when there were minimal components and zero form libraries and started fading away from React once hooks were added. Redux is still pretty nice, and overall still use React because I much prefer it to anything else. But we&#x27;re definitely in the long-term bloat phase which you can tell by the popularity of things like Vue, &quot;React Lite&quot; libraries being built, etc.
miohtamaover 2 years ago
I was using React earlier for many years, but nowadays Svelte and SvelteKit (file based routing). I feel I am more productive (might be an illusion), but at least I am less frustrated.<p>More here:<p><a href="https:&#x2F;&#x2F;kit.svelte.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kit.svelte.dev&#x2F;</a>
评论 #32916623 未加载
PaulStateznyover 2 years ago
Function components are a useful tool, but for the life of me I can&#x27;t understand why the community currently builds <i>everything</i> with them.<p>A lot of React code I run into these days would be simpler and less verbose with a traditional (non-function) React component.
评论 #32915221 未加载
评论 #32919164 未加载
bern4444over 2 years ago
The &#x27;issue&#x27; with forms and front end is that we cram the entire kitchen sink into the front end code, handling everything about them via onChange: validation, error messaging, options etc.<p>There&#x27;s very little need for a<p><pre><code> onChange(e) =&gt; setFormValue(e.target.value) </code></pre> and all the extra work that comes with that.<p>There is an absurdly simple solution which removes all the &#x27;cruft&#x27; the article bemoans: use uncontrolled form elements that then send the form data to the server and have the server do the validation, error messaging etc.<p>In this approach, the client gets back into the business of pure network calls. When the server sends back a response parse it and update the UI. This is trivial with some conditional rendering of error messages, styles etc.<p>But rarely is this done. This approach is why I really like using Remix. It encourages this paradigm by coupling the server side code that runs on a form submission in the same file as the client side code.<p>All this becomes blissfully easy.
sergiotapiaover 2 years ago
Since quitting React I&#x27;ve been happier with my day to day. Phoenix Liveview came in clutch and showed me I don&#x27;t have to put up with these kinds of self-inflicted problems.<p>If you&#x27;re tired of React and the npm lunacy, I recommend you take a dip into Elixir and Phoenix Liveview. Take it for a spin, see how much better it is for you and your users. It&#x27;s _sane_. You don&#x27;t have to &quot;split the context&quot; anymore. xD
评论 #32915545 未加载
blumomoover 2 years ago
Give react-admin [0], the post author’s react framework, a glimpse. If you develop an ERP&#x2F;CRM like react app, you‘ve probably rebuilt parts of react-admin already, but you did it worse. Ah, and their source code is a breeze of fresh air.<p>[0] <a href="https:&#x2F;&#x2F;marmelab.com&#x2F;react-admin&#x2F;" rel="nofollow">https:&#x2F;&#x2F;marmelab.com&#x2F;react-admin&#x2F;</a>
padseekerover 2 years ago
If you are using that many refs you built it wrong - from the React documentation (<a href="https:&#x2F;&#x2F;reactjs.org&#x2F;docs&#x2F;refs-and-the-dom.htmlhttps:&#x2F;&#x2F;reactjs.org&#x2F;docs&#x2F;refs-and-the-dom.html);" rel="nofollow">https:&#x2F;&#x2F;reactjs.org&#x2F;docs&#x2F;refs-and-the-dom.htmlhttps:&#x2F;&#x2F;reactj...</a><p>&quot;There are a few good use cases for refs:<p><pre><code> Managing focus, text selection, or media playback. Triggering imperative animations. Integrating with third-party DOM libraries. Avoid using refs for anything that can be done declaratively. </code></pre> ...<p>Don’t Overuse Refs:<p><pre><code> Your first inclination may be to use refs to “make things happen” in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy. Often, it becomes clear that the proper place to “own” that state is at a higher level in the hierarchy. See the Lifting State Up guide for examples of this.&quot; </code></pre> If you are using refs to talk to your child inputs you&#x27;ve made a mistake. React talks about RAISING THE STATE - for complex forms you need to make all of your inputs controlled, you need to manage the state at the highest level. You need to push those changes down to child components, none of them should have their own state.<p>React gives you some nice tools to handle most common use cases but you can still make less than optimal decisions.
11235813213455over 2 years ago
Salut Marmelab<p>The best way we found is a custom useForm hook (simple to code, using useState&#x27;s):<p><pre><code> const { submit, getProps, isLoading, error } = useForm({ onSubmit: cb, initialValue: {} &#x2F;*optional*&#x2F; }); return ( &lt;form submit={submit}&gt; &lt;input {...getProps(&#x27;firstName&#x27;)} &#x2F;&gt; </code></pre> very flexible, you can use other wrappers than form or input<p>react-query is another super useful lib, you could use useMutation() for implementing useForm actually
nutancover 2 years ago
We tried to use other frameworks but finally came back to React for only one reason. It&#x27;s easier to hire for React. The talent pool for React is almost 10 times that of other frameworks.<p>And for now, this reason is good enough for us.
评论 #32914987 未加载
评论 #32913818 未加载
asdajksah2123over 2 years ago
I really hope React doesn&#x27;t handle dependencies automatically. There have been many frameworks that have done that in the past. It does not end well with an application of any decent size.<p>A pre-compile step that statically adds dependencies to your code might be a reasonable compromise, but those dependencies do need to be explicit.<p>The rest of the stuff makes a lot of sense though.
评论 #32914033 未加载
sakagami0over 2 years ago
React is bad in the same way C++ is bad. It&#x27;s not really, but it does take a while to learn the ins and outs. In the end, the pattern React provides is much more powerful when used right. But it&#x27;s not a one size fits all, a lot of the time you don&#x27;t need the flexibility if you&#x27;re new to it and just want to get something done.
insane_dreamerover 2 years ago
React and other client-side frameworks are great for apps where you need a highly responsive UI, but for many websites, server-side frameworks (Rails, Django the many spinoffs) are easier to write and maintain than SPAs. Yet there seems to be this idea that every &quot;modern website&quot; must be written with a JS framework like React.
markandrewjover 2 years ago
The thing that has kept me tied to React is the support for native mobile and desktop development. Expo has been a really nice environment for mobile development compared to some other things I have used in the past. EAS is also pretty handy. It looks like Svelte has improved in this area, but my past experiences with NativeScript were not very inspiring. Is anyone using Svelte for production mobile or desktop development?<p>What are peoples thoughts on Svelte vs Solid? I know Lit&#x2F;native web components are out there as an option as well. I have past experiences with it when it was Polymer.<p>If anyone is looking for something very lightweight they may want to consider Alpine as well.
评论 #32919660 未加载
shadowgovtover 2 years ago
&gt; And I thought that reference counting was a native feature of all languages with a garbage collector. But no, I have to micromanage dependencies myself because you don&#x27;t know how to do it.<p>So annoyingly enough... There&#x27;s not anything inherent to the language that makes it impossible to get a list of closure references for a function, other than it&#x27;s not something JavaScript exposes. In a hypothetical future version of JS, this could be a first-class feature of the function API.<p>... because what JavaScript really needs is yet another feature to support one framework&#x27;s special-caee needs. ;)
tootieover 2 years ago
&gt; There are two kinds of programming languages: The ones people complain about and the ones nobody users<p>- Bjarne Stroustroup
recursivedoubtsover 2 years ago
<i>&gt; What&#x27;s next for us? You tell me. </i><p>I&#x27;m gonna say something crazy here, but hang with me: <i>hypermedia</i>.
评论 #32912598 未加载
bedersover 2 years ago
I&#x27;m happily using React as a low-level renderer (using Reagent) - I would welcome splitting this codebase up into a pure DOM-diffing renderer and state&#x2F;event handling on top.
dogcomplexover 2 years ago
Throwing my message in a bottle here, in hopes someone can answer:<p>What is currently the best way to handle the complexity once you have a ton of asyncronously-loaded JSX components which have complex conditional rendering logic based on multiple inputs and datatypes? (including defaults, local variables, and all kinds of other stuff)<p>At this point I&#x27;m inclined to just handle all the data processing logic and when-will-it-render logic in some intermediary controller and then keep the visual templating barebones and strictly separated, though it feels quite un-React-like to do this, and almost more trouble (and certainly more boilerplate) pushing vars through the stack and separating Controller &#x2F; View than to just let my JSX be messy with useEffect hooks. I suppose this is when I should use a React class component? Or a subcomponent? Or a custom hook..? Or maybe I should just modify (global) state - even grosser from data duplication perspective, but at least then all the data processing is in one clearly defined format instead of scattered throughout templating files.<p>Last I checked (and burned out) this was the major React hurdle, and the downside of React&#x27;s simple-by-default templating. This complex stuff got real ugly real fast. What&#x27;s the elegant solution here, if any? Any improvement?
sibeliussover 2 years ago
How has nobody mentioned the insane complexity monster that is React 18 &#x2F; Suspense?! I mean, it makes sense once you understand it, but who is going to understand it?<p>React&#x27;s concurrency features should have been broken off into a separate, opt-in library, not packaged into React core, and they sealed their own coffin with this release. That said, suspense is awesome once it&#x27;s fully understood. Give the public a few more years to get it, though.
评论 #32918464 未加载
joshribakoffover 2 years ago
Concurrent react actually makes your app less concurrent: <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;21668" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;21668</a><p>5yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.
评论 #32914925 未加载
autorunover 2 years ago
I&#x27;d like to know how a newcomer would feel after reading the tutorial of the monster you created, React.<p>Take React hooks at its purest for example. I can&#x27;t imagine the WTF feeling in a newcomer&#x27;s mind, when the <i>useState(&lt;default-value&gt;)</i> helper function returns the &quot;reactive&quot; variable and a function you have to use to update it (!) do you realize how tricky you end up with your technical DOM optimizations?<p>Same with <i>useEffect()</i>, where you probably will have your whole function defined right into the first argument, and a list in the second one, very lost in your IDE. Who would expect that an empty array of dependencies would trigger it once? Why we should track all those dependencies at first place?<p>When recommending a frontend framework, I found Vue to be more dev friendly. However, it&#x27;s currently in a long migration crisis, because documentation shows the 2 different APIs you can choose. I know that the differences are well explained (although they don&#x27;t even say that&#x27;s to be retrocompatible with Vue2 mindset), but for a newcomer&#x27;s mind, it&#x27;s like asking: which pill do you want to take? red or green? Choose your own adventure!
padseekerover 2 years ago
As someone who built a product that is a form builder that uses React, <a href="https:&#x2F;&#x2F;keenforms.com" rel="nofollow">https:&#x2F;&#x2F;keenforms.com</a>, the best thing I can say is this;<p>Most of these libraries are fine for simple to medium complexity forms. However once you cross a certain level of complexity these libraries become impediments rather than tools. I probably could have used a redux implementation but build my own state management API with a mixture of object oriented as well as functional programming. The values of the inputs persist so you want objects, but hiding&#x2F;validating&#x2F;calculating need to be reset for each change so I used a functional approach for these other features.<p>React is not perfect and its easy to paint yourself into a corner. However as someone who used to write js for IE6 and has forgotten more js libraries that you can imagine (Dojo, ExtJS, Backbone, Ember, etc) I can tell you right off the bat its the best tool for the job. Not perfect, just like Javascript. Just know and accept its limitations and you should be able to get React to do what you want.
geeweeover 2 years ago
Can definitely agree with his pain point about forms. I&#x27;ve been through most of the libraries, and the one I liked the most was Formik, because it felt like I could actually get something done. react-hook-forms is beautiful when it works, but the documentation is byzanthine - even when I know exactly what I&#x27;m looking for (and I&#x27;ve seen the page before), I often can&#x27;t find it.
评论 #32913631 未加载
评论 #32912668 未加载
tabtabover 2 years ago
I keep saying we need a state-ful GUI markup language standard so we don&#x27;t have to re-re-re-reinvent real GUI&#x27;s with JS+CSS+DOM. Those weren&#x27;t meant for real GUI&#x27;s and retrofitting creates bloated, buggy, ever-changing messes. GUI&#x27;s have been around more than 30 years, why can&#x27;t we network-ify its common and loved idioms?
vcanalesover 2 years ago
I know it&#x27;s not the point, but you can generalize the input handler in the first example by using the name of the input field as a key — in most simple forms, at least:<p>```<p>const Form = () =&gt; {<p><pre><code> const [formData, setFormData] = useState({ firstName: &#x27;&#x27;, lastName: &#x27;&#x27; }); function handleChange(event) { const { target } = event; const { name, value } = target; &#x2F;&#x2F; Destructuring in steps to make it easier to figure out where values come from. setFormData({ ...formData, [name]: value }); } return ( &lt;&gt; &lt;input name=&quot;firstName&quot; value={formData.firstName} onChange={handleChange} &#x2F;&gt; &lt;input name=&quot;lastName&quot; value={formData.lastName} onChange={handleChange} &#x2F;&gt; &lt;&#x2F;&gt; )</code></pre> }<p>```
评论 #32928084 未加载
synergy20over 2 years ago
what about Vue? its html approach(instead of React&#x27;s fully JS approach) seems more beginner friendly to me as a non-frontend professional, is React (much) harder to learn relatively speaking(comparing to Vue that is)
NayamAmarsheover 2 years ago
Waiting for React Recoil to become the standard, it&#x27;s amazing!
评论 #32914011 未加载
评论 #32913112 未加载
评论 #32916379 未加载
评论 #32916407 未加载
didipover 2 years ago
It&#x27;s time to make server side HTML templating trendy again.<p>I think frontend technology took things too far.<p>Imagine the possibilities of using HTMX and any server side technologies like Elixir, Go, or Rust.
hunkinsover 2 years ago
Using an opinionated library can help with some of these issues. Personally, I love <a href="https:&#x2F;&#x2F;mantine.dev" rel="nofollow">https:&#x2F;&#x2F;mantine.dev</a>.
dmurawskyover 2 years ago
I doubt web devs would ever accept React as the de facto JavaScript framework and we definitely shouldn’t if it wants to keep evolving but most of the articles against react these days seem to be the equivalent of frat boys negging and mocking woman just because it’s the cool thing to do.<p>I’m sure there are some good points being made out there but those points Are getting lost in the noise which is a real shame.
pgambleover 2 years ago
Relatively new react developer here (still learning in fact!), I liked this article although it shook me a bit and made me wonder &quot;am I wasting time with some of this stuff? maybe I should be looking ahead to the next &#x27;best framework&#x27;&quot;. Id be interested in hearing people&#x27;s thoughts: what would be best to learn for maximum applicability in the ~3 year timeframe?
评论 #32921400 未加载
评论 #32916922 未加载
评论 #32914781 未加载
评论 #32914920 未加载
评论 #32914289 未加载
valyagolevover 2 years ago
Useless rerenders are really hard to avoid in the latest react, mostly because they changed the rerendering logic of useTransition, breaking some of the state abstractions built on top of it. Had to downgrade and started to think about using class-based components again. Hooks are very beautiful but too weird, weak and leaky as an abstraction, unfortunately
评论 #32913028 未加载
评论 #32928119 未加载
isochronousover 2 years ago
This kind of thing is exactly why my old boss went and created his own minimalist framework built around using native code: <a href="http:&#x2F;&#x2F;www.domxjs.com" rel="nofollow">http:&#x2F;&#x2F;www.domxjs.com</a>. Its explicit purpose is to allow developers to learn and utilize the platform, rather than learning a bunch of libraries.
insane_dreamerover 2 years ago
Hardly any mention of Ember in the comments. Is it no longer considered a viable alternative to React?
评论 #32919604 未加载
newbieuserover 2 years ago
I love hooks, but the main problem with hooks is that when you have a problem, you usually have to fix it in hacky ways. hooks were a revolution yes, but since the foundation was quite weak, everything they added on it unfortunately made it worse.
topspinover 2 years ago
Props to marmelab&#x27;s react-admin, and the ng-admin that preceded it.<p>If you need CRUD without adopting some &quot;low code&quot; platform and its half dozen containers full of weird databases, react-admin is a fine choice.<p>I have wondered what svelte-admin would look like.
评论 #32916257 未加载
caycepover 2 years ago
When ppl whine about Swift UI, this sort of post kinda seems to highlight that growing pains issues are perhaps similar across the board.<p>The difference is that Microsoft languages may have better ppl working on developer documentation, who knows...
tarkin2over 2 years ago
I’d argue, although this can happen with other frameworks, the high level of abstraction makes it worse with React. As soon as you’ve signed up with that ship, you’re going down with that ship.
reactive881236over 2 years ago
the fundamental issue with hooks is that it&#x27;s too hard to ensure you have access to the latest state inside the hook. why would we ever want something other than that? react has failed us.
rgloverover 2 years ago
<i>Come to the dark side, we have cooookies</i> <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick</a>
评论 #32920635 未加载
评论 #32912981 未加载
branko_dover 2 years ago
The biggest problem I have with React is that it’s not reactive.<p>And the biggest problem I have with hooks is that they make functional components non-functional.<p>This is starting to look like a pattern… :)
ralphcover 2 years ago
I have a message from the future. The JSParty podcast episode 244, recorded live but not part of their feed yet, is &quot;Is React only great at being popular?&quot;
taf2over 2 years ago
Yeah... my opinion use the DOM... it was a great invention... Mustache and JS class with async,await - really what more do we need?
bot41over 2 years ago
I just use Remix and use React in it&#x27;s simplest form. Working for me so far but it might not work for big complex apps
darepublicover 2 years ago
I use next.js with react and typescript and mostly it&#x27;s a good experience
marstallover 2 years ago
love the way this is written
ajkjkover 2 years ago
Agree with a lot of this, but, some quibbles:<p>1. yes, un&#x2F;controlled forms are messed up and need work<p>2. yes, contexts should replace Redux and Redux should go away. but in practice having a few contexts is pretty manageable. Currently we use Redux for all the dynamic state and contexts for everything else and it works pretty well. It is quite easy, also, to write your only little `useSelector()` wrapper around a non-mutating context value (ie: the context has a callback on changes, you listen and filter updates, then update a `useState` to trigger rerender)... but but maybe this a bit too abstract to actually want to do.<p>3. yes, forwardRef is silly.<p>4. yes, useEffect is kinda broken. My main issue which wasn&#x27;t discussed much here is that the difference between `useEffect(..., [])` and `useEffect(...)` is insane. The latter should not exist, or have a different name entirely.<p>Otherwise, I really don&#x27;t mind tracking deps _that much_, although I hate that it&#x27;s hard to have an effect that updates &#x27;on some local variable changes but not others&#x27;, so in practice I pretty much ignore the lint warnings all the time.<p>It all feels like &quot;there&#x27;s a DSL waiting to be written for this stuff, similar to how JSX makes createElement() more ergonomic, but it doesn&#x27;t exist yet&quot;.<p>That said, Solid doesn&#x27;t seem like the answer. Solid&#x27;s even worse: now you&#x27;re using JSX for if&#x2F;else statements, instead of the actual DSL you want that doesn&#x27;t exist yet. Good luck running a debugger on that. (Although actually, if the Solid AST ends up in the Devtools view, that&#x27;s pretty good. But still: this needs a fully-featured DSL).<p>5. +1, yeah, the continuing addition of weird hooks feels like a mistake that will eventually be regretted.<p>6. The right way to do your Inspector example is to have a parent component that decides whether it&#x27;s rendered, and a separate child which does all the event listeners. It is a bit weird to me that React doesn&#x27;t allow this to be done in one place. The closest thing is defining another component inline in the first one and then immediately rendering it. But for readability it&#x27;s best to just have two separate components.<p>7. +1 to old docs getting in the way. I&#x27;d love to see a React 2 with a new name that deletes all the class component stuff entirely so that all of the docs about it are up-to-date. I&#x27;ve been toying with trying to work on this myself.<p>8. Yeah, fuck FB<p>9. Yeah, I&#x27;m not going to any of the other frameworks either. React is great, it&#x27;s just ... not... great enough. I am in the middle of writing a series of blog posts about exactly this and I haven&#x27;t finished yet but anyway here&#x27;s the first one that I have written about why I like it so much? <a href="https:&#x2F;&#x2F;alexkritchevsky.com&#x2F;2022&#x2F;09&#x2F;17&#x2F;react.html" rel="nofollow">https:&#x2F;&#x2F;alexkritchevsky.com&#x2F;2022&#x2F;09&#x2F;17&#x2F;react.html</a>
评论 #32913876 未加载
hnuser847over 2 years ago
&gt; Dear React.js,<p>&gt; We&#x27;ve been together for almost 10 years. We&#x27;ve come a long way. But things are getting out of hand. We need to talk.<p>&gt; It&#x27;s embarrassing, I know. Nobody wants to have that conversation. So instead, I&#x27;ll say it in songs.<p>Am I the only that finds this open letter format extremely cringey? I almost didn&#x27;t want to read the article after that intro. The content was excellent otherwise.
评论 #32915902 未加载
iLoveOncallover 2 years ago
It may be due to the codebase I&#x27;m working on, but I doubt it since I assume I have decent colleagues (I&#x27;m in a FAANG), but I just fucking hate React.<p>I spent years working on Angular before changing team, and there everything makes sense instantly. It&#x27;s just normal programming, normal MVC, normal everything, and you basically only need to learn about the syntaxic sugar for data-binding and stuff like this.<p>In React it seems like they reinvented the wheel and they thought a circle was too easy so they made it in a 5 dimensional shape. You have 18 ways of doing anything and they are all deprecated, your logic and your template are mixed which turns your application into an unreadable mess, every single aspect is overengineered to death, requiring you to call useState() to have a fucking boolean that you can update, everything is stored in a variable or declared as a function instead of in classes, etc.<p>I&#x27;ll have to give a try to React from scratch where it&#x27;s not on an existing codebase, but I don&#x27;t think that&#x27;s the real issue.<p>It&#x27;s been more confusing for me to go from Angular to React than to learn a functional language after years working with imperative ones.
评论 #32914636 未加载
评论 #32918369 未加载