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

201–210 of 279 posts

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

#201

Post by mejutoco »

quickthrower2 wrote: post #154
Tarks wrote: post #22

Earlier quoted context omitted.

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.

You can use the ports system and interoperate with js in Elm. I used it in the past and it is quite a clean abstraction.

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

#202

Post by dgb23 »

fiddlerwoaroof wrote: post #169
akira2501 wrote: post #83

Earlier quoted context omitted.

> without implementing a significant chunk of the frameworks In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else. So far, just using custom elements and a small wrapper around the element, I've not been struggling to create the features I need o…

Yeah, my experience is that people frequently overestimate the cost of building something for your needs and underestimate the integration cost of buying something. Also, the trend of hiring developers is a plague: if you know JavaScript and the DOM well, learning the basics of react is a couple afternoons of work and you can figure out the pitfalls via code review and learning on the job.

That’s right, except I think it would take most people longer than an afternoon. There’s stuff that’s quite unique (and powerful) like useEffect and JSX takes a bit to get used to.

But generally I wouldn’t be worried about onboarding a web dev who doesn’t know the lib, it’s not rocket science. One of the appealing things is how very straight forward and clear it is.

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

#204

Post by gopher_space »

ng12 wrote: post #167
dvt wrote: post #133

Earlier quoted context omitted.

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.

I'm fairly certain you're trolling but as a good rule of thumb if you find yourself fighting your framework you picked the wrong one.

I'd suggest thinking about dismantling your framework if you've been happy with it for a bit. If you've been rewriting or authoring large chunks and disabling features it might be informative to spend a slow day looking at what you've found useful.

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

#206

Post by bambataa »

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…

That raises an interesting question: what would be the declarative framework easiest to minimally reimplement?

I’m thinking you could have a single file, jQuery-based, hand rolled version of some framework and get many of the benefits while still technically complying with the “no frameworks” rule. In the same way that you could reimplement Redux easily if you for some reason weren’t allowed to use it.

I suspect diffing performance would be the bottleneck but I wonder if you could come up with some weird half solution that worked for your particular use case.

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

#207

Post by dmitriid »

thayne wrote: post #190
dmitriid wrote: post #182

Earlier quoted context omitted.

> It is still pretty early days Web components were proposed 11 years ago. Widely available for at least six. When will it stop being "early days"? Now all the air in browser development has been sucked out of the room by them. Instead of actually moving the web forward browsers are busy patching holes and problems created by web components because they are horrendously badly designed. And they still have an issue li…

> widely available for at least six Custom Elements weren't available until 2018. So unless you are referring to the chrome-only experimental v0 version, I don't think you can say it has been widely available for more than 4. And there will likely be substantial improvements to it before it starts dominating web development.

> I don't think you can say it has been widely available for more than 4

Yes, my timeline was off.

> And there will likely be substantial improvements to it before it starts dominating web development.

I'm definitely veering away from my original statement, but here goes :)

There won't be any substantial improvements in web components. It's painfully obvious how many shortcomings they have, and how many holes have to be patched before they can become actually useful. I mean, they had to come up with a whole new Javascript API just to make them participate in forms.

And now their existence taints and poisons most other improvements to the platform. For example, Scoped CSS (which on its own would solve a huge chunk of what web components offer) now have to be twisted to accommodate web components, and will likely be a worse spec as a result.

Chrome "developer advocates" will incessantly berate and gaslight other projects and frameworks, and will claim that web components are a success because companies with billions of dollars in revenue and thousands of developers use them to create a yet another avatar or breadcrumbs component. That... that is neither success nor a path towards any substantial improvement.

"It's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1] And the future is likely to be component-less [2]

If the tens of millions of dollars that Google alone has poured into Web Components had gone into something meaningful like https://open-ui.org we'd have a significantly better and a substantially more future-proof web. Alas.

[1] https://twitter.com/Rich_Harris/status/1513668040784814084

[2] https://dev.to/this-is-learning/components-are-pure-overhead...

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

#208

Post by bigDinosaur »

mejutoco wrote: post #201
quickthrower2 wrote: post #154

Earlier quoted context omitted.

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

You can use the ports system and interoperate with js in Elm. I used it in the past and it is quite a clean abstraction.

It's frustrating that it forces you to jump into handling async code, though, in all cases. This wasn't always the case, and for good reason: sometimes async code is just vastly more complicated for no actual benefit if you can tolerate the FFI causing a crash at any calling point.

The interest in Elm took a major hit after the compiler banned use of JS.

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

#209

Post by deepstack »

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…

>If you're really worrying about when your component renders or re-renders it's probably because there are other issues with your app.

that's why I prefer Solid instead of React. For client side stuff, Solid is sooo much better than React.

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

#210

Post by ratww »

interlocutor wrote: post #141
Jcampuzano2 wrote: post #40

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

> 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 two simpler ways of doing it. The first solution (only keeping the state in one place) is the better one.

About the solution you're repeating all over the thread, anyone using React will notice that the "key" change solution you're talking about only works for trivial cases: it doesn't work in practice if you have more internal state in the component. It does work perfectly fine if you only have one single piece of internal data.

This is of course a past worry. All this is much simpler to solve by using Hooks.

But the important lesson here is maybe that one shouldn't judge whole Frameworks by advanced articles about edge cases written 4 years ago that require more experience with the framework than you have.

Post reply on HN