[lars-b2018]

I read the article and the GitHub page, looking for specific examples that characterize their objectives. I believe they are on to something, but without specific illustrations, it is too abstract. Context matters in decisions, and I believe they are trying to say: just don't default to using a framework based on what you know (everything is React or Rails or...) but ask yourself "do I really need this for this project based on scope and maintainability?" Everything has a cost to it in a project and over time, and the bigger picture must be considered.

One itch I think it is trying to scratch is that often times frameworks stand in for a gap between what the core language and standard libraries support and what is required by the application. For example, web delivered applications have shifted from the traditional server rendered web interface, to single page applications. Web apps that act like applications have requirements that browsers out of the box don't support: often you need to have tables that can be sorted and shifted for example. There are not "native" javascript/DOM mechanisms for this. So enter third party code to facilitate. Which to choose from? In desktop applications, this facility is handled by the UI layer running on the OS. The JS/DOM doesn't provide it and so if you need it: roll your own, use a third party app, etc. But that has baggage you may not want: dependencies, potential security risks, and maintainability. So I think, at least in the web area, there is a gap in what people need for SPAs, and what the underlying JS/DOM provides.