Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects.<p>> <i>Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons of questions and answers on StackOverflow and Quora.</i><p>I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
Also their user onboarding literally forces a unknowing user to create a GitHub account then star their specific repository.<p>Making GitHub stars ultimately meaningless, if they ever meaned anything.
Hey, I'm the author of the "GraphQL Visualizer" tool (<a href="http://nathanrandal.com/graphql-visualizer/" rel="nofollow">http://nathanrandal.com/graphql-visualizer/</a>) that they mention in the article as inspiration for their project.<p>This new project is quite nice and definitely a step up from mine.<p>Also wanted to mention that there is a CLI version of the visualizer at <a href="https://github.com/sheerun/graphqlviz" rel="nofollow">https://github.com/sheerun/graphqlviz</a> for when you want to quickly visualize a GraphQL endpoint for documentation purposes, etc. Keep up the good work!
<i>But after looking at the source code we found a fatal flaw in this tool: it used Graphviz — a decades old tool written in plain C and compiled to unreadable JavaScript using Emscripten.</i><p>Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".
Ignoring the fact that Github Stars are a aweful metric for anything else than vanity, "More bells and whistles" feels like a terrible advice and you should much more focus on a "easy-to-get-started" readme with just the minimal amount of beels and whistles to effectively communicate what your thing is really about.