So it makes sense because there's a fancy name for it?
For a moment let's just imagine you are inventing a brand new UI framework. You obviously want to have components in it. So how do you represent a component in your new framework? A component needs state, logic and a way to render that state. Do you choose to represent the component as a class which naturally encapsulates state as properties and logic as methods or do you choose to represent components as functions which lack state so you bolt it on via an implicitly injected context that you access via abstractions?
I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant.
I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represented as a class plus template (plus styles). A event listener is mostly calling a method on the class. A state can be as simple as a property on the class. It's very natural and there are way less caveats (although not zero).
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.
I'd say on average about 50% faster but it really depends on the task at hand. On problems that can be isolated pretty well like a new feature that is relatively isolated (for example building a file export in a specific format) it's easily a 10x speed up.
One thing that generally gets less talked about is exploration of the solution space during manual implementation. I work in a very small company and we build a custom ERP solution. Our development process is very stripped down (a good thing IMO). Often times when we get new requirements we brain storm and make a rough design. Then I try implement it and during that phase new questions and edge cases arise, and at any time this happens we adjust the design. In my opinion this is very productive as the details of the design are worked out when I already know the related code very well as I already got down to implementing. This leads to a better fitting design and implementation. Unfortunately this exploration workflow is incompatible with llms if you use them to do the implementation for you. Which means that you have put more effort in the design up front. From my experience that means the gain in speed in such task is nullified and also results in code that fits worse into the rest of the codebase.
That's awesome! I feel similar, I drew a lot back in the days because growing up in a small town I was bored so often. I did portrait art only but today I struggle because I just don't know what to draw and I'm just not good at doodling.
Best of luck to you!
I once wrote a formatter for powerquery that's still in use today. It's a much simpler language and I took a simpler approach. It was a really fun problem to solve.