Hacker News Reader

Comment by henk53 | Hacker News Reader

Society has shifted from the client to the server and back again a couple of times before, and don't forget that one of the biggest web sites out there (Twitter) has switched back from the client to the server.

Pure client-side technologies have many disadvantages, including a long initial load time, high local memory usage and high CPU usage. Ironically, a browser tab in Chrome can easily take up a magnitude more memory than a Java EE server takes up.

And don't forget that the client-side ecosystem is anything but stable. Google the phrase "javascript framework of the week" and the term Javascript fatigue.

Even if you do want to go with client-side UIs, there's a wealth of technology in Java EE to back these; JAX-RS, WebSockets, JSON-P, Bean Validation, JPA, JTA, etc etc.

View on HN

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.

That would have been a viable explanation, I agree.

Unfortunately, this isn't the case. I follow all the Java EE specs very closely, and this inactivity by Oracle concerns each and every spec. JPA as pure backend technology didn't even get an update, then after much asking a maintenance release was scheduled, but that's completely quiet again. JAX-RS, same deal. Spec lead didn't show up for months, and then occasionally he shows up saying little more than: "no! we're not going to do that"

And the same thing is true for brand new specs like MVC and Security. They were started with much enthusiasm, and then at exactly the same time as the graphs in this article shows (just after JavaOne) commits and mails from the spec leads completely plummeted.

>I've seen GC utilization in JSF under a big load. It wasn't nice.

I've actually seen the reverse. Which version and implementation of JSF was that?

See for instance this: http://jsfcentral.com/articles/understanding_jsf_performance...

The GC churn of JSF is rather good, and better than for instance Spring MVC + Thymeleaf, which people somehow expect to perform better.

> Also, JSF/Portlets' APIs are mostly synchronous.

In what respect? Many JSF applications uses AJAX quite intensively. And WebSockets is used a lot too. PrimeFaces has its own Atmosphere based implementation for a long time, while JSF 2.3 will adopt the approach introduced by OmniFaces which is more Java EE standards centric.

But while an interesting discussion, I'm pretty sure client-side vs server-side is not the main thing the article is about, which is really about Oracle silently and without giving any reason all of a sudden doing almost nothing anymore.

Reply on news.ycombinator.com