I find intriguing your idea of letting projects grow toward needing a framework. I have a hard time imagining myself on such a path, but I should mention that the only framework I have tried to work with so far is Rails, and in the above article framework means front-end framework.
My first rails project was "duper," which was an attempt to implement a simple double-entry bookkeeping system as a Rails app. The reason I wanted to do this is because I had taken to using GnuCash for balancing my checkbook and the like. I love the precision, and I love the data model, but I hate the user interface. As someone with 20 yrs data entry experience (but shameless plug, gitlab.com/n8chz) I know a bad user interface when I see one, especially input interface. I thought to build a Rails app around GnuCash's data model (available as your choice of an XML file or a MySQL database) but all of the Rails tutorials were walkthroughs of crud apps from scratch, including building models ex nihilo. I could find no non-paywalled hints on how to build a Rails app over an existing data model. So I created my own model, incorporating sombunall features of GnuCash, which (if I may brag) a vastly superior user interface of my own devising.
But if GnuCash is overkill for balancing my checkbook (and it is), surely Ruby on Rails is massive overkill. I'm thinking maybe instead I should have written something in whatever language (they all have a MySQL library available it seems) that simply sends raw SQL statements to the GnuCash backend, but that would be so, what, 2004?
I also think brain wiring may be a factor. You say frameworks exist to abstract away the DOM. I remember reading somewhere (but alas I forgot where) that frameworks exist to abstract away SQL. Perhaps you're both right depending on whether it's front-end or back-end frameworks. But I think in SQL. I took a community college course titled "Relational Databases" where I was taught something called "relational algebra" (the data structures rubric that is the home of Boyce-Codd normal form) and I was like that's literally how I've been organizing information mentally for my whole life. I literally think in SQL (or the conceptual equivalent). So when I heard that someone invented frameworks as a way to abstract away relational algebra so developers can instead think in a (to me) clunky language called "object oriented," well, let's say I was blown away by a sense of how truly unfathomable neurodivergence can be.
This is a really interesting point, which I read as what the article was getting at - that frameworks always bring an overhead. Sometimes it's computing-related (memory, execution time) and others it's cognitive...having to understand the framework to do anything useful. The aim is that the gains from the framework exceed the overhead. In the case of ORMs (that is Object-Relational Mapping - translating SQL into objects) theres such an assumption (wrongly, often, and touted by OOP developers who don't understand SQL) that the gains are obvious and don't need to be explored. Writing stored procedures in a database and calling them directly is perfectly fine in lots of cases! Go for it, I say.
In the case of client-side frameworks though, abstracting the DOM is the reason to use one...any one. There really isn't any such thing as the DOM; there are multiple implementations that appear similar but vary according to the browser being used. In the case of web apps, the browser is a choice of the user, not the developer, and so the developer is encumbered with having to test functionality across all of the differing implementations. Client side frameworks do this for you. Knockout.js, for instance, has support for browsers going back to IE6 - try doing that with vanilla JS.
Server side rendering also has its challenges. Take a simple tick-box filter, for instance. The click in the checkbox doesnt trigger a post back, so you have to listen for it and force it through using JS (taking into account all of the differing browser subtleties), then figure out on the server what state your UI was in (HTTP being stateless, the server has no intrinsic "memory" of what this particular user saw beforehand so only has the data posted back from the client to go on).
In the case of client-side frameworks, therefore, the overhead is miniscule in comparison to the advantages, which perhaps explains why there are a) so many of them and b) why even in the smallest projects they are worthwhile.
In fairness to Rails, it is not intended to be used to build over existing data models. You can absolutely coax ActiveRecord to store PKs using non-standard conventions, but if you want to benefit from the ecosystem, you aren't likely to have much luck if you stray from the ORM patterns.
This is 100% by design. Rails is an abstraction from Basecamp. The creator of Rails has frequently stated that it hit critical mass the moment they used it to launch their own product. If anyone else finds it useful, this is a happy side-benefit.
For those of us who find it useful, a big part of the Rails value proposition is that we embrace the concept of convention over configuration. That is, there is a name, place and strategy for most things you want to do. You can absolutely step out of these patterns, but then you are violating what we call the principle of least surprise. The upside of this standardization of expectation is that an arbitrary Rails developer can join your project and intuitively know where everything is. They will be productive almost immediately.
By collectively deciding that bikeshedding is an over-rated time waste, we go from 'rails new' to serving authenticated pages that display data very quickly.
As a rule of thumb, if you cannot find documentation to support what you're trying to do, it's very likely that you're trying to make Rails do something against its own conventions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find intriguing your idea of letting projects grow toward needing a framework. I have a hard time imagining myself on such a path, but I should mention that the only framework I have tried to work with so far is Rails, and in the above article framework means front-end framework.
My first rails project was "duper," which was an attempt to implement a simple double-entry bookkeeping system as a Rails app. The reason I wanted to do this is because I had taken to using GnuCash for balancing my checkbook and the like. I love the precision, and I love the data model, but I hate the user interface. As someone with 20 yrs data entry experience (but shameless plug, gitlab.com/n8chz) I know a bad user interface when I see one, especially input interface. I thought to build a Rails app around GnuCash's data model (available as your choice of an XML file or a MySQL database) but all of the Rails tutorials were walkthroughs of crud apps from scratch, including building models ex nihilo. I could find no non-paywalled hints on how to build a Rails app over an existing data model. So I created my own model, incorporating sombunall features of GnuCash, which (if I may brag) a vastly superior user interface of my own devising.
But if GnuCash is overkill for balancing my checkbook (and it is), surely Ruby on Rails is massive overkill. I'm thinking maybe instead I should have written something in whatever language (they all have a MySQL library available it seems) that simply sends raw SQL statements to the GnuCash backend, but that would be so, what, 2004?
I also think brain wiring may be a factor. You say frameworks exist to abstract away the DOM. I remember reading somewhere (but alas I forgot where) that frameworks exist to abstract away SQL. Perhaps you're both right depending on whether it's front-end or back-end frameworks. But I think in SQL. I took a community college course titled "Relational Databases" where I was taught something called "relational algebra" (the data structures rubric that is the home of Boyce-Codd normal form) and I was like that's literally how I've been organizing information mentally for my whole life. I literally think in SQL (or the conceptual equivalent). So when I heard that someone invented frameworks as a way to abstract away relational algebra so developers can instead think in a (to me) clunky language called "object oriented," well, let's say I was blown away by a sense of how truly unfathomable neurodivergence can be.
This is a really interesting point, which I read as what the article was getting at - that frameworks always bring an overhead. Sometimes it's computing-related (memory, execution time) and others it's cognitive...having to understand the framework to do anything useful. The aim is that the gains from the framework exceed the overhead. In the case of ORMs (that is Object-Relational Mapping - translating SQL into objects) theres such an assumption (wrongly, often, and touted by OOP developers who don't understand SQL) that the gains are obvious and don't need to be explored. Writing stored procedures in a database and calling them directly is perfectly fine in lots of cases! Go for it, I say.
In the case of client-side frameworks though, abstracting the DOM is the reason to use one...any one. There really isn't any such thing as the DOM; there are multiple implementations that appear similar but vary according to the browser being used. In the case of web apps, the browser is a choice of the user, not the developer, and so the developer is encumbered with having to test functionality across all of the differing implementations. Client side frameworks do this for you. Knockout.js, for instance, has support for browsers going back to IE6 - try doing that with vanilla JS.
Server side rendering also has its challenges. Take a simple tick-box filter, for instance. The click in the checkbox doesnt trigger a post back, so you have to listen for it and force it through using JS (taking into account all of the differing browser subtleties), then figure out on the server what state your UI was in (HTTP being stateless, the server has no intrinsic "memory" of what this particular user saw beforehand so only has the data posted back from the client to go on).
In the case of client-side frameworks, therefore, the overhead is miniscule in comparison to the advantages, which perhaps explains why there are a) so many of them and b) why even in the smallest projects they are worthwhile.
In fairness to Rails, it is not intended to be used to build over existing data models. You can absolutely coax ActiveRecord to store PKs using non-standard conventions, but if you want to benefit from the ecosystem, you aren't likely to have much luck if you stray from the ORM patterns.
This is 100% by design. Rails is an abstraction from Basecamp. The creator of Rails has frequently stated that it hit critical mass the moment they used it to launch their own product. If anyone else finds it useful, this is a happy side-benefit.
For those of us who find it useful, a big part of the Rails value proposition is that we embrace the concept of convention over configuration. That is, there is a name, place and strategy for most things you want to do. You can absolutely step out of these patterns, but then you are violating what we call the principle of least surprise. The upside of this standardization of expectation is that an arbitrary Rails developer can join your project and intuitively know where everything is. They will be productive almost immediately.
By collectively deciding that bikeshedding is an over-rated time waste, we go from 'rails new' to serving authenticated pages that display data very quickly.
As a rule of thumb, if you cannot find documentation to support what you're trying to do, it's very likely that you're trying to make Rails do something against its own conventions.