Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms, then you have to bolt on server side session management, state transfer and the other patterns that emerge from sending everything to the server. In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management.

Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale.

I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.

> In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management.

Is this even true in most cases? You almost always have some state that needs to be in both places. The more you choose strategies to optimize for client-side development and treat the backend as just a store for "blobs" of data, the more problems you have given enough scale, requirements, or just the passage of time.

What you state is correct for a subset of applications, but it's not universally applicable. With enough time and experience you'll likely understand the limitations. I'm not going to keep arguing with you because your subset can get you very far, and it's probably the right thing to do for your needs.

> I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities

Can you elaborate on the complexities? The desktop (as in Win32, Qt, etc.) and the web are on different ends of a spectrum. With JavaScript frameworks we have an in-between. In many ways you can put native mobile development in the desktop bucket because they are effectively have similar constraints, although some of the ideas/tools are a more modern implementation.

When you try and build abstractions to make the web feel more and more like desktop you expose the limitations of web development. The web will support more and more application features, but progress is naturally going to be slow around the maturation of these features than if you had gone with full desktop. What's interesting is that the web keeps pace enough that it never gets eliminated from the race. This is very important part of web and why people keep betting on it.

Oh, I'm not necessarily talking about going back to old server-side stacks, more that the heavy client-side stacks seem to get used all the time even if the problem didn't need them.

If you're writing something really horrendously complicated, yes, some sort of framework will help. If it's a little throwaway tool for internal or casual use, it's usually perfectly feasible to do the whole thing in one or two hundred lines of HTML+CSS+script. No tooling, no dependencies. It's so much quicker and so much less painful, and yet bizarrely people look at you like you're a wizard because the whole thing is 5k uncompressed and doesn't even need a webserver.

"Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms"

Both of these stacks are themselves deprecated and replaced by better solutions in the same ecosystem. "We're only as bad as 10-15 year old stacks" is hardly a compelling argument.

That sounds ridiculously more complex than clicking "new project" and just going with it.

No, I want to be clear, I certainly was not arguing that point, just making the point that I view the current state as an advancement over where we have been, in relation to past web development trends.

Or compare it to something like Lazarus, where you install the environment (sadly it is not at all portable) and can construct GUI applications with a WYSIWYG editor that compile directly to native binaries for multiple platforms.

GUI editors always go in cycles, and we always come back around to writing code as the editors can't represent the things we want to do.

Except for a huge number of use cases where they can, of course. Obviously not everything can be abstracted away, but things like Lazarus or HyperCard or even Excel offer a starting off point for people to build powerful tools to solve their problems without acquiring a traditional programming education, and offer a ramp into programming for when people need to do more with those tools.

It's still possible to get 99% of the results with 1% of the effort using something like parcel+(vue/react).

Right but part of the problem is the proliferation of different tools. If I choose Parcel I can no longer use Vue CLI, and 99% of documentation, blog posts, stackoverflow answers etc. no longer apply. Plus I have to learn what Parcel is.

This is why I've stuck so strongly with Ember for web development. Even with the modern edition of Ember, Octane, it's as simple as `ember new my-project` and off you go. No choices to make, no toolchains to configure, just writing productive code.

Qt, Flutter, JavaFX, hell even Swing is infinitely better than any JS framework. Easier to get started with. Easier to ship. Easier to maintain. Easier to do actual, you know, computer stuff with because you can do actual I/O and talk to the OS. It's not even in the same solar system as JS, from either the user's or the developer's perspective.

The state of the art in web is React which is an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Win32's UI loop.

Could have been, but I’m happy to develop in js and upload it so anybody could just visit the site and run. Build till worldwide is infinitely faster. Especially for smaller projects. e.g

http://aperocky.com/prehistoric

This is cool but it would have been easier to build in Java or Dart or C++.

Meanwhile, I don't think any of the non-web client platforms can compete with how nice it is to develop web clients, from React to Elm to trivial async-everything + async/await + the simple Promise and concurrency management. Just to give you another viewpoint.