31 ms·

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

• koplenov 4y ago
  [dead]
• recursivedoubts 4y ago
  > What's next for us? You tell me. I'm gonna say something crazy here, but hang with me: hypermedia.
  • nsonha 4y ago
    didn't it fail like 20 years ago, why do you think it'll succeed now?
    • recursivedoubts 4y ago
      unfortunately HTML didn't make any significant progress as a hypermedia for a decade and a half, but some folks (myself included) are trying to fix that (unpoly, htmx, hotwire, etc.) an enhanced hypermedia model offers a lot more interactivity often at a fraction of the complexity, and w/ the benefits of the REST-ful architecture (flexibility, etc.)
      • nsonha 4y ago
        to draw a desktop app analogy, I guess these things need a back-end as a GUI application that has to deal with all the presentation logic, and thin client that remote desktop to that. While the current SPA model would be RPC with fat clients, your call.
• deleted 4y ago
  [deleted]
• ch_sm 4y ago
  I think the title is a reference to this wonderful song by LCD Soundsystem: https://www.youtube.com/watch?v=-eohHwsplvY https://www.youtube.com/watch?v=-eohHwsplvY
  • fzaninotto 4y ago
    OP here. I'm glad at least one reader noticed that. You're my hero! By the way, all section titles in this article are song or album titles.
    • deleted 4y ago
      [deleted]
  • spartanatreyu 4y ago
    How did you manage to share the song without also sharing that amazing mashup? One of those rare exceptions, where overlaying another song improves the original: https://www.youtube.com/watch?v=huEtJw7pfLk https://www.youtube.com/watch?v=huEtJw7pfLk
• qprofyeh 4y ago
  One could argue that it's not that React can't handle increasingly complex situations for you and that'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's healthy to retrospect how we got to this breeding site, yet there's always a certain doubt or even bias that what brought us here today is not what takes us forward tomorrow. It's like the reverse of Shiny Object Syndrome. In time, I believe React can still take us forward.
  • ravenstine 4y ago
    What React does is no longer novel. People have both cloned React and have made other libraries/frameworks that accomplish the same thing differently or even faster in some cases. Frontend craft has also become too complex in general. We really need to step back and decide whether all this fucking shit around SPA, SSR, route splitting, transpiling, everything-as-a-type, "me too" features between frameworks, overemphasis on trendy designs, package managers that wrap around other package managers, REST or GraphQL or RPC, etc. etc. etc. Much of which serves mostly to create corporate careers for developers more than to actually serve users. React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation or jQuery, and it's simple enough that it doesn't come with the same baggage as Vue, Angular, Ember, and so on. Even if React itself were to fade, the institution that is React I think will continue on for the foreseeable future.
    • ThalesX 4y ago
      > Much of which serves mostly to create corporate careers for developers than to actually serve users. I'm a developer that's done with this, but it brings in VC money so in my experience it serves mostly to create opportunities for CEOs to get some more money on the table via buzzword pitches.
    • azangru 4y ago
      > React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation There was recently a demo of what a Todo MVC app might look like if written in vanilla JS with today's apis. It looks fairly decent; I could see myself going back to something like that: https://frontendmasters.com/blog/vanilla-javascript-todomvc/ https://frontendmasters.com/blog/vanilla-javascript-todomvc/
• fabian2k 4y 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't do a job well it was never meant to do. The part about the Inspector component and the rules of hooks I don'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.
  • lghh 4y ago
    While I agree that the intent of Context isn't state management, but its functionality in practice is nearly identical to state management. I know and agree this has been discussed to death, so please be patient while I beat this long-dead horse. In the beta React docs, Context is described as: "Context lets the parent component make some information available to any component in the tree below it—no matter how deep—without passing it explicitly through props." [1] In the docs prior to that, they go over how to use the useState hook to manage state [2]. In the paragraphs immediatly following, they describe how to drill props to pass that state around to child components and how to lift it up so it is easier to share [3]. So, while Context may not explicitly be about state management, it's positioned as a way to make managing state via prop drilling much easier. It's easy to see how someone new to React would come to the conclusion that Context is about state management. The React beta docs all but say so. If the React team doesn't want developers to think about Context as state management, they should not implicitly position it as state management. [1] - https://beta.reactjs.org/learn/passing-data-deeply-with-context https://beta.reactjs.org/learn/passing-data-deeply-with-cont... [2] - https://beta.reactjs.org/learn#updating-the-screen https://beta.reactjs.org/learn#updating-the-screen [3] - https://beta.reactjs.org/learn#sharing-data-between-components https://beta.reactjs.org/learn#sharing-data-between-componen...
    • fabian2k 4y ago
• geewee 4y ago
  Can definitely agree with his pain point about forms. I'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'm looking for (and I've seen the page before), I often can't find it.
  • nsonha 4y ago
    this is an unpopular opinion, most people including myself would say the opposite. react-hook-forms seems pretty natural and closer to html form & plain javascript, while Formik is (was?) this bizzare thing that forces jsx and controlled inputs upon us devs.
    • nightpool 4y ago
      Yeah, I agree that react-hook-forms feels much more natural and straightforward to use compared to Formik. It's just a shame it's so poorly documented.
      • azemetre 4y ago
        What is poorly documented about react-hook-form? I like the documentation a lot, and it's creator is EXTREMELY responsive regarding github issues & discussions and on their discord as well.
        • geewee 4y ago
          I think the documentation is usually pretty great if you can find it. Somehow I never seem to be able to.
  • bluedevil2k 4y ago
    Formik hasn’t been updated in years, is riddled with bugs and performance issues, and very likely will never be updated again. Not what I’d want in a JS library.
• NayamAmarshe 4y ago
  Waiting for React Recoil to become the standard, it's amazing!
  • joriskok1 4y ago
    I have never used Recoil. How does it compare to Zustand?
    • meitros 4y ago
      Recoil = Jotai (mostly equal.) Check out the comparison doc https://jotai.org/docs/basics/comparison https://jotai.org/docs/basics/comparison
  • lhnz 4y ago
    I've been using it for the last two years. Don't you feel it's quite low-level and also quite problematic to have to keep thinking about caches all the time?
  • colinmegill 4y ago
    recoil is a winner
  • agumonkey 4y ago
    apparently they lifted atoms
• throwaway284534 4y 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. 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. 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.” Has anyone else here successfully left for greener JS pastures?
  • kansface 4y ago
    That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…
    • root_axis 4y ago
      Hooks are not a "language", they're just react API calls.
      • svachalek 4y ago
        "Just" is not really fair here, they're a window into global variables. Global state is awful to deal with but a necessity in the real world, so having some sort of constrained global state is something we're always trying to solve in new ways, singletons, monads, etc. Here we have hooks, which is an interesting experiment but something I personally would have played with in some new framework rather than dropping into the most popular and mainstream one.
        • postalrat 4y ago
          Depends on what you mean by global state. You don't have access to a single pool of global variables. You only have access to what you put there and what you've been given.
• jitl 4y ago
  Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted. > Form libraries are portly maintained or documented 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. Write your own form field hook. The state model for a form is simple - 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. > useContext and useEffect have annoying dependency tracking; I prefer Solid’s mutable state and automatic dependency tracking. 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. 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 & scale.
  • pier25 4y ago
    > The two-way data binding in Svelte saves ~4 lines of reusable hook function Based on the RealWorld projects, Svelte saves you around 50% in loc vs React. https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
    • addicted 4y ago
      That’s from 2020 and I’m pretty sure that’s using class components, considering the latest implementations has a separate (using hooks) implementation.
      • pier25 4y ago
• valyagolev 4y 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
  • nightpool 4y ago
    You mean they changed the edge-case performance characteristics of an experimental alpha API? It feels hard to get up-in-arms about that.
  • 11235813213455 4y ago
    I don't think you especially need to try to prevent useless re-renders, as long as it doesn't slow down the app
• ajkjk 4y ago
  Agree with a lot of this, but, some quibbles: 1. yes, un/controlled forms are messed up and need work 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. 3. yes, forwardRef is silly. 4. yes, useEffect is kinda broken. My main issue which wasn'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. Otherwise, I really don't mind tracking deps _that much_, although I hate that it's hard to have an effect that updates 'on some local variable changes but not others', so in practice I pretty much ignore the lint warnings all the time. It all feels like "there's a DSL waiting to be written for this stuff, similar to how JSX makes createElement() more ergonomic, but it doesn't exist yet". That said, Solid doesn't seem like the answer. Solid's even worse: now you're using JSX for if/else statements, instead of the actual DSL you want that doesn't exist yet. Good luck running a debugger on that. (Although actually, if the Solid AST ends up in the Devtools view, that's pretty good. But still: this needs a fully-featured DSL). 5. +1, yeah, the continuing addition of weird hooks feels like a mistake that will eventually be regretted. 6. The right way to do your Inspector example is to have a parent component that decides whether it's rendered, and a separate child which does all the event listeners. It is a bit weird to me that React doesn'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's best to just have two separate components. 7. +1 to old docs getting in the way. I'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've been toying with trying to work on this myself. 8. Yeah, fuck FB 9. Yeah, I'm not going to any of the other frameworks either. React is great, it's just ... not... great enough. I am in the middle of writing a series of blog posts about exactly this and I haven't finished yet but anyway here's the first one that I have written about why I like it so much? https://alexkritchevsky.com/2022/09/17/react.html https://alexkritchevsky.com/2022/09/17/react.html
  • 4y ago
• autorun 4y ago
  I'd like to know how a newcomer would feel after reading the tutorial of the monster you created, React. Take React hooks at its purest for example. I can't imagine the WTF feeling in a newcomer's mind, when the useState(<default-value>) helper function returns the "reactive" variable and a function you have to use to update it (!) do you realize how tricky you end up with your technical DOM optimizations? Same with useEffect(), 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? When recommending a frontend framework, I found Vue to be more dev friendly. However, it'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't even say that's to be retrocompatible with Vue2 mindset), but for a newcomer's mind, it's like asking: which pill do you want to take? red or green? Choose your own adventure!
• rav 4y ago
  Regarding the Inspector/isVisible complaint: When you want to have "early return" in a component, it's possible to just split the component into two to introduce an "inner" component that contains whatever comes after the early return point in the original component. Any local variables from before the early return then need to be passed as props to the new inner component. 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. It's really a code transformation similar to async/await where you derive a state machine from a block of code by identifying transition points. In async/await you have transitions at the await points; in components you have transitions at the early return points. In async/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 "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". But it's probably a Hard Problem™.
  • augzodia 4y ago
    This is exactly the use case for HOCs and why I continue to be old man yells at cloud about how the "hooks replace(d) HOCs" zeitgeist is missing a key benefit. Wrapping components lets you have layers that don't have to care about what's going on inside. HOCs just let you write those layers in a way that can be composed. In your example, `isVisible` could be its own HOC, and then the inner component can have whatever name it needs.
• rglover 4y ago
  Come to the dark side, we have cooookies https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
  • pc86 4y ago
    Tangentially related: https://xkcd.com/927/ https://xkcd.com/927/
    • rglover 4y ago
      The number of people who have sent me this exact meme for daring to offer an alternative is quite illuminating of why it's so hard to make progress. Not picking on you, but dogmatic thinking is why OPs article even exists. Don't substitute memes for thinking. Evaluate what I've built on its actual merits.
      • pc86 4y ago
        Respectfully, I don't have the time or interest to, and to be quite honest while I am qualified to implement just about anything you want in vanilla JS, jQuery, [old versions of] Angular, React, or Vue2, I'm very likely not qualified to judge a brand new one on its merits other than just a superficial comparison to the ones I've used before.
        • rglover 4y ago
          So why post something snarky and try to discourage me? Serious question: what was the motivating factor that made you take the time to reach for that cartoon and respond to me with it?
          • pc86 4y ago
            It's a joke - and a pretty common/unoriginal one at that. Calm down.
            • 4y ago
• knoebber 4y 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! 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/reusability. Overall I liked what I came up with, but it felt like a lot of inventing stuff on my own, which I'm not sure if the next developer who comes along will appreciate.
  • mind-blight 4y ago
    I think a lot of the problems the author highlighted become more apparent as the number of devs in the codebase goes up. If one member doesn't understand all of the nuances of useEffect or paint useCallback, they can write a component or custom hook that another team uses and gets subtle bugs from. For example, I need to look inside of a hook to see whether the callback it provided was wrapped in useCallback. That means I can't truly rely on the abstraction since I need to learn it's internals.
    • arcturus17 4y ago
      I don’t know of any language or framework that guards from mangling a buggy abstraction and then exposing an interface for it.
    • skydhash 4y ago
      Pretty much this. I've owned entire applications and it's really fun when you're working alone. But adding a new developer that does not grok hooks (mostly because they are more use to imperative patterns than functional ones), and you will have bugs to deal with almost every single day. In a project, I was using Firebase as the backend and hooks allowed me to nicely abstract it away and use a language closer to business domain (like `useEntity(entityId)` and `useCreateEntity(entityData)`). Everything was more modular from changing the backend layer to breaking up bigger components.
• rafale 4y ago
  I prefer Angular. I never could accept writing css/html in my javascript. To be fair, my background is from XAML, so declaring the state separately and simply binding to it in my html template felt natural. The whole functional approach in React is overkill imo. It's okay if the state mutates in 90% of scenarios. Where there is really benefit from immutable states, I can enforce that on my own.
  • deleted 4y ago
    [deleted]
  • xtracto 4y ago
    Yes yes yes! I´ve done some React at my job and also done some Angular/Ionic before. What I never understood of React is why did the creators decided to throw DECADES of Software Engineering development and comingle presentation layer with logic... To separate Views from Logics was an agreed good practice in Software Engineering since I was in undergard school 20 years ago.
    • vlunkr 4y ago
      I disagree that React is doing anything controversial actually. Angular has logic in it's views, what do you think the handlebars syntax is? The only difference is that they added new syntax to JS instead of adding new syntax to HTML. And how much logic you put into a component is up to you. Your components can be almost entirely view logic, with any other data fetching or computation offloaded to other regular js files.
    • javcasas 4y ago
      That's fair. Why write html in javascript, when you can write shitty javascript in the templates (via ng-if and ng-for)?
    • chrisco255 4y ago
      Because you will inevitably need to use control flow, conditional rendering, and computed values in your components. And creating proprietary HTML syntax (ie ngIf) to cross reference variables defined in the JS anyways. So why not use JS and gain access to powerful array manipulation, ternary operators, map/reduce/filter functionality, etc instead of leaning on an inferior template syntax?
• PaulStatezny 4y ago
  Function components are a useful tool, but for the life of me I can't understand why the community currently builds everything with them. A lot of React code I run into these days would be simpler and less verbose with a traditional (non-function) React component.
  • shadowgovt 4y ago
    Mostly because functional components are understood to be the direction the framework is headed, with class components still supported for backwards compatibility reasons only. They'll almost certainly never go away without a major version bump because it would break way, way too many sites, but at some abstract level people feel class components will have a shorter shelf-life than functional. And certainly, any given third-party integration to React in the future is allowed to just say "We only support functional components" (with the corresponding hit to popularity, of course).
    • PaulStatezny 4y ago
      Thanks for commenting about the community sentiment. Interesting that you didn't comment at all about my take on functional components not being the best tool for every job in React. Curious – do you have an opinion?
      • shadowgovt 4y ago
        If I understand correctly, the team is pretty clear that if they had written React from scratch today, they would have gone with functional components and not class components. The major issue is life cycle. When is a class component instance created or destroyed? The answer is "whenever the framework feels like it," and that's a really ugly model for instance life cycle. Additionally and most importantly, it means that member variables on a React class component instance don't work the way that members are expected to work; you just can't rely on them having any particular value because the framework can create or destroy an instance when it feels like it for performance reasons. What good is a class and instance abstraction if when you try to use member variables (one of the key features of object-oriented programming) you're highly likely to just break the model in hard-to-debug ways? Because the framework isn't using class component instances like instances are supposed to be used, the React team is tossing that model to the curb.
• 11235813213455 4y ago
  Salut Marmelab The best way we found is a custom useForm hook (simple to code, using useState's): const { submit, getProps, isLoading, error } = useForm({ onSubmit: cb, initialValue: {} /*optional*/ }); return ( <form submit={submit}> <input {...getProps('firstName')} /> very flexible, you can use other wrappers than form or input react-query is another super useful lib, you could use useMutation() for implementing useForm actually
• sillycube 4y ago
• marstall 4y ago
  love the way this is written
• padseeker 4y ago
  As someone who built a product that is a form builder that uses React, https://keenforms.com https://keenforms.com, the best thing I can say is this; 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/validating/calculating need to be reset for each change so I used a functional approach for these other features. 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.
• collyw 4y ago
  Does anyone do server side rendering these days? 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'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. 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.
  • belmont_sup 4y ago
    You should try again and reconsider if your team truly doesn't have an answer. Most everyone using React should be using Nextjs or similar level of frameworks. Server rendering comes out of the box. On the other hand, it really isn't too complex anymore. With Next, Sveltekit, Remix, Nuxt, and friends, you get simple, hardened tooling out of the box. And you've decoupled frontend from api which many teams find very helpful to split responsibilities and allow certain features to move at different paces.
  • reducesuffering 4y ago
    > Does anyone do server side rendering these days? Yes, in React, with Next.js. I'm going to have to dynamically create html and attach event handlers based on data either way. Much rather do it all in Typescript than remember Django templates DSL and still do javascript, for the result of worse UI's, poor 3p library support, and awful state management between frontend and backend.
    • bot41 4y ago
      Or with Remix Run which is great
    • collyw 4y ago
      Django temples are pretty simple. They are basically HTML with a a few constructs that you can put variables or loops in. Way simpler than React and Typescript.
• nonethewiser 4y ago
  I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.
  • gwn7 4y ago
    You are not alone.
  • elbac 4y ago
    Did you use to work in Java?
    • nonethewiser 4y ago
      No
    • goatlover 4y ago
      Coming from Ruby and Python, I also prefer class components to hooks. I had to deal with hooks enough in Drupal/PHP which is in the process of deprecating them in favor of Symfony classes.
      • nightpool 4y ago
        Drupal hooks have nothing to do with React hooks except sharing a name. What would cause you to compare the two?
        • cooperadymas 4y ago
          Sharing the same name, I presume.
        • goatlover 4y ago
          Drupal hooks are a functional approach to design compared to the OOP approach of Symfony components. As in you use functions to modify/extend existing code instead of inheritance. That's the context of the discussion, not whether they are otherwise similar to React hooks. Anyway, I just tend to think more in terms of making things with classes/objects than with functions.
• darepublic 4y ago
  I use next.js with react and typescript and mostly it's a good experience
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• nutanc 4y ago
  We tried to use other frameworks but finally came back to React for only one reason. It's easier to hire for React. The talent pool for React is almost 10 times that of other frameworks. And for now, this reason is good enough for us.
  • ch_sm 4y ago
    Good point. But then again, if the engineer is good, switching between say React, Vue and Svelte shouldn’t be too hard. EDIT: To clarify, I mean picking up one of the three if you already know another one.
    • wildrhythms 4y ago
      I 100% agree. I find it troubling that people are 'hiring for React'. How does a developer possibly learn React without learning the core concepts of HTML, CSS, Javascript and thus adapt to any library? It doesn't make sense to me at all.
      • nutanc 4y ago
        That would seem so right? I thought so exactly too. This works when your engineering team is small. But once you go beyond the first level of engineering and its mostly maintenance and updates, the people who apply for the job are not interested in learning new things. They have learnt one thing and want to apply that skill 9-5 and go home. For those roles hiring for react is easier.
  • randomsearch 4y ago
    Vue is learnable in a single day. React is almost as easy to learn. Just hire React devs and give them a couple of days with Vue, no problem
    • ssijak 4y ago
      There is a difference in being able to write something that runs and writing idiomatic something which uses all the libraries idiomatically that runs.
• sergiotapia 4y ago
  Since quitting React I've been happier with my day to day. Phoenix Liveview came in clutch and showed me I don't have to put up with these kinds of self-inflicted problems. If you'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's _sane_. You don't have to "split the context" anymore. xD
  • azemetre 4y ago
    What are some resources (book or courses or videos or blogs) you'd recommend for learning Elixir and Phoenix?
    • sergiotapia 4y ago
      Easily these three courses: https://pragmaticstudio.com/ https://pragmaticstudio.com/ Phoenix Liveview, Elixir & OTP, and Full-stack Graphql with Phoenix. Best way to learn Liveview.
    • krnsi 4y ago
      Better be fast: https://www.humblebundle.com/books/elixir-programming-pragmatic-programmers-books https://www.humblebundle.com/books/elixir-programming-pragma...
    • jnsaff2 4y ago
      I can recommend this book currently in beta, that has been pretty good at keeping up to date with most developments in LiveView. https://pragprog.com/titles/liveview/programming-phoenix-liveview/ https://pragprog.com/titles/liveview/programming-phoenix-liv...
• Waterluvian 4y 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/lidar views + joystick controls). 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 "in my way" when it comes to the only goal I really care about: shipping a maintainable product on-time. 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.
• pgamble 4y ago
  Relatively new react developer here (still learning in fact!), I liked this article although it shook me a bit and made me wonder "am I wasting time with some of this stuff? maybe I should be looking ahead to the next 'best framework'". Id be interested in hearing people's thoughts: what would be best to learn for maximum applicability in the ~3 year timeframe?
  • jd24 4y ago
    Depends on what you are learning for. If it is for a job, then react has the most openings by a large margin and will likely stay like that for a while.
  • vore 4y ago
    Learn the theory, not the framework.
    • dchest 4y ago
      Completely disagree. Theory is useless without application. For some people, the best way to learn is to start making projects immediately. Theory will come later.
    • dogcomplex 4y ago
      lol this is the wrong job for that. Join a game development team that uses assembly and C and cares about filling a gpu efficiently if you want to learn real programming. Here theory is philosophizing about the best way to organize a garbage dump to take our mind off the shoveling.
  • azemetre 4y ago
    Don't call yourself a react dev, it's unlikely this framework will be around in 10 years time (see what was popular in frontend dev 10 years ago). Call yourself a developer and try to learn the core tech, if you're a web developer that means javascript and html. All these libraries are built on JS, understanding JS is the safest bet you can make.
  • chrisco255 4y ago
• synergy20 4y ago
  what about Vue? its html approach(instead of React'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)
• miohtama 4y 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. More here: https://kit.svelte.dev/ https://kit.svelte.dev/
  • bot41 4y ago
    Is Svelte still overly dependent on Rich Harris? He's great but that reliance put me off Svelte.
    • miohtama 4y ago
      I believe there are at least 3 full time core developers now.
    • qabqabaca 4y ago
      He was recently hired by Vercel to work on it full time so I wouldn't be too concerned about the future of Svelte
• asdajksah2123 4y ago
  I really hope React doesn'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. A pre-compile step that statically adds dependencies to your code might be a reasonable compromise, but those dependencies do need to be explicit. The rest of the stuff makes a lot of sense though.
  • vore 4y ago
    Why not? Having to manually manage the dependency array is tedious: in fact, not specifying a required dependency is a logic error anyway, so having the compiler do it is basically preferred in all cases.
    • chrisco255 4y ago
      Because the dependencies for hooks have to do with re-rendering the component or recomputing the value, not with the usage of the dependencies themselves. That cannot be inferred by the framework without taking a one-size-fits-all approach that probably fits no one particularly well.
      • vore 4y ago
        Huh? react-hooks/exhaustive-deps does exactly that: it statically infers dependencies and is very noisy if you forget one, and the React team recommends that you always have it on. In fact, the React docs have this to say, right in the documentation for useEffect (https://reactjs.org/docs/hooks-reference.html#conditionally-firing-an-effect https://reactjs.org/docs/hooks-reference.html#conditionally-...): The array of dependencies is not passed as arguments to the effect function. Conceptually, though, that’s what they represent: every value referenced inside the effect function should also appear in the dependencies array. In the future, a sufficiently advanced compiler could create this array automatically.
        • chrisco255 4y ago
          The useEffect dependency array defines the values for which you want the effect function to trigger any time those values change. It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-effect-dependencies-change-too-often https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...
• iLoveOncall 4y ago
  It may be due to the codebase I'm working on, but I doubt it since I assume I have decent colleagues (I'm in a FAANG), but I just fucking hate React. I spent years working on Angular before changing team, and there everything makes sense instantly. It'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. 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. I'll have to give a try to React from scratch where it's not on an existing codebase, but I don't think that's the real issue. It's been more confusing for me to go from Angular to React than to learn a functional language after years working with imperative ones.
  • postalrat 4y ago
    Funny because every time I need to work on anything angular I'm constantly thinking how over-engineered everything is and how much simpler it is in react.
    • imcotton 4y ago
      Have you read the article?
    • iLoveOncall 4y ago
      Sure, if you have only a very basic 1 page website with no routing, no backend calls, no components to reuse, etc. React will be a simpler and better choice. If you have anything more complex than that, like a real web application, Angular is an actual frontend framework, where React is just the modern jQuery. Angular is for software engineers, React is for web developers.
      • postalrat 4y ago
• holistio 4y ago
  ...and that's why I switched to Vue nearly four years ago. Best professional decision I've ever made.
  • hnrodey 4y ago
    Are you finding much "professional traction" with Vue? I really like Vue and use it for personal projects but React seems to dominate the job postings.
    • zero_shift 4y ago
      Vue is mostly used in China, where there is a preference for Chinese tech.
      • azemetre 4y ago
        Really? What are they using for things like containerization, observability, testing, or even compilers and operating systems? Really curious if there's an alternative word for all these core tools in the west. From my understanding Vue was heavily adopted in China because it was the only major framework that had its docs translated into Chinese by Evan himself (initially at least). Guessing this isn't accurate nor the case?
      • CharlieDigital 4y ago
        That's probably not the reason why it's heavily used in China. More likely there was some early draw based on Evan You being the figurehead and eventually a community that built up Chinese language documentation around it that made it more accessible to Chinese developers.
        • zhouyxamp 4y ago
          This is true. I'm a Chinese developer and I have saw too many developers here using Vue because of it's good Chinese documentation. I used both Vue and React in my projects, I think one advantage of vue is it makes some concepts explicitly. Like the computed property, its more obvious than the way you do it in React. Vue's document is simple at the early days of the framework, that made it more accessible to new comers, especially people who was trying to migrate away from AngularJS, and didn't want to take Angular 2.x.
• markandrewj 4y 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? What are peoples thoughts on Svelte vs Solid? I know Lit/native web components are out there as an option as well. I have past experiences with it when it was Polymer. If anyone is looking for something very lightweight they may want to consider Alpine as well.
  • steve_taylor 4y ago
    I’ve tried Svelte, but it seemed a lot harder to work with than React. Solid on the other hand is very straightforward. It has a hooks-like appearance, but it’s quite different as functional components are executed only once, so you don’t have silly dependency tracking issues. If I had the time, I’d throw myself into a Solid project.
• caycep 4y 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. The difference is that Microsoft languages may have better ppl working on developer documentation, who knows...
• kirse 4y ago
  As an early beta user, I also agree. I think the issue with many modern libraries is that they don'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. 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're definitely in the long-term bloat phase which you can tell by the popularity of things like Vue, "React Lite" libraries being built, etc.
• padseeker 4y ago
  If you are using that many refs you built it wrong - from the React documentation (https://reactjs.org/docs/refs-and-the-dom.htmlhttps://reactjs.org/docs/refs-and-the-dom.html); https://reactjs.org/docs/refs-and-the-dom.htmlhttps://reactj... "There are a few good use cases for refs: 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. ... Don’t Overuse Refs: 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." If you are using refs to talk to your child inputs you'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. React gives you some nice tools to handle most common use cases but you can still make less than optimal decisions.
• tootie 4y ago
  > There are two kinds of programming languages: The ones people complain about and the ones nobody users - Bjarne Stroustroup
• simon83 4y 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't even accept projects that use React anymore, exactly because of all the pain points OP mentioned. 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.
• hunkins 4y ago
  Using an opinionated library can help with some of these issues. Personally, I love https://mantine.dev https://mantine.dev.
• molszanski 4y ago
  Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years. 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. 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. 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. 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 `<IF>` components for christ… 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. 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.
  • pdntspa 4y ago
    Where are good examples of clean, well-implemented React code by your definition? Because your comment perfectly encapsulates my experiences and frustrations in learning and using React off-and-on over the past 8 years or so. React is the one tech that really freaks me out because every time I have to dive into it, it's a completely different beast and it feels like so many people actually writing in React are just effing CRAZY Years ago I wrote a 12-line-or-so JS "framework" that did one-way databinding, it accepted a fragment of HTML with template strings and replaced those with the data you wanted... it could handle thousands of updates without falling over (though updating the whole table would freeze the browser for a half second) and last I checked was still in production doing fine. But now nobody understands it and I'm fielding weird questions about why X framework wasn't being used in 2015 when I wrote it. And it feels like 90% of what I do in React is the same thing! (Simplifying, sure, but my point is that React feels bloated as hell and reinvents the wheel way too much)
• newbieuser 4y 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.
• tabtab 4y ago
  I keep saying we need a state-ful GUI markup language standard so we don't have to re-re-re-reinvent real GUI's with JS+CSS+DOM. Those weren't meant for real GUI's and retrofitting creates bloated, buggy, ever-changing messes. GUI's have been around more than 30 years, why can't we network-ify its common and loved idioms?
• joshribakoff 4y ago
  Concurrent react actually makes your app less concurrent: https://github.com/facebook/react/issues/21668 https://github.com/facebook/react/issues/21668 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.
  • Jasper_ 4y ago
    Oh wow. I was always skeptical of "concurrent React" (the scheduler approach seemed insane to me), but this seems like such a basic issue, I'm surprised this ever shipped in any form.
    • Rapzid 4y ago
      Yeah, it seems suss AF. IIRC it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?). And if it bales out, it has to re-render everything again when it comes back to make sure the state is consistent(nothing has changed). The exact details are fuzzy and that may be incorrect but the impression I came away with after reading an engineering post about the deets was that: * The risk of thrashing seemed very high * Debugging performance issues seemed like they were going to be a nightmare. Worse than right now. Worse than hook hell. This line from the song Taro comes to mind: "Do not spray into eyes. I have sprayed you into my eyes.
      • acemarke 4y ago
        > it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?) It's exactly the opposite. React splits work into two parts: the "render phase", where it loops over components and asks them to describe the UI they want (returning JSX/elements); and the "commit phase", where it has determined the changes that _need_ to happen to the DOM. The render phase is the part that can be split into many pieces. React can render a few components, see that 5ms has elapsed, and yield to the browser, then pick up where it left off and render a few more components. Or, it could render some components, pause, see a high-priority user event happen like typing into an input, and set aside the partially completed render pass to go re-render based on the input update. Then, after the input render is done, it can pick up where it left off with the other partial render, "rebase" it onto the current UI contents, and continue from there. The commit phase is _always_ synchronous, start to end, and that's where the actual DOM updates are applied. Some more details: - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... - https://github.com/reactwg/react-18/discussions/55 https://github.com/reactwg/react-18/discussions/55 - https://reactjs.org/blog/2022/03/29/react-v18.html#what-is-concurrent-react https://reactjs.org/blog/2022/03/29/react-v18.html#what-is-c...
• reactive881236 4y ago
  the fundamental issue with hooks is that it'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.
• beders 4y ago
  I'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/event handling on top.
• topspin 4y ago
  Props to marmelab's react-admin, and the ng-admin that preceded it. If you need CRUD without adopting some "low code" platform and its half dozen containers full of weird databases, react-admin is a fine choice. I have wondered what svelte-admin would look like.
  • cpursley 4y ago
    React Admin works really well with Hasura (there's an adapter) for whipping up dashboard apps.
• corytheboyd 4y ago
  I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each other, half-finished move-to-new-framework initiatives. I just mean to say that when I hear "it's because React" or "it's because rails views", 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'd rather it be in a big ball of frontend than in the data models, infrastructure, etc.
  • kristopolous 4y ago
    They mostly encourage bad practice by design and people do what these tools give an affordance for which is why the results are broken.
    • bobthepanda 4y ago
      People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend. Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.
      • kristopolous 4y ago
        woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions. Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution. Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration. Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable. Given a product: . Systems should not continue to function without the programmer . Code has to constantly be rewritten in order to achieve the same ends Also it permits the users to go on constant employer funded vacations to conferences and training sessions. From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following: . Job security by ensuring brittle applications . Endless tasks by ensuring endless complexity . A sense of elitism and entitlement . No expectations of deliverables . Be vague enough so blame can get shifted if things break By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done. The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible. In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power. People adopt the patterns because they want to have the perceived protective properties of the obscurities. Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic. ... Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
• shadowgovt 4y ago
  > 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't know how to do it. So annoyingly enough... There's not anything inherent to the language that makes it impossible to get a list of closure references for a function, other than it's not something JavaScript exposes. In a hypothetical future version of JS, this could be a first-class feature of the function API. ... because what JavaScript really needs is yet another feature to support one framework's special-caee needs. ;)
• randomsearch 4y 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. JSX yuck.
  • cillian64 4y ago
    I’m an embedded/backend dev looking to tinker with some frontend stuff for the experience and out of curiosity. I’ve been leaning towards react because it’s so common and what my team use, but I’m finding it pretty hard to get into.
  • pcthrowaway 4y ago
    Would you say Vue 2 or Vue 3 would be better for someone venturing into Vue? Also, have you used Svelte much?
    • Hawxy 4y ago
      Easily Vue 3, the dev tooling/xp + docs are much better over Vue 2.
      • randomsearch 4y ago
        Oops yes this is a very good point I missed.
    • randomsearch 4y ago
      Vue 3 is more exciting, but I'm stuck on Vue 2 for my real work due to dependencies. Much of Vue 3 has been backported, and you can use Vue 3 like Vue 2, so it doesn't matter too much... probably go for 3 as it's the standard now. I've looked at Svelte. I was deterred by lack of ecosystem. Vue's is just big enough to be workable, I think Svelte doesn't offer enough to reach the Vue/React size - probably.
    • rk06 4y ago
      Vue 3. Apart from the fact that it is modern and has more features, It uses proxies, so it doesn’t have the vue2’s reactivity gotchas.
• Patrol8394 4y 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.
• deleted 4y ago
  [deleted]
• isochronous 4y ago
  This kind of thing is exactly why my old boss went and created his own minimalist framework built around using native code: http://www.domxjs.com http://www.domxjs.com. Its explicit purpose is to allow developers to learn and utilize the platform, rather than learning a bunch of libraries.
• tarkin2 4y 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.
• sakagami0 4y ago
  React is bad in the same way C++ is bad. It'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's not a one size fits all, a lot of the time you don't need the flexibility if you're new to it and just want to get something done.
• hnuser847 4y ago
  > Dear React.js, > We've been together for almost 10 years. We've come a long way. But things are getting out of hand. We need to talk. > It's embarrassing, I know. Nobody wants to have that conversation. So instead, I'll say it in songs. Am I the only that finds this open letter format extremely cringey? I almost didn't want to read the article after that intro. The content was excellent otherwise.
  • cosinetau 4y ago
    By the same extension, would you consider your comment worthy of the same classification of "cringey"? How you feel about the delivery is not relevant to the topic, and if you had opted not read to it, it would not be the person in the arena that would be at a loss because of it.
    • hnuser847 4y ago
      > By the same extension, would you consider your comment worthy of the same classification of "cringey"? No, but I think your comment falls squarely in that category.
      • fortyseven 4y ago
        Ah, the ol' "no, you are" response. The mark of quality conversation.
      • cosinetau 4y ago
        Have a great day! Hahaha
• deleted 4y ago
  [deleted]
• bot41 4y ago
  I just use Remix and use React in it's simplest form. Working for me so far but it might not work for big complex apps
• bern4444 4y ago
  The 'issue' 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. There's very little need for a onChange(e) => setFormValue(e.target.value) and all the extra work that comes with that. There is an absurdly simple solution which removes all the 'cruft' 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. 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. 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. All this becomes blissfully easy.
• ralphc 4y ago
  I have a message from the future. The JSParty podcast episode 244, recorded live but not part of their feed yet, is "Is React only great at being popular?"
• blumomo 4y ago
  Give react-admin [0], the post author’s react framework, a glimpse. If you develop an ERP/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. [0] https://marmelab.com/react-admin/ https://marmelab.com/react-admin/
• sibeliuss 4y ago
  How has nobody mentioned the insane complexity monster that is React 18 / Suspense?! I mean, it makes sense once you understand it, but who is going to understand it? React'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's fully understood. Give the public a few more years to get it, though.
  • swyx 4y ago
    suggesting the concurrency features can simply be broken off is evidence that you may not understand them as well as you imply.
    • sibeliuss 4y ago
      Sorry, to clarify: What I'm suggesting is that React 18's changes were substantial enough to have been broken off into a separate library, not maintained inside of React. I don't mean to diminish the teams amazing work here, but they're overkill for 90% of the developer community who are already having a hard time understanding all of the abstractions that have made it in since hooks were added. All of this is _overwhelming_ given how simple React was at one point in time.
      • unconed 4y ago
        Amen. React 18 was the moment where they forgot they started as the V in MVC. Concurrent React was a mistake, and the hooks they had to add to make it work too. The main example I always cite of where the React team is naive is mousemove handlers: - there is no guarantee that react will re-render between two mousemove events - even if it did, creating a new mousemove handler after every move is ridiculous - avoiding this using the `setState(s => s)` form doesn't work if you have multiple pieces of state or need to invoke other callbacks Therefore, every mouse dragging UI I've built has used useRef instead, mutating state directly. The answer from the react team to this seems to be.... nothing. They just say it's bad to mutate state and that it will lead to bugs, seemingly not realizing that so will useEffect for the reasons above. I think OP is wrong, and that people who have never built an app with undo/redo don't know what they're talking about when it comes to front end dev... but the React team is definitely chasing the wrong ideas. Also, forms utterly suck as a UI, and every form abstraction I've ever used was terrible and ran into a wall. It just seems pointless to try to optimize for it. If some people want to make forms easier because it's most of what they do day to day... hint, they're atrocious front end developers.
• insane_dreamer 4y ago
  Hardly any mention of Ember in the comments. Is it no longer considered a viable alternative to React?
  • aarpmcgee 4y ago
    I’ve been using React ever since that David Nolan article and ridiculed Ember all the way. Now I’m wondering if maybe I need to give it another look.
    • insane_dreamer 4y ago
      I haven't had the opportunity use Ember much, but I like the philosophy that it's built on (and its original author, Yehuda Katz has a pretty good rep as a solid thinker).
• insane_dreamer 4y 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 "modern website" must be written with a JS framework like React.
• steve76 4y ago
• vcanales 4y ago
  I know it'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: ``` const Form = () => { const [formData, setFormData] = useState({ firstName: '', lastName: '' }); function handleChange(event) { const { target } = event; const { name, value } = target; // Destructuring in steps to make it easier to figure out where values come from. setFormData({ ...formData, [name]: value }); } return ( <> <input name="firstName" value={formData.firstName} onChange={handleChange} /> <input name="lastName" value={formData.lastName} onChange={handleChange} /> </> ) } ```
  • 11235813213455 4y ago
    even better, wrap those props as <input {...getProps('firstName')} /> and make a custom hook returning that getProps function
• swyx 4y ago
  As someone whose career success was very tied to React, I will say that "quiet quitting React" (or, nonjudgmentally, realizing my longterm interests were broader and taking action on it) has been one of the hardest career transitions I'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'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). React is doing innovative, groundbreaking stuff with React 18 and beyond. I'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'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't everything; once you identify the 10-20 things everyone shouldn't DIY you're basically done (I ended on this at last week's Svelte Summit https://www.youtube.com/watch?v=A8jkJTWacow https://www.youtube.com/watch?v=A8jkJTWacow)
  • llanowarelves 4y ago
    Timestamp ?
• taf2 4y 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?
• didip 4y ago
  It's time to make server side HTML templating trendy again. I think frontend technology took things too far. Imagine the possibilities of using HTMX and any server side technologies like Elixir, Go, or Rust.
• pipeline_peak 4y ago
• dogcomplex 4y ago
  Throwing my message in a bottle here, in hopes someone can answer: 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) At this point I'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 / 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. Last I checked (and burned out) this was the major React hurdle, and the downside of React's simple-by-default templating. This complex stuff got real ugly real fast. What's the elegant solution here, if any? Any improvement?
• dmurawsky 4y 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. 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.
• branko_d 4y ago
  The biggest problem I have with React is that it’s not reactive. And the biggest problem I have with hooks is that they make functional components non-functional. This is starting to look like a pattern… :)