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

111–120 of 279 posts

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

#111

Post by panny »

louthy wrote: post #69
_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…

> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

I can advertise for a "React developer" and find people familiar with react rendering. I will never be able to do that with in-house render solution. This will apply to whatever replaces react as well.

Unless I'm selling a render solution, I don't want to be maintaining a render solution. Maintaining glue code might suck, but writing everything from scratch limits the scale of the work that a person can accomplish. I liken it to polishing gears rather than driving the car.

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

#112

Post by MonaroVXR »

ldiracdelta wrote: post #101
xwdv wrote: post #97

Earlier quoted context omitted.

You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.

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.

Never thought about that, where do you get this from? But it kinda rings true for me in life.

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

#113

Post by ldiracdelta »

MonaroVXR wrote: post #112
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.

Never thought about that, where do you get this from? But it kinda rings true for me in life.

I heard it from Scott Adams, the creator of Dilbert. In addition to writing that comic he is a very interesting thinker. He is also a trained hypnotist.

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

#114

Post by MonaroVXR »

v0idzer0 wrote: post #75
LAC-Tech wrote: post #37

Earlier quoted context omitted.

React very much feels like its own platform to me - having its own browser tools to debug it is a dead giveaway.

I think it feels that way because it’s a bit of a paradigm shift in terms of the way we think about building user interfaces, but the reality is its just javascript running in a browser. I’ve been writing react over 10 years and used to devtools just a handful of times. They’re by no means necessary. I used to use an extension for jQuery to quickly find css selectors. Nobody was saying we weren’t using the platform t…

> "...and used to devtools just a handful of times."

How do you debug?

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

#115

Post by recursive »

Jcampuzano2 wrote: post #40
interlocutor wrote: post #26

React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might a…

This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props. If you instead are talking about syncing props with state, there are ways to do this as well without changing the key, but this is considered an anti-pattern in the first place. This sounds more like bashing react without even knowing it very well in the first place.

If you pass new props, it swaps out the whole instance of the element in the document. Probably.

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

#116

Post by eyelidlessness »

5Qn8mNbc2FNCiVV wrote: post #68
ricardobeat wrote: post #63

Earlier quoted context omitted.

React doesn’t offer any render optimizations by default, so not worrying about it sounds like blissful ignorance - you’re just ignoring a ton of unnecessary renders because they don’t visibly affect performance (on your development device). After a certain level of complexity the issues will start to show.

What's there to optimize? If you don't use state, it doesn't rerender. If you click a button to add another element for example, it does exactly that. If you have a reactive variable in your HTML and update it it rerenders that part only. What's there to optimize further?

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; these can be expensive whether implemented as a hybrid wrapper around native XPath or fully in userland

- Which in turn may trigger recomputation of their own dependent nodes

A naive implementation of this according to the algorithm you described will cause real world usage to block sometimes for several seconds until the app becomes responsive again.

Being able to have greater control over when to commit state and when to render intermediate state are crucial to usability for this app. Being able to defer the entire computation for state without a path to an associated view is even better. Being able to batch state -> render updates based on priority even better still. All of this can be accomplished with React’s APIs, but it certainly wouldn’t be the default behavior. And it’s all from a real world use case where SolidJS—which has a similar DX to React but significantly better performance, and which I’ve been prototyping for gradual adoption—also needs more optimization than its dependency tracking alone can achieve.

Even trivial demo apps with well designed pre-hydration state (note: already optimized beyond the default) and otherwise find performance at runtime can suffer significant lag between LCP and TTI by running far too much code for stuff that’s nowhere near needed for immediate interaction.

Granted in most cases this tradeoff is reasonably acceptable. In many cases it’s not. Prematurely optimizing it isn’t a great idea, but there’s a wealth of room for optimizing when it’s valuable to do so.

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

#117

Post by wrongandrew »

Both React and Lit's approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist.

Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe and rerender approach is too slow, while being declarative because their constantly rotating staff had trouble writing it imperatively.

To meet this requirement you need:

a constantly revolving staff that are of varying degrees of competence and can't write non-buggy imperative code in the few situations you can't just wipe and re-render

a situation in your application where wipe and re-render is too slow, AND the situation is too complex to hand-write the individual updates manually

The other decision React made that was wrong was the need for JSX. They decided on JSX because they made a mistake many people make when just using the pure JavaScript API for creating components - they tried to make it nested like html using a fluent/chained call approach. As it turns out, trying to keep the nested HTML structure is not necessary for readability.

My library is github.com/thebinarysearchtree/artwork

After using it, it makes React look like SOAP vs JSON. It has less code, runs as fast as you can get, and everything is in your control because it is just web components with some functions to handle the repetitive parts.

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

#118

Post by croes »

nawgz wrote: post #73
louthy wrote: post #69

Earlier quoted context omitted.

> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

That’s a pretty funny stance. The library has a gigantic developer share and is supported by a tech giant. A world where React isn’t used and remembered is one where the web isn’t based on the same primitive. The idea of a thin layer on top of JS offering composition is not complex, and the execution by react is still trend setting. Remember when they introduced hooks and now tons of libraries have the same thing? Th…

Applies the same to jQuery or Bootstrap?

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

#119

Post by eyelidlessness »

ldiracdelta wrote: post #101
xwdv wrote: post #97

Earlier quoted context omitted.

You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.

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.

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

#120

Post by croes »

danachow wrote: post #94
metadat wrote: post #84

Earlier quoted context omitted.

jQuery has faded into the background, no longer interesting. React has too many sharp edges, it'll only be here until something shinier supercedes it.

> jQuery has faded into the background, no longer interesting. It’s a mature, stable technology, still in wide use - and not really a competitor with react. That you claim it’s “no longer interesting” says more about your own preferences and ironically makes it sound that you are personally interested in the newest shiny fads - so I’m confused, what is your objection to react then? Angular isn’t exactly dead - and is…

What else do you need jQuery for? The most important parts are already included in the browser.
Post reply on HN