Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

811–820 of 866 posts

Re: React is winning by default and slowing innovation

#811
post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS?

This is actually the selling point to me. As someone who started learning pure HTML, JSX just makes a lot of sense to me intuitively. It feels like intelligent HTML

Re: React is winning by default and slowing innovation

#812

Earlier quoted context omitted.

> 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…

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well). Web components can be passed objects in JS, but its news to me if that is available in HTML.

Yes, this is what I meant. Because you want to listen to attribute changes. Anyway, I was saying it's a good thing. I've built entire complex apps where I pass everything via HTML element attributes; it has made me think about architecture and separation-of-concerns in a specific way which has been really good in terms of increasing transparancy/observability and keeping the code simple.

Simple interfaces are critical for good architecture. Forcing everything to be a string, forces pass-by-value and forces minimal communication between components. You get maximum separation of concerns; high cohesion, loose coupling.

I know exactly what inputs each component is dealing with by just looking at the HTML. This is incredibly useful... And components can output stuff by dispatching events on themselves (with bubbling for important events which may potentially affect higher level components).

Re: React is winning by default and slowing innovation

#813

Earlier quoted context omitted.

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well). Web components can be passed objects in JS, but its news to me if that is available in HTML.

I generally think the reflex to try to pass an object to an attribute on an element is a code-smell that the element hasn't been properly decomposed into sub-components. In those cases, I look more to adding child elements to represent those objects as an HTML serialization of the object.

Wow. Yes. Great comment. So glad to come across someone else who fully gets it. Components should 'communicate' with each other. If you start passing elaborate structures, this is getting into the realm of micromanagement, not 'communication'. It means your concerns aren't properly separated.

This is not a new theory. Alan Kay, who invented OOP has been saying such things for decades. People got totally the wrong idea about OOP by focusing on mechanisms to allow passing complex structures to each other. That was never the point.

Imagine if you worked with other people towards some goal and instead of talking to each other and separating responsibilities, ready-made, complex parts would just come out of people's mouths and everyone tried to make each others' parts fit together as an afterthought... Or imagine trying to catch a taxi and you bring a steering wheel and a tank of petrol with you to give to the taxi driver. It's absurd, obviously so, but that's what a lot of people have been doing with code.

Re: React is winning by default and slowing innovation

#814
post #304

I've used React, Vue, Svelte and Solid. React is my far my least favourite of the four. Both before and after they added hooks, all the major API calls seem to have been designed for least intuitiveness. I really wish something else had won.

Which is your favorite, and why? :-)

I have by far the most experience with Vue, but I'm a bit ambivalent about Vue3, and often still write in a Vue2 style.

Svelte looked pretty nice, but before I had a chance to really proficient, that codebase got re-written in Solid. Solid seemed to have the benefits of React-compatibility without so much brain-hurt.

Re: React is winning by default and slowing innovation

#815

Earlier quoted context omitted.

No OP, but I've also used Angular, React, Vue, Solid and Svelte in real world projects and my default choice is Vue, because it's on par with Solid and Svelte (and with Vue Vapor those three are basically the same) but with the larger ecosystem (vuerouter, vueuse, nuxt, nuxt-ui, primevue, nuxt-content, ...). I must also say that React was by far the most unpleasant and unproductive to use.

I keep reading unpleasant without any arguments. React is simple by nature, what made it unpleasant and unproductive? Granted I mostly do work on Shopify apps, so most of the heavy work has been done for me, I just put components together. This works fine, and I'd rather do this in React than e.g. Angular due to the small scale of the apps. Then again web components would've also been fine.

> React is simple by nature, what made it unpleasant and unproductive?

It isn't "simply by nature" at all. I have lost so much time battling through the minutiae of the different use...() hooks, trying to figure out either why something never updates, or updates too often, or updates but the state is stale etc etc. I never run into issues like this at all with Vue. Things update simply and predictably for me.

Re: React is winning by default and slowing innovation

#816
post #618

Earlier quoted context omitted.

I keep reading unpleasant without any arguments. React is simple by nature, what made it unpleasant and unproductive? Granted I mostly do work on Shopify apps, so most of the heavy work has been done for me, I just put components together. This works fine, and I'd rather do this in React than e.g. Angular due to the small scale of the apps. Then again web components would've also been fine.

Perhaps "simple by nature" is not at the top of everyone's mind. Simple is great until you build something complex, or need to create a large reactive UI that is not a simple CRUD fetcher. Things like non-linear video editors, 3d editors, games, things with a large component tree that takes work to plan, build, and non-trivial to re-arrange thereafter. Your "simple by nature" framework with one-way binding and render…

Yeah, it's one of my bugbears that a framework like React is built to solve a niche problem (running an enormously big and complex app like Facebook for an audience where timing is critical), and then gets doled out for everyone, even though most web apps have much lower requirements.

Re: React is winning by default and slowing innovation

#818
post #679

Earlier quoted context omitted.

> React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. I agree with JSX, and function components are nice, but React is most definitely not just function composition. Hooks add state and introduce life cycle events that take…

So basically react class components? It definitely was not easier in those days. When your just using vanilla react, I've never had a problem with hooks being that hard to reason about. Once you add in SSR, routers, query caching frameworks, etc the "lifecycle & state" starts to get confusing. This is mostly a problem with the additional complexity of these frameworks (nextjs, tanstack) and not react at its core. Bui…

> So basically react class components? It definitely was not easier in those days.

Yes, class components.

Function components help in reducing boilerplate code when all you want to do is put together a component that is a thin wrapper over other components with barely any state or logic.

The problem with function component fundamentalism rears its head when you start to add state and life cycle handlers, as you start to pile hooks on top of hooks when simple inversion of control would make things cleaner and easier to manage.

Literally the main criticism thrown at class components is boilerplate code and support for life cycle methods. It turns out that they are a nuisance when writing small stateless components, but are an unavoidable need when you add non-trivial state and life cycle handlers.

Re: React is winning by default and slowing innovation

#820

Earlier quoted context omitted.

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…

Innovation is not really measured in terms of how well something "scales down".

As a counter example, consider the jerry can from WWII. It was easy to handle a single unit to refill a vehicle, and it was also easy to stack millions of them for shipping.

Another example is the internet itself. You can have a local LAN of a few computers or a global network of billions. So I'd say that to some degree innovation is measured by how well something can scale both up and down, but of course that's not always the case.

Post reply on HN