JavaServer Faces Are Evil (draft)

1. Problem

Let me start with a story. Once upon time

• there were 2 developers
• working together for 1 day
• to produce 2 lines of hackish JavaScript

Why? Because JSF makes it hard to do anything its authors haven't expected when designing it.

----

Let me repeat it: 2 experienced consultants, working 1 day to produce 2 ugly lines of code.

Can you smell the scent of money burning?

And this is my point today: Frameworks are bloody expensive.

... A point I want to demonstrate on the example of JSF.

2. Exploration

What is JSF?

• Standard Java EE web framework that abstracts away HTTP - and provides a stateful tree of components, familiar from desktop UIs
• It renders the tree into HTML and reflects user actions back to the tree and eventually to the model POJOs bound to the components
• Tries to abstract away HTML/CSS/JS (shiled; hidden in components)
• It does everything: Data binding with type conversion, validation, navigation, i18n, templating etc.

So what is wrong with JSF? (goto ihatejsf.com)

• The main problem: it is a complex beast; ex.:
  • 6-10 phase req-resp lifecycle, and good luck if you need something that does not fit it!
  • JSF is a component fwrk - yet creating a component in JSF 1 was a lot of work; much easier now but the complexity is still there, only hidden
  • The complexity is shown on failures such as the infamous "duplicate id" error when rendering
• No separation of concerns: A complected, all-in-one black box => stuck with author's choices
• Tries to hide how web works (http/html/css/etc) => of course a leaky abstraction! (Hibernate, anyone?)
• Pluggable yet inflexible and limited/ing

ThoughtWorks Technology Radar 1/2014:

We continue to see teams run into trouble using JSF - JavaServer Faces - and are recommending you avoid this technology.

Teams seem to choose JSF because it is a J2EE standard without really evaluating whether the programming model suits them. We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. JSF , like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken.

We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS.

How does that apply to frameworks in general?

• Frameworks are supposed to tackle the intrinsic complexity but add their own
• They make it easy to start (especially if you have no opinion about how to do things) - but eventually you hit the walls of accidental complexity and inflexible design
  • <- N. Ford: Why everybody eventually hates Maven
• (Achieving simplicity is hard)

3. Way out

Frameworks are not bad per se, only due to the costs they incur. What would and "ideal" framework that does not incur them look lik?

• Sensible out-of-the-box behavior
• Let you easily drop down to any lower level in the extent desired (not “all or none”)

<=>

• Doesn’t force a radically different abstraction
• Empowers, doesn’t hide/take any power from devs
• Doesn’t try to do/know everything

Examples

• Clojure: Composable libs doing 1 thing well
• Ubuntu
• Spring JDBC

It is always a cost-benefit decision - but we tend to forget the cost and exaggerate the benefit.

4. Take away

When you hear "framework," remember this: