Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

Post reply on HN
Print view View original

841–850 of 866 posts

Re: React is winning by default and slowing innovation

#841

Post by [deleted] »

Etheryte wrote: post #836
rimunroe wrote: post #810

Earlier quoted context omitted.

> In that case we could just as well omit it by default and only have users define it when they want something different. I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparis…

For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable. For two, this is exactly what I mean with leaky abstractions. The fact that you even have to think about this at all is a strong design smell. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. Th…

[deleted]

Re: React is winning by default and slowing innovation

#842

Post by rimunroe »

Etheryte wrote: post #836
rimunroe wrote: post #810

Earlier quoted context omitted.

> In that case we could just as well omit it by default and only have users define it when they want something different. I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparis…

For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable. For two, this is exactly what I mean with leaky abstractions. The fact that you even have to think about this at all is a strong design smell. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. Th…

> For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable.

Yes, of course. That's why it's recommended as a first step and not as something to do all the time (though you often can if you use something like usePrevious).

> For two, this is exactly what I mean with leaky abstractions. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.

I'm sure it's possible to do it better, but I'm discussing this in the context of hooks versus the class component APIs they replace.

I'm not very familiar with signals beyond what I've read about them in the past. What I've read about them sound exactly like Knockout observables[0]/computed observables[1], which I'm extremely happy to have left in the past. I assume frameworks using signals must use something to scope subscriptions or enforce update directionality?

Do signals provide a solution to knowing when to run an effect to e.g. establish or close a network connection?

[0] https://knockoutjs.com/documentation/observables.html

[1] https://knockoutjs.com/documentation/computedObservables.htm...

Re: React is winning by default and slowing innovation

#843

Post by uzy777 »

mexicocitinluez wrote: post #630
ironmagma wrote: post #81

Earlier quoted context omitted.

> It just basically does everything React does but better SolidJS still has some major pain points; the one I found was not knowing whether a prop was a signal or needed to become one. The type system doesn't help much. In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. In Solid, it's less clear whether the update will be observed.

> In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. Amen. Data flows down. That, to me, is one of React's biggest strengths.

Amen because of this we have useeffect and calling the whole component tree on a isloading change

Re: React is winning by default and slowing innovation

#844

Post by ipaddr »

johnfn wrote: post #822
ipaddr wrote: post #788

Earlier quoted context omitted.

Merits yes technical merits no. Products rarely win because of technical merits. Products win with marketing. Technical merits can add another layer to the marketing but without facebook's brand people would still be on angular.

It's unclear to me that Facebook's 'brand' is superior to Google. Google has plenty of popular, successful open source projects. If Facebook's brand was all that was needed for it to crush Google, wouldn't Pytorch be crushing Tensorflow right now?

We are talking about a different time and different market. Google had the top brand overall back then but just in terms of frontend frameworks their brand became mud and no one trusted them after they spent the last year or two moving into angularjs and now they needed to rewrite everything. So they rewrote what they had in React instead of AngularJS. Facebook had the more trusted brand over Google and other frameworks.

Re: React is winning by default and slowing innovation

#845

Post by hajile »

balamatom wrote: post #415
theturtle32 wrote: post #73

I feel this with every fiber of my being. I used to do a TON of front-end work, some of it quite cutting edge, delivering highly performant user experiences in the browser that had previously been only thought possible in a native app. Back in like 2009-2015. I was deeply connected with the web standards fundamentals and how to leverage them mostly directly. I detoured into heavier focus on backend work for quite a w…

>You still get JSX Give me S-expressions instead. How else am I supposed to prove to frontend developers that I didn't make those up

The frontend would be so much better if Eich had shipped scheme.

ES6 wouldn’t have been needed. CSS-in-JS would have become standard decades ago. HTML would have almost disappeared too because parsing s-expressions would have been native. JSON would never been invented either due to S-expr.

In short, everything about the modern web would have appeared decades sooner and been more consistent.

Re: React is winning by default and slowing innovation

#846

Post by progmetaldev »

librasteve wrote: post #767
CooCooCaCha wrote: post #738

Earlier quoted context omitted.

Looking at the example on the front page, I don’t see how you can look at that and think it’s better than react.

I think that HTMX is better than React. I think that writing in my server side language of choice (Raku as it happens - ymmv) is better than TypeScript. If you want to write HTMX / HTML in a componenty and functional way then HARC stack gives you that for Raku. I grant that Raku is a step change if you haven't seen it before and that there are some awkwardnesses in the example that could be ironed out. You may prefer…

I have been taking a deep-dive into Lit recently, because the CMS I use (Umbraco) has built their BackOffice (CMS management interface) in it. It has been fairly easy to grok, other than learning the CMS specific libraries.

With that said, HTMX feels like the progressive enhancement solution I wish I had back when I was doing so with jQuery (and Prototype.JS even before that). I appreciate your solution, and definitely want to take a deeper look in the future. For applications, I still tend to use ASP.NET (Core, whatever you want to call the current open-source version of .NET). HTMX seems like a perfect solution to progressively enhance an application, while your library does far more for controlling how library code is written in JavaScript than a gigantic mess of jQuery scripts with shared state.

Re: React is winning by default and slowing innovation

#847

Post by 3nt3 »

hbrn wrote: post #719
gloosx wrote: 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…

> React feels natural because it never asks you to stop writing JavaScript I want to increment some counter on the webpage. Which approach feels natural? increment = () => { this.setState((prevState) => ({ count: prevState.count + 1 })); }; const increment = () => setCount((count) => count + 1); function increment() { count += 1; } No one wakes up saying "please let me mutate simple state with function calls".

Haskell devs do ;)

Re: React is winning by default and slowing innovation

#848

Post by klysm »

eYrKEC2 wrote: post #717
klysm wrote: post #187

If something innovates enough to be a lot better than react then it will start winning. I haven’t seen anything yet

React, _combined with its ecosystem_, feels like a local maxima. System D may be better than C++, but it wasn't better _enough_. We needed massive improvements offered by Rust to move the C++ community (not everyone, I know).

You must mean D lang, not systemd right?

Re: React is winning by default and slowing innovation

#849

Post by ironmagma »

uzy777 wrote: post #843
mexicocitinluez wrote: post #630

Earlier quoted context omitted.

> In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. Amen. Data flows down. That, to me, is one of React's biggest strengths.

Amen because of this we have useeffect and calling the whole component tree on a isloading change

isLoading should be a boolean; it will maintain referential equality across renders and not cause a re-render unless it is an actual edge from false to true or vice versa.

Re: React is winning by default and slowing innovation

#850

Post by eYrKEC2 »

klysm wrote: post #848
eYrKEC2 wrote: post #717

Earlier quoted context omitted.

React, _combined with its ecosystem_, feels like a local maxima. System D may be better than C++, but it wasn't better _enough_. We needed massive improvements offered by Rust to move the C++ community (not everyone, I know).

You must mean D lang, not systemd right?

oops. You're right.
Post reply on HN