You are right about JAX-RS, WebSockets, JSON-P, JPA, JTA, etc: there are no replacements for these Java EE technologies in client-side technologies.
But I have a feeling that author is judging about whole set of EE technologies by JSRs that loose their popularity at the current time. I've provided explanation for that.
As for Chrome: the lifecycle of the UI in Chrome is different than UI lifecyclein JSF/Portlets. JSF/Portlet builds the DOM in memory, sends the output, GC cleans up after. This happens per request.
But I've seen GC utilization in JSF under a big load. It wasn't nice.
Also, JSF/Portlets' APIs are mostly synchronous.
Also, browsers are evolving. Client-side technologies are easier to learn. Server-side is harder. That's why I don't believe in major shift back to server-side. Twitter is relatively simple application. This is an exception, I think. There will be cases when server-side rendering is more efficient. But UI will be much simpler (no templating support, for example).
But I have a feeling that author is judging about whole set of EE technologies by JSRs that loose their popularity at the current time. I've provided explanation for that.
As for Chrome: the lifecycle of the UI in Chrome is different than UI lifecyclein JSF/Portlets. JSF/Portlet builds the DOM in memory, sends the output, GC cleans up after. This happens per request. But I've seen GC utilization in JSF under a big load. It wasn't nice. Also, JSF/Portlets' APIs are mostly synchronous.
Also, browsers are evolving. Client-side technologies are easier to learn. Server-side is harder. That's why I don't believe in major shift back to server-side. Twitter is relatively simple application. This is an exception, I think. There will be cases when server-side rendering is more efficient. But UI will be much simpler (no templating support, for example).