No one said that they have to be micro services. One should provide composite services that provide all of the data for a work-flow. Then use a pub-sub event based model to notify the UI of available data. This way components stay loosely coupled and are only listening for an event that injects the relevant data that they need. This results in a single call to a composite service yet the micro services are available should a different UI need a more microscopic flow or data load (for example, limited memory on a mobile device).
As well another common mistake I see is services calling services to build a composite service. If at all possible services should be the facade into the system with logic wrapped up in a jar, DLL, etc. All services if possible should rely on said library and not rely on loosely coupled services for composting, inter-system communication is different than disparate system communication.
Building/maintaining that sounds way more complex than writing a JSP.
In my experience, if you architect your server-side components well, if/when you want to expose something as a web service you can prop up a web service that's basically just a thin wrapper around the relevant backend component(s). It avoids the "premature optimization" of building everything as a bunch of micro and aggregate services that you may or may not actually make use of in the future.
For building a complex web page for a normal browser, (assuming you're using Java on the backend) a JSP built using various local component objects is almost certainly the fastest performance solution, both server side performance and client side perceived performance.
For building other interfaces (iPhone app, dashboard widget, etc...), until you build them you're unlikely to know exactly what calls will make the most sense for them. When you do, just build those calls as wrappers to your existing components. Very fast to do. I've done it many times against Seam and ATG eCommerce applications.
If you are a one man show maybe, but if you are a team it is far more maintainable because each concern is clearly delineated. JSP is not easier for a HTML designer nor is ASP or PHP it is an amalgamation of languages composites into a document. It is only easier for a code developer and that it the crux. Usually a company starts out as a one man shop with a code developer and then graduates to a team. Having to teach designers JSP is a waste of time and resources. The entrance barrier to web development is so high because of this bastardization of development domains. It is only easier because you are reasoning from your view point. To a new developer just learning HTML the list of technologies is insurmountable all because we coupled back end technologies with the front end.
I typically work with largish teams on very large websites (cingular.com, jcrew.com, ulta.com, pcavote.com, etc...).
With good frameworks most JSPs are very close to normal HTML and we actually usually have: designers/UX folks who provide PS docs/images/etc..., front end devs (JSP/JS/AJAX impl folks) who take those and make real working JSP pages out of them, and back-end devs who write the Java backing components.
You seem to be expecting these new developers who are just learning HTML to know how to build complex pages using aggregate web service calls via JS, based on a non-standard in-house system.
Even if you don't have separate designers and front-end devs, and I've worked at several places like that, helping HTML designers figure out JSP using a good framework (ATG, JSF) really isn't that bad, it's just a few new tags which are really well documented all over the web.
While I am a Java dev/arch, my "view point" is typically that of a lead architect, team lead, or project lead, so making sure people can get stuff done, regardless of what role they're in is key.
Do you have any live examples of websites built using your proposed method?
"You seem to be expecting these new developers who are just learning HTML to know how to build complex pages using aggregate web service calls via JS, based on a non-standard in-house system."
Sorry I missed hitting on this one. I do not expect a designer to be doing service calls that is the point. You can write a JavaScript controller that grabs reference to any UI components that it needs, you do not write JavaScript in the HTML, the designer is then working in pure HTML CSS. The JavaScript developer is the one orchestrating the work-flow logic in a code-behind manner. Each person has their domain and once a developer feels comfortable they can graduate to the next domain. Just as I don't expect a HTML designer to have to know Java constructs I don't expect a Objective-C developer to know HTML constructs. It's not about constraining people, it's about re-usability of reusable components and isolating non-reusable components.
You are not taking into account, distributed development teams or completely outsourced development of certain portions of the overall solution In which you have no control over the skill level of the developers.
As well, I am not proposing anything any more non standard than say JSP or Struts and Tiles. Their are plenty of AJAX frameworks that provide all of the bolts to erect this style of system without building and in-house system. Further, JSP is only standard for web development it does not take into account the variety of UI possibilities and that is the point of the matter. The UI much like the database is only a portion of an overall system. Just as you would not write you data-storage in your logic tier you should not be coupling the UI tier to your business logic.
There are plenty of sites that use this development methodology. Pick almost any mature "Web 2.0" site and they will be somewhere along in this evolution. Google, Amazon, Yahoo et. al.
I apologize in advance for being vague, but I would prefer to not loose my anonymity on this site and referencing my work would do so.
"building everything as a bunch of micro and aggregate services that you may or may not actually make use of in the future"
I wanted to touch on this real quick, The point of letting the client deal with it's concern, is that you can prototype and user acceptance test you application before you ever write a service. Then you only have to build what you need to support your UI and what ever batch processing you need. It is a far more agile process. Not only do you have a working UI but you have a service inventory of functionality that need to be implemented to support you UI. From there you can build out your service tier and if you so chose look at the next likely UI and do some due diligence to see if you are going to need more micro services to support you next endeavor. You may not chose to build them but you can at least architect the solution with the next endeavor in mind.
As well another common mistake I see is services calling services to build a composite service. If at all possible services should be the facade into the system with logic wrapped up in a jar, DLL, etc. All services if possible should rely on said library and not rely on loosely coupled services for composting, inter-system communication is different than disparate system communication.