All of the new JSMVC type frameworks do this. For example, in Angular you take your HTML and mark it up with js "tags" that look a lot like the way you marked up
jsp html with tags. Later when you deliver this code to the browser, the HTML is in fact wrapped up in the javascript. At run time, the Angular engine matches these "js tags" to json models and then shows them in the page. It sounds like a very heavy duty parser. This
pattern is very popular these days, but for me has some inherent issues.
1) The first issue is from a development perspective. As a developer I don't like to do things in more than one place. It takes more time to duplicate effort plus it makes it more likely I will make a mistake. In JSP's I only had to render the data to one spot in the layout, one time server side. For example, if I wanted a first name to show up between some html tags I used a jstl tag to output it there in my html. However, with JSMVC patterns I have to do everything twice. For example, I first render my first name into a json object server side. This is the same amount of work as rendering it into the jsp was. Next, I have to put in my js tag in my html to unpack the value from the json client side. Not only do I have to match the field name, but I have to make sure it comes from the right model object etc. There is a lot more coordination that has to happen, and to beat I dead horse I had to code in two places.
2) My next issue is how fat the js stack has gotten on the client. These js engines are big collections of js, and we all know that js is harder to debug than a compiled language like
java. Furthermore, as a developer, my whole controller is now sitting in js on the browser. Do I really want to maintain that much js code?
3) Another issue is security. Since my whole controller is on the browser, can't a hacker now see everywhere my application could potentially let him go, regardless of his user role? A hacker might not have access to a service call but he now knows its there whereas on a jsp based application he would not.
4) Internationalization is also a problem with JSMVC. In JSP the page was being rendered server side where a random access resource bundle was available. Even if for each language supported you had 4000 phrases (I've seen this first hand) when your bundle is sitting there in memory you have no performance problems picking phrases from it and rendering them into your layout. Imagine how this would work in a JSMVC application now. Are you going to download 4000 phrases every time the user logs in? Instead will you just download the subset of phrases for each page, yuck.
5) Controller remoteness is also a problem. Imagine the browser sends a post to the server and the browser is expecting a certain page back. However, logic in the controller based on state in the database decides that the browser should actually get a different page back then the one it was expecting. In a server based JSP pattern the controller simply does some db queries runs some logic and sends the browser a different page than it expected. Instead, what happens in Json JSMVC pattern? Instead of returning the json the browser expected does it send back a redirect command? Now the controller on the browser has to go to another page, so two trips to the server are involved instead of one and not simple ones. All of this complication happens because the controller is remote from the database. The controller is no longer central and this is a paradox in any command system. The controller on the browser does not have access to all of the information it needs to make decisions, whereas a controller on the server does! The controller on the browser only has access to data that has been previously delivered to it, which is a big limitation.