20 ms·

React has grown beyond its original promise and it's causing more harm than good

226 points by OccamsMirror 3y ago

dbrueck 3y ago
His points are why I like Svelte. YMMV, but for me it hits the sweet spot of not having to do a lot of stuff by hand like we did in the jQuery (and earlier) days while also not being this massive, intrusive thing.
- darylteo 3y ago
  And thus the cycle of JS libraries continues. - Large standard library exists - "It does too much! It's slow! It's too hard to use" - "Here's a new library. It's 28kb and lightning fast" - Becomes new standard library - "... but it doesn't do this thing" - 2 rewrites later - Large standard library exists
  - jraph 3y ago
    Svelte, however, has its very specific way of working compared to all the other usual frontend frameworks: virtually no runtime (library) supporting the app and many things happening at compile time instead and via generated code. It also seems quite focused. If anything is to become bloated, I would expect SvelteKit rather than Svelte, to become larger. I also don't know how much of the bloat is to be attributed to React vs. its usual friends or their numbers, and maybe SvelteKit actually helps keeping things in order in the Svelte ecosystem. Svelte has also been around for a while now. (Note that I have only small experiences with Svelte, none yet with SvelteKit)
    - pcthrowaway 3y ago
      I think it's more accurate to say that Svelte can create a build with no run-time for certain apps (so can React with SSR), but for the general case, the Svelte compiler basically builds a custom runtime that only works for your application
      - jraph 3y ago
        Yep, the custom runtime you mention would be the generated code I mentioned. When I said "runtime", I was thinking of some support library you'd need to include next to the code of your app (which is left intact by React, and mangled to death with Svelte).
Waterluvian 3y ago
Know when a tool is right or wrong for the job. But be careful not to beclown one’s self by perceiving every job as being the same job.
debacle 3y ago
This sentiment is trendy (and a bit edgy among people who still refuse to learn modern JavaScript), but it's missing the point. React is the first JavaScript platform that feels well engineered for the web. "React suffers churn" -> goes on to talk about a lot of things that aren't React. "React should stay in its lane" -> React has a router to better manage lifecycle state. And it's simple and flexible and easy to work with. "React's talent pool is diluted" -> lol "React is not fast" -> This is true if you are comparing to e.g. htmx, but except for a bulky first load, React is just as fast as anything else. "React is overengineered" -> React is simple. It's good because it's simple. The data flow and rendering flow are intuitive once you understand them, and once you think in React, things become so nice that working with plugins that aren't React-y becomes kind of frustrating. React is a great framework for app dev. It has nice conventions, a simple learning curve, a good ecoystem, and good corporate support. I don't need React, but I use it because I like it.
- vsgherzi 3y ago
  I don’t know about simple learning curve I feel like it’s quite a different paradigm especially compared to vanilla. Not necessarily difficult just different.
- throw__away7391 3y ago
  > React suffers churn This one in particular always seems to be pulled out by people advocating for yet another new framework. I don't do much frontend these days...for like a decade now, but as a mostly outsider who occasionally dabbles, React has been a constant for a long time now. The latest stuff in Next looks fantastic, in the real world we were never able to build anything nearly as nice as what is possible these days. There's a lot of historical revisionism and rose-colored glasses being worn these days, but the truth is that most web apps have always been garbage, and that will probably never change either.
  - timw4mail 3y ago
    The library API itself might be stable, but the ecosystem is not. And that ecosystem has vulnerable libraries that should be updated. And that's not even going into using a big component library, like Material UI, which might be its own nightmare. This is something I've dealt with a lot personally, and I've made a good attempt to avoid unnecessary 3rd-party dependencies. But the huge churn continues in the build tooling, testing, linting, etc.
acomplexplan 3y ago
This post is just a list of grievances that don’t convince me in any way why I don’t need it. Maybe, I don’t care if it’s “overengineered” or maybe I don’t need something fast or maybe I need an abundance of talent to work on it. There are plenty of reasons why it might often be the best choice.
- vsgherzi 3y ago
  I feel that the documentation is often overlooked. In react I’m always confident that if I can think of something someone has likely already done it. Can’t say the same for my experience in the newest version of angular (I will admit that might be due to my noobishness)
  - acomplexplan 3y ago
    [dead]
rdgddffd 3y ago
This just sounds like a bunch of vaguries that could be written about any framework. And React works fine for small projects. There’s no need to loop in a bunch of dependencies like css in js or graphql either I’ve been using it for years.
- acomplexplan 3y ago
  [dead]
usere9364382 3y ago
Any fool can come up with a complicated solution, but the best mind comes up with the simplest. A man I respect once said to me. React is just another example of how rot takes over what is good. And people confuse loud with popular, popular with good, easy with simple, and tedious with merit.
- owlstuffing 3y ago
  >Any fool can come up with a complicated solution, but the best mind comes up with the simplest I know a best mind, he made htmx.
- palmfacehn 3y ago
  I explained that I preferred not to build and add a React based tool to a profitable Vanilla JS app. The package included dependencies for Postgres. The purpose was to spawn a modal dialog and dispatch requests to the selected service. All of the core functionality could have been provided by a single JSON file describing the possible endpoints. Of course that kind of elegance was nowhere to be found. The discussion progressed as you'd imagine. "NPM ecosystem is the biggest developer ecosystem in the world", he replied.
  - Shorel 3y ago
    NPM is a nightmare that makes old style C++ dependency management look like a next-gen wonder. It's hundreds, thousands of silly dependencies taking countless disk space, and a waste of time "minimizing" what should have never been there in the first place. I avoid Node.js like the plague. I feel nauseous just thinking about that.
hilux 3y ago
> ... when you're deep in it, its hard to miss the forest for the trees. That's very confusing. But so is the entire article. While I have your attention, as a relative newbie to web dev (with limited time and focus), is Next.js my way to go?
- 65 3y ago
  I hate Next.js because they make it extremely difficult to deploy an SSR app anywhere except Vercel. You basically have to use the Docker image to deploy your SSR Next.js app. I prefer https://remix.run https://remix.run or https://vike.dev https://vike.dev However, if you just want a static site, Next.js is great.
  - Aeolun 3y ago
    Ooh, looks like I need to check out Vike. It may address all concerns I have with Next :)
    - 65 3y ago
      I use it on my personal site. It's great - easy to use and super robust. Hopefully more people use it.
  - OccamsMirror 3y ago
    There's also Astro: https://astro.build/ https://astro.build/ - which admittedly I haven't tried yet but am planning on checking out for my personal site.
    - ringofchaos 3y ago
      Astro is great, using it for my blog site and. I have a mono repo setup React SPA and Astro For Blog. I can create a reusable component in React Repo and reuse in Astro blog. You could also write native astro components which are very close to vanilla html css with added benifit of making reusable components and scoped css. And you can also use svelte or vue components.
65 3y ago
This sounds good until you want to actually get things done. I don't think of React as merely adding needless interactivity, it's also an excellent view engine. It's extremely easy to get a site up and running with easy to read and maintain code with React. Technology builds on top of itself. Might as well use the things that make you more productive. The DHH ideology of anti-modernism makes some sense in some cases, but most of the time it doesn't hold up. Thank god I can deploy my static site React app to S3 with some GitHub actions and don't have to FTP a whole site into some Linux server I pay $5/month for.
- Lukas_Skywalker 3y ago
  DHH never suggested to host a static site on a Linux server. He only says that most (database-backed) applications could do without frontend frameworks like React. The alternative to the „static site React app“ you‘re hosting on S3 would obviously be static HTML.
- kaba0 3y ago
  I like React, but I didn’t quite figure out the “additional” ecosystem - what do you use for managing the communication with your backend, for example?
- lurking15 3y ago
  > don't have to FTP a whole site into some Linux server I pay $5/month for I actually enjoy doing this, it's also easy to automate with github actions too
skybrian 3y ago
I'm using Preact (via Deno Fresh). Simple examples look similar. I haven't used React enough to know if I'm missing anything.
MattDaEskimo 3y ago
This sounds like the complaints from a new developer that's frustrated over the layers of web dev. React does a fantastic job working with common developer principles such as Don't Repeat Yourself, and Single Source of Truth. Their points come across as overly vague and lack any true insights into development besides initial impressions. For a static page it doesn't make sense to use React, obviously. For a highly interactive page it, or another framework is critical to clean, manageable code.
- tauchunfall 3y ago
  >For a static page it doesn't make sense to use React, obviously JSX is a nice templating language. And when you use Deno or Bun you can use it directly on server-side. My server-side components have no hooks and use preact-render-to-string or `renderToString()` from `react-dom/server`. Also there is Gatsby which is a popular content management system which also allow non-interactive statically rendered pages (as far as I remember).
  - benatkin 3y ago
    > you can use it directly Because of a poor design choice in an otherwise well designed platform (at least in the case of Deno).
  - NathanaelRea 3y ago
    Or Astro, and plugins for React/Tailwindcss/etc. Components are just nice to work with because of their modularity. Using the ergonomics "most web devs" are familiar with is just nice.
  - mvdtnz 3y ago
    JSX is a mediocre templating language that's missing a ton of features from more mature templating languages like Razor
    - tauchunfall 3y ago
      >JSX is a mediocre templating language You can also complain about JSON being a mediocre data format. But I think it's minimalism and compatibility with JS made it successful.
deleted 3y ago
[deleted]
niceice 3y ago
But without the complexity that layers of abstraction create, Snapchat would only have 1 person working on buttons instead of 400.
- evantbyrne 3y ago
  It's amazing how much developer time is wasted writing components. I have to imagine that these jobs are at risk of being disrupted by AI though. If AIs can create designs, then they should also be able to convert design specifications into mostly-complete components. Expect the tech to exist by 2025 and disruption to component developer employment within a couple years.
  - kirill5pol 3y ago
    You can use GPT-V to create functional components from images directly: There was an open source project (https://github.com/abi/screenshot-to-code https://github.com/abi/screenshot-to-code) that I borrowed the prompt from and made a custom GPT for myself where I just drag and drop the image. It’s not perfect but it’s pretty great overall! Here are the prompts: https://github.com/abi/screenshot-to-code/blob/main/backend/prompts/screenshot_system_prompts.py https://github.com/abi/screenshot-to-code/blob/main/backend/...
  - wonnage 3y ago
    The hard part is usually not getting the component to look like the design but rather the fun process of discovering all the interactions nobody thought about while they were focused on pretty pictures
Osmose 3y ago
> React was meant to be a way to provide snappy page loads and UX. This is a very common misconception. React was meant to provide one-way data flow. With an app built directly on the DOM you have to deal with the DOM having its own state to manage on top of the state your own code is storing. You have a list of comments in a variable, and a list of DOM elements for each comment, and nothing but your own code is making sure they stay in sync with each other. React changed things so that the state of the DOM is always derived from your own app's state, which eliminates what turned out to be a pretty tedious and error-prone amount of work in complex web apps. It wasn't the first to provide this but its API was unique and compelling vs existing alternatives. The virtual DOM, server-side rendering, etc. are not things that make React faster than non-React code, they are things that counteract the inherent slowness in React's design to make it competitive with non-React code. Watch the original JSConf talk where React was publicly announced and released, and notice how the talk is mostly about the one-way data binding, and the virtual DOM/reconciliation are mentioned in the back half as ways React catches up to non-React app speeds: https://www.youtube.com/watch?v=GW0rj4sNH2w https://www.youtube.com/watch?v=GW0rj4sNH2w
- bell_tower 3y ago
  Unfortunately people do not find out what it was meant for, before they start writing about it
  - 88913527 3y ago
    We're at the point where many newer engineers haven't had real hands-on DOM experience but are expected to deliver applications built in React. You need to know at least one level abstraction below your current one to use the tool effectively. This all tracks with how the industry's changed, how we hire, how we train, and so on.
    - eru 3y ago
      > You need to know at least one level abstraction below your current one to use the tool effectively. I'm not sure that's true in general. For example, for some tools there's no single 'one level abstraction below'. Let's take regular expressions as a simple example. You can use them effectively, no matter whether your regular expression matcher uses NFAs or Brzozowski derivatives under the hood as the 'one level [of] abstraction below'. (Just be careful, if your regular expression matcher uses backtracking, you might get pathological behaviour. Though memoisation makes that less likely to hit by accident in practice.)
Aeolun 3y ago
I have to agree that with the introduction of React 18, and the new versions of Next and SSR everything has taken a turn for the worse. I’m sure it’s all very fancy and advanced, but it’s become completely impossible to reason about.
- teaearlgraycold 3y ago
  The new Next has jumped the shark. I wish there was a good alternative right now. I feel like they’re building for FE devs who are scared to learn BE dev.
  - 0xblinq 3y ago
    So far I’ve found some shelter in Remix. But I’m skeptical they won’t fuck up as well. They have a reputation of breaking everything with react router.
- maronato 3y ago
  I feel the same. After a year of not touching Next, I came back last week to find it’s unrecognizable. It feels like there are 10 ways of accomplishing the same things now, and Next tries very hard to make none of them feel like the right way. Want to structure your code? There are 4 ways to do it. Want to fetch data? You can use route handlers, server components, or server actions. Don’t forget to choose one of the 5 ways to cache and revalidate data! Want to show a loading indicator while the data loads? There are a few ways to do it, but be careful because some ways depend of parent components being server or client side! Not to mention all of the “unstable” apis. I appreciate that they want to make it easier to build incredibly efficient applications, but now there are so many options and so many ways to shoot yourself in the foot that I’m stuck with choice paralysis. IMO a good framework should have one and only one obvious way to accomplish something. More advanced use cases should be hidden away in the reference documentation or left as an exercise. That’s why frameworks like Django and Rails were so successful.
andrewstuart 3y ago
I love React but I use no state management, apart from useState locally within components. State management in React is a major source of pain and complexity and if you build you application using events then you can eliminate state entirely. Most state management in react is used to fill out props and get the application to behave in a certain way - don't do it - too hard, drop all that. Here is how to control your React application and make it simple and get rid of all state except useState: const ImageComponent = () => { const [cacheBust, setCacheBust] = useState(0); useEffect(() => { const eventListener = () => setCacheBust(Date.now()); window.addEventListener('customEvent', eventListener); return () => window.removeEventListener('customEvent', eventListener); }, []); return ( <div> <h2>Profile Image</h2> <img src={`https://example.com/profile-image.jpg?cachebust=${cacheBust}`} // Image URL with cacheBust as query param alt="Profile" style={{ maxWidth: '200px' }} /> </div> ); }; // Component that dispatches custom event const DispatcherComponent = () => { const dispatchCustomEvent = () => window.dispatchEvent(new CustomEvent('customEvent')); return ( <div> <h2>Dispatcher Component</h2> <button onClick={dispatchCustomEvent}>Reload Image</button> </div> ); }; Trust me - once you switch to using custom events you can ditch all that crazy state and crazy usage of props to drive the behaviour of your application.
- stnmtn 3y ago
  How is this different from the goal of redux or contexts other than ergonomics?
  - andrewstuart 3y ago
    I don't see anything in common with Redux or contexts. No libraries. No higher order components. No concepts to learn. No weird rules. No complex tracing of props and trying to work out why state updates were not triggered, or were triggered. Redux is one of the most painful software development experiences I have had. Just the thought of using Redux fills me with dread. The event code above simply sends a message directly between components - that's nothing at all like Redux. Can you describe how the above is like Redux?
adamzochowski 3y ago
Oh the irony of a text blog bemoaning complexity that won't load without javascript.
- chrisco255 3y ago
  Ironically if they had written it in server side react it would work without JS.
gustavus 3y ago
Cycle of frameworks: Young dev: it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use. Time passes, framework becomes popular blogs write about how framework X is the future. If you don't have 10 years in framework X you can't get a job. People start using it for things features get added to accommodate needs. People argue saying it's necessary it fits the demand. Framework X becomes a gigantic bloated monstrosity, development slows as useless bureaucratic leeches posing as developers create a "foundation" to "shepherd Framework X towards a bright future." At this point usually the creator leaves or is driven out. A young developer comes along and says to himself "it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use." The Wheel of Development turns, and frameworks come and pass, leaving defaults that become best practices. Best practices fades to srandards, and even standards is long forgotten when the problem that gave it birth comes again.”
- kevinsync 3y ago
  lol which of the Forsaken is React? Aginor, creator of the Shadow DOM?
- giljabeab 3y ago
  On the contrary some much older and experienced frameworks are simplifying and consolidating. .NET for example
strken 3y ago
> Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running This is wrong. If you want to build a web app in React you don't have to use anything except state management, which you need in absolutely any stateful application anyway and which can be a literal one-line React hook. The point about not building websites in React is valid, but...just don't do that if there's no advantage? This is about as helpful as saying you don't need to store binary blobs in Postgres. Well, no, you usually don't, but I'm still going to use Postgres for what it was actually designed to do.
joshxyz 3y ago
solid sentiments. i get a massive distaste on what bulky behemonth of a mess nextjs is along with the ssr etc. i fucking hate it. this bleeding edge stuff is whack. but one thing these geeks got right is how mature the developer tooling is around react. it just all fits well along with eslint, stylelint, vite, tailwind, etc. this cutting edge stuff is good.
mvdtnz 3y ago
I stopped writing anything in react the moment they introduced that ridiculous hooks API. Very clear they have no clue at all. There are plenty of other options that don't reach so hard to appeal to functional purist propeller-heads.
- chrisco255 3y ago
  The hooks API is entirely optional. By all means you could continue using Redux or Mobx or class components.
- kaba0 3y ago
  Sounds like you are the one without any clue, unless you have anything substantial to say.
- maronato 3y ago
  I couldn’t disagree more. Having components be pure functions makes testing and developing so much easier, not to mention the reusability of hooks. Class components were a mess. They had way too much business logic and state stuffed into them that it was impossible to maintain any reasonably large component. Of course you can still write shitty code with functional components and hooks, but at least now the paradigm itself steers you towards more maintainable code
  - nitwit005 3y ago
    Having uses both, it just feels like trading one set of quirks for another set of quirks. In general, hooks seem tidier, but the quirks of useEffect seem rather more surprising than the old way.
jmartrican 3y ago
This risk with using the simple tech to start out is that you are one feature request away from being under engineered and will have to rebuild the whole thing.
naikus 3y ago
I like react but I agree with these points in the article ...Why is there always a new way of doing things? ...Why am I learning the same thing but in a different way? ...Why was the "old" way inferior? ...Why change at all? Browsers don't move THAT quickly.
- ruszki 3y ago
  Don’t they have long posts, or Dan Abramov doesn’t talk about the reasons anymore?
Gigacore 3y ago
> React is the automatic target for a lot of newbies. They jump straight into webdev, learn some HTML/CSS and eventually work their way towards React for employability. This has been the trend largely for last 3 to 4 years with the candidates (<5 yoe) I have interviewed. I probe them on core fundamentals of Javascript, HTML and CSS. When I get to the nuances, most of them outright call it out saying that they are React developers and do not do Javascript without realizing the fact that React is based on Javascript. And other common misconception is that they assume JSX works the same way while writing the vanilla Javascript code.
- cqqxo4zV46cp 3y ago
  Yup. I’m hiring for a mid-level FE role right now, and the number of “React developers” that don’t know JS fundamentals is incomprehensible. I’m not talking about anything esoteric. Just the sorts of things that I as someone that’s far from a JS expert considers necessary to work in that space day to day. I’m more and more just taking it as a given now that someone won’t have much if any experience writing CSS by hand. If they do, never in an actual .css file. Always via some CSS in JS something or other. A strange new world out there.
  - ssijak 3y ago
    Give us some examples of JS fundamentals they do not know
    - jahewson 3y ago
      Not op but “write hello world to the DOM” and “make an http request” are questions I’ve seen go unanswered many times.
      - pronik 3y ago
        "make an http request" as in fetch() would be OK, but doing "classic" XHR in an interview? Hell no, I've got better things to do.
      - 3y ago
superice 3y ago
I have been programming since 2008, but I truly started my professional webdev career in 2014. The company I started at was providing software in a B2B-sector. Very boring, very non-startupy. They were considered innovators for doing webapps and SaaS in a market where everybody was used to win32 UIs made in Delphi or C++. The tech stack my employer used was Java EE, PostgreSQL, with a frontend in EmberJS. The prevailing view at the time was that we knew how to do applications on the backend with MVC, and that 'if we just figured out how to MVC in a JS-framework, everything would be fine'. Some went with Angular, some with EmberJS. Build steps for frontend were in its infancy, we used Gruntfiles to just concat everything together essentially. When React started to gain traction, everybody scoffed at them. JSX was weird, uni-directional data flow was weird, ES6 classes were weird, too many building steps were weird. But it quickly became clear that this was the way forward. Traditional MVC approaches quickly failed once you got out of the example code and into more complex use cases. Which brings me to my point: React was better IF-AND-ONLY-IF your webapp needed to do more than basic forms. React was never meant for consumer websites. It was never meant to be the default tool for anything on the web. If you wrote a web application, something complex, something with forms, planboards, custom UI, then yeah, it would be a sensible choice. It was meant to solve the problem that doing two-way binding of data is incredibly difficult if you have anything more than some standard form components. The reality of the situation is that innovation in frontend websites (as opposed to webapps) has mostly been standing still, as everybody just switched to using React. CSS has gotten much better, but doing something like a form rendered with PHP + some validation with JS is still a pretty painful experience. HTMX is probably the best attempt I've seen, along with Elixir and the Phoenix LiveViews. Most of the effort seems to go into writing a bunch of libraries for React to solve the complexities of having to deal with a complex set of tools for writing complex webapplications. These abstractions tend to either be complex themselves, or are leaky. I realize my next sentence might as well be 'get off my lawn', but I really hope that devs stop focussing on writing the next state management framework, or routing library, or even rewriting existing things, and just try something to actually move dev forward. Open source a kit of sensible standard components including styling for webapps. Write a simple JS tool for some form validation. Show your barebones NodeJS app rendering HTML and processing forms in an PHP-esque way, give it a logo and a fancy name, chuck it up on GitHub. Don't try and combat complexity with more complexity. We have all the tools we need to write complex webapps. Please make simple websites easier, so people can stop complaining about the complexity of the complex tools meant for complex use cases that they don't need for their simple case.
tuan 3y ago
> Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running. It feels like the author is confused between react (the library) and the its ecosystem. They don't need all those things in order to use React. - Routing: Not mandatory. You can just use server side routing. You're no longer a SPA in this case, but do you need to be a SPA ? - SSR: I actually do not understand the new obsession with SSR. If you need SEO, add a static marketing page, that might be enough for a lot of scenarios. - CSS-in-JS: just write a plain css file and class names - State management: useState + context API works for a lot of simple apps. I don't even understand why "hot reloading" is even listed in the complaints. It's a nicety, not a requirement. It's not even "react".
- nitwit005 3y ago
  People seem convinced they need to pull in 12 different libraries and frameworks these days, and then get mad that it's complicated. Of course it's complicated. You made it complicated.
bottlepalm 3y ago
Did I miss the part where he suggested what to use that's better than React? At this point we've been through enough front end churn, React is fine. Components, static typing, a javascript/html based templating language. Server and client side rendering. With Next.js my DX is better than anything I've used before. Vanilla JS? Yea, no thanks. I'm not going back to square one, choose your own adventure custom framework because of your skill issue.
- bemusedthrow75 3y ago
  I too am not going back to square one, and I find React to be fine for e.g. a Gutenberg component. But I'm looking at tiny web interfaces for microcontrollers at the moment, and as an experienced Vue developer I find petite-vue and a classless CSS framework an appealing compromise for designs without a build step. With a build step, maybe preact?
  - Osmose 3y ago
    You can use Preact + HTM to skip the build step, too. It's very nice for the middle ground where DOM management gets annoying but adding a build process would be difficult.
    - bemusedthrow75 3y ago
      I knew it was usable without the build step but it's been a while since I looked at preact and I did not know about HTM -- thank you!!
- wiseowise 3y ago
  > Vanilla JS? Yea, no thanks. I'm not going back to square one, choose your own adventure custom framework because of your skill issue. Isn't it the other way around? Those who have skill issues select React?
  - bemusedthrow75 3y ago
    No, I don't think so. It's possible to write a whole load of very clever things in vanilla JS, but it's not always a good use of time to do so, and it is not a very easy way to develop things in large teams, without building up an abstraction layer with getters and setters that is not appreciably better than a minimal reactive framework. The one-way data flow in reactive frameworks is the bit worth fighting for (and fighting over).
federalbob 3y ago
Maybe unrelated but, HN: what is your go-to stack to build simple business web site then ?
- ghiculescu 3y ago
  Rails
- 8organicbits 3y ago
  Marketing site: mkdocs with static hosting like github+Netlify (unless it needs eyecandy, I don't do those). Buy a theme or build one. Interactive sites: Django with server-side template rendering, very minimal Javascript, CSS via tailwind, bulma, or bootstrap. Buy themes if needed. Payment, billing: send users to something like typeform+stripe, avoid building custom payment processing, order management, etc. Web applications: things that need complex interaction in the browser I'd choose react.
bemusedthrow75 3y ago
This article is written from a lack of experience of fundamentals and it is not very rigorous, but it's kinda sorta not wrong. I have been thinking for a while about specialising in teaching how the web came to be, so people who are non-technical can understand enough to commission work, understand proposals, etc.; because I think people have no sense of what goes on under the hood. But increasingly I think it's junior developers and web-oriented designers who need to be taught it. (Also the developers of Hacker News: "flag" should be idempotent, surely, and not a GET request?)
- namaria 3y ago
  I also feel that there's a growing need to teach fundamentals to people across the board. On the other hand, there doesn't seem to be any market for it. So many people become 'developers' by attending 90 days bootcamps to get a job quickly and so many more avoid anything technical altogether because they're 'not a technical person'. So I doubt there's any market for teaching these basics...
  - bemusedthrow75 3y ago
    > So I doubt there's any market for teaching these basics... While working through the idea, the most challenging aspect for me has been how to describe the value of it, even though I know what the value of it is. I think there are parallels, like no longer knowing what is going on under the hood of your car, which has its own anxieties. Paradoxically I think it is non-programmers who are more interested in the kind of "history lessons" of it -- like, how did we end up here, 10,000 feet view stuff. And perhaps just a small amount of that would stop people being bamboozled by copy-and-paste nonsense in proposals, quotes, project plans etc. It strikes me as interesting to think about, that if you were to go back in time and ask someone twenty years ago if they knew much about the web, those people, who might be from diverse non-technical fields, might be able to tell you quite a lot they'd gleaned about how it actually works. Because the books on the web then taught you how it worked. Surprising people used to know about domain names and FTP servers. But nowadays, the knowledge is much higher-level, and in a way that leads people into believing things only have complex dependencies, like React or serverless designs or Cloudflare. It's like the web needs its own Raspberry Pi movement.
wouldbecouldbe 3y ago
Time to go on a tangent, does anyone think useEffect was good idea? In general I've found "side-effects" libraries like rxjs & saga's being the main cause of bugs in react codebases, and useEffect a good second.
- zeptonix 3y ago
  Kinda necessary isn't it? What would you replace it with?
- Scarblac 3y ago
  It's necessary but way overused. The docs have a whole page explaining how things some devs do with useEffect should be done differently: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect. I think class based components led to really strange patterns that people thought should all be replaced with useEffect in function components. UseEffect is sometimes necessary and then it's fine but it's a code smell too.
nosefurhairdo 3y ago
React is great; many use it badly. This is a tired debate, and the author offers no solutions or practical advice. This is someone who is tired after refactoring a badly written react application. I work on a badly written react application. I sometimes sift through our microservices written in go, ruby, and Java. They're badly written too. This is not an indictment of those languages or whatever framework or technology was used in those services. Business requirements change, engineers change, and refactoring doesn't give management anything to brag about so nobody gets time to clean up the mess. Complaining about the "churn" is even more asinine. React continues to support more usecases. New frameworks and technologies are competing and challenging one another to improve. God forbid we might have to learn something new.
- wouldbecouldbe 3y ago
  It was great, but feel like it gotten too complex. And this complexity invites for more options to do bad things.
- agos 3y ago
  many use it badly, indeed. but is React evolving in a way that makes it easier to not use it badly?
  - nosefurhairdo 3y ago
    I don't think it's possible for a framework to do all of the following: add functionality, preserve existing functionality, and reduce the possibility of dubious implementations. Also, I do think packages like those from tanstack have made it easier to implement react well. From what I can tell, most people's bad experiences with react come from applications which incorrectly use redux or similar global state as a cache for data from the server. The new Redux Toolkit Query and similar Tanstack Query approaches to handling server state are much more manageable, and in conjunction with appropriately using URLSearchParams you can often get away with no/minimal global state. In other words, React is not the problem.
abdellah123 3y ago
Kudos, right on spot. This is a very down to earth masterpiece. Much needed! Ask why?
zamalek 3y ago
React has lived long enough to become the villain. It definitely pushed web apps in the correct direction, but it has grown some nasty kludges to account for things that were very hard to foresee. Choosing to use it nowadays for greenfields projects comes across as cargo cutting to me. I somewhat disagree that the approach is ill-suited to simple sites, server-side JSX is a strong step in the right direction. If you're using it on the server you may as well use it on the client, even for minor interactivity problems.
- globular-toast 3y ago
  What would you use instead for greenfield?
  - zamalek 3y ago
    Fine-grained reactive, i.e. solid. Svelte works for that too.
- zer00eyz 3y ago
  > I somewhat disagree that the approach is ill-suited to simple sites, server-side JSX is a strong step in the right direction. Wow that sentence made me want to throw my laptop. I want you to build me a site that can be cached (think basic product shopping cart page) and then do the JS/hydration magic after the user has seen the render. Go ahead, and take your time, it's not a fun exercise in react. As for JSX on the server side... It was a shitty idea to mix presentation and code when PHP did it and got laughed at, JS/JSX isnt special. Templating languages are LIMITED for a reason. You know code/content/presentation all being separated is a good reason to do that...
  - wonnage 3y ago
    You’d rather write a bunch of nested React.createElement calls due to some unjustified religious hangup? JSX is sugar for a tree, it’s not that complicated
  - zamalek 3y ago
    I was referring to static sites, which the post talks about quite a bit. JSX is just a sane templating language. Much of the hydration stuff is accidental completely, I would argue that all is with the advent of search engine scrapers that give the page some time to render. The goal of including associated data for the first render is essential complexity - it can save up to 200ms of latency, but there are simpler ways to do that (such as data islands, early hints, or SSE). At that point JSX is, again, nothing more than a really good templating language. Data islands are my choice because they worked in the 90s meaning they will certainly work today. XML back then, but JSON works just as well. Of course, hydration is assumed to be the only solution for the react-size-fits-all crowd.
jwmoz 3y ago
I feel like finally after many years js devs are starting to see the light.
brotchie 3y ago
Bad React code can get bad really really quickly. Pretty much forced to build production systems in Angular in my day job. But typical process for prototyping new speculative functionality is: $ npm create vite@latest > React Typescript And then blindingly fast building out super hacked functionality with sub-second Write -> Compile -> Reload times (joyous vs production Angular build infra). Then after a few demos and iteration, take it all and build out a well structured Angular app. Signals + @if syntax in templates makes modern Angular development pretty good. And the strong separation between styles / component / template ends up creating more maintainable large code bases where a lot of engineers are contributing.
koonsolo 3y ago
Here is the number 1 thing you need to realize about web development: it goes from simple article websites to ecommerce to full blown applications like Photopea or Figma. People act as if it's all 'web development'. And then you get things like "We need to move back to server side rendering". And I think: why the hell did you think using a front-end only framework was ever good for your e-commerce website? It boils down to this: figure out what you're actually doing, and get the best tools for that. React is an awesome framework, but if you're building a simple blog, why the hell would you use that?
ricardobayes 3y ago
React's original problem was that its users were expecting a framework and got a library. It's not semantics what matters here, but the fact it didn't take care of fundamental parts of web apps, leaving those to be handled by someone else. And the result was often a buggy, half-working slow app, due to a mismatch of different modules. In my opinion, it is kind of like the "C" of web languages, in a way. It is powerful, but certain concepts are difficult to master and leave out too many important features. This is why nextJS is becoming so popular.
canterburry 3y ago
"...Why is there always a new way of doing things? ...Why am I learning the same thing but in a different way? ...Why was the "old" way inferior? ...Why change at all? Browsers don't move THAT quickly." Welcome to the rest of your software engineering career.
highwaylights 3y ago
> almost a decade ago with the old-fashioned MVC style of web development The idea that MVC is considered antiquated makes me wanna reach for my zimmer. Yikes. I’d say “you younguns today” but I’m certain I was the same with the JSP/COBOL/Perl people years ago. JavaScript frameworks are an unnecessary burden on most websites? We been on that.
gloosx 3y ago
React is actually really simple functional renderer, 20 files, 316 KB It is not difficult or complex at all to use pure functions and seven hooks. They are documented exceptionally well. All the complexity author is complaining about he created himself. You can keep the browser router if you want, it can be synced with reactive state using a single side-effect and a single reducer, you don't need to replace it with react-router. You don't need to use Next.js. You don't need SSR or graphql. You can use just regular CSS if you want. This is not complexity that "comes with React", React comes with nothing like that. This is complexity you are stuffing into it.
fedeb95 3y ago
you can make bad code with almost any language, library or framework. We should stop thinking that any tool prevents us from making design mistakes.
deleted 3y ago
[deleted]
0xblinq 3y ago
In my experience the sweet spot nowadays is to use a traditional batteries included framework such as Django/laravel/rails with Inertia, which basically just replaces the template part of those frameworks by a modern components framework such as Vue, react, etc. We are using this approach in one of our projects at work and it’s been working great. https://inertiajs.com/ https://inertiajs.com/
malakai521 3y ago
I've done front-end with PHP, ASP.NET Web Forms, Razor, jQuery, AngularJS, Angular and React and React was by far the most enjoyable experience I've had. It made front-end development tolerable and even fun. I've never seen React code that was as horrible as Angular one.
- javcasas 3y ago
  But, but, what do I do with the EnumerateAll@injectables plugin that I bought for Jetbrains? Do I have to not write all these @s??? What is that key in the keyboard if not for @singleton@injectable@module@component??
jinushaun 3y ago
As someone who has been doing React for nearly as long as it’s been public, the honeymooon is definitely over. Hooks were supposed to save us, but now my projects are more complicated and harder to maintain than the old class based components. My team is constantly fixing useEffect and useCallback bugs. UseEffect just traded one foot gun for another. As Vue and Svelte have shown, maybe it’s time for react to include a compile step to automate some of the boilerplate/tedium and reduce avoidable bugs.
imetatroll 3y ago
So I have a react related question regarding the following stackoverflow solution. I find myself ignoring the warning in useEffect fairly often but wonder if the solution provided is a reasonable one or not? https://stackoverflow.com/questions/64106594/is-the-useeffect-has-a-missing-dependency-warning-sometimes-wrong https://stackoverflow.com/questions/64106594/is-the-useeffec... The situation I have in mind right now is a search field which updates a local useState value. When the user hits enter to trigger submit (or clicks submit), I want the useEffect to fire. At the same time I want to be able to clear the field and submit via another button. I am probably not explaining it well but the missing dependency becomes a pain point in these situations. Is useRef basically what people end up using to work around it? As for what the article above says, I do agree that the churn in the JS world in general is very exhausting. I guess it is filled with a lot of young "talent" who have endless time and energy at their disposal.
- pas 3y ago
  the churn is because iteration-by-iteration we're moving closer to something that is just right. but that goal is also constantly changing. (not to mention that the webdev community is not a hivemind, so it makes sense that there are many tools, and many new tools.) and after a few iterations it makes sense to do a jump in some non-functional metric (vite, deno/bun), or do a vertical integration (vercel), and then new tools target those platforms, and ... if it's exhausting stop chasing the new shiny thing, and just use Angular like normal people. or HTMX :p
NoPedantsThanks 3y ago
[dead]
aabbcc1241 3y ago
Is it a behavior art? This blog cannot be read when Javascript is not enabled.

226 points by OccamsMirror 3y ago

His points are why I like Svelte. YMMV, but for me it hits the sweet spot of not having to do a lot of stuff by hand like we did in the jQuery (and earlier) days while also not being this massive, intrusive thing.

darylteo 3y ago
And thus the cycle of JS libraries continues. - Large standard library exists - "It does too much! It's slow! It's too hard to use" - "Here's a new library. It's 28kb and lightning fast" - Becomes new standard library - "... but it doesn't do this thing" - 2 rewrites later - Large standard library exists
- jraph 3y ago
  Svelte, however, has its very specific way of working compared to all the other usual frontend frameworks: virtually no runtime (library) supporting the app and many things happening at compile time instead and via generated code. It also seems quite focused. If anything is to become bloated, I would expect SvelteKit rather than Svelte, to become larger. I also don't know how much of the bloat is to be attributed to React vs. its usual friends or their numbers, and maybe SvelteKit actually helps keeping things in order in the Svelte ecosystem. Svelte has also been around for a while now. (Note that I have only small experiences with Svelte, none yet with SvelteKit)
  - pcthrowaway 3y ago
    I think it's more accurate to say that Svelte can create a build with no run-time for certain apps (so can React with SSR), but for the general case, the Svelte compiler basically builds a custom runtime that only works for your application
    - jraph 3y ago
      Yep, the custom runtime you mention would be the generated code I mentioned. When I said "runtime", I was thinking of some support library you'd need to include next to the code of your app (which is left intact by React, and mangled to death with Svelte).

Waterluvian 3y ago

Know when a tool is right or wrong for the job. But be careful not to beclown one’s self by perceiving every job as being the same job.

debacle 3y ago

This sentiment is trendy (and a bit edgy among people who still refuse to learn modern JavaScript), but it's missing the point. React is the first JavaScript platform that feels well engineered for the web. "React suffers churn" -> goes on to talk about a lot of things that aren't React. "React should stay in its lane" -> React has a router to better manage lifecycle state. And it's simple and flexible and easy to work with. "React's talent pool is diluted" -> lol "React is not fast" -> This is true if you are comparing to e.g. htmx, but except for a bulky first load, React is just as fast as anything else. "React is overengineered" -> React is simple. It's good because it's simple. The data flow and rendering flow are intuitive once you understand them, and once you think in React, things become so nice that working with plugins that aren't React-y becomes kind of frustrating. React is a great framework for app dev. It has nice conventions, a simple learning curve, a good ecoystem, and good corporate support. I don't need React, but I use it because I like it.

vsgherzi 3y ago
I don’t know about simple learning curve I feel like it’s quite a different paradigm especially compared to vanilla. Not necessarily difficult just different.
throw__away7391 3y ago
> React suffers churn This one in particular always seems to be pulled out by people advocating for yet another new framework. I don't do much frontend these days...for like a decade now, but as a mostly outsider who occasionally dabbles, React has been a constant for a long time now. The latest stuff in Next looks fantastic, in the real world we were never able to build anything nearly as nice as what is possible these days. There's a lot of historical revisionism and rose-colored glasses being worn these days, but the truth is that most web apps have always been garbage, and that will probably never change either.
- timw4mail 3y ago
  The library API itself might be stable, but the ecosystem is not. And that ecosystem has vulnerable libraries that should be updated. And that's not even going into using a big component library, like Material UI, which might be its own nightmare. This is something I've dealt with a lot personally, and I've made a good attempt to avoid unnecessary 3rd-party dependencies. But the huge churn continues in the build tooling, testing, linting, etc.

acomplexplan 3y ago

This post is just a list of grievances that don’t convince me in any way why I don’t need it. Maybe, I don’t care if it’s “overengineered” or maybe I don’t need something fast or maybe I need an abundance of talent to work on it. There are plenty of reasons why it might often be the best choice.

vsgherzi 3y ago
I feel that the documentation is often overlooked. In react I’m always confident that if I can think of something someone has likely already done it. Can’t say the same for my experience in the newest version of angular (I will admit that might be due to my noobishness)
- acomplexplan 3y ago
  [dead]

rdgddffd 3y ago

This just sounds like a bunch of vaguries that could be written about any framework. And React works fine for small projects. There’s no need to loop in a bunch of dependencies like css in js or graphql either I’ve been using it for years.

acomplexplan 3y ago
[dead]

usere9364382 3y ago

Any fool can come up with a complicated solution, but the best mind comes up with the simplest. A man I respect once said to me. React is just another example of how rot takes over what is good. And people confuse loud with popular, popular with good, easy with simple, and tedious with merit.

owlstuffing 3y ago
>Any fool can come up with a complicated solution, but the best mind comes up with the simplest I know a best mind, he made htmx.
palmfacehn 3y ago
I explained that I preferred not to build and add a React based tool to a profitable Vanilla JS app. The package included dependencies for Postgres. The purpose was to spawn a modal dialog and dispatch requests to the selected service. All of the core functionality could have been provided by a single JSON file describing the possible endpoints. Of course that kind of elegance was nowhere to be found. The discussion progressed as you'd imagine. "NPM ecosystem is the biggest developer ecosystem in the world", he replied.
- Shorel 3y ago
  NPM is a nightmare that makes old style C++ dependency management look like a next-gen wonder. It's hundreds, thousands of silly dependencies taking countless disk space, and a waste of time "minimizing" what should have never been there in the first place. I avoid Node.js like the plague. I feel nauseous just thinking about that.

hilux 3y ago

> ... when you're deep in it, its hard to miss the forest for the trees. That's very confusing. But so is the entire article. While I have your attention, as a relative newbie to web dev (with limited time and focus), is Next.js my way to go?

65 3y ago
I hate Next.js because they make it extremely difficult to deploy an SSR app anywhere except Vercel. You basically have to use the Docker image to deploy your SSR Next.js app. I prefer https://remix.run https://remix.run or https://vike.dev https://vike.dev However, if you just want a static site, Next.js is great.
- Aeolun 3y ago
  Ooh, looks like I need to check out Vike. It may address all concerns I have with Next :)
  - 65 3y ago
    I use it on my personal site. It's great - easy to use and super robust. Hopefully more people use it.
- OccamsMirror 3y ago
  There's also Astro: https://astro.build/ https://astro.build/ - which admittedly I haven't tried yet but am planning on checking out for my personal site.
  - ringofchaos 3y ago
    Astro is great, using it for my blog site and. I have a mono repo setup React SPA and Astro For Blog. I can create a reusable component in React Repo and reuse in Astro blog. You could also write native astro components which are very close to vanilla html css with added benifit of making reusable components and scoped css. And you can also use svelte or vue components.

65 3y ago

This sounds good until you want to actually get things done. I don't think of React as merely adding needless interactivity, it's also an excellent view engine. It's extremely easy to get a site up and running with easy to read and maintain code with React. Technology builds on top of itself. Might as well use the things that make you more productive. The DHH ideology of anti-modernism makes some sense in some cases, but most of the time it doesn't hold up. Thank god I can deploy my static site React app to S3 with some GitHub actions and don't have to FTP a whole site into some Linux server I pay $5/month for.

Lukas_Skywalker 3y ago
DHH never suggested to host a static site on a Linux server. He only says that most (database-backed) applications could do without frontend frameworks like React. The alternative to the „static site React app“ you‘re hosting on S3 would obviously be static HTML.
kaba0 3y ago
I like React, but I didn’t quite figure out the “additional” ecosystem - what do you use for managing the communication with your backend, for example?
lurking15 3y ago
> don't have to FTP a whole site into some Linux server I pay $5/month for I actually enjoy doing this, it's also easy to automate with github actions too

skybrian 3y ago

I'm using Preact (via Deno Fresh). Simple examples look similar. I haven't used React enough to know if I'm missing anything.

MattDaEskimo 3y ago

This sounds like the complaints from a new developer that's frustrated over the layers of web dev. React does a fantastic job working with common developer principles such as Don't Repeat Yourself, and Single Source of Truth. Their points come across as overly vague and lack any true insights into development besides initial impressions. For a static page it doesn't make sense to use React, obviously. For a highly interactive page it, or another framework is critical to clean, manageable code.

tauchunfall 3y ago
>For a static page it doesn't make sense to use React, obviously JSX is a nice templating language. And when you use Deno or Bun you can use it directly on server-side. My server-side components have no hooks and use preact-render-to-string or `renderToString()` from `react-dom/server`. Also there is Gatsby which is a popular content management system which also allow non-interactive statically rendered pages (as far as I remember).
- benatkin 3y ago
  > you can use it directly Because of a poor design choice in an otherwise well designed platform (at least in the case of Deno).
- NathanaelRea 3y ago
  Or Astro, and plugins for React/Tailwindcss/etc. Components are just nice to work with because of their modularity. Using the ergonomics "most web devs" are familiar with is just nice.
- mvdtnz 3y ago
  JSX is a mediocre templating language that's missing a ton of features from more mature templating languages like Razor
  - tauchunfall 3y ago
    >JSX is a mediocre templating language You can also complain about JSON being a mediocre data format. But I think it's minimalism and compatibility with JS made it successful.

deleted 3y ago

[deleted]

niceice 3y ago

But without the complexity that layers of abstraction create, Snapchat would only have 1 person working on buttons instead of 400.

evantbyrne 3y ago
It's amazing how much developer time is wasted writing components. I have to imagine that these jobs are at risk of being disrupted by AI though. If AIs can create designs, then they should also be able to convert design specifications into mostly-complete components. Expect the tech to exist by 2025 and disruption to component developer employment within a couple years.
- kirill5pol 3y ago
  You can use GPT-V to create functional components from images directly: There was an open source project (https://github.com/abi/screenshot-to-code https://github.com/abi/screenshot-to-code) that I borrowed the prompt from and made a custom GPT for myself where I just drag and drop the image. It’s not perfect but it’s pretty great overall! Here are the prompts: https://github.com/abi/screenshot-to-code/blob/main/backend/prompts/screenshot_system_prompts.py https://github.com/abi/screenshot-to-code/blob/main/backend/...
- wonnage 3y ago
  The hard part is usually not getting the component to look like the design but rather the fun process of discovering all the interactions nobody thought about while they were focused on pretty pictures

Osmose 3y ago

> React was meant to be a way to provide snappy page loads and UX. This is a very common misconception. React was meant to provide one-way data flow. With an app built directly on the DOM you have to deal with the DOM having its own state to manage on top of the state your own code is storing. You have a list of comments in a variable, and a list of DOM elements for each comment, and nothing but your own code is making sure they stay in sync with each other. React changed things so that the state of the DOM is always derived from your own app's state, which eliminates what turned out to be a pretty tedious and error-prone amount of work in complex web apps. It wasn't the first to provide this but its API was unique and compelling vs existing alternatives. The virtual DOM, server-side rendering, etc. are not things that make React faster than non-React code, they are things that counteract the inherent slowness in React's design to make it competitive with non-React code. Watch the original JSConf talk where React was publicly announced and released, and notice how the talk is mostly about the one-way data binding, and the virtual DOM/reconciliation are mentioned in the back half as ways React catches up to non-React app speeds: https://www.youtube.com/watch?v=GW0rj4sNH2w https://www.youtube.com/watch?v=GW0rj4sNH2w

bell_tower 3y ago
Unfortunately people do not find out what it was meant for, before they start writing about it
- 88913527 3y ago
  We're at the point where many newer engineers haven't had real hands-on DOM experience but are expected to deliver applications built in React. You need to know at least one level abstraction below your current one to use the tool effectively. This all tracks with how the industry's changed, how we hire, how we train, and so on.
  - eru 3y ago
    > You need to know at least one level abstraction below your current one to use the tool effectively. I'm not sure that's true in general. For example, for some tools there's no single 'one level abstraction below'. Let's take regular expressions as a simple example. You can use them effectively, no matter whether your regular expression matcher uses NFAs or Brzozowski derivatives under the hood as the 'one level [of] abstraction below'. (Just be careful, if your regular expression matcher uses backtracking, you might get pathological behaviour. Though memoisation makes that less likely to hit by accident in practice.)

Aeolun 3y ago

I have to agree that with the introduction of React 18, and the new versions of Next and SSR everything has taken a turn for the worse. I’m sure it’s all very fancy and advanced, but it’s become completely impossible to reason about.

teaearlgraycold 3y ago
The new Next has jumped the shark. I wish there was a good alternative right now. I feel like they’re building for FE devs who are scared to learn BE dev.
- 0xblinq 3y ago
  So far I’ve found some shelter in Remix. But I’m skeptical they won’t fuck up as well. They have a reputation of breaking everything with react router.
maronato 3y ago
I feel the same. After a year of not touching Next, I came back last week to find it’s unrecognizable. It feels like there are 10 ways of accomplishing the same things now, and Next tries very hard to make none of them feel like the right way. Want to structure your code? There are 4 ways to do it. Want to fetch data? You can use route handlers, server components, or server actions. Don’t forget to choose one of the 5 ways to cache and revalidate data! Want to show a loading indicator while the data loads? There are a few ways to do it, but be careful because some ways depend of parent components being server or client side! Not to mention all of the “unstable” apis. I appreciate that they want to make it easier to build incredibly efficient applications, but now there are so many options and so many ways to shoot yourself in the foot that I’m stuck with choice paralysis. IMO a good framework should have one and only one obvious way to accomplish something. More advanced use cases should be hidden away in the reference documentation or left as an exercise. That’s why frameworks like Django and Rails were so successful.

andrewstuart 3y ago

I love React but I use no state management, apart from useState locally within components. State management in React is a major source of pain and complexity and if you build you application using events then you can eliminate state entirely. Most state management in react is used to fill out props and get the application to behave in a certain way - don't do it - too hard, drop all that. Here is how to control your React application and make it simple and get rid of all state except useState: const ImageComponent = () => { const [cacheBust, setCacheBust] = useState(0); useEffect(() => { const eventListener = () => setCacheBust(Date.now()); window.addEventListener('customEvent', eventListener); return () => window.removeEventListener('customEvent', eventListener); }, []); return ( <div> <h2>Profile Image</h2> <img src={`https://example.com/profile-image.jpg?cachebust=${cacheBust}`} // Image URL with cacheBust as query param alt="Profile" style={{ maxWidth: '200px' }} /> </div> ); }; // Component that dispatches custom event const DispatcherComponent = () => { const dispatchCustomEvent = () => window.dispatchEvent(new CustomEvent('customEvent')); return ( <div> <h2>Dispatcher Component</h2> <button onClick={dispatchCustomEvent}>Reload Image</button> </div> ); }; Trust me - once you switch to using custom events you can ditch all that crazy state and crazy usage of props to drive the behaviour of your application.

stnmtn 3y ago
How is this different from the goal of redux or contexts other than ergonomics?
- andrewstuart 3y ago
  I don't see anything in common with Redux or contexts. No libraries. No higher order components. No concepts to learn. No weird rules. No complex tracing of props and trying to work out why state updates were not triggered, or were triggered. Redux is one of the most painful software development experiences I have had. Just the thought of using Redux fills me with dread. The event code above simply sends a message directly between components - that's nothing at all like Redux. Can you describe how the above is like Redux?

adamzochowski 3y ago

Oh the irony of a text blog bemoaning complexity that won't load without javascript.

chrisco255 3y ago
Ironically if they had written it in server side react it would work without JS.

gustavus 3y ago

Cycle of frameworks: Young dev: it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use. Time passes, framework becomes popular blogs write about how framework X is the future. If you don't have 10 years in framework X you can't get a job. People start using it for things features get added to accommodate needs. People argue saying it's necessary it fits the demand. Framework X becomes a gigantic bloated monstrosity, development slows as useless bureaucratic leeches posing as developers create a "foundation" to "shepherd Framework X towards a bright future." At this point usually the creator leaves or is driven out. A young developer comes along and says to himself "it is way too complicated to do something as simple as a todo or hello world app. You have to configure a dozen settings, install 10,000 dependencies and fiddle with too much stuff. I'm going to create a framework that is simple, lightweight and easy to use." The Wheel of Development turns, and frameworks come and pass, leaving defaults that become best practices. Best practices fades to srandards, and even standards is long forgotten when the problem that gave it birth comes again.”

kevinsync 3y ago
lol which of the Forsaken is React? Aginor, creator of the Shadow DOM?
giljabeab 3y ago
On the contrary some much older and experienced frameworks are simplifying and consolidating. .NET for example

strken 3y ago

> Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running This is wrong. If you want to build a web app in React you don't have to use anything except state management, which you need in absolutely any stateful application anyway and which can be a literal one-line React hook. The point about not building websites in React is valid, but...just don't do that if there's no advantage? This is about as helpful as saying you don't need to store binary blobs in Postgres. Well, no, you usually don't, but I'm still going to use Postgres for what it was actually designed to do.

joshxyz 3y ago

solid sentiments. i get a massive distaste on what bulky behemonth of a mess nextjs is along with the ssr etc. i fucking hate it. this bleeding edge stuff is whack. but one thing these geeks got right is how mature the developer tooling is around react. it just all fits well along with eslint, stylelint, vite, tailwind, etc. this cutting edge stuff is good.

mvdtnz 3y ago

I stopped writing anything in react the moment they introduced that ridiculous hooks API. Very clear they have no clue at all. There are plenty of other options that don't reach so hard to appeal to functional purist propeller-heads.

chrisco255 3y ago
The hooks API is entirely optional. By all means you could continue using Redux or Mobx or class components.
kaba0 3y ago
Sounds like you are the one without any clue, unless you have anything substantial to say.
maronato 3y ago
I couldn’t disagree more. Having components be pure functions makes testing and developing so much easier, not to mention the reusability of hooks. Class components were a mess. They had way too much business logic and state stuffed into them that it was impossible to maintain any reasonably large component. Of course you can still write shitty code with functional components and hooks, but at least now the paradigm itself steers you towards more maintainable code
- nitwit005 3y ago
  Having uses both, it just feels like trading one set of quirks for another set of quirks. In general, hooks seem tidier, but the quirks of useEffect seem rather more surprising than the old way.

jmartrican 3y ago

This risk with using the simple tech to start out is that you are one feature request away from being under engineered and will have to rebuild the whole thing.

naikus 3y ago

I like react but I agree with these points in the article ...Why is there always a new way of doing things? ...Why am I learning the same thing but in a different way? ...Why was the "old" way inferior? ...Why change at all? Browsers don't move THAT quickly.

ruszki 3y ago
Don’t they have long posts, or Dan Abramov doesn’t talk about the reasons anymore?

Gigacore 3y ago

> React is the automatic target for a lot of newbies. They jump straight into webdev, learn some HTML/CSS and eventually work their way towards React for employability. This has been the trend largely for last 3 to 4 years with the candidates (<5 yoe) I have interviewed. I probe them on core fundamentals of Javascript, HTML and CSS. When I get to the nuances, most of them outright call it out saying that they are React developers and do not do Javascript without realizing the fact that React is based on Javascript. And other common misconception is that they assume JSX works the same way while writing the vanilla Javascript code.

cqqxo4zV46cp 3y ago
Yup. I’m hiring for a mid-level FE role right now, and the number of “React developers” that don’t know JS fundamentals is incomprehensible. I’m not talking about anything esoteric. Just the sorts of things that I as someone that’s far from a JS expert considers necessary to work in that space day to day. I’m more and more just taking it as a given now that someone won’t have much if any experience writing CSS by hand. If they do, never in an actual .css file. Always via some CSS in JS something or other. A strange new world out there.
- ssijak 3y ago
  Give us some examples of JS fundamentals they do not know
  - jahewson 3y ago
    Not op but “write hello world to the DOM” and “make an http request” are questions I’ve seen go unanswered many times.
    - pronik 3y ago
      "make an http request" as in fetch() would be OK, but doing "classic" XHR in an interview? Hell no, I've got better things to do.
    - 3y ago

superice 3y ago

I have been programming since 2008, but I truly started my professional webdev career in 2014. The company I started at was providing software in a B2B-sector. Very boring, very non-startupy. They were considered innovators for doing webapps and SaaS in a market where everybody was used to win32 UIs made in Delphi or C++. The tech stack my employer used was Java EE, PostgreSQL, with a frontend in EmberJS. The prevailing view at the time was that we knew how to do applications on the backend with MVC, and that 'if we just figured out how to MVC in a JS-framework, everything would be fine'. Some went with Angular, some with EmberJS. Build steps for frontend were in its infancy, we used Gruntfiles to just concat everything together essentially. When React started to gain traction, everybody scoffed at them. JSX was weird, uni-directional data flow was weird, ES6 classes were weird, too many building steps were weird. But it quickly became clear that this was the way forward. Traditional MVC approaches quickly failed once you got out of the example code and into more complex use cases. Which brings me to my point: React was better IF-AND-ONLY-IF your webapp needed to do more than basic forms. React was never meant for consumer websites. It was never meant to be the default tool for anything on the web. If you wrote a web application, something complex, something with forms, planboards, custom UI, then yeah, it would be a sensible choice. It was meant to solve the problem that doing two-way binding of data is incredibly difficult if you have anything more than some standard form components. The reality of the situation is that innovation in frontend websites (as opposed to webapps) has mostly been standing still, as everybody just switched to using React. CSS has gotten much better, but doing something like a form rendered with PHP + some validation with JS is still a pretty painful experience. HTMX is probably the best attempt I've seen, along with Elixir and the Phoenix LiveViews. Most of the effort seems to go into writing a bunch of libraries for React to solve the complexities of having to deal with a complex set of tools for writing complex webapplications. These abstractions tend to either be complex themselves, or are leaky. I realize my next sentence might as well be 'get off my lawn', but I really hope that devs stop focussing on writing the next state management framework, or routing library, or even rewriting existing things, and just try something to actually move dev forward. Open source a kit of sensible standard components including styling for webapps. Write a simple JS tool for some form validation. Show your barebones NodeJS app rendering HTML and processing forms in an PHP-esque way, give it a logo and a fancy name, chuck it up on GitHub. Don't try and combat complexity with more complexity. We have all the tools we need to write complex webapps. Please make simple websites easier, so people can stop complaining about the complexity of the complex tools meant for complex use cases that they don't need for their simple case.

tuan 3y ago

> Adding a view library is helpful, but with it these days comes state management, routing, graphql, SSR, hot reloading, CSS-in-JS, and just mountains and mountains of related things just to get your app running. It feels like the author is confused between react (the library) and the its ecosystem. They don't need all those things in order to use React. - Routing: Not mandatory. You can just use server side routing. You're no longer a SPA in this case, but do you need to be a SPA ? - SSR: I actually do not understand the new obsession with SSR. If you need SEO, add a static marketing page, that might be enough for a lot of scenarios. - CSS-in-JS: just write a plain css file and class names - State management: useState + context API works for a lot of simple apps. I don't even understand why "hot reloading" is even listed in the complaints. It's a nicety, not a requirement. It's not even "react".

nitwit005 3y ago
People seem convinced they need to pull in 12 different libraries and frameworks these days, and then get mad that it's complicated. Of course it's complicated. You made it complicated.

bottlepalm 3y ago

Did I miss the part where he suggested what to use that's better than React? At this point we've been through enough front end churn, React is fine. Components, static typing, a javascript/html based templating language. Server and client side rendering. With Next.js my DX is better than anything I've used before. Vanilla JS? Yea, no thanks. I'm not going back to square one, choose your own adventure custom framework because of your skill issue.

bemusedthrow75 3y ago
I too am not going back to square one, and I find React to be fine for e.g. a Gutenberg component. But I'm looking at tiny web interfaces for microcontrollers at the moment, and as an experienced Vue developer I find petite-vue and a classless CSS framework an appealing compromise for designs without a build step. With a build step, maybe preact?
- Osmose 3y ago
  You can use Preact + HTM to skip the build step, too. It's very nice for the middle ground where DOM management gets annoying but adding a build process would be difficult.
  - bemusedthrow75 3y ago
    I knew it was usable without the build step but it's been a while since I looked at preact and I did not know about HTM -- thank you!!
wiseowise 3y ago
> Vanilla JS? Yea, no thanks. I'm not going back to square one, choose your own adventure custom framework because of your skill issue. Isn't it the other way around? Those who have skill issues select React?
- bemusedthrow75 3y ago
  No, I don't think so. It's possible to write a whole load of very clever things in vanilla JS, but it's not always a good use of time to do so, and it is not a very easy way to develop things in large teams, without building up an abstraction layer with getters and setters that is not appreciably better than a minimal reactive framework. The one-way data flow in reactive frameworks is the bit worth fighting for (and fighting over).

federalbob 3y ago

Maybe unrelated but, HN: what is your go-to stack to build simple business web site then ?

ghiculescu 3y ago
Rails
8organicbits 3y ago
Marketing site: mkdocs with static hosting like github+Netlify (unless it needs eyecandy, I don't do those). Buy a theme or build one. Interactive sites: Django with server-side template rendering, very minimal Javascript, CSS via tailwind, bulma, or bootstrap. Buy themes if needed. Payment, billing: send users to something like typeform+stripe, avoid building custom payment processing, order management, etc. Web applications: things that need complex interaction in the browser I'd choose react.

bemusedthrow75 3y ago

This article is written from a lack of experience of fundamentals and it is not very rigorous, but it's kinda sorta not wrong. I have been thinking for a while about specialising in teaching how the web came to be, so people who are non-technical can understand enough to commission work, understand proposals, etc.; because I think people have no sense of what goes on under the hood. But increasingly I think it's junior developers and web-oriented designers who need to be taught it. (Also the developers of Hacker News: "flag" should be idempotent, surely, and not a GET request?)

namaria 3y ago
I also feel that there's a growing need to teach fundamentals to people across the board. On the other hand, there doesn't seem to be any market for it. So many people become 'developers' by attending 90 days bootcamps to get a job quickly and so many more avoid anything technical altogether because they're 'not a technical person'. So I doubt there's any market for teaching these basics...
- bemusedthrow75 3y ago
  > So I doubt there's any market for teaching these basics... While working through the idea, the most challenging aspect for me has been how to describe the value of it, even though I know what the value of it is. I think there are parallels, like no longer knowing what is going on under the hood of your car, which has its own anxieties. Paradoxically I think it is non-programmers who are more interested in the kind of "history lessons" of it -- like, how did we end up here, 10,000 feet view stuff. And perhaps just a small amount of that would stop people being bamboozled by copy-and-paste nonsense in proposals, quotes, project plans etc. It strikes me as interesting to think about, that if you were to go back in time and ask someone twenty years ago if they knew much about the web, those people, who might be from diverse non-technical fields, might be able to tell you quite a lot they'd gleaned about how it actually works. Because the books on the web then taught you how it worked. Surprising people used to know about domain names and FTP servers. But nowadays, the knowledge is much higher-level, and in a way that leads people into believing things only have complex dependencies, like React or serverless designs or Cloudflare. It's like the web needs its own Raspberry Pi movement.

wouldbecouldbe 3y ago

Time to go on a tangent, does anyone think useEffect was good idea? In general I've found "side-effects" libraries like rxjs & saga's being the main cause of bugs in react codebases, and useEffect a good second.

zeptonix 3y ago
Kinda necessary isn't it? What would you replace it with?
Scarblac 3y ago
It's necessary but way overused. The docs have a whole page explaining how things some devs do with useEffect should be done differently: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect. I think class based components led to really strange patterns that people thought should all be replaced with useEffect in function components. UseEffect is sometimes necessary and then it's fine but it's a code smell too.

nosefurhairdo 3y ago

React is great; many use it badly. This is a tired debate, and the author offers no solutions or practical advice. This is someone who is tired after refactoring a badly written react application. I work on a badly written react application. I sometimes sift through our microservices written in go, ruby, and Java. They're badly written too. This is not an indictment of those languages or whatever framework or technology was used in those services. Business requirements change, engineers change, and refactoring doesn't give management anything to brag about so nobody gets time to clean up the mess. Complaining about the "churn" is even more asinine. React continues to support more usecases. New frameworks and technologies are competing and challenging one another to improve. God forbid we might have to learn something new.

wouldbecouldbe 3y ago
It was great, but feel like it gotten too complex. And this complexity invites for more options to do bad things.
agos 3y ago
many use it badly, indeed. but is React evolving in a way that makes it easier to not use it badly?
- nosefurhairdo 3y ago
  I don't think it's possible for a framework to do all of the following: add functionality, preserve existing functionality, and reduce the possibility of dubious implementations. Also, I do think packages like those from tanstack have made it easier to implement react well. From what I can tell, most people's bad experiences with react come from applications which incorrectly use redux or similar global state as a cache for data from the server. The new Redux Toolkit Query and similar Tanstack Query approaches to handling server state are much more manageable, and in conjunction with appropriately using URLSearchParams you can often get away with no/minimal global state. In other words, React is not the problem.

abdellah123 3y ago

Kudos, right on spot. This is a very down to earth masterpiece. Much needed! Ask why?

zamalek 3y ago

React has lived long enough to become the villain. It definitely pushed web apps in the correct direction, but it has grown some nasty kludges to account for things that were very hard to foresee. Choosing to use it nowadays for greenfields projects comes across as cargo cutting to me. I somewhat disagree that the approach is ill-suited to simple sites, server-side JSX is a strong step in the right direction. If you're using it on the server you may as well use it on the client, even for minor interactivity problems.

globular-toast 3y ago
What would you use instead for greenfield?
- zamalek 3y ago
  Fine-grained reactive, i.e. solid. Svelte works for that too.
zer00eyz 3y ago
> I somewhat disagree that the approach is ill-suited to simple sites, server-side JSX is a strong step in the right direction. Wow that sentence made me want to throw my laptop. I want you to build me a site that can be cached (think basic product shopping cart page) and then do the JS/hydration magic after the user has seen the render. Go ahead, and take your time, it's not a fun exercise in react. As for JSX on the server side... It was a shitty idea to mix presentation and code when PHP did it and got laughed at, JS/JSX isnt special. Templating languages are LIMITED for a reason. You know code/content/presentation all being separated is a good reason to do that...
- wonnage 3y ago
  You’d rather write a bunch of nested React.createElement calls due to some unjustified religious hangup? JSX is sugar for a tree, it’s not that complicated
- zamalek 3y ago
  I was referring to static sites, which the post talks about quite a bit. JSX is just a sane templating language. Much of the hydration stuff is accidental completely, I would argue that all is with the advent of search engine scrapers that give the page some time to render. The goal of including associated data for the first render is essential complexity - it can save up to 200ms of latency, but there are simpler ways to do that (such as data islands, early hints, or SSE). At that point JSX is, again, nothing more than a really good templating language. Data islands are my choice because they worked in the 90s meaning they will certainly work today. XML back then, but JSON works just as well. Of course, hydration is assumed to be the only solution for the react-size-fits-all crowd.

jwmoz 3y ago

I feel like finally after many years js devs are starting to see the light.

brotchie 3y ago

Bad React code can get bad really really quickly. Pretty much forced to build production systems in Angular in my day job. But typical process for prototyping new speculative functionality is: $ npm create vite@latest > React Typescript And then blindingly fast building out super hacked functionality with sub-second Write -> Compile -> Reload times (joyous vs production Angular build infra). Then after a few demos and iteration, take it all and build out a well structured Angular app. Signals + @if syntax in templates makes modern Angular development pretty good. And the strong separation between styles / component / template ends up creating more maintainable large code bases where a lot of engineers are contributing.

koonsolo 3y ago

Here is the number 1 thing you need to realize about web development: it goes from simple article websites to ecommerce to full blown applications like Photopea or Figma. People act as if it's all 'web development'. And then you get things like "We need to move back to server side rendering". And I think: why the hell did you think using a front-end only framework was ever good for your e-commerce website? It boils down to this: figure out what you're actually doing, and get the best tools for that. React is an awesome framework, but if you're building a simple blog, why the hell would you use that?

ricardobayes 3y ago

React's original problem was that its users were expecting a framework and got a library. It's not semantics what matters here, but the fact it didn't take care of fundamental parts of web apps, leaving those to be handled by someone else. And the result was often a buggy, half-working slow app, due to a mismatch of different modules. In my opinion, it is kind of like the "C" of web languages, in a way. It is powerful, but certain concepts are difficult to master and leave out too many important features. This is why nextJS is becoming so popular.

canterburry 3y ago

"...Why is there always a new way of doing things? ...Why am I learning the same thing but in a different way? ...Why was the "old" way inferior? ...Why change at all? Browsers don't move THAT quickly." Welcome to the rest of your software engineering career.

highwaylights 3y ago

> almost a decade ago with the old-fashioned MVC style of web development The idea that MVC is considered antiquated makes me wanna reach for my zimmer. Yikes. I’d say “you younguns today” but I’m certain I was the same with the JSP/COBOL/Perl people years ago. JavaScript frameworks are an unnecessary burden on most websites? We been on that.

gloosx 3y ago

React is actually really simple functional renderer, 20 files, 316 KB It is not difficult or complex at all to use pure functions and seven hooks. They are documented exceptionally well. All the complexity author is complaining about he created himself. You can keep the browser router if you want, it can be synced with reactive state using a single side-effect and a single reducer, you don't need to replace it with react-router. You don't need to use Next.js. You don't need SSR or graphql. You can use just regular CSS if you want. This is not complexity that "comes with React", React comes with nothing like that. This is complexity you are stuffing into it.

fedeb95 3y ago

you can make bad code with almost any language, library or framework. We should stop thinking that any tool prevents us from making design mistakes.

deleted 3y ago

[deleted]

0xblinq 3y ago

In my experience the sweet spot nowadays is to use a traditional batteries included framework such as Django/laravel/rails with Inertia, which basically just replaces the template part of those frameworks by a modern components framework such as Vue, react, etc. We are using this approach in one of our projects at work and it’s been working great. https://inertiajs.com/ https://inertiajs.com/

malakai521 3y ago

I've done front-end with PHP, ASP.NET Web Forms, Razor, jQuery, AngularJS, Angular and React and React was by far the most enjoyable experience I've had. It made front-end development tolerable and even fun. I've never seen React code that was as horrible as Angular one.

javcasas 3y ago
But, but, what do I do with the EnumerateAll@injectables plugin that I bought for Jetbrains? Do I have to not write all these @s??? What is that key in the keyboard if not for @singleton@injectable@module@component??

jinushaun 3y ago

As someone who has been doing React for nearly as long as it’s been public, the honeymooon is definitely over. Hooks were supposed to save us, but now my projects are more complicated and harder to maintain than the old class based components. My team is constantly fixing useEffect and useCallback bugs. UseEffect just traded one foot gun for another. As Vue and Svelte have shown, maybe it’s time for react to include a compile step to automate some of the boilerplate/tedium and reduce avoidable bugs.

imetatroll 3y ago

So I have a react related question regarding the following stackoverflow solution. I find myself ignoring the warning in useEffect fairly often but wonder if the solution provided is a reasonable one or not? https://stackoverflow.com/questions/64106594/is-the-useeffect-has-a-missing-dependency-warning-sometimes-wrong https://stackoverflow.com/questions/64106594/is-the-useeffec... The situation I have in mind right now is a search field which updates a local useState value. When the user hits enter to trigger submit (or clicks submit), I want the useEffect to fire. At the same time I want to be able to clear the field and submit via another button. I am probably not explaining it well but the missing dependency becomes a pain point in these situations. Is useRef basically what people end up using to work around it? As for what the article above says, I do agree that the churn in the JS world in general is very exhausting. I guess it is filled with a lot of young "talent" who have endless time and energy at their disposal.

pas 3y ago
the churn is because iteration-by-iteration we're moving closer to something that is just right. but that goal is also constantly changing. (not to mention that the webdev community is not a hivemind, so it makes sense that there are many tools, and many new tools.) and after a few iterations it makes sense to do a jump in some non-functional metric (vite, deno/bun), or do a vertical integration (vercel), and then new tools target those platforms, and ... if it's exhausting stop chasing the new shiny thing, and just use Angular like normal people. or HTMX :p

NoPedantsThanks 3y ago

[dead]

aabbcc1241 3y ago

Is it a behavior art? This blog cannot be read when Javascript is not enabled.