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.

This entire blog post is well written garbage. There is no content.

That header animation was cool only the first 50 times I saw it

I agree with the general sentiment.

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?

what if it being more productive for you has nothing to do with these magic strings? :)

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.

react is not based on logicless templates. Their very first presentation in 2012 or 2013 made that clear. It's a feature.

But managing state is quite hard in general. Angular proudly advertises it solves all problems you can have on the frontend but I would take react state + utils over angular's magic templates, rxjs and bindings any day.

React was never a view-only library.

Pete Hunt always said he saw React components as mini MVC modules.

it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.

Man, this argument is so dumb indeed...

Even dumber than the "Hey, why should we care about the environment since a few countries can decide not to"

Really like typescript. You could code an algorithm with very dynamic types then expose its API with very rigorous typing (TS's type system can go pretty advanced)

Devs like you is the main reason why the web is much, much slower than it could be.

Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc.

Making your dev life easier is nice, but don't forget the end goal...

(Note: I'm not talking about those internal apps that have 10 users :p)

This. People often have a beef with the very wild npm ecosystem with tons of libs of varying quality, abandonned projects, bloated libs, etc but mostly it comes down to the standard library being anemic.

Gave me seasickness. And I'm not even sick on boats.

Very true. The US unleashed orders of magnitude more hell than that, abroad. Why should we be so biased?

Looks like pretty average code to me.