I spent past few weeks thinking and arguing with my fellow friends about one particular subject – what the problem with JSF? Why people again and again think that JSF is bad, slow and hard to use? What is wrong? Yes, I’m a member of JSR 314, we all have tons of ideas what is broken and how to fix it. Still I think we missing something fundamentally important, and here is my opinion – what is it.
I was a big fan of JSF from the very early days of it, when Craig McClanahan was blogging about Struts vs JSF. It was so long time ago, that it hard to believe that it actually happened. That days JSF proclaim to be “client” agnostic, you can use different Render Kits and have your great application on different clients for free. Does anyone recall these promises?But than people realize that JSF went too far “ignoring” html. If you put plain html into the page – JSF simply throw it away. Finally everyone admit the fact, that people actually use the only one client – browser.
And yes, solution was found; now HTML is first class passenger in JSF vehicle.
But suddenly Ajax-mania happened. People get used to the idea that web applications may behave similar to desktop applications. That was great, because it happened to be the most obvious case for JSF – a technology for stateful, rich, intranet, business applications. And Ajax just comes naturally into that place.
But then we begin to feel PAIN! We pushed our DHTML JSF based applications to the very limits of technology, follow very painful learning curve of understanding fine differences between browsers, how to make that particular JavaScript run equally fast on both – IE and Mozilla, etc. And still, desktop applications can run circles around us!
The problem is obvious – browser and DHTML are the worse tools to solve such problems. Yes, there are a good number of cases where browser shine – but people normally use other technologies (not JSF) to build such applications. That happens because of some other JSF’s birth defects (stateful component tree, URL/REST difficulties and some others) – I will not discuss those problems here. At least we all agree that it can be fixed and we must fix it.
But for many other cases DHTML is at least useless, and sometime it is pure evil. In my experience it is vast majority of cases. Why do we need to translate tabular data from collections of beans to cumbersome text format with table, td and tr’s (and don’t forget tbody!) tags and then let browser painfully slow translate it to human readable form on the screen!
But JSF itself has nothing to do with such problem. Remember early days of JSF and promises of “client-agnostic” Server Faces? Ok, I believe now it a good time to take closer look to this promise.
I’m talking about simple idea – let’s create special client for JSF applications with Java!
Look, there is nothing new about this idea! Remember “write once, run anywhere”? We just combine similar approaches from the past and from not that distant past – and create ultimate solution, end-to-end Java, from client to server, powerful and dynamic, nice looking, snappy and easy to use!
Let me to dream a little bit about some features of such solution:
- Application is hosted on server, when browser pointed to some application URL – special response generated, that will load Java WebStart application (our client) and put it into work
- Variation may include browser plug-in that do basically the same, but run client inside of browser window
- After client starts, it will establish communication with server (add more details there)
- Client request view from server, server assembly component tree and send it to the client (for example in some compact serialized form)
- Client render view; components are rendered using various Swing widgets etc.
- Everything live, inputs accept input, transformers transforms, validators validates, some descent client life-cycle spins
- Binding now become real bindings – when something changed on server, client immediately refreshed
- Events (like ValueChange) flying between client and server, in all directions
- Eventually some button clicked, server action executed and some outcome generated, passed thru Navigation Handler and another view become current
- That view created, serialized and sent to the client
Such picture looks really attractive to me, and – yes, no DHTML allowed!
For sure such project will require some effort, hopefully not too much, we can re-use vast number of Swing artifacts, Java itself become more and more client-oriented with all this resent movements and plans for 7.
BTW, the answer for question is – yes, we do need JSF. That is by far the best tool for many cases – we just need to take browser and DHTML out of the picture. Ok, sure not for all cases, but at least for many of it!
WDYT?
