I understand all the hook rules and all the gotchas around stale closures. But I don't want to have to deal with those as part of my everyday, regular programming, it's just stupid. React is no longer productive and hooks are way out of control. Did you know hooks are even more stupid with concurrent mode on?
I must have some very womanly traits then. When I first joined my engineering school, I felt so bad/inadequate because all the guys were like "yeah this is easy, I totally got this" and I was like "really? it's not that easy imo!" (for me, easy means I understand 100% of the topic)
First few exams and I had WAY better marks than all of them, lol.
Not sure why Evan is not being more transparent regarding this renaming.
It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"
Insead he's like: "what? it was the plan all along :)"
Yes it's terrible naming. The more abstract the naming, the harder it is to reason about.
Plus, JS/TS already have proper union types without a need for a construct like Either.
A better naming for 99% of cases is (like found in Elm)
No matter the underlying technology, "lightweight, truly reusable UI components" is almost an ideologic dream, at the web scale. (some companies might achieve it on their own scale with a lot of effort, but not sure for how many years)
As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years!
It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place?
The sweet spot for web components really seems tiny.
There's a big difference though: persistent data structure libs are heavy to send over the network.
What we need is immutable data structures in the platform.
The difference is even more pronounced once you start typing your code.
TS/TSX = 100% typed
arbitrary template DSL = 0% typed
and now these string template based on interpolation = 5% typed:
Only the dynamic values inside ${} expressions are "typed", but there are no coherence checks. DOM attribute names and values remain untyped
In the absence of any real advantage for string templates, why even bother?
Of course it's unintuitive. I see dev veterans make the mistake all the time.
JS was so poorly designed. An implicit (not passed as an arg), dynamic this parameter. You couldn't be more cheeky than that really.
something like console.log.bind(console.log) is beyond silly. It's what we're stuck with but I will minimize the occurences of that kind of crap any single time I can.