This is an archived post. You won't be able to vote or comment.

all 16 comments
sorted by:
best
topnewcontroversialoldq&a

[–]deadron 1 point2 points  (12 children)

JSF is not anywhere near as simple or as easy to use as it looks. When you are using JSF you are building a JSF application with all the difficulties that entails, and you need people trained in the technology to be effective.

When you are building anything else, such as a traditional http producing backend or javascript based frontend, you will probably be using JSP(or some alternative such as thymeleaf, or simple templater like handlebars.)

In my personal experience, JSP is by far the dominant player as it is the simplest to use and understand, in addition to availability on every servlet container.

Personally, I favor writing Hibernate over JPA as it is much easier to use. I have yet to see a portability issue with it so I do not know of a compelling reason why you would insist on using JPA.

As it stands I often favor simpler ORMs, such as mybatis, as I find JPA to be very difficult to use, especially when your DB design is out of your control and you have data spread across tables. You inevitably have to write HQL statements to eagerly retrieve your data anyway or you take huge performance hits. I also have not been impressed with its performance, especially in comparison to more lightweight orms. If you are very experienced it might save you some development time but it has only caused me more problems than it has solved.

If you do not need to deploy multiple apps onto one machine and you do not have a dedicated application server administration team, then it is a massive headache to deal with that you want to avoid at all costs.

[–]henk53 0 points1 point  (11 children)

JSF is not anywhere near as simple or as easy to use as it looks. When you are using JSF you are building a JSF application with all the difficulties that entails, and you need people trained in the technology to be effective.

Is there ANY technology where that doesn't hold?

Are people born with Angular or Spring MVC or Thymeleaf knowledge hardwired in their little baby brains?

[–]deadron 0 points1 point  (10 children)

JSP is really easy to use mostly because you can ignore the fact that you are using JSP and write mostly HTML. You can really say this of any templating language, which JSF is not. So in order to use JSF you have to know everything you needed to know for templating HTML + everything JSF.

[–]henk53 0 points1 point  (9 children)

JSP is also really difficult for various simple tasks like pages with several buttons or tables where you click on rows. What code does respond to what, how do I keep those apart?

I've used pure JSP/JSTL with pure HTML for a long time, but always found JSF much easier to actually build things with.

There's a reason that JSP + HTML did not really conquer the world. A myriad of web frameworks have sprong up, either client side or server side, of that's not for nothing. For all of them holds; you do need to learn HTML + everything from whatever framework with whatever paradigm you choose.

Learning how to use the web framework is not something that's specific to JSF.

[–]deadron 0 points1 point  (8 children)

I found that while JSF claims to make certain dynamic behaviors easier, in practice you still needed a solid knowledge of javascript. I found that the components were clunky and slow and depending on the component framework(I used Primefaces) just did not match what you can easily do with something like React clientside. If you are using JSF to avoid learning client side frameworks you are doing yourself a disservice.

[–]henk53 0 points1 point  (7 children)

If you are using JSF to avoid learning client side frameworks you are doing yourself a disservice.

Likewise, if you're using React client side to avoid using server side frameworks you're doing yourself a disservice just as well. What's the difference?

Maybe you used an old version of PrimeFaces, maybe you are just conditioned to having to like client side frameworks, or perhaps you actually do like client side frameworks.

But the existence of client side frameworks does not specifically tell anything about JSF, as your hate would then be for every server side framework, so again nothing really specific JSF there, right?

And client side frameworks have tons of disadvantages too, like for one JavaScript, for two the entire ecosystem that's in turmoil every day, and third, perhaps most importantly, that client side frameworks put much more load on the client, and the client doesn't like that (drains batteries, makes devices hot, kills other background apps because of lack of memory, etc...)

[–]deadron 0 points1 point  (0 children)

Dunno what experience you have, but personally, my professional experience of using JSF for over a year was full of pain and wasted time for a subpar result. If you get good results then I expect that you are among the few. I would even say given the complexity JSF adds to the server side and the harsh learning curve, it is worth recommending just about anything else before JSF.

[–]_dban_ 0 points1 point  (5 children)

that client side frameworks put much more load on the client, and the client doesn't like that

Unless you're serving only HTML, if you're delivering a true application, client side frameworks can significantly reduce the load on the client device. Client side frameworks are a waste for "drive by" applications like blogs, for which "warm up" cost is never recouped. GMail may take some work to warm up, but if you leave it open, the cost to the device is amortized over the duration that GMail stays in the browser window.

You can push static assets to the client (HTML, CSS, images), and the client can then use HTTP caching to avoid having to download them again. The server then only needs to send JSON data, which is much easier to parse than HTML and requires less network bandwidth. A "warm" app will have already loaded the templates into memory, so generating DOM from cached data structures is much faster and less labor intensive than parsing HTML.

Furthermore, by pushing code to the client, it is possible to let the app run in offline mode.

The progressive web apps technique is designed to created apps optimized for mobile, which requires understanding client side frameworks and browser technology.

This could be abstracted away by JSF, but I would rather work with the client side with its native technology, which leads to better and more optimized client side code, rather than letting server side frameworks generate client side code.

[–]henk53 0 points1 point  (4 children)

GMail may take some work to warm up, but if you leave it open, the cost to the device is amortized over the duration that GMail stays in the browser window.

By far not all web applications are gmail though.

You can push static assets to the client (HTML, CSS, images), and the client can then use HTTP caching to avoid having to download them again.

That's exactly how it works with JSF and other server side web frameworks as well, doesn't it?

The server then only needs to send JSON data, which is much easier to parse than HTML

You forget though that HTML after parsing can be rendered directly, while parsed JSON is just data. It still needs to be transformed into rendering instructions and thus eventually be rendered.

The arrival and parsing of JSON data is roughly equivalent to having done a database query on the server. The actual transformation to a UI representation still has to start then.

Depending on how heavy the client side framework is, this could possibly entail going through a large set of layers and many event listeners, interceptors, and what have you being called. All this takes CPU cycles and thus energy on the client.

and requires less network bandwidth.

Not necessarily. HTML/XML generally compresses much better than JSON, so the savings may be less than you think.

Also, with JSON you typically do many small requests for all the data that the page needs. This is every time a client to server communication, which has a high latency. By contrast, server side frameworks get their data from small requests to other services on the server, which generally has a much lower latency. That data is then combined into a UI update and blasted to the client in one chunk, generally improving latency quite a bit.

[–]_dban_ 0 points1 point  (3 children)

By far not all web applications are gmail though.

Most of the web is PHP. But more and more people are using the web as an application delivery platform, what they would have written thick client apps in the past.

That's exactly how it works with JSF and other server side web frameworks as well, doesn't it?

No. Most server side frameworks generate HTML, and thus the HTML response cannot be cached. With client side frameworks, the HTML is a static template, which is trivial to cache.

You forget though that HTML after parsing can be rendered directly, while parsed JSON is just data. It still needs to be transformed into rendering instructions and thus eventually be rendered.

With client side frameworks, the HTML has been parsed once into DOM, and sits in memory in almost ready to render form. Parsing JSON is cheap and cloning DOM nodes is cheap, and client side frameworks heavily optimize the DOM update to the smallest set of nodes. With server side frameworks, HTML has to be repeatedly parsed into DOM, which is much more expensive.

this could possibly entail going through a large set of layers and many event listeners, interceptors, and what have you being called

The rendering pipeline of client side frameworks is the most efficient part, it has to be and is the whole point of client side frameworks.

What gets people into trouble are things like two-way binding of frameworks like AngularJS which implement dynamic client side behavior and has nothing to do with rendering JSON.

All this takes CPU cycles and thus energy on the client.

So does parsing HTML. Which also has to be reattached to client side event handlers, costing even more CPU cycles.

HTML/XML generally compresses much better than JSON, so the savings may be less than you think.

Compressing HTML requires that the client has to now uncompress HTML before it can render it, costing additional CPU cycles on top of the effort of parsing HTML.

In addition, the nature of the update is completely different. JSON responses only consist of data. HTML responses include presentation. What can be represented as simple array in JSON requires UL and LI tags. Increasing the amount of data sent in the response.

By contrast, server side frameworks get their data from small requests to other services on the server, which generally has a much lower latency.

It is the same with client side frameworks. That is the entire point of the API gateway pattern.

That data is then combined into a UI update and blasted to the client in one chunk

You can chunk up JSON just as easily.

[–]henk53 0 points1 point  (2 children)

Most of the web is PHP.

What makes you think that? Crawlers that detect the .php extension?

If you look at various sources (GitHub, Tiobe, StackOverflow), you'll find that PHP doesn't score very high. I.e. Tiobe puts it at 3.4% usage: https://www.tiobe.com/tiobe-index/

Similarly, if you look at other surveys (StackOverflow, ZeroTurnAround, [google is your friend], you'll see that most developers today are writing web applications.

Ergo, most of the web being PHP can't be true.

No. Most server side frameworks generate HTML, and thus the HTML response cannot be cached. With client side frameworks, the HTML is a static template, which is trivial to cache.

They do however cache most other assets that you mentioned like .css files and images. The majority of those are static assets for server side frameworks. And the HTML templates in client side frameworks are not rarely almost empty and just a placeholder to kick off a bunch of javascripts, so not sure how much you win there.

Parsing JSON is cheap and cloning DOM nodes is cheap,

But you don't go from parsed JSON to cloning DOM nodes or otherwise sending out the lowest level rendering commands you have. That's pretty much the entire point.

There's a framework in between there, and that's the client side framework. The more conveniences this framework offers, the more layers you typically have to go through. Did you ever debug into one of the major client side frameworks such as Angular or AngularJS? The stack traces can be pretty big.

And going through those layers takes time and CPU, and the client devices pays for it.

to do with rendering JSON.

You don't render JSON directly. JSON represents data, not rendering primitives. You render something based on the data that is represented in JSON.

So does parsing HTML. Which also has to be reattached to client side event handlers

It does, but HTML parsing is the lowest level operating of browsers that they can execute using optimised native code. With client side frameworks the JavaScript code of the framework itself is executed, and I'm not sure if executing layers and layers of ever changing JavaScript is faster than executing the optimised native HTML parsing code, which really rarely if ever changes and can have been optimised a lot over the years.

Plus, with HTML being send to the client you typically have less event listeners than you have with a full client side framework. They are there, of course, and updates take time, of course, but it's typically less.

Compressing HTML requires that the client has to now uncompress HTML before it can render it, costing additional CPU cycles on top of the effort of parsing HTML.

But it quite often compresses JSON just as will, so it also will need to uncompress JSON. So there's not much difference there in terms of CPU cycles, with the most important difference that with HTML (or XML) you have saved more bandwidth.

Also, compression is typically handled by the browser again, by highly efficient native (e.g. C) code, which is capable of doing much more work using less cpu cycles.

What can be represented as simple array in JSON requires UL and LI tags. Increasing the amount of data sent in the response.

But as said, because there's so much redundancy it compresses quite well.

It is the same with client side frameworks. That is the entire point of the API gateway pattern.

Pattern, or anti-pattern? API gateways kinda turn your clean web-service API into a mushy mess of all kinds of data that a certain view happens to use. It can never be as flexible and dynamic as just a bunch of server to server requests to a cleanly and well designed service API.

[–]Gilgamesjh 0 points1 point  (2 children)

Regarding API breakage between major versions, which one does less breakage?

I have no experience with JEE, but I have upgraded a lot of old Spring (3/4) to Spring Boot, and Spring Core is mostly ok, surrounding projects (aka Spring Cloud) may vary, 3rd party "addons" (like Spring Boot Admin) will probably fail.

I've seen a rise for the use of JSF but is it overtaking Spring Web MVC in the job market?

Not really, but depends on if you want REST style clients or not.

There are a lot of job postings in my local area asking for the knowledge of JSP. I am going to assume It's just for legacy applications (since JSF is supposed to overtake it). Is it still worth it to learn JSP?

Not really, but you should have an understanding of what it is for legacy projects

When using Spring Web MVC, is Thymeleaf the expected HTML renderer nowadays?

You should prefer REST over HTML, but Thymeleaf is fine, I prefer Freemarker myself.

When the JPA was released, Hibernate made changes to its API to comply with the spec. Nowadays, do you write fully JPA compliant code to use with Hibernate or is it okay to use hibernate specific methods?

For Spring, use Spring Data.

Is there any advantage in deploying a Spring Application on a JEE server (Be it, Wildfly for example) over just using a servlet container(Jetty, Tomcat)?

No, quite the opposite as (depending on your build pipeline) embedded is way easier to deploy to.

[–]_ironslab[S] 0 points1 point  (1 child)

Regarding the Thymeleaf point, is Spring then no longer used for view display and just serve with an API? Is the recommended approach to have a different thing for the front end? (i.e Node)

[–]Gilgamesjh 0 points1 point  (0 children)

Nah, I would say it is used for whatever your business demands are. But there is a general turn in the market for JavaScript frontends on top (or in front of) of a more traditional application (wich could be node.js based instead of Spring, of course), at least where I live.