[KronisLV]

>> API-only - the only technology we should be using to create web UI is JavaScript.

> Thanks. I'll pass on that one.

I don't know, there's definitely some merit in separating your front end from your back end - at least that's the impression I got after struggling on JSF/PrimeFaces Java projects for a few years, because at least with a well defined API and no magic behind the scenes everything becomes more observable and easier to reason about, with fewer bugs. Some might prefer TypeScript or something else to JavaScript, but I think the point still stands.

In addition, this lets migrate or change everything piece by piece, as long as the interface isn't broken:

  - different frameworks (let's say from Spring to Spring Boot, or from the old ASP.NET to the new variety that runs on Linux, or Rails to Rage or vice versa)
  - different languages (if someone decided to take their PHP Laravel solution and migrate to Ruby with Ruby on Rails, or Python, or anything else)
  - deprecated technologies can also be handled gradually (e.g. supporting an EOL AngularJS solution while developing a new front end in Vue/React/Angular/whatever)

As for the reason for those migrations, sometimes code just rots due to neglect, other times you need features that aren't available in your solution of choice (for example, pre-made UI components, like PrimeVue, PrimeReact and PrimeNG have; or maybe needing to have responsive maps in the app). In addition, you can also deploy your front end and back end separately, have different rules for the reverse proxy in front of them, suddenly have a very clear view of where your static assets are, might have all of the benefits of a SPA and PWA (if needed), anyone can integrate with your API if needed/allowed because you've hopefully built it to actually be usable and so on. Plus, your front end can talk to multiple different APIs, so if you have multiple teams working on those, suddenly that is a solved issue for you as well.

That said, it's also a lot of work because SPA and adjacent approaches bring a lot of complexity into the mix and something like Vue/React/Angular and its ecosystem will bring its own pain points and things you have to learn. If all you need is a bunch of forms, then pretty much anything will do fine and SSR is a good choice. If you need an "app" on the web, then HTML/JS/CSS isn't a very good choice to begin with (historically not built for that; though I don't think there are actually good choices, same as with desktop software), but those SPA solutions will see you pretty far.

[Draiken]

Use HTMX and you'll be surprised how much you don't need JS for (or to be more accurate, very little JS).

Rails especially is very good for this with partials. Use ERBs (or Haml, Slim, etc) and it's an absolute bliss with the added benefit of easy caching.

Stop duplicating state. Stop duplicating logic. Maybe in the future when your app needs 5 different clients, it makes sense to only have an API. But let's not pretend that should be the default!

I still cry every time I see a new application using GraphQL to have literally one client which is simply serving HTML with a bloated JS framework. The whole premise of it was to be flexible for multiple frontends. Come on folks, YAGNI.

[egeozcan]

I used HTMX since the intercooler days [0] but the stuff you can make is rather limited. Also you still need the JS to deal with a11y things like expanded state (or hyperscript, apparently).

If you have a lot of components to implement, everything requires thinking. Example: You want to add a repeat field to a form. Easy, get the input from an endpoint, and append. Done? No, how do you remove a field? Add a line of JS, simple! Drag and drop if the order needs to change? Let's add a dependency! [1]

I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever.

And you will need another client (don't YAGNI me on this one, burned too many times by people not caring about endpoint design), but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint (respect the accepts header) and call it an API.

[0]: https://intercoolerjs.org/

[1]: https://htmx.org/examples/sortable/

[ecshafer]

Rails with turbo and stimulus is amazing. Very similar to htmx and phoenix liveview. Stimulus lets you make a really minimal web framework for ui elements that are mostly defined as ruby components, and turbo lets you to use erb without whole page reloads. Whole responsive web apps with a dozen lines of js, its great.

[Draiken]

What do you mean by UI elements defined as ruby components? Are you referring to ViewComponents or something else?

[ecshafer]

Yeah you can define viewcomponents in ruby. Have them rendered based on stimulus code. Turbo lets you do updates without full page reloads, viewcomponents make much more reusable and flexible ruby based components than pure erb, and stimulus handles front end state. I rewrote a medium size react + graphql page with this and thr code base was literally 1/10th the size

[_heimdall]

> I don't know, there's definitely some merit in separating your front end from your back end

This is 100% true and the biggest loss in web development in my opinion.

SPAs actually end up making this worse in the long run though. The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together. The original SPA approach did offer the ability to separate frontend and backend, but the frontend scaled poorly and brought in too many complex considerations like routing, caching, error handling and recovery, etc. The new approach is basically abandoning the benefits of an isolated back end in favor of tight coupling simply because the existing frameworks are too far down the wrong path.

If your goal is ever to isolate the frontend and backend you'll want to consider three environments - backend, web server, and frontend. Ironically that's exactly where we were when SPAs broke out onto the scene

[pmontra]

> The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together.

I'm not familiar with this development. Do you mean that for example React has grown a backend running on a server, querying the database, etc?

I know that backend frameworks like Rails and basically all the major ones added a JS layer running inside the browser and obeying to the backend. It listens to messages from the backend with changes to the UI elements and that saves full page reloads.

[_heimdall]

I'm thinking mainly about about SPA frameworks (metaframeworks?) like NextJS, SvelteKit, Remix, and I think NuxtJS as well though I'm less familiar.

They're all adding features where code is marshalled back to the server either through useServer() hooks, pragmas, or magic $ signs and imports.

They all create RPC calls as part of the build and bundle step. Depending on the specific implementation, that usually means taking code that otherwise looks like client code, moving it to the server bundle with a unique API signature, and swapping the RPC API call into the client code.

[mattmcknight]

> backend frameworks like Rails

Rails has been a full stack framework since the start, with the JS component changing frequently over the decades, but with template helpers that generate JS being a fundamental component since the beginning.