I get what you're saying, but anecodtally I can say I've never worked on a codebase like that. The pattern I came across most frequently would use JS values to store state, scoped as tightly to the relevant event handler as possible, e.g.

    $(function(){
      var myState = 123;
      var myElem  = $('<span>' + myState + '</span>');
      $('#myParent').append(
        myElem,
        $('<button text="Increment" />').click(function(){
          myState = myState + 1;
          myElem.text(myState + '');
        }));
    });

Interaction with the DOM was treated as I/O, akin to file or stdio access: for reading, get it into a sensible internal variable as soon as possible; for writing, dump it out as the final step. Using the DOM to hold state seems, to me, akin to holding state in an external file (reading and writing as needed), rather than a variable.

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax...

I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable.

When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.

While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet).

I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually.

But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things.

I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing.

It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.

Keeping the view state in the server is what Java Server Faces did and trust me you don't want to repeat that same mistake.

Here's an interesting response from Elixir's creator (and contributor to LiveView) specifically about JSF:

https://elixirforum.com/t/phoenix-liveview-is-now-live/20889...

I don't know JSF so I can't really argue this point, but I'd really love to hear what you think about the argument Jose put forward and where you might disagree!

I kept a real nasty implementation of this alive for the last two years while building a REST api and React frontend to replace it.

I learned a good lesson, though: no logic in template files! Ever!

I've recentlt started working on a project where they store data / state in the ids of dom objects. Sometimes even something like dash separated strings that need to then be parsed.

I come from having done pretty much no Web development and this seems like a hateful way to do development.

It is, and basically the selling point of modern front end practices like APIs, state managed only in JS, SPAs, etc. Maybe this tech is overused in some cases, but it's vastly better than the "JavaScript Sauce" type development you describe.