What to expect from your framework

What to expect from your framework
johan.hal.se

A good example of this is: Rack::MethodOverride

Try making your non-JS server rendered view functions and HTML form submissions handle PUT, PATCH and DELETE. Depending on which lightweight alternative to Rails you're using this can become very tricky and you end up spending an entire day of Googling and maybe finding a questionable solution instead of having that available without thinking about it.

I never got why people care about the difference between a library and framework and try to categorize these offerings, especially when we don't even have meaningful definitions. The way I've seen it, you're usually going to have one front end "base thing" and build everything around it - be it Vue, or React, or Angular, or Svelte, or jQuery, or Next.js, or Nuxt, or JSF, or Vaadin, or Laravel's Blade templates, or the Rails equivalent etc.

In some cases, it will try to provide everything out of the box, in other cases you're going to integrate a bunch of other stuff to do what you want, but you're rarely (at least in my experience) going to have something like React combined with Vue, or Vue with Svelte in the same site, which is sometimes touted as one of the advantages of libraries. I think I can recall one micro frontend project in my past like that. Furthermore, I've seen very few cases where integrated libraries are ever swapped out for something else once there's lots of code written against them, so they get coupled with the rest of the codebase regardless (unless you're really good at establishing boundaries/abstractions), so that's another supposed advantage that doesn't always pan out. And even when you use most of the frameworks out there, you still need to think about UI components and such, of which there are many libraries to integrate with your framework, so you still need additional bits introduced.

It's almost like saying "Next.js acts 75% like a framework, whereas React only provides 25% of what you'd need for a full batteries included experience and therefore will mostly be treated as a library on its own." Silly way of framing it, I'll admit, but the end result will most likely be the same - one big repo of front end code (possibly a sub-folder), regardless of how many packages it's made up of. Just pick a group of solutions that fit your architecture of choice: Laravel, Rails and Django front end offerings are all good for SSR, whereas for SPAs just pick things depending on how much of an integrated experience you want, anything from Nuxt to barebones Vue, with libraries imported based on needs.

Personally, I like the benefits of SSR (how integrated development can feel, easy to reason about), but I dislike the coupling and how you eventually will need to upgrade "the entire thing", which might be a big rewrite (e.g. moving from Spring to Spring Boot, or upgrading Rails/Laravel projects across major versions). I like the ability to throw away and replace SPAs if the need presents itself (AngularJS, anyone?) and the clear decoupling thanks to the API (running the old and new thing side by side is nice for dev). Oh, also SPAs lend themselves nicely for build parallelization, but have the downside of two deployment units (e.g. separate front end and back end containers/packages). Solutions that give you most of what you'll need are great, but only for as long as you don't have to fight against them due to needing to do something different.

I think a huge reason the js crowd got away with the "better DX" spiel is because CSS got left on the side.

So doing it CSS-in-JS allowed to paper over the CSS painpoint for componentisation and composition.

If you look at it this way, Tailwind make sense. Because what it gives you is mixins and variable. Just... Mixins in html `class`