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

151–160 of 279 posts

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

#151

Post by ehnto »

Gigachad wrote: post #135
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.

The longer something has existed on top, the longer it will continue to. React still hasn't peaked yet. Its tail to obsolescence will outlast anything you build in it today.

Which is certainly more about popularity and subsequently littering the world with soon to be legacy apps. React and Wordpress, pick those up and you'll have work for your whole career I suspect. Also a legacy knowledgebase on how to achieve just about anything with both of those tools.

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

#152

Post by timfsu »

apprewired wrote: post #21

> In our case, we still felt this decision was justified because we don't have to recreate a scheduler with all the complexity of React's; we can build a small, self-contained implementation that only implements what we need. I wish there were more details about this. Implementing a small scheduler seems like a monumental task and I'd love to learn more about how to implement a base-case.

Not OP, but if you're building a small scheduler for batching changes, it should be pretty straightforward:

- `jobs` is an array of functions

- enqueue adds a job to `jobs` and starts running jobs if not running

- job running can be triggered by animation frames or setTimeout

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

#153

Post by bobertlo »

lcnPylGDnU4H9OF wrote: post #13
bobertlo wrote: post #9

My ad for web components: btw I used to use react

> Firstly, because some people on the internet like to get angry over opinions that may not match their own, I want to make clear what this blog post is not: > It is not a call for everyone to immediately drop React and move to web components. > It is not a blog post declaring React “dead”, or the wrong choice for every project. > It is not a blog post declaring web components the best solution to all projects. You m…

I was only joking that the title of the piece seemed slightly misleading/baiting! (but I also was not familiar with the term "using the platform")

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

#154

Post by quickthrower2 »

Tarks wrote: post #22
ng12 wrote: post #11

> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…

The escape hatches were one of the first things I used to explain why I initially liked react, called them exactly that too. "They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"

This is why I felt out with Elm. It is harder to escape the hatches with it.

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

#155

Post by eyelidlessness »

shrimp_emoji wrote: post #142
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;…

> what you just described can basically become unusable Oh, so like every JS interface ever. :D

I mean, not really? My naive implementation in Solid required a few tweaks understanding the model and performs updates perceptually instantaneously on a perf sensitive input I use as a smoke test, without any of the tricks I expected to need, just its built in reactive primitives. The existing implementation performs the same computations on that data in about half a second, which feels like an eternity without special care to unblock the UI. JS is really fast. You just have to know how to use it, and when not to.

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

#156

Post by eyelidlessness »

gitgud wrote: post #137
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;…

> Being able to batch state -> render updates based on priority even better still. Mobx [1] is pretty good for this, it batches updates that happen, making rendering more efficient. Also regarding rendering, react will update a component it it's state changes. It might update its children components, but if you pass them in as props, they won't be updated, as they're rendered in the parent component's context. This a…

Yep. Solid is too! Even so all of these abstractions need help when the computation itself is expensive and knowing whether to perform it is too. The ones best designed for that provide really clear APIs for how to take control where they’d otherwise handle it.

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

#157

Post by mondaygreens »

dvt wrote: post #133
ng12 wrote: post #11

> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…

This has got to be gaslighting at the highest level: oh you're doing something wrong because that's not how you're supposed to do it in React. Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework.

Too many folks' livelihoods depend on it at this point. The other side of the same coin is the gaslighting that you can't build anything sufficiently complex without react. If you did build it without react, it obviously wasn't sufficiently complex.

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

#158

Post by LAC-Tech »

mst wrote: post #148
LAC-Tech wrote: post #103

Earlier quoted context omitted.

IME marrying business logic so closely to presentation makes it very hard to change one without the other. Especially relevant for web apps, where you may want to re-use business logic for mobile apps, which becomes very difficult when they're tied to a react component. Also makes it harder to test. There's a great paper called "Naked Objects" which I'd recommend for anyone doing GUIs, but powerful idea I got from it…

Pawson's Naked Objects thesis is absolutely brilliant. It proposes a complete approach of which not all of the parts will be useful for any given project, but it is -very- much worth reading even so.

Hey, someone else on the internet who knows about it!

And yeah agreed, but I think we could all use some scantily clad objects at the very least.

Post reply on HN