23 ms·

React is holding me hostage

• iredd 4y ago
  "frontend engineers"
  • scotty79 4y ago
    same as "backend engineers", "database engineers" or "ai engineers" or "data scientists" we are all just primates staring at blinking lights and poking things
    • willio58 4y ago
      Yep! I’m full stack and have no clue why some people want to say frontend engineering is “less than” backend. It’s all a means to an end. The product requires both sides equally in most cases, and neither side is trivial.
      • shadowgovt 4y ago
        If anything, what I miss from doing "backend" is the ability to just pull in whatever library I want to solve a problem. I need a web server to work by slapping together fifteen Java libraries from thirteen different code houses and writing an absolute Shoggoth of shim code to convert between their types and classes? Sure, whatever, datacenter storage is damn near free. I need to put code on a client machine on the internet? You'd best pick one of these date libraries, because there's no way in hell we're justifying shipping moment and Joda down the wire.
  • AA-BA-94-2A-56 4y ago
    Weirdest hill to die on
  • seattle_spring 4y ago
    Somewhat ironically, the absolute worst engineers I’ve ever worked with are the ones that look down on frontend as a lesser discipline.
  • happytoexplain 4y ago
    What context am I missing to interpret this comment?
  • seattle_spring 4y ago
    You've had this account for over a decade and this, a childish display of junior capability, is the pinnacle of your contributions.
    • satvikpendem 4y ago
      That is honestly hilarious, I took a look at their other comment (singular), and this person waited literally over ten years just to post this comment. Wow.
• acemarke 4y ago
  The post is excellent (and I actually got quoted in there from my "Rendering Behavior" article), but the title seems completely over-editorialized? There's not even a mention of the word "fractal" in the post.
  • nh23423fefe 4y ago
    I take fractal to mean: at all scales
    • zdragnar 4y ago
      It was likely a play on the ancient https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
  • dang 4y ago
    We've reverted the title now, in keeping with the site guideline: "Please use the original title, unless it is misleading or linkbait; don't editorialize." (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html) (Submitted title was "React is a fractal of bad design")
• rektide 4y ago
  It's exciting & unsurprising to me that state is such an unsolved problem. For the longest time React was kind of in denial to a large degree about what they were. They called themselves a View library. Hooks have definitely noticeably changed that relationship, & how people integrate app state with React, but the problem here of updating hasn't really changed all that much. It's not a new thing either. A lot of the initial resistance to React & the VDOM was that it felt like unnecessary work. Because so many frameworks at the time were working towards two-way data-binding systems, which aren't necessarily but were often associated with with smaller, precise DOM updates. HP/LG's WebOS's underlying Enyo project was one high profile would be effort here. Signals have definitely been a good re-grouping point, for reconsidering what the shape of things might look like, for trying to do a better job. I'm a bit surprised we're still operating so much at a library level regarding reactive systems/signals. JavaScript objects have quite a lot of flexibility already, and the addition of Proxies added a lot of capabilities. Faint/distanct memory, but I think Proxies were justification for killing Object.observe[1]: now users could do whatever they wanted, so we no longer needed a JS native way to see objects change. Yet, we're still very library based, rather than trying to make objects themselves better, more reactable. [1] http://web.archive.org/web/20200218195131/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe http://web.archive.org/web/20200218195131/https://developer....
  • PaulHoule 4y ago
    There is context which wages a war against debugging and testing, for one thing. React has no real answer to state going sideways. Then there is controlled/uncontrolled component which is an example of structural instability (what looks like a tiny change to your boss is a bigger deal than it should be) unless you ride the crazy train and use “plain ordinary javascript” to build a parallel system to move (some of) the state around.
    • rektide 4y ago
      One of the main reasons I was so hopeful for Object.observe was because it would have been a stable language feature to build better debuggers around. Instead, it feels like most state management libraries ultimately end of writing their own Chrome extensions. Which now that I say that makes me curious: do any of these executions also let you observe/monitor server-side state management systems?
• nathants 4y ago
  10 years with an unchanged react state model: https://reagent-project.github.io/ https://reagent-project.github.io/
  • whacked_new 4y ago
    Having used reagent, watching the React space evolve is like a bricklayer watching a constant stream of innovations around mud. Sure, you could build foundations with bricks, but why do that when you can use a fancy mold and pour mud into it? Why have clean blocks when you can have sticky, messy, dirty goop? Alas, castles and fortresses have been built with messy goop, and the amount of goop-specific tools and goop slappers far outweigh the bricklayers. So I too slap goop.
    • nathants 4y ago
      metaphor of the year!
    • shadowgovt 4y ago
      Have you seen the debugging tools for goop? I mean, they're absolutely necessary because the goop is full of insects. But so elegant!
  • nawgz 4y ago
    This kind of thing is possible because the React state model ultimately hasn't evolved too much itself; only the easily-accessible user-facing parts of it. I've been running a mobx-react setup for 7 years. It's been thru a few syntaxes but it behaves identically. Minimal rendering, observability, I find it the most intuitive state management pattern.
    • nathants 4y ago
      mobx looks the most reagent like state model in vanilla react. my forever setup is here: https://github.com/nathants/aws-gocljs https://github.com/nathants/aws-gocljs
• ARandomerDude 4y ago
  Reagent is peak React. All the good stuff without any of the hook madness and readability problems the article describes. No affiliation, happy user for years. https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent
• brigadier132 4y ago
  I missed it in the article. How do signals fix react's shortcomings? With signals you still have the same exact state management problem of having these crazy stateful functions. Sure you don't need to deal with the additional complexity brought about by use effect and rerenders but that's only a small part of the problem in my opinion. I've gotten to the point where I think frontend code should just be modeled as state machines from the start. I like XState but you can use reducers too if you like.
• willio58 4y ago
  Lovely read. I’ve been in TS and React land for a year now and it’s been so great but as our codebase grows I do see the walls closing in a bit. Signals are interesting, I wonder what react could look like if they supported them more natively in the library in the future.
• CharlieDigital 4y ago
  I've been feeling the same sentiment as the author. Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain. The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected side effect and redraw and explaining how `useMemo` and `useCallback` actually need to be used [0] and made me think of Stephen King's Langoliers. It occurred to me that "React is the new IBM" [1] It has become so dominant in the market that no one can get away from it. But that also means that it can no longer innovate. Andrew Clark's twitter post *acknowledging* that signals and fine-grained reactivity would be better for performance but that the React team doesn't care pushed me over the edge of frustration. I think that React finds itself not too far off from where IBM was at the micro-computing revolution. IBM had become too beholden to its market and too arrogant in their own success to see their own downfall. The traffic and feedback on the second article is an indication that there are a lot of folks out there who are really, really dissatisfied with the state of React. [0] https://chrlschn.medium.com/8eb7bb72c87 https://chrlschn.medium.com/8eb7bb72c87 [1] https://chrlschn.medium.com/react-is-the-new-ibm-6af2f4b04e5e https://chrlschn.medium.com/react-is-the-new-ibm-6af2f4b04e5...
  • bern4444 4y ago
    React definitely continues to innovate. Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago. The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities. Frameworks like remix and next will be able to leverage and build on this to create even better systems for building apps. The whole signals blow up event is weird to me. Seems to be a loud and extremely small minority making a fuss around it. IMO React continues to dominate over others (Vue, Svelte, Angular, Solid etc) because its just better - it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.
    • rk06 4y ago
• jrochkind1 4y ago
  A side issue, but... can anyone tell me why people say "the orange site" instead of just saying Hacker News, as if it is a bad word or a secret?
  • Stratoscope 4y ago
    They're just showing off their cleverness. It's not even orange for me. I changed the "topcolor" in my profile settings to d0c8b5 - a darker shade of the body background color. Now the only orange thing is the Y logo. Much easier on my eyes this way.
  • neongreen 4y ago
    It’s been irking me as well, so I looked up “the orange site” in HN search and apparently it’s a euphemism some people who dislike HN use on Twitter. I’d love to know who started using it first, though.
• treis 4y ago
  I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this: >Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. This is just doing it wrong. State should change in response to user inputs. Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. It's hard to blame anyone though. The docs suck and most of the tutorials you find get it wrong one way or another. That said, there's kind of a reason why functional programming isn't more popular. It can be hard to grok and there can be a significant performance overhead. There's also a reason why this sort of implicit programming isn't as popular as imperative style. It's hard to predict what the implicit behavior is and footguns abound.
  • cetra3 4y ago
    The example you highlighted as "doing it wrong" is pretty typical for an autosuggest component: Input updates trigger some request, which propagates to some list somewhere else in the dom. As it's loading, a spinner is shown, but when results are retrieved, they're updated again. Throw in apollo to the mix or some other request library, and context is used.
    • treis 4y ago
      Think you're gonna have a bad time. Should be something like: function handleChange(e){ getAutoSuggestions() setLoadingState(true) } ^ Side effects happen in response to user input function getAutoSuggestionsCallback(resp){ setSuggestions(resp) setLoadingState(false) } ^ No side effects
  • petilon 4y ago
    > Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. React is not that at all. Unless your UI is very simple, React is not f(newState) => UI. React isn't functional. More on that here: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
• shadowgovt 4y ago
  I used Angular pretty heavily before switching to React. At the end of the day, they approach the problem from two different directions, solve issues in two different ways, and end up with two different sets of challenges in terms of what's easy and what's hard in them. I've definitely written React UIs that would be easier in Angular. But I've also crashed Angular performance through the floor trying to wire up a table display with Angular update hooks. Angular makes it easier to hide state-update dependencies in a way that causes really bad thrashing to reach steady state, which I've (anecdotally, generally) found harder to do in React because doing it in React involves writing a lot more code and a lot more cross-state dependencies.
• coppertuft 4y ago
  I’ve happily used MobX for years. It comes with its own quirks but almost completely bypassed the awfully awkward state management that is React. Made my life 200% more enjoyable!
  • Rodeoclash 4y ago
    If you use Typescript, take a look at: https://mobx-keystone.js.org/ https://mobx-keystone.js.org/ It's an additional layer on top of MobX that adds strong typing. I've been using it for an open source video annotation project and it's been amazing for keeping track of local state, cascading calculations of things. Here's my "models" directory for it if you want a taste of how it works: https://github.com/Rodeoclash/vodon-player/blob/main/player/src/services/models/ https://github.com/Rodeoclash/vodon-player/blob/main/player/...
    • coppertuft 4y ago
      Thank you! If only I had been a better programmer back then I'd probably have opted for a solution like this. Instead I had worked out through the year and made some highly custom system that resulted in very similar patterns. Too ingrained in my app now to consider new options but might be a good idea to build on top of those next time around!
• ng12 4y ago
  Meh. The most important thing about React is you have to think like React wants you to. It's a very pattern-oriented type of development I haven't seen much of elsewhere. Most of the footguns listed in this article are things you obviously shouldn't want to do because they're not React-y.
  • theteapot 4y ago
    Some others would describe it as idiom-orientated.
    • ng12 4y ago
      Thanks! That's probably a better phrasing.
  • DangitBobby 4y ago
    Forms are absolutely a problem, though. Forms not being "reacty" isn't going to get you out of needing them.
    • hobofan 4y ago
      As react is only the core library and not a batteries-included framework, you will often find additional libraries that help with certain use-cases. E.g. if you are dealing with forms a lot, I would strongly suggest using react-hook-form or formik.
      • mattigames 4y ago
        If it's not batteries included if should not require people to add a huge amount of overhead to their projects to use it, stuff like JSX or create-react-app
        • hobofan 4y ago
          > create-react-app That's neither required, nor being recommended by the wider community anymore. > JSX JSX on the other hand I feel like is something that is essential to React (yes, I know that some people disagree), and one of the few things it should provide/require, as it forms a cornerstone of it's UX. Getting things set up to understand JSX/TSX has been smoothed out a lot now, and hasn't been an issue in any greenfield project I have set up in the last 2-3 years.
• rglover 4y ago
  Joystick [1] will let you go. No Stockholm syndrome. No lotion in the basket. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
• petilon 4y ago
  This is a great article on the frankenstein (neither OOP nor functional) that is hooks: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
• dre85 4y ago
  For reasons that I can't quite explain fully, I like angular much better. For me it's a shame that react won the battle and is used at every company now.
  • wildrhythms 4y ago
    For me, Angular enforces a rigidity that seems oppressive at first, but once the codebase grows in size and complexity it all makes sense. In React I might find API calls nested in component effects, setting context that gets consumed or overriden god knows where down the tree; in Angular all of the API calls and state is isolated in high level services and it's very easy to follow the logic and track where those get injected and consumed. I also find it much easier to mock a service rather than mocking contexts for testing.
  • NayamAmarshe 4y ago
    Angular seems like a step back to me. The MVC thing, while fine, introduces extra hiccups. Creating generic UI components is pretty tiring and using Angular material is pretty much your best option. Upgrading to newer versions is a pain and also finding well supported third party libraries. React is much easier to work with since you don't always need to reinvent the wheel for time consuming things. Hooks and simple state management with Jotai are also much nicer to work with than RxJs. RxJs requires a strange mental model and a lot of verbose code and functions. Angular is kinda like Java, more code for less features. Great if you don't wanna think, meh if you want something exciting and new.
• pupppet 4y ago
  Not to start an unholy flame war, but if you were to start a new project and didn’t need to worry about the ecosystem or workforce, what framework would you choose? Vue? Svelte? Something else?
  • taveras 4y ago
    SolidJS
  • ctom96 4y ago
    Svelte for me
  • runarberg 4y ago
    Honestly just use what you know. Unless your goal with the project is to learn new things or to have fun, than go with what is most interesting for you. Or if you are in a larger team, then talk to your teammates and try to get a consensus around what you are most comfortable with collectively. I only advice against using a niche framework if you suspect the project is gonna be long-lived and managed by a medium to a large team, in that case pick the one of the big ones—React, Angular, Vue, or Svelte—which your teammates can agree with.
  • FractalHQ 4y ago
    Svelte is a no-brainer here.
    • machiaweliczny 4y ago
      How’s debugging?
  • illiarian 4y ago
    Svelte or SolidJS.
  • michaelchisari 4y ago
    I'm interested in what's happening in the MPA space. The Page and View Transitions API that the chrome team is working on, partial update libraries like htmx and unpoly, etc. If payloads are tight and servers snappy, many of the concerns that led to complex SPA architectures in the first place have begun to wither away.
• pictur 4y ago
  React hooks could have been very different with very minor touches. But at this point, a structure has emerged where you need to make extra efforts to work steadily. It wasn't like that at the core of React. Class components had their own problems. But you know how to solve them. I don't think this applies to react hooks.
• andrewstuart 4y ago
  The snark is strong with this one. It's a pretty major rant, without putting forward an alternative. The only viable alternative for me personally is VueJS and that's not my cup of tea either. I like React. It makes sense mostly. Is React perfect? No. Do I like React's recent transition to focus server side? No. But the problems it addresses are tough to solve. Show me a better solution and convince me its tangibly better than React.
  • RealonDusk 4y ago
    It's reasonable to highlight issues without presenting alternatives. If a valid alternative existed, people would have moved already and this type of post wouldn't exist.
  • genuine_smiles 4y ago
    Solid.js?
    • NayamAmarshe 4y ago
      No, sorry. Not close. I like solid but accessing dom is a mess that I'd like to avoid.
• ajkjk 4y ago
  > It is not obvious that your component re-renders on state updates. I... isn't it? Isn't this like the first thing in the hooks introductory material? If you don't find this, yeah, hooks are gonna be a bad time.
  • nitwit005 4y ago
    I went and checked, and it is a bit buried at the bottom of the useState explanation when explaining what an example does: > Line 9: When the user clicks, we call setCount with a new value. React will then re-render the Example component, passing the new count value to it. https://reactjs.org/docs/hooks-state.html https://reactjs.org/docs/hooks-state.html I think they assume you'll figure out that it must do so to function at all.
    • bobthepanda 4y ago
      This has been true even in the old class components. A component always updates when props update.
      • throwaway290 4y ago
        It's about state not props. But yes state is more or less implicit props.
    • Izkata 4y ago
      I had a co-worker that assumed it worked template-style, where the value in the JSX would update and what's on the page would re-render, but the component function wouldn't be re-run.
• yashap 4y ago
  As a more backend guy who does some frontend, the main thing I like about React over alternatives like Svelte, Vue and SolidJS is React Native. React is maybe not perfect for the web, but it’s very, very good, and it’s also quite good for mobile via React Native. The more purely web-focused libs/frameworks have far inferior (or no) mobile options, while other cross-platform frameworks, like Flutter, suck on the web. Being able to use such similar concepts/knowledge for both web and mobile, with strong results in both places, that’s something React is uniquely good at (AFAIK), and a huge reason to choose it IMO.
  • Semaphor 4y ago
    People seem to say Quasar [0] (a framework on top of Vue, websites, PWAs, mobile, desktop) is great in that niche, but I can only say that their documentation looks good. [0]: https://quasar.dev/ https://quasar.dev/
    • yashap 4y ago
      Interesting, have never played around with it. Is it just a WebView on mobile, though? What I like about React/React Native is that it’s web-native components on the web, mobile-native components on mobile, so you get true native look/feel/behaviour in both places. Too many of the alternatives are WebViews on mobile, basically just a web page embedded in an app. Or they do crazy things on the web, like Flutter turning your webpage into a giant canvas. React/React Native is the only popular/mature approach I’ve seen that embraces native components on both the web and mobile, though maybe there are others?
      • Semaphor 4y ago
        > Is it just a WebView on mobile, though? Checked, yeah. Using Cordova or Capacitor. They say it looks native, though? No idea. > What I like about React/React Native is that it’s web-native components on the web, mobile-native components on mobile, so you get true native look/feel/behaviour in both places. Oh, that is cool. I never worked with anything mobile, so I didn’t know. I will read into that, not that I plan to use it, but it sounds interesting :D
• bragadiru_mafia 4y ago
  Basic react plus redux for state felt clean on the one React project I worked on years ago. Why do you need hooks and usememo? Most of this article is a rant against the react hooks project, not React itself.
• onion2k 4y ago
  Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird. I think this highlights part of the problem with React and most other frameworks - people expect too much from them. If you're delegating all of your coding skill to the framework and expecting it to just magically work no matter what dodgy code design you throw at it then you're going to build a shitty app. You have to remember that you still have to think things through, use your skills as a dev, understand what's happening and why. That is always going to be true. You're always going to have to put the work in. At the beginning of the article the author says they feel trapped by React because their previous, current, and next jobs are all going to be React based. That isn't true if they choose to put effort into learning other technologies and seeking roles that use them. If you work hard you find options open to you. Heck, they could move out of web and start writing completely different code that isn't even JS if they felt they wanted to. No one is being held hostage by React. You are only held hostage by your own fear of doing something hard. Feeling like you have to stick with React is a state of mind - you can change that with enough effort.
  • azangru 4y ago
    > I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. Isn't this the whole selling point of Solid's signals? If a child component receives its props from the parent as signals, and asks the parent to fetch some data and update the state, then the child won't rerender; only the bits that are consuming the signals will. Fine-grained reactivity, they call it.
    • k__ 4y ago
      I saw signals in Preact and I thought the same.
• fabian2k 4y ago
  It will be interesting to see whether the React Forget compiler (https://reactjs.org/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.html#react-compiler https://reactjs.org/blog/2022/06/15/react-labs-what-we-have-...) will change any of this. I'm curious how this will turn out to work, and if it will remove some of the issues that tend to confuse and annoy people. My own impression is that the core model of state and rerendering is actually quite nice and intuitive, though often explained a bit wrong. The part that makes it complex and confusing are things like callbacks, which can trigger lots of unnecessary rerendering and force quite some boilerplate if you want to avoid that. If you can remove all the stuff around trying to avoid rerendering unnecessarily, React would be a lot simpler. I also think that people are too quick to use the wrong tools for managing state in React, e.g. Context to avoid a bit of prop drilling.
• ojkelly 4y ago
  This post follows the current trend hyping up signals, but glosses over the complexity they bring. We can agree that state management is complex, no matter how it’s done. If you disagree, cool go build a database. Of all the complexities around state management, the one squarely placed at the top for me is: time. State is a variable you care about, that will change over time. Signals and Hooks/Effects present two very different approaches to the problem. They both require updating your mental model, and they both have specialised tooling. Myself, I’ve never fully grokked observables/signals—particularly in relation to a UI. They shift complexity into a location that I think makes them harder to reason about. I did take to the React approach with Components and hooks. And in my experience so did many others. I disagree with the article saying all frameworks must have signals, and I appreciate the React core team holding their ground on that. It’s healthy for the ecosystem to have frameworks built on different ideas, otherwise why build a new framework? But React, if you added signals I think you would warp it’s entire foundational paradigm.
• azangru 4y ago
  > When I build libraries for React, ironically, I don't really use hooks like useState, useReducer, etc. One of the best perks (and footguns) of managing your state outside of react is that you get to have full control over when a component should rerender. I don't understand this quote from Tanner. Aren't React hooks, like, the only way to tell a function React component (while inside of it) to re-render? And if you look at the code of, say, the useBaseQuery hook of tanstack-query, you will indeed find React's native hooks being used there [0]. 0 - https://github.com/TanStack/query/blob/main/packages/react-query/src/useBaseQuery.ts https://github.com/TanStack/query/blob/main/packages/react-q...
  • pcthrowaway 4y ago
    I really only have familiarity with React-query, but I'd guess it's something like: While of course React-query plugs into the React lifecycle, it's also kind of an escape hatch that plays nice with React. Managing the fetch function calls, their state, their resolutions, and the cache, all probably happens outside of React, but then changes to any of the query state are reflected into the React lifecycle. This probably lets him do something like using localstorage for storing cached query data, communicating between tabs, etc
• nathias 4y ago
  use svelte
• kajaktum 4y ago
  I feel like React + Redux + some kinda lens mechanism is a really good fit for UI development. Is there anything like that already?
  • ivxvm 4y ago
    > some kinda lens mechanism Does immer count? :)
    • kajaktum 4y ago
      You still have to reduce the entire state no? I would imagine it to be something like: struct A { b : B } impl Reducer<Action> for A {} impl Reducer<Action> for B {} Now the reducer logic is spread out across the state. Sure, every sub-state now need to handle Action every time but with tools like ADT and pattern matching I don't think its as bad. I feel like this will be cumbersome, but the complexity should scale linearly.
• Illniyar 4y ago
  I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for React was - 1. JSX - typing and auto-complete for components, colocation. 2. No direct dom access. (Good bye $element) Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. Luckily none of the other frameworks, even Angular, have rampant direct dom access anymore. Hooks aren't a problem in general. It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed. And it was clear from the start it'll be a pain from the limitations around it. It requires a mental model detached from everything people are used to and from other things around it. When using React I usually just use MobX and everything just works.
  • manmal 4y ago
    What’s the alternative to useEffect? I need it very often.
    • redbar0n 4y ago
      you could try XState events, see David's "Goodbye useEffect" talk: https://www.youtube.com/watch?v=bGzanfKVFeU https://www.youtube.com/watch?v=bGzanfKVFeU or you could try the newfound craze: signals.
  • thegeomaster 4y ago
    How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard it, and why the modern webapp experience is so miserable for the average person.
• college_physics 4y ago
  There is this niche movement that argues that good code should be very long lived. It should solve problems in a fundamentally efficient way that makes it hard to turn into obsolete and throwaway code. There are not many examples of such code bases. Maybe numerical algebra libraries come close. Reading through the comments it seems that providing (fairly basic by now) UI functionality on cross-platform basis has not matured to the point of providing a stable paradigm. Given how many people and for how long have been banging on this problem it feels a bit strange. Surely people can find better use for their time and energy than churning through half-baked frameworks?
  • awesomegoat_com 4y ago
    Incentives. One has to ride (and eventually) create trends to sell.
  • HeavyFeather 4y ago
    > Surely people can find better use for their time and energy than churning through half-baked frameworks? We should have all stayed on backbone or Prototype.js with that logic. People look for alternatives because the status quo is awful (slow, verbose, footgunful). You’re saying “who needs cars when we got horses? Cars break down all the time”
    • college_physics 4y ago
      No, when you mention js libraries you are already starting the clock way too late. The UI problem is not new. People were already building clunky UI cars long ago. MFC was introduced by Microsoft in 1992. Of course the emergence of the web platform and mobile/touch devices complicates the matter as you now have a proliferation of platforms to address (desktop native, desktop web, mobile native, mobile web) but my argument is that fundamental patterns on how to do this efficiently should have emerged by now - and I see exactly the opposite. It would be nice to see some sort of convergence. Reinventing the wheel might be "fun" or gainful in a narrow sense but it certainly doesn't help with productivity.
      • 4y ago
• askonomm 4y ago
  I quite like React. When used from ClojureScript via a Reagent library and using Re-frame for state management.
• ivxvm 4y ago
  What a nice idea it was to scroll immediately and figure out this is another bullshit reactive programming evangelism blogpost. Bro, we've already had this shit in JS like 20 years ago (Flapjax anyone?). Now go on and write your code like this for at least few weeks and see how great and maintainable and "fine-grained" it becomes.
• activitypea 4y ago
  ``` The quickest obstacle you’ll run into as someone new to React will be something like this function MyComponent() { const [num, setNumber] = useState(42); // infinite loop setNumber(n => n + 1); return <div>{num}</div> } Trying to make state updates at the top level of a component will result in an infinite loop. ``` I've taught React to dozens of people without ever seeing someone try this. A render function is an idempotent function that produces UI for a given state, and it's called every time the state changes. What are you, semantically, trying to do by updating state midway through a render function? This isn't a footgun, this is the author picking up a screwdriver and going "I wonder what happens if I press it against my eyeball"
  • pas 4y ago
    This is because people forget that React is still a only "view" library with the M and C sprinkled all over with meathooks. ¯\_(ツ)_/¯
    • activitypea 4y ago
      React doesn't map to the MVC paradigm at all, though.
  • zelphirkalt 4y ago
    I like the mental picture of the comparison. Consider, that you might have taught a boased selection of people, and that others might not be so diligent to have read the docs and actually thought about it in depth to also understand it ; )
    • activitypea 4y ago
      The idea of pure functions deriving UI from state is the single central idea of React's worldview. The docs work extra hard to get this model of apps into your brain. This is not the same thing as people being elitist about Git, this is refusing to engage with the design of the framework and blaming the framework. I like how you say "others might not be so diligent to have read the docs"... As opposed to? Picking up a UI framework and just winging your way through LSP autocompletions until something happens on your screen?
• fidgewidge 4y ago
  Good, he should rant! > What would framework-integrated fine-grained reactivity look like? Probably something like Solid.js It would look like JavaFX which has had this exact approach since it launched over 10 years ago as well as a large library of observable operators and collections complete with delta events, the ability to define components with a "shadow DOM", with custom CSS properties, using both JSX-like widget-oriented markup and code, and a whole heap of other things the web community has since slowly rediscovered. Here's the high level observable operators API (there is a lower level one that lets you define custom operators): https://openjfx.io/javadoc/19/javafx.base/javafx/beans/binding/Bindings.html https://openjfx.io/javadoc/19/javafx.base/javafx/beans/bindi... And here's the author's Solid.js example in Kotlin with FX: class Counter : Label() { private val count = SimpleIntegerProperty(0) init { textProperty().bind(concat("Counter: ", count)) timer(period = 1000L) { runLater { count.value++ } } } } You could also write that in many other languages like Clojure (with cljfx for FP fans), Python, Ruby, JavaScript, and of course Java. It would be less verbose if I used a library that better used Kotlin's features, but the goal here is that you can look up the APIs from the link above (there are a couple of implied static imports). So not much different, but it demonstrates how the text property of the label is bound to a dynamically computed string which is in turn bound to an observable number. When the timer fires, the count increases and the label is recomputed. Everything is done that way so layout computations, for example, won't run unless the size of the label changes. And that's it - no need for VDOMs or prop drilling or state memoization or any of these other performance hacks. At some point you'll observe that this seems a lot like "reactive programming" as used on the server side, and then might want to explore a library like ReactFX which connects these two worlds together. https://github.com/TomasMikula/ReactFX https://github.com/TomasMikula/ReactFX There are some other nice features in this type of toolkit that the web community seems to be heading towards. I'd be willing to bet a lot that at some point they'll even reinvent inheritance under a new name, because being able to write code that's generic over component trees is really pretty useful. The hooks/functions model totally wrecks that and has led to this explosion of "design systems" (otherwise known as themes that bundle half a widget toolkit), none of which interoperate properly or can be coded against in an abstracted manner. None of this is to say that FX is perfect or that React/SolidJS etc are the wrong tools to use. You can run FX apps in a browser using a form of server side rendering - check out https://www.jpro.one https://www.jpro.one to see a fully crawlable website that's actually implemented using JavaFX on the server with no frontend/backend split existing at all. But it only works well if you don't have a fast and reliable server connection, plus a server with plenty of RAM and CPU. Alas browsers pull all sorts of mean tricks to keep people locked inside the HTML5 sandbox so JS frameworks aren't going anywhere, but it would be nice if that community spread its wings a bit and looked at prior art from outside their language. GUIs are old and the challenges involved in them aren't new, and from the outside it looks suspiciously like there is no real progress being made here, only wheel spinning.
• Lapsa 4y ago
  `Perhaps this is why React makes such a good choice for non-web renderers` yeah I 'member using some kind of terminal react thingy. quite joyful
  • HeavyFeather 4y ago
    You’re probably referring to https://github.com/vadimdemedes/ink https://github.com/vadimdemedes/ink
• Kiro 4y ago
  > On every key stroke we have now rerun toTitleCase in every component. In game dev you run millions or even billions of computations 60 times a second. If running toTitleCase three times every key stroke is an example of a compounding performance problem in React then surely the problem must lie deeper.
• snowstormsun 4y ago
  It's a bit frustrating how difficult it is to find out the old value of a dependency of a React useEffect hook: https://stackoverflow.com/questions/73399384/how-to-get-and-compare-previous-state-value-with-a-new-value-inside-useeffect https://stackoverflow.com/questions/73399384/how-to-get-and-... Back with components, it was trivial to compare old and new values and change the state based on that.
  • Sammi 4y ago
    I was super interested in hooks when they first came out. But after a short honeymoon period I noticed all the complex rules, exceptions, caveats, and footguns, and I wondered how the React team ever thought this was something you could put into the hands on new developers and expect them to not run into trouble. It reminds me of teachers who have been teaching so long that they don't understand what it's like to be new to the subject any more. It's called The Curse of Knowledge cognitive bias: https://en.wikipedia.org/wiki/Curse_of_knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge
• Accacin 4y ago
  The whole thing around React is odd to me. People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead. I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people, and if there's an issue you can be fairly sure that someone else out there has had an issue too and there's a solution to be found. I'm not in a hurry to replace React, but I don't need to. React is stable enough to rely on in my honest opinion.
  • tomgp 4y ago
    My position isn't that we should be using a new library per se. It's that we should be more selective about what 3rd party code we use and espescially what we ship to end users. React has tended towards a kitchen sink approach and this is exacerbated by initial design shortcomings/decisions i.e. no built in state management or method for encapsulating styles has lead to a deluge of libraries that promise to fill the gaps, none of which quite work with one another. This I guess is why we've seen the rise of meta-frameworks like Next which fill this gaps in a predictable way. But these just meta frameworks just shift developers another step further from the underlying HTML/CSS/JS making it harder to debug things and harder to fix issues when you stray from the framework's happy path. (All that said, I don't blame people for choosing React for certain classes of projects, the economics of hiring new devs, the relative maturity and stability , the large community etc all make for powerful incentives to choose React)
    • quest88 4y ago
      Wait react is a kitchen sink approach but in the same breath you said it doesn't come with everything. Do you mean tended away?
      • tomgp 4y ago
        Sorry, reading this back I see where that might be confusing. It's a few days later now but I think I was referring to React in the round as deployed in the real world, the community norms etc. rather than just the core library. In my experience the way that React projects tend to develop is that "tried and tested" libraries get added to to solve particular issues, most commonly state and styling (codified in meta-frameorks like NextJS etc.) but also UI transitions, wrappers around common non-react libraries like Leaflet or threeJS etc. The reason being that it's actually quite hard to sensibly integrate vanila JS libraries into a React code base so if someone has done the hard work why would you not use that. But of course this comes at a cost. More recent libraries (in my experience svelte but i understand this is a common feature) mitigate the issue by 1. having a builtin approach to state and styling 2. making it easier to drop down to the underlying HTML/CSS/JS without making a mess.
• boredumb 4y ago
  A simple server side template render is more than enough than 99.99% of SPA apps need for a fraction of the complexity, bandwidth or brainpower spent minding performance.
• scotty79 4y ago
  > Frameworks like Preact, Vue, Angular, Marko, Solid, and Svelte have all adopted some form of fine-grained reactivity. They’re called signals, stores, or observables. The semantic differences might be important, but I’m going to refer to the concept as a signal. I would call this concept noodle. Because when there's a lot of them you get back your tasty spaghetti. The whole reason for React was avoiding it whenever possible.
• fullstackchris 4y ago
  I don't understand the animosity around useEffect. It executes a function based on a list of dependent variables. That's it. Once you understand that, its purpose becomes very clear. You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables! You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you use and you should go back to UI development 101. Bottom line: if you write clean code and are aware exactly of what your local state / redux variables are (or whatever state management you are using), you should never have a problem with too many rerenders. I've been writing React for 6+ years now and have NEVER had to reach for useMemo or useCallback.
  • wildrhythms 4y ago
    I agree, and I'd like an anti-hooks person to explain their thoughts a bit more. My impression is that they believe useEffect inclines devs to cause side-effects in the component, quickly making the logic of a component difficult to follow- for example, a useEffect that sets a state that kicks off another useEffect that sets another state that kicks off another useEffect... But this problem existed before hooks: old school React devs will remember the days of class-based components with humongous componentDidUpdate methods peppered with calls to this.setState(...) that did the same thing. My own impression is that hooks offer better lifecycle controls overall, with the side effect (heh..) of handing devs an arsenal of footguns that will inevitably go off if they don't fully understand the hooks or where to use them or how React detects and triggers a re-render. So in a way I agree with the author of the original article here, but in the sense that React devs should probably not use hooks until they understand how re-renders happen and why to avoid that and only then should they be handed one footgun at a time.
    • rk06 4y ago
      My problem with hooks isn't the philosophy but the ergonomics and footguns it creates. Compare that with Vue composition api, and you can see how idea of hooks can be implemented much better[0] [0] https://vuejs.org/guide/extras/composition-api-faq.html#comparison-with-react-hooks https://vuejs.org/guide/extras/composition-api-faq.html#comp...
• MrPatan 4y ago
  Don't fetch data from your views! React enables v=f(s) by making DOM updates faster. v=f(s) was always a good idea, but before vDOM, replacing the HTML of the page on every little state change was too much for the browser. - Now you describe your views as pure functions of their inputs and stop caring about them, React cares about them. You know that with the right s, the right v will follow. - You need to care and manage your app's state carefully, yes, and everything goes in there. Fortunately, patterns and frameworks like Redux make it releatively straightforward to do this. You can still make a mess, sure, and make mistakes, etc, of course. No silver bullet. But you can now deal with those two separately. If you start fetching data from your components directly you're back in jQuery hell with extra steps.
• sonicgear1 4y ago
  Anyone trying to justify the usage of React is just suffering from Stockholm Syndrome at this point.
• thih9 4y ago
  > I recently read someone’s astonishment at how smoothly the React ecosystem’s transition to Hooks was - how everyone was unilaterally in agreement on its benefit. This is not the past I remember. I remember quite a bit of a contention. Particularly on the orange site, but not exclusive to it. Does anyone have a source?
• NohatCoder 4y ago
  Meanwhile us Vanilla.js'ers are still wondering exactly what a front-end framework does for a site that displays some text and some images. It seems like the framework culture is driven by the search for a silver bullet that makes problems go away. But each solution to a problem always comes with its own set of problems, only these problems are initially unknown. So you trade a set of known problems for a set of unknown ones. It is possible that these new problems are lesser problems, but this is hard to verify upfront, and the nature of being unknown makes it a lot harder to deal with them preemptively. So anyway, you have your framework, you have used it for a while, and you have learned about the previously unknown problems that it causes. You could rejoice that you now have this knowledge, and therefore have a reasonable shot at working around the problems. But instead you ditch your imperfect framework and search for a new one, beginning the cycle anew.
• iandanforth 4y ago
  In case you're feeling alone. I detest hooks and I'm glad I was able to get out of front-end dev before they became wide-spread. I loved react at first with class components and its friendly lifecycle. It was designed to be understandable and self-documenting. It was a pleasure to write self-contained components. The move to function components, redux, and hooks stripped all of that away. I'm glad others have found value in the evolution of react, but it always felt like watching a tragedy from the outside as the newest Abramov idea seeped through the ecosystem.
  • wildrhythms 4y ago
    You say you detest hooks, but didn't elaborate why. Can you explain more? Is it just a preference for the class-based model of overriding lifecycle methods?
    • kybernetikos 4y ago
      I don't know about the GP, but hooks are fundamentally an attempt to stick a state managing effects system into a language that is designed to use objects to manage state. This gives you something approximating the worst of both worlds - your 'functional' components are not pure, and the effect management system is something you have to deeply understand to use correctly, but it clashes with the rest of the language.
• nathell 4y ago
  I've been mostly using React from ClojureScript, via reagent and re-frame. I've mostly avoided the hype of hooks, except in interop where they've been a pain. And I second the sentiment of Mike Thompson, who says [0]: > Humans have a cognitive bias: "what is focal is presumed causal". > Political leaders know this. They like presenting good news themselves because they like to be "seen" as causal of good stuff, but they'll get a press secretary to deliver bad news. Movie directors know how to use this when framing their protagonists within the story. > Unfortunately, the React team have lost themselves in this bias. They keep trying to make the most focal part of the system (components) also be the causal part. Please stop doing that! It is a mistake. Events are what's causal - they embody the user's intent. > Just to be clear, I love React. What an utterly brilliant idea and great execution. I'm deeply grateful because, wow!, did it change things. It is just that I preferred React when it was only trying to be the V part of MVC. Everything since has been downhill. [0]: https://day8.github.io/re-frame/FAQs/LoadOnMount/#why-this-difference https://day8.github.io/re-frame/FAQs/LoadOnMount/#why-this-d...
• hyfgfh 4y ago
  I have been using react since 2015, hooks for the most part seems like a miss. I use sometimes, but for the most part is overused feature. I think thats a symptom of a problem with the front end community, people get too attached to the new thing and try to make it the standard instead of building something stable and concise. Im tired to having to rewrite a code because one library that I had to upgrade decided to migrate to the "new thing"
  • matsemann 4y ago
    The composability of hooks, which was one of it main selling points, is also my main gripe with them now. I often have to wade through multiple levels of hooks to figure out what's really going on. And using it professionally for years now, there's still some cases I can't wrap my head around. And the mental model is just a bit "off". Like, the same function is ran multiple times, but with different behavior (like a useState only uses the parameter the first time the function is ran) which is very unclean.
• jongjong 4y ago
  I never understood why React became so popular. I thought it was a kind of mass hysteria. I was exposed to a broad range of front end frameworks early in my career (Backbone, SproutCore, JavaScriptMVC/CanJS, AngularJS), one of my colleagues was experimenting with Google's PolymerJS and recommended it. After trying it out, I was blown away by its elegance and simplicity. Yet somehow it never caught on. When React came out, people jumped on the bandwagon en mass; most of them had never even heard of Polymer. React had some obvious red flags; it seemed unwise to re-render entire components each time and regenerate the DOM instead of trying to work with it; it's a hack. It's not difficult to think of scenarios were it fails; for example think of what happens to an element's scroll bar after it has been re-rendered from scratch; it resets... Yet people kept coming up with workaround after workaround to all these kinds of issues. If they had tried PolymerJS (which was going for a native Web Components approach and interfaced nicely with the DOM instead of bypassing it), they would have questioned React's merits. When the useEffects hook was introduced in React, to me, that was a vindication of Polymer's stance (which it had figured out years earlier) that you couldn't completely pretend that DOM elements don't exist, yet React's solution was not as elegant as Polymer's as it was tacked on as an afterthought rather than as a carefully thought out design decision. Nowadays, with native Web Components (HTMLElement) in most browsers, I don't see why people would still start projects with React, especially given the massive number of dependencies it typically introduces and how often they keep changing stuff and breaking compatibility. They promised a simple component library which would be the answer to our prayers. What we got instead is a 7 year religious pilgrimage which involved a million developers simultaneously trying to make sense of it; attempting to discover its true form by inventing abstraction upon abstraction and growing increasingly fanatical as it devolved into a wicked monstrosity which should have brought the wiser among us to our knees, begging for JQuery.
  • TheMagicHorsey 4y ago
    I'm with you on this.
  • bsenftner 4y ago
    I totally agree.
  • 4y ago
• crabmusket 4y ago
  As someone who has used Vue full time for the past... going on 7 years, and before that used a probably-little-remembered framework called Mercury,* I feel like I'm missing something. I wonder how many of the issues people have with React are due to it not being built on a state management library - like Vue is, and Mercury was. The rendering is whatever. Templates, JSX, it doesn't really matter. Mercury used hyperscript and we got by just fine. But state management is critical, and React seems to leave it completely up to you. Vue added a hooks-like API. While I haven't used it in anger, I've toyed with it. And it sidesteps some of the weird React hooks caveats... because of Vue's reactivity system. Huh. *With a brief interlude using the original Angular, which I did not understand then and still do not understand looking back from today.
• gg2222 4y ago
  Nice to see Solid JS mentioned in the article. Its mental model is sooo much simpler than React. It's a joy to use. I'm lucky that I am an independent developer so I can choose to use Solid JS in my projects. React has so many gotchas and they keep changing the 'best practices' I can't believe people still stick with it.
• ripperdoc 4y ago
  Is there a good, complex and open source React app that shows how it "should be done"?
• ughitsaaron 4y ago
  At first, it felt to me that the broad stroke criticism of React expressed in this post was of the very familiar type that’s been around prob sky since it’s first release: that React should be more than what it’s ever intended to be, which is a library that outputs UI as a function of state (input via props). By offloading the responsibility for all the rest of it, e.g. managing state, remote fetching, etc. onto the person implementing it, React has always left a lot of room for frustration and poor decisions. But I think the criticism here is a bit sharper and more pointed than that. The author isn’t expecting Reach to do something for which it was never intended, I think. Instead, they’re saying that the abstractions (hooks in particular) that have evolved over time expose unhelpful interfaces that either conceals too much information, encourage poor patterns that lead to bugs, inefficiencies, etc. In other words, the criticism isn’t of React’s explicit decision to offload responsibility outside the scope of outputting UI, but rather that it’s evolved to make handling of those responsibilities more challenging. I think that’s a bit more serious than the former critics and worth at least considering. For my part, I’ve found little substantive advantage to hooks and do think they hide a lot of bugs by making implicit things that should probably be (and, once upon a time, were) more explicit.
  • psychphysic 4y ago
    How can performance not be considered ergonomic? Having to write optimized code usually makes dev ergonomics the first casualty. Like the famous Haskell qsort. Every beginner sees a cute version that should never see the light of a production environment
• ajani 4y ago
  I can't help but sigh exhaustedly. There was a moment in time angular was the thing. And then x. And another. And React. The problem each of them tried to solve, and continue to try to solve is purely lexical in the end. It's about writing things differently. Creating abstractions (terms) beyond what the underlying language/platform allows you to do. And this is not a bad thing. The solution really is to create your own language so you can express the problem you are solving in the terms of the problem and not the underlying language/platform/hardware. And then I sigh again... aah but if only Common Lisp and it's macros were the underlying platform.
  • giovannibonetti 4y ago
    > The solution really is to create your own language so you can express the problem you are solving in the terms of the problem and not the underlying language/platform/hardware. That's what Elm is about. I've talked about it in another thread, so I won't repeat myself here.
    • ajani 4y ago
      I had heard of it, but never checked until you mentioned it in this context. It seems that Elm is an entirely new language written atop JS (or maybe not, and targets JS?). A DSL. DSLs also usually are an incomplete solution. Unless they themselves allow adhoc language creation using the DSL as a base. Common Lisp with its macros allows writing DSLs quite off-handedly as you program. You grow your program and language together as you get deeper into your problem.
      • giovannibonetti 4y ago
        Elm is an entirely new language that compiles to JS, it is not a DSL.
• exabrial 4y ago
  Can we please just leave SPAs in general? POST/Redirect is beautiful. It’s fast. It’s simple. It’s low maintenance.
• sgbeal 4y ago
  This quote from the article somehow justifies my continued willful ignorance of React: > It’s just abstractly funny to watch the ecosystem of a UI renderer work so tirelessly to keep using it while avoiding every part of it.
• bsenftner 4y ago
  You all will hate this: I've been a pro coder for 44 years, at a high level. I was an early Assembly programmer on the pre-release Mac in '83, a 3D graphics researcher during most of the 80's, OS developer for 3D0 & the first PlayStation, and quite a bit more. I have over 40 high profile commercial applications published. I think React creates needless complexity. The software I write is complex by it's nature, I do not need the software I create my application within to exponentially increase that complexity. React does not just let one write code and create one's application, React dictates how the code is written, and if that does not fit with one's application structure you must change it. And React developers cannot wrap their heads around anything other than React's dictated way to write React, so... they are useless. So, what do I use: nothing. I just write html/css with direct DOM access via js, very minimally. Dicking around with the web page is the least priority of the applications I write, and the freedom to create the application structure as the purpose of the application dictates is far more important to my clients. Plus, I do not write consumer click bait vehicle software, I write software for people to accomplish things, typically complex things of the nature an engineer, designer, or architect would use.
• TheMagicHorsey 4y ago
  I came from the video game world. I used to program for the Playstation 1 and 2. For me, all these reactive frameworks are baffling. Is it weird that I just prefer immediate mode UIs and roll my own state management and "reactivity" on a project by project basis? I may be wrong here, or it could be my age showing, but I feel like explicit UI systems like that might be more verbose, but I find them more accessible to dive into and less "magic". I'm totally lost and baffled by everyone's enthusiasm for these increasingly arcane and complex abstractions. I suppose they are necessities that arise when you reach a scale that I have not yet encountered (I work on small to medium sized teams of a dozen or dozens rather than hundreds of programmers).
• K5EiS 4y ago
  Can't say I relate to this, interesting perspective nonetheless. This line however "It is not obvious that your component re-renders on state updates." is kinda strange, maybe it's not obvious if you didn't read any documentation or tutorial? also "You could build your own framework in an hour using reactive primitives [...]" is the same as when people say "just make your own sorting algoritm", yeah sure you can get the exact behaviour you want, but come on.
• giovannibonetti 4y ago
  One alternative is the Model-View-Update framework developed in the Elm language [1]. A few years ago, it influenced Redux [2], but JS doesn't have good ergonomics to support it, so people complained it was too verbose. Anyway, I brought Elm to the company I worked at two jobs ago, and it worked very well, since it is conceptually very simple. The experienced developers loved its explicitness, which made it possible to build a very intricate app from just a few dependencies, which in turn allowed the company to have a very fine-grained control of the UI, and the customers loved the result. On the other hand, other less experienced developers didn't like Elm so much because React allows you to write your app with fewer lines of code. The article from this discussion explains well that React (especially with hooks) hides complexity, which bites people later. At that time, it is perhaps too late to switch to something else. Needless to say, I haven't been able to convince any other employer to use Elm, and then I see issues popping out all the time that would never happen with it. Such a waste, just because people like shiny toys and just follow what others around them are doing without thinking too much. [1] https://elm-lang.org/ https://elm-lang.org/ [2] https://redux.js.org/understanding/history-and-design/prior-art https://redux.js.org/understanding/history-and-design/prior-...
  • iudqnolq 4y ago
    I'd love to use Elm, but I'm completely uninterested in building off something where low-level hacks are impossible. For example, I recently wrote a react component that diffs it's new state against the previous state and then calls an imperative map API to bring it into alignment. Ideal, no. But I'm not going to wait for the compiler devs to do something perfect before I write this app.
• turbobooster 4y ago
  Glad most people here are agreeing to move to SvelteKit
• dcchambers 4y ago
  It seems like the pendulum of public sentiment around react is swinging the other way. I see more and more criticisms of react every day.
• slmjkdbtl 4y ago
  React is the most "framework" framework out there especially when hook come out, it completely dictates you how you write your program, and it's very easy to go into traps if you don't know how hooks are implemented. I'd much rather use a reactive UI framework like Solid because they use a much simpler concept
• nottorp 4y ago
  I wonder... Why the modern obsession with hiding the underlying state machine with callbacks? To prevent devs from seeing the bigger picture?
• mbrochh 4y ago
  I don't know. The guy just doesn't like hooks? I think hooks are absolutely amazing. I'm in charge of a very large codebase. We are currently migrating it from CRA to Remix, about 40% done. When I compare my Remix code with the old code, it's EVEN BETTER than the old stuff. Despite the gigantic codebase, I am always able to figure out what is going on (thanks to hooks, just read the function from top to bottom), where the data comes from, where it goes to. It's just all around a good developer experience. I have a feeling this guy just yearns back to simpler days where websites where static HTML & CSS. I have also been able to consistently hire absolute greenhorns right out of tech bootcamps with zero formal computer science training and they were able to build features that made our company real money and push to production within the first two weeks. React can't be that bad. Now that we threw out react-hook-forms (Remix does it all fine with default form APIs), Apollo (don't need their caching any more, so just sending plain GQL requests via fetch does the job), Redux (Context API is just fine), emotion (TailwindCSS is so so so so so much better)... our Remix codebase is basically pure HTML and Tailwind's css classes. It's a bliss.
• phendrenad2 4y ago
  Good to see that a Vue vs React religious war is happening here in the comments. And here I thought tech was becoming a monoculture!
• vaughan 4y ago
  There is way too much local ad-hoc state in modern web apps. (Ad-hoc as opposed to persisted state.) The first example of UI frameworks is always the `counter`, but it's always the least realistic scenario you encounter. Almost every app involves retrieving state over the network, sharing state in multiple places in the app, and how this state is CRUDed. The reality is that all state is very interconnected. Ideally you want fine-grained reactivity for every rendered UI element, that ultimately reacts to the changes in a database in the cloud. And every piece of state should ideally be persisted. Even things like dropdown menus and their state. The simple solution to all this is to store all state/data in a single database on the client. Every time you render something from the database, a component should have its own "view model". And this view model should react to changes in the database. This "view model" also shouldn't be hidden inside components. There should be one place where you can view all the view models throughout your code. And see the interconnectedness. In a visual way too. Maybe we went off-track when we started to merge the view/model/controller in the same file. We create hierachies of views, and then they need to get their data from this view hierarhcy. But instead they should be getting their data from a central database in as few transformations as possible. The mistake people make is trying to make components isolated and decoupled from the rest of the app as a principle. It sounds nice, in that when you work on a single component, you only have to worry about what props are being passed to it. What makes apps complex though is data transformations. Ideally you want data to be as close in shape to the underlying dataset as possible. Otherwise caching/memoizing becomes very difficult, and this is usually the cause of many performance issues.
• rhaway84773 4y ago
  I have a few problems with React hooks. 1. I’m not sure what they have in common with each other. What exactly is a React hook. Nearly every hook is its own thing, with its own purpose, use, etc. With the new “use” hook, even the original hooks rules don’t apply anymore. 2. Related to the above, every hook is an entirely new concept. Learning react you would think once you learn “hooks” you will be able to understand basically what they did. Much like once I learn “classes” or “functions” I can figure out what they are. But every hook is its own concept, with its own rules, and gotchas, etc. Sometimes I wonder if the reason they’re called hooks is to present them as a single Concept, otherwise it would be too obvious that React replaced a few concepts, state, and component lifecycle, with about 3-5 concepts in the library in the early versions, and many more now, with an infinite possibility of concepts through custom hooks. 3. No one in the React world seems to have a clear mental model of what hooks are. useEffect is the most egregious here, but the name (and the original React docs) indicated it was for side-effects. But then it’s also used for lifecycle management. Finally, it appears that now the React devs have started pushing the idea that it’s to keep “components in sync with an external system”. And useEffect is probably the most used hook outside useState. To be fair, usually descriptions of concepts can change with time. But with useEffect it’s not just the description that’s changing. It’s the entire mental model, which makes it seem that the React devs themselves are not clear what useEffect is supposed to be. Fundamentally, hooks seem to be a bunch of ad-hoc solutions that React devs use to solve specific problems they notice in the wild. But there doesn’t appear to be any fundamental consistency to what they really are.
• mcv 4y ago
  How are you being held hostage? I'm currently using React, but I've used a lot of other frameworks in the past, and expect I'll be using a lot more in the future (Svelte is currently topping my list of frameworks to check out). I started out in these sort of frameworks doing Angular 1 in 2013. Did a lot more Angular 1 projects in those years, and really got to know the intricacies of the framework. Was ready to switch to Angular 2, but instead I ended up doing some native JS web components, a little React, then some Vue, and now some serious React. I've got to say, I liked the little React a lot more than the serious React. All those useEffects everywhere don't make the code any more readable. There's layers upon layers upon layers of components and abstractions and layers in between. It comes across as less organised than my old Angular 1 or Vue code did, though that's probably also due to the size of the code. Anyway, I'm not being held hostage by anyone. Next project I hope to be doing something in Svelte, but maybe I'll end up doing something completely different. Maybe some Kotlin? I still haven't used that.