I disagree; I don't think there's a lot of "hate" just some gentle mockery.
> What he did isn't insane. It's not exactly what I would've done, but then, the meta-lesson from this post is that you don't have to do what everyone else is doing.
The thing is, he did do exactly what everyone else is doing, just a bit worse than most of the popular solutions.
> And when other people come up with a solution that's different from what you would've done, try to see how their problem differs rather than saying they're stupid.
But his problem didn't differ. He had the same problem everyone else has, and ended up re-inventing the same solution everyone else is using.
If you're working on the web, you'll need to turn data into HTML, and his solution was a JS function to turn data into HTML; it's the single most common problem and the single most obvious solution pattern. The issue is that there are already good solutions for his exact problem, and his isn't one of them.
1. Spend an hour writing 50 lines of code.
2. Spend 3 hours identifying a framework that includes those 50 lines of code, reading the docs for it, finding exactly which call or combination of calls duplicates the functionality that you would've written yourself, writing code to that API, and then debugging where your mental model doesn't match the mental model of the framework authors.
Which of those is better?
I suspect most of the commenters here would say #2. My point is that the real answer is neither: it's "it depends". It depends upon who you're working with and what their background is; how long you expect the code to live; whether you expect to use additional functionality in the framework in the future; how well-documented the framework is; what fraction of the framework will be used in this solution; etc.
A lot of people, particularly more junior ones, look at an established framework like React and think "because it's supported by Facebook and thousands of people use it, of course you should too". I'm saying that it's not always that simple: sometimes it's appropriate, but sometimes, just rolling your own is fine too.
(My perception is colored because when I was at Google, I was frequently the one writing the software that everybody else assumed they should be using, and I was intimately familiar with all of the downsides and weaknesses of said software. I recall running into a post on servo-dev where someone proposed using the Gumbo HTML parser, which I wrote, for Servo's HTML parser. pcwalton's reply was "Just because Google released it doesn't mean that it's suitable for our purposes" - which is exactly correct, Gumbo was never meant to function as a browser engine.)