In bullet points:
1. Yesterday someone presented a case where they needed to interact with a DOM API that used local state.
2. I didn't think it would be worth the trouble to wrap that API.
3. That is not an endorsement of local component state.
Hopefully that clears things up. :)
It seems you want all Elm news to be positive Elm news. So does the language's author. In fact, when addressing the announcement re: Hacker news, he wrote this:
"Just an FYI, if you go to a HN post via direct link and vote on it, those votes either do not count or are used as demerits because it indicates that people are trying to artificially boost things. I guess getting a kickstarter to the top of HN can be worth a lot of money, so they try to protect against voting rings."
(See https://groups.google.com/forum/#!topic/elm-dev/NQxML4HA4X8 )
Civility is important. But so is the honest, unfettered exchange of ideas.
I guess if your issues were legitimate, we'd see a post on the mailing list, not an open attack on Richard's credibility.
For the record, this is evidence-backed criticism:
https://news.ycombinator.com/item?id=10081955
Yours is just trolling.
1. You don't get to define evidence-backed criticism to be only the criticism that you appreciate.
2. I didn't "attack" Richard. I pointed out an inconsistency with other recent statements that he has made, that bear on the credibility of his current advice.
3. I'm not sure how my identity is relevant to my ideas. But the reason I don't post under my own name has to do with requirements of my job. (I'm not a programmer by trade.) I can't have social media accounts. In any event, this isn't a throwaway account. These are, in fact, my first posts to HN.
> "Local component state is the new two-way data binding. . . If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "yeah it wasn't awesome so I went back to local component state."
> "I wouldn't maintain cursor state in the model . . . Whenever you want to change its value, just send the desired new value to that port and let the JS snippet do the "stash cursor position, set the new value, restore cursor position" bit."
The question we were addressing is where your state should live. @boubiyeah questioned the wisdom of storing all component state (e.g., the current position of a cursor) in a global atom. You responded that "[l]ocal component state is new two-way data binding." Yet yesterday you advised that component local state should live outside of the global atom.
Maybe it wasn't disingenous, as perhaps you've simply changed your mind. But then you should make clear that your opinion today is different from what you advised yesterday, as it bears on the credibility of your current advice.