8 ms·
I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively
by ehnto 9mo ago
I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction.
Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someone knows is React or other frameworks, things get overengineered. They didn't realise it could be so much simpler if they just knocked it back a layer instead of climbing higher and higher.
- teaearlgraycold 9mo agoWorse still is the misunderstanding that React is simple. It’s an endless stream of cache invalidation bugs. Linters are getting better at catching these. But they also have false positives.
- tiborsaas 9mo agoWhat is cache in this context? useState? What do you mean by cache invalidation in react apps?
- azangru 9mo agoStale closures, perhaps.
- danabramov 9mo agoIt never happens if you enable the lint rule.
- azangru 9mo agoI remember how react team's message, around the time hooks were introduced, was how hooks were going to save us from the tyranny of `this`, which people presumably found confusing. I often think back to that message, while adding things in a dependency array. Especially those things that I know won't change (e.g. the redux `dispatch` function pulled from the context), but the linter doesn't. Or while being admonished by the linter for reading from a ref, or writing to it.
- hahahahhaah 9mo agoThe problem is app-document impedence mismatch. CSS makes stuff easier but for doc-like pages. In addition doc-like pages want some app-like niceness too. If you need to be an app you usually need a framework to stay sane (evidence: most other native UI kits are frameworks of some sort) and thus React etc. But they want full contol. Thus 2 ways to do a radio etc.
- wouldbecouldbe 9mo agoIt was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better
- realusername 9mo agoI also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase. The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?
- jcgl 9mo agoYeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks. I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.
- Tade0 9mo agoI've been doing frontend since 2012 and I still don't understand why React became so popular. No two React projects are the same. Like, even the router has at least three different mainstream options to choose from. It's exhausting.
- realusername 9mo agoEven when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently
- 9mo ago
- curtisblaine 9mo agoManaging state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.
- stevepotter 9mo agoRight. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain
- curtisblaine 9mo agoIt's not even the young devs. It looks like most of those complaining are back end developers who "rarely tinker with frontend" but think they can teach everyone else how to make it simple because "it should be static forms". A great example of all-world-is-a-nail stance mixed with extreme hubris.
- ehnto 9mo agoI did spend a serious amount of commercial time developing fronted UIs in React, Angular, and the before times in vanilla JS/css. I even wrote my own UI framework in Web Components, developed my own CSS framework used by an agency churning out projects for years. You get the idea, I did the thing, commercially, for over a decade. React and Angular are absolutely more complex in practice. That's fine, if you want the features go ham. But you don't need them, and most people mis-use the power and end up with a slow complex mess. Perhaps those same people would have a slow complex mess in vanilla tools too though, so maybe React is a scapegoat like PHP was, and Javascript was.
- QuadmasterXLII 9mo agoi’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.
- smartmic 9mo agoYou make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time. Due to the divergent complexity of today's abstractions and unavoidable leaks, we have a plethora of "modern" frameworks and tools that are difficult to use and create mental strain for developers. In short, I always avoid using such frameworks and prefer the old, boring basics wherever possible.
- throwaway5465 9mo ago> divergent complexity of today's abstractions The vast majority of websites and apps do not have complex divergent abstraction needs. Some developers however require complex divergent abstractions in order to baffle brains and collect paycheck.
- Bewelge 9mo agoI'm struggling to form a definitive statement about my thoughts here, but I'll give it a try: Every (useful) abstraction that aims to make an action easier will have to be more complex inside than doing the action itself. Would love for someone to challenge this or find better words. But honestly, if that's not the case, you end up with something like leftPad. Libraries also almost always cover more than one use case, which also leads to them being more complex than a simple tailored solution.
- shermantanktop 9mo agoI think of it as: adding an abstraction relocates complexity away from what you want to make easy and moves it somewhere else. It does not eliminate complexity in total, it increases it. The best abstractions have a soft edge between using them and not using them. The worst are like black holes.
- DaanDL 9mo agoThe problem is also that every other year contracts/paradigms/... are broken, introducing bugs in libraries and documentation.
- WA 9mo ago> when all someone knows is React or other frameworks, things get overengineered The next level annoyance is that everybody just assumes React to be the default for everything. Check the Shadcn website. The landing page doesn’t mention that this is a React-only UI library at all. Same with Radix. The marketing sounds like a general-purpose UI lib. You gotta dig around a bit to realize that this is React-only.
- TheCapeGreek 9mo agoI've started straight up being doubtful of every UI kit until I see in the docs a HTML or non-React example.
- trueno 9mo agomy brain for whatever reason won't accept react it's just instant ejection. i was there in the before times all the way up till jquery became uncool and i just tuned out of front end entirely once react and all the stuff driven by facebook became so ubiquitous, my soul just does not want to dabble in any of it. i think im mostly just appalled at what feels like over complexity that might've made sense over a decade ago but perhaps im waiting for a more satisfying paradigm to come along. i dunno. i had some sparks of joy tinkering with golang to build ssr stuff, i dont keep up with wasm at all but i hope its cruising along. i wonder if what im after is like some kinda dead simple easy to use declarative front end api that can be built from a backend, something like streamlit or nicegui that has great ergonomics and is easy to maintain but scales better and has better state mgmt than streamlit & puts all the power of a general purpose programming language right there with it. i love compiled things i hate setting up environments with runtimes and stuff.
- i-am-gizm0 9mo agoObligatory "you should try Svelte"
- deleted 9mo ago[deleted]
- 9mo ago
- socalgal2 9mo agoIs this the same with everything? In the past, a hard drive, a mouse, or a web camera was a dumb piece of hardware and a driver that ran on your PC. Now, IIUC, each of those has it's own computer (SoC) running an entire OS. Your phone probably has ~20+ SoC. One for USB, one for Wifi, One for Bluetooth, one for each of the 4 cameras, one for lidar, one for SSD, one for cellular, one for the secure enclave, one for audio, Each of them is an entire computer, more powerful than most 1980s general purpose computers, running an entire OS with multiple abstractions internally and all of that to make that device appear as yet another abstraction. Am I wrong?
- layer8 9mo agoThere is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.
- sorahn 9mo agoI don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup. Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have to make a 27 div component to style an input. The big problem is trying to convince the rest of the team that they should learn and use CSS.
- rahoulb 9mo agoI agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays. I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc). One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/ https://every-layout.dev/).
- stavros 9mo agoI really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps. Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?
- sorahn 9mo agoIf you're experienced with or like the way CSS works, and you didn't like Tailwind, then you were probably using it correctly.
- mhitza 9mo ago> and it seemed like setting style="" on all elements, but with extra steps. And extra benefits. Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.
- 9mo ago
- danabramov 9mo agoFor what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input. React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.
- deleted 9mo ago[deleted]
- jagged-chisel 9mo ago> That’s the power of component abstraction. Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.
- nine_k 9mo agoWhat are some much better ways to do components? React with is so prevalent because it's a deep local optimum.
- fsniper 9mo agoSo is a span or div element? What am I missing here?
- daveidol 9mo agoThe parent comment is seemingly blaming React for the decisions of Shadcn for some reason. There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).
- danabramov 9mo agoThe point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.
- christophilus 9mo agoI guess it depends on your definition of complexity. Being able to think about your UI as a function of state is a lot simpler than dealing with mutability, coordinating imperative updates all over the place, etc. React’s core idea is simpler than the paradigms it replaced. By simple, I mean as in “Simple Made Easy”[0]. [0] https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1hZGUgZWFzeQ%3D%3D https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1...
- cztomsik 9mo agoReact is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video). Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in <50 lines and then you own the code and can make project-specific changes. Maybe that's the biggest issue after all, people being lazy, expecting to do npm install and being able to reuse everything in any situation. Except that it almost never work like that and a lot of damage is done in the name of it... </rant>
- christophilus 9mo agoWell, to be fair, Preact is what I use. I use the name Preact annd React interchangeably when discussing tech, but I agree Preact is the simpler and preferable of the two. But, in the context of this thread, both provide a nearly identical way to model UI.
- frderrin 9mo ago> React is much more complex than the technology it's building on. Necessarily, to enable it's features React, just like most software today, is excessively complex for the tasks it performs. The only reason React is used is that many use it as a framework to attempt to provide more interactivity on the page without page reloads. There are other frameworks to do this, but none are as well-used. Webpage interactivity with data was accomplished with page reloads via cgi-bin in the 1990s. Everything that has been done since then was not strictly necessary to produce the websites we use today; it would just be a more choppy experience. A smoother experience didn’t require the overwhelming complexity that was introduced primarily in the 2010s in a framework war that React basically won. That complexity is the reason why many web and full-stack developers in the 2010s (such as myself) lost their minds and quit or seem incredibly depressed, grumpy, and confused much of the time today, and why some have invented strange new frameworks to attempt to reduce this complexity.
- holbrad 9mo agoI'm just genuinely really confused by this take. It's a 100x easier to build products today than it was in the 1990's. (I don't think that's an exaggeration in the slightest) It would be basically be impossible to build anything like Maps, Excaidraw, Chat GPT etc. Arguably people are reaching for the tools without those interactive requirements ?
- ezst 9mo agoReact was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.
- dyeje 9mo agoI did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.
- NoGravitas 9mo ago> The core insight of UI being a function of state is a good one. We had that before, it was called HATEOAS.
- mooktakim 9mo agoI've seen React components where div is used with click event for adding a normal link
- tomashubelbauer 9mo agoFWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
- elktown 9mo agoNot everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
- andai 9mo agoMost software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)
- elktown 9mo agoThere are indeed less user-centric metrics with surprising weight when it comes down to it. I've also noticed that "We read a FAANG blog post and got enchanted" is easily remembered as "Everything was bad and we had to change it all" ;).
- jauntywundrkind 9mo agoI don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain? SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support. I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.