Just a few years ago, before the LLM-assisted-coding-era, I already did not like frameworks as much as I used to.

I liked Rails. But that was more because through Rails I learned the MVC pattern, learned the layer-middelware pattern from Rack (and the ActiveRecord ORM -- but I now no longer like ORMs but that's a different story). Those 2 pattern I still use today in some way or form, and I find them in many modern (Rust) web development frameworks/libs.

So I now no longer use Rails for new projects. These projects were all SSR web apps (traditional server-side rendered web apps that use JavaScript sparingly), built with Kotlin+http4k. Http4k is a web library, so no framework there and it feels very good.

The article is very frontend/JS-focussed. I prefer to keep things simpler and just use SSR for the UI. This is because above all (1) I dont like JavaScript (not even when my LLM writes it for me) and (2) for the type of application it is not needed to do state management again in the browser (IMHO it's just more code for the same features).

Sure, a little JS is needed in my apps too. But I (assisted by LLM) use it sparingly and when I use it it's with Alpine.js.

CSS with Tailwind and JS with Alpine makes for pages that are mostly "self contained" (the CSS and JS defined in the same place as the HTML that relates to it), which makes reasoning about them so much easier. For HTML building i use kotlinx.html (an HTML eDSL in Kotlin; HTML as Kotlin code).

I'd say http4k, Tailwind and Alpine are not frameworks. Maybe Alpine is most framework-like of all of these. At least they are not frameworks in the sense that they do not dictate my project folder structure and "how everything ties together".

With http4k the "how everything ties together" answer is in your own project's code, NOT in "the framework" or in 3rd party library code.

In my latest projects (all LLM assisted) I make heavy use of architecture tests: tests on the shape (e.g.: folder structure) of my codebase. These tests check that my architecture rules are adhered to. Think of enforcing the MVC pattern; only the pattern that I use is way more split out (instead of M-V-C, it more like: boot - contract - db - domain - filter - handler - job - lib - path - presentation - routing - workflow).

I'd say framework matter more when:

1. you are learning something, or

2. when the team needs to have shared code hygiene values, or

3. when you do not use architecture tests yet!