HN comments are underrated

It's a vicious cycle based on a kafkatrap. If you don't agree that women are discriminated against in tech, you're discriminating against women. Culture committees, diversity consultants and women-only groups are set up to "address" this problem, yet all they do is create more division and alienation, holding up the most stereotypical fragile princess as representative for every woman on the planet.

They keep throwing all sorts of accusations and aspersions on every single guy in the field, shriek and pearl clutch when they receive blowback, and have the gall to call this empathy, in a field where the average worker is an undersocialized and overworked code janitor. Whose preferred communication styles, hobbies and accomplishments are fair game to ignore or bulldoze over.

Pointing this out gets you labeled as "horrible". Fine, then. Yet another word to add to the pile that has lost all meaning. Misogyny used to mean "hatred of women", now it just means "something a woman hates". Which appears to include the average mid-rung nerd.

I am curious about something else.

Do you have non anecdotal information about Wikipedia's general dependability?

How is the dependability for large subjects? For subjects like a poet where less than a hundred people even recognize the name?

(The last I saw on this was years ago, when Wikipedia edged out the Encyclopædia Britannica. It would be strange to be less dependable now?!)

I believe the most important thing when developing software is managing state. The best cross-language technique I know for reducing state is to prefer functional approaches, lock down mutability wherever possible, and prefer persistent datastructures. These techniques cause problems for truly high performance code (HAMT-like datastructures have pointer contention at the head) but very little of the code I write is that performance sensitive.

From the UI side, I believe the reactive programming model has won out and I'm unaware of any medium to large javascript frameworks that don't have some sort of change detection/propagation system. Polymer is the most dom manipulation oriented current gen framework I know about and it still makes substantial use of observables and bound properties.

Put together, I currently believe that the virtual dom diffing approach on persistent datastructures is the best general purpose starting point for building a user interface. The biggest arguments against the approach I've heard are that it's memory inefficient since the entire output virtual DOM has to be retained for diffing and that the diffing process itself is less efficient than direct change propagation using observables. While both valid complaints, I have not found them useful complaints.

For memory, the target market for the apps I've written has yet to include mobile devices that are memory constrained to the point that virtual DOM size is a significant factor and if they did, I'd be inclined to try something like incremental dom before abandoning the pattern.

For performance, the combination persistent datastructures guiding the diff substantially reduces the amount of diffing overhead. I've been able to hit 60 fps on a randomly-update 10k DOM node stress test using Inferno and a custom HAMT implementation on a 2012 Macbook Air and ~25 fps on my 2nd generation Moto X. I consider this good enough but I can see how people who are more focused on mobile and in particular emerging mobile markets would have different opinions.

My counter to these arguments is that I find the performance characteristics of the virtual DOM easy to reason about and performance being primarily driven by the output size has allowed me to take input datasets that I would not have even considered on observable systems. An example: I put together a calendar that was supposed to be a temporary prototype, wound up getting put into production (semi-predictably), and we had the events input grow to 9MB of gzipped JSON (two orders of magnitude more than I expected) before it got replaced. Load time was terrible but once it was up, latency for all actions was ~30ms.

As for React itself, I find it acceptable. Its artificial event system made more sense when it was made but I think it's more overhead than value these days. I've never liked setState and never used it in a production app. The main reason to stick with it over a second-gen vdom library like Inferno is network effects. I tend to not use a lot of third party code so I expect to switch to an alternative vdom at some point in the not too distant future.