boubiyeah

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?

It's just an implementation detail.

I just can't take the irony of the Elm leadership trying to come across as inclusive.

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.

But that's the simplest union type.

You could have:

type Result = {type: 'ok', value: string} | {type: 'err', value: string}

It was! The new result just isn't all that much better. They got trapped in their own bubble of complexity.

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)

type Result error value = Ok value | Err error

They work best if your team has low standards and just settle with whatever the framework has choosen for you. I'm not surprised it's fine for many.

Wasn't event baited

Trump is 1% of the U.S.A problems. He's more or less just a dumb symptom.

No more reason now than 2 years ago.

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.

type IJustWantToExperiment = any

You could use the allowJs typescript flag and mostly use JS files at first; perhaps only typing a few models.

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.