It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model.
For example lets take a shopping cart, in the page post model you would submit the page to the server, create a cart in the session (bad, bad, bad) and then respond to the client with a new UI, the client would select an item, you would form post that item and the server would update the cart with the item. Back comes the UI and we do it over again with another item, ad nauseum. Eventually the user selects check out, we form post and hit a routine that tallies everything up and spits back another UI. We do this until all the data is collected to complete the transaction.
With the new model, The UI is the sole domain of the client and we speak to the server in complete representative state when we have the whole communication. Not only that but data definitions have very ridged walls that define what that data is, therefore making the server side code far more reusable (more on that in a minute).
So for this example, done the new way, JavaScript creates an order object, it then displays the UI for products after making an asynchronous call to get the product information (given that this is a defined call to the /products URL we can set a cache expiration in the future and therefore any subsequent calls have very little cost associated with them).
So now the server is acting as a data and business logic layer, while the client is providing the work-flow and the screens.
Back to the example, on the client side we have an order object, loaded with products that we have not had to make transitions to the server to create and update, we can then push this object to the server via a POST to the /orders service.
As you can see your data and business logic are becoming very defined and resource-able. If you decide to provide a mobile interface you already have the services available to support it, your data is no longer intertwined with UI work-flow.
The benefits of this model are vast but at a high level here are the big ones:
The client side becomes responsible for the work flow. So different UI's can provide optimized work-flows for their format. Web, Mobile, voice, do not have to rely on the same work-flows to reuse existing code and not start over.
Front end developers work in pure HTML, CSS and JavaScript there is no reliance on back end technologies to be able to perform their tasks.
Back end developers work in pure platforms, a Java developer works in Java, a .NET developer works in C#.
The front end and back end are loosely coupled through service calls, either can be swapped out without ramifications to the opposing side.
You data and business logic becomes addressable, a natural byproduct is that you can expose your system to third party consumers and alternative UI's.
You are working with a non-fragmented object model, one party is responsible for state and that is the client.
The front end is far more responsive to user input. You have far more opportunity to pre-fetch data based on user patterns and expectations. You have fine grain control over performance.
UI's are best programmed via an event based model. It is impossible to achieve this within the old page post model. (See the Node.js talk on blocking vs no-blocking, this is a relative of that argument).
Session management is offloaded to the client, reducing large amounts of memory and resource requirements on the server side. No longer does the server have to approximate what is happening on the client side.
A byproduct of the client holding session is that any disruption in communication does not reflect a total failure of the transaction. The client holds state and therefore can submit to the server once it become available again, no matter the point in work flow.
The decoupling of the server side allows the UI teams to develop the front end in a far more agile and rapid fashion. They can hold closer to the stake holder and rapidly modify the application to meet user needs.
If a top down approach is used, the entire front end can be prototyped while creating stub service files, allowing the stakeholder the ability to touch and feel the application before back end development begins. This significantly reduces the costs associated with development to get to the point where end users touch and request rework to the application. Further, the stubbed services provide a clean definition of the services required to the back end team.
I could write a book on the pros of this development methodology but sufficient to say, with JavaScript frameworks and proper architecture, writing new style web apps is far less cumbersome and a lot less convoluted. I was one of the nay-sayers until I tried it and actually found that it was easier and produced a superior user experience. The benefits to building apps this way are numerous.