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

The React2Shell Story

lachlan.nz

Post reply on HN
Print view View original

41–50 of 50 posts

Re: The React2Shell Story

#41

Post by ervine »

halflife wrote: post #39
ervine wrote: post #37

Earlier quoted context omitted.

So your argument is that instead of explicit class component methods, hooks are implicit based on understanding the react rendering model? I guess so - but react could also change (and I think did at some point) how their class methods work, how often they're triggered, and when. I don't understand the stateless comment - hooks are as stateful as you make them, using useState or useContext or any of the other ways of…

Classes are inherently stateful. A class instance is a long lived object. Functions are not, a functions internal state is thrown the moment the function returns. What react ask you to do is to attach to external state inside the function, in other words, an un pure function, forego idempotency. In class based components, you didn’t care how react works under the hood, except for the render method which is called by…

I guess I think it's table stakes to need to deeply understand how the framework you're using works. Lifecycle methods vs. hooks, you still gotta know what's doing what and why.

Re: The React2Shell Story

#42

Post by b4ckup »

Sankozi wrote: post #33
littlecranky67 wrote: post #21

Earlier quoted context omitted.

You are probably a Javascript dev, not doing typescript? Classes were horrible to type for, especially when you tried higher-order components. Hooks removed so much clutter and friction and allows pretty well-typed components and higher order functions (i.e. hooks that return components).

Hooks made simple things simpler, but hard things harder, code with lots of boilerplate was replaced with code with leaky abstractions full of various workarounds - I don't think this is a good trade. While I hate class component lifecycle methods they are much better than complex hook setups when solving more advanced problems.

Could you elaborate why you dislike lifecycle methods? I read this take a lot and I use mainly angular but did some smaller projects with react class components and with function components. I also think function components are very counter intuitive but I also never had anything against lifecycle methods.

Re: The React2Shell Story

#43

Post by halflife »

ervine wrote: post #41
halflife wrote: post #39

Earlier quoted context omitted.

Classes are inherently stateful. A class instance is a long lived object. Functions are not, a functions internal state is thrown the moment the function returns. What react ask you to do is to attach to external state inside the function, in other words, an un pure function, forego idempotency. In class based components, you didn’t care how react works under the hood, except for the render method which is called by…

I guess I think it's table stakes to need to deeply understand how the framework you're using works. Lifecycle methods vs. hooks, you still gotta know what's doing what and why.

Of course, but that really depends on the level of expertise and the type of programmer you are, and to some extent, the attitude of the organization your in to code and refactoring.

When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.

Re: The React2Shell Story

#44

Post by switz »

NewLogic wrote: post #14

I'm still yet to be convinced React Server Components are anything but a disaster to the developer experience. Mixing backend and frontend without a clear boundary is terrible for any codebase beyond a handful of contributors.

I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.

It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.

Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.

It's also always worth noting that RSCs don't require a server, and still bring value without one.

Re: The React2Shell Story

#45

Post by mejutoco »

pjmlp wrote: post #19
NewLogic wrote: post #14

I'm still yet to be convinced React Server Components are anything but a disaster to the developer experience. Mixing backend and frontend without a clear boundary is terrible for any codebase beyond a handful of contributors.

But it is so cool! I really don't understand why people complain about Spring or ASP.NET annotations, and then go running to Next.js with its useXXX and import magic.

Spring is a very good analogy to what useX hooks were to react. Thank you for this.

A different dsl inside Java or js implemented with duct tape in a dynamic way. React was screaming for a real typed functional language like elm imo, instead of a kludge of abstractions enforced by linters and weekly-changing best practices. React should have been "finished" like jquery. It is possible to develop something solid in it of course, but elegant it is not. Full of leaky abstractions.

Re: The React2Shell Story

#46

Post by ervine »

halflife wrote: post #43
ervine wrote: post #41

Earlier quoted context omitted.

I guess I think it's table stakes to need to deeply understand how the framework you're using works. Lifecycle methods vs. hooks, you still gotta know what's doing what and why.

Of course, but that really depends on the level of expertise and the type of programmer you are, and to some extent, the attitude of the organization your in to code and refactoring. When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.

No, writing shit in react is gonna be a nightmare regardless of paradigm. HoC, Class Components, render props, whatever - if you don't know what you're doing and react internals are magic to you, it's game over. Anyway, we can agree to disagree on hooks vs. classes. Cheers.

Re: The React2Shell Story

#47

Post by dang »

owebmaster wrote: post #10
Rauchg wrote: post #3

R2S was a painful one, but Lachlan was a dream of a security researcher to partner with. Not just from a responsible disclosure POV, but things like hopping on multiple calls with Meta and our team to help us validate remediations. Thank you Lachlan for helping make the internet safer (and great job on figuring out this 'labyrinth' of a vulnerability)

[flagged]

You can't attack another user like this here, so please don't.

It's particularly bad when someone shows up to discuss their work and commenters take the opportunity to attack them. That's a mob dynamic, and we don't want those here.

It also strictly worsens the site because it gives people a disincentive to contribute in precisely the areas they know the most about. I've been trying to explain this for years: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: The React2Shell Story

#48

Post by halflife »

ervine wrote: post #46
halflife wrote: post #43

Earlier quoted context omitted.

Of course, but that really depends on the level of expertise and the type of programmer you are, and to some extent, the attitude of the organization your in to code and refactoring. When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.

No, writing shit in react is gonna be a nightmare regardless of paradigm. HoC, Class Components, render props, whatever - if you don't know what you're doing and react internals are magic to you, it's game over. Anyway, we can agree to disagree on hooks vs. classes. Cheers.

Agreed. In the end, I always say that every line of code has deadline in which it will be removed.

Re: The React2Shell Story

#49

Post by Sankozi »

b4ckup wrote: post #42
Sankozi wrote: post #33

Earlier quoted context omitted.

Hooks made simple things simpler, but hard things harder, code with lots of boilerplate was replaced with code with leaky abstractions full of various workarounds - I don't think this is a good trade. While I hate class component lifecycle methods they are much better than complex hook setups when solving more advanced problems.

Could you elaborate why you dislike lifecycle methods? I read this take a lot and I use mainly angular but did some smaller projects with react class components and with function components. I also think function components are very counter intuitive but I also never had anything against lifecycle methods.

They often require quite complex ifology for simple use cases. Also didmount and diduptade often needs to be overriden together only to have almost the same implementation. They also have some gotchas regarding state updating inside them.

Re: The React2Shell Story

#50

Post by richierob62 »

switz wrote: post #44
NewLogic wrote: post #14

I'm still yet to be convinced React Server Components are anything but a disaster to the developer experience. Mixing backend and frontend without a clear boundary is terrible for any codebase beyond a handful of contributors.

I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience. It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most hi…

[flagged]
Post reply on HN