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

Why I don't miss React: a story about using the platform

jackfranklin.co.uk

Post reply on HN
Print view View original

251–260 of 279 posts

Re: Why I don't miss React: a story about using the platform

#251

Post by ralusek »

NatSydenham wrote: post #212
ralusek wrote: post #110

Earlier quoted context omitted.

React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework. And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be. Now, do I still use React for everything? Yes. Do I pref…

I work primarily with React, and I'm curious - why do you consider hooks to be an anti-pattern? (This isn't a criticism, genuine curiosity)

In practice, because they don't work the way most people think they work, and because it's really easy to screw up using them.

Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.

For example, if I have

    const a = useRef(true);
    const b = useRef(false);
The only way react knows that the first value it should return the next time it renders is what I'm expecting to be value `a` is because that useRef is called first every render. These are all kinds of rules and assumptions about hooks that make them not behave at all like normal functions. I don't think people understand that, for useRef, for example, those two lines of code are run every render, passing in the initial starting values, which then react disregards after the initial render, and maintains a mapping of ref and state and memo etc values all by the order the hooks are called in. I see people use hooks in callbacks all of the time and just fundamentally not understand that they're doing it wrong.

Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.

And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.

Re: Why I don't miss React: a story about using the platform

#252

Post by hajile »

hirvi74 wrote: post #166
_pdp_ wrote: post #8

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…

> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place. Does it work? Yes. Is it an elegant and maintai…

Look at the Mithril or Preact codebases and make a basic version of your own.

Re: Why I don't miss React: a story about using the platform

#253

Post by efdee »

BatteryMountain wrote: post #199
_pdp_ wrote: post #8

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…

I've been down this path. I've built my own framework once out of frustration, thinking typescript will make it easy... after a while I realized that I was just rebuilding chunks of existing frameworks and most likely not in the best way. Webtech is really messy to begin with, typescript didn't really save me. So I stopped. Sure it was nice to know how to build your own viewstack, navigation and state management and…

Maybe I'm misunderstanding your point, but React really doesn't dictate project structure at all.

Re: Why I don't miss React: a story about using the platform

#254

Post by eyelidlessness »

porker wrote: post #198
eyelidlessness wrote: post #116

Earlier quoted context omitted.

Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions;…

Would love to know what the app does. From the mentions of xpath all I can think is "visual xml editor"?

It’s an implementation of ODK[1] extensions to the XForms specification[2]. The specific implementation is Enketo[3], which I was brought on to ODK to help maintain. Not exactly the spec I’d go with greenfield, but it’s been successfully in use for a decade with great impact.

1: https://getodk.org/

2: https://getodk.github.io/xforms-spec/

3: https://enketo.org/

Re: Why I don't miss React: a story about using the platform

#255

Post by dmitriid »

dtagames wrote: post #247
dmitriid wrote: post #240

Earlier quoted context omitted.

> Tagged template literals are not string concatenation They are not concatenation by themselves. But for them to be useful, you will end up doing a lot of it because there's nothing else to do with strings than parse (often with regexps [1]) and concatenate [2] the strings. And then you dump the concatenated string into the DOM using `.innerHtml` [3] There's no magic. [1] https://github.com/lit/lit/blob/main/package…

I use Lit every day and I have no idea what you're talking about. Any property can be a full JS object. When the property is changed, it is re-rendered in your component. I have never touched innerHtml and my Lit apps pass and render all kinds of stuff into html`` tagged templates. It's really pure magic because you can freely mix regular old HTML and regular attributes with dynamic data and data binding. There's mor…

> I use Lit every day and I have no idea what you're talking about.

I'm talking about how lit is implemented internally and that's why I provided links to relevant parts of lit's code.

People having no idea how things work is the bane of our industry. And that's why we have objectively false statements like "regular old HTML and regular attributes with dynamic data and data binding".

Lit is almost as far from "regular old HTML" as React's JSX is: lit is a HTML-like DSL that even has constraints on how you use tagged literals themselves.

E.g. `` is a valid tagged literal and it's invalid in lit.[1]

> they work for CSS and SVG, too.

If lit lets you mix SVG with custom elements, they don't really use custom elements. See discussion https://twitter.com/Rich_Harris/status/1198339672361119745?s...

[1] https://lit.dev/docs/templates/expressions/#invalid-location...

Re: Why I don't miss React: a story about using the platform

#256

Post by TAKEMYMONEY »

dtagames wrote: post #244
TAKEMYMONEY wrote: post #242

Earlier quoted context omitted.

They combine lit-html with a "basic scheduler" that they've written themselves. I'm guessing that's intended as a replacement for React, but it could easily be seen as a replacement for Lit, which offers "reactive properties" too. I think how they gloss over the "we'll just write a library to handle component rendering, lifecycle and state" portion as a "basic scheduler" is a bit disingenuous. The author even mention…

There is no doubt that, when using Lit, you're going to re-write portions of some existing framework. That's the big selling point: You're going to write them your way, and only the ones you need. Instead of inheriting and learning React (or Angular, or Vue), you decide what syntax and behavior your components will have -- all the way down to "bare metal" of when and if they render and with what contents or results.…

> create all kinds of new behaviors that React doesn't understand

Care to expand? (I'm working on SVG-as-React-component stuff.)

Re: Why I don't miss React: a story about using the platform

#257

Post by baxuz »

WA wrote: post #236
baxuz wrote: post #217

Tried Lit and StencilJS. They are both forcing the usage of custom events to dispatch functions and share data between components. It's horribly unergonomic. Using the DOM with event bubbling and capturing feels really bad. Orchestrating rendering is a mess. The Shadow DOM and templates don't really solve any issues that aren't already solved with things like CSS modules for style scoping and even using element cloni…

So what do you do? Hand-craft Web Components?

I avoid using them, except when having to expose a component to a third party, if they _really_ want the ergonomics of using WCs.

Then I'd use something like https://github.com/preactjs/preact-custom-element, https://stenciljs.com/docs/custom-elements or https://github.com/solidjs/solid/tree/main/packages/solid-el....

As far as I see, there is nothing that WCs provide which isn't already solved, in a better way, both for devs and users.

And making a framework that use custom elements and shadow DOM for component-based logic and encapsulation seems like a purely philosophical approach to adhere to some vision of "platform purity".

Re: Why I don't miss React: a story about using the platform

#258

Post by ldiracdelta »

onion2k wrote: post #177
ldiracdelta wrote: post #101

Earlier quoted context omitted.

As Scott Adams says, "Analogies are for fighting." If you try to counter a statement with an analogy you almost always simply get a fight.

Surely it's the countering bit that shows you want to get in to a fight more than the analogy. Analogies are just a way of illustrating a point.

I do wish that people would engage in dialectic conversation when they encounter an analogy, rather than rhetoric. Unfortunately, I find Scott Adam's words ring true.

Re: Why I don't miss React: a story about using the platform

#259

Post by ldiracdelta »

eyelidlessness wrote: post #119
ldiracdelta wrote: post #101

Earlier quoted context omitted.

As Scott Adams says, "Analogies are for fighting." If you try to counter a statement with an analogy you almost always simply get a fight.

Quoting absolutes expressed by highly opinionated people is also for fighting. Not saying you shouldn’t, but maybe there’s some nuance missing. Not even saying the particular analogy was devoid of conflict, it has plenty of room for disagreement. But it didn’t feel to me like it was inviting any which wasn’t already present.

I would classify Scott Adam's statement as a trueism -- true for most people, under most circumstances, for most times. Unfortunately, couching a trueism in its most precise linguistic form with associated probabilities and error margins is a path to simply being ignored. Once a thread switches to rhetoric, dialectic responses are like pissing in the wind, forgive the analogy :-)

Re: Why I don't miss React: a story about using the platform

#260

Post by interlocutor »

ratww wrote: post #210
interlocutor wrote: post #141

Earlier quoted context omitted.

> This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props. https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

This whole article is about an edge case where components have an internal "draft" state and an external "final" state, where both represent the exact same thing , and you want internal state to change when props change. This, in itself, would be an anti-pattern in any kind of programming, reactive or not. What the author is trying to convey is that using getDerivedStateFromProps is not the best idea, and there are t…

Nothing has changed in the last 4 years. Any time you have props and state, updating props is best done by replacing the component by changing the key. If you think hooks has fixed this, you are welcome to point to an article or code that demonstrates that.

All of this complexity is completely unwarranted, which is the point of the article at the subject of this thread. You can do it with simple vanilla js and it is easier. Javascript developers tend to buy into frameworks too easily without realizing the framework is making some things more complicated than without any framework.

Post reply on HN