The ecosystem lock-in is real. We rebuilt our frontend 3 times and kept coming back to React not because it was the best choice, but because hiring developers who know anything else was so hard. The irony is that React's 'flexibility' means you spend more time choosing between 50 different state management libraries than actually building features haha
React is winning by default and slowing innovation
191–200 of 866 posts
Re: React is winning by default and slowing innovation
#192As someone still building websites mostly like it's 2010, it's funny to look at these discussions. "How do we abstract away browser APIs" — but what if you just do not ? What if you use them directly? What if you don't do client-side rendering unless absolutely necessary? The two most modern tools I use in my web stack are TypeScript and PostCSS. But these are build tools that make my life easier. At runtime, I still…
The same is true everywhere in tech, I swear.
"What if we abstracted away X?"
My dude, you're already operating on like five levels of abstractions, and you haven't the slightest clue how any of them work. The answer isn't another abstraction, it's learning how computers actually operate.
Re: React is winning by default and slowing innovation
#193React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decis…
Remix v3 isn't react though, the alternative is react router 7
React router have completely bungled their marketing and PR, but they still make the best web framework out there
Re: React is winning by default and slowing innovation
#194I use html and server side rendering. The whole react thing has passed me by. If I need to use a js framework to add interactivity it’s Alpine. But then I just ask myself the question? Is this bad design? And if the answer is yes, I look for a vanilla html approach. Bye the way... the answer is always yes.
Yeah, I have to admit I don't really understand the need for front end frameworks in 2025 with how fully featured vanilla JS and CSS are.
With web components and a little bit of good architecture you can sidestep most front-end complexity. And server-side rendering dramatically simplifies state, because your state is now the database.
Re: React is winning by default and slowing innovation
#195I would say react being the default expands to apps that normally would work perfectly server-side rendered. The insane amount of added boiler plate associated with writing an API, tests for the API (including contract tests), API documentation, API versioning concerns, deployment timing considerations; front-end API integration, front-end state management, front-end tests, API mocks, I feel like there's about 10 more items I could rattle off.
I feel like people forget that web apps can be rendered server-side, and with HTML-over-the-wire (HMTX, Rails Hotwire, Phoenix LiveView, Larvel LiveWire, etc), server-side rendered apps can have a UX similar to a react app, but with far less total effort.
Re: React is winning by default and slowing innovation
#196React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decis…
If react adds extra render time and extra dev time, what is it saving?
Re: React is winning by default and slowing innovation
#197As someone still building websites mostly like it's 2010, it's funny to look at these discussions. "How do we abstract away browser APIs" — but what if you just do not ? What if you use them directly? What if you don't do client-side rendering unless absolutely necessary? The two most modern tools I use in my web stack are TypeScript and PostCSS. But these are build tools that make my life easier. At runtime, I still…
The same is true everywhere in tech, I swear. "What if we abstracted away X?" My dude, you're already operating on like five levels of abstractions, and you haven't the slightest clue how any of them work. The answer isn't another abstraction, it's learning how computers actually operate.
Why? I don't care how the chrome engine works. I care about building a great CX and making money
Re: React is winning by default and slowing innovation
#198Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…
At my large corporation, we are required to use a centralized React library for internal apps. So it is not “react by default”, but instead “React is the only choice”. 100% agree that our path out is for the central library to be reimplemented as web components to open us up to using whatever framework we choose.
Re: React is winning by default and slowing innovation
#199People using react do not care of availability, of accessibility, of links, of the web foundations. They probably do not know why they are important. Beata ignoranza.
Re: React is winning by default and slowing innovation
#200Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…
Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch. Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attribute…
> the fact that you can only pass strings as attributes
This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.
Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.