Let me address one point here: I know Ed and he is cool, and I had a cheap talk with Craig at BrasilOne 2005. Both are cool and their work with the community is great. But I must say: JSF was born with the wrong Co-Spec leader.
So, what's the problem of having McClanahan as spec leader? Well, as you may noticed if you had some time with JSF already, the View tier is basically... Struts (version 1). And what's the problem with that? The web development process with Struts is painful, and for large projects can achieve a high level of difficulty and maintainability, by dealing with huge struts-config.xml files, Action Forms and, let's not forget, JSPs bloated with tags (libraries). How do I call this? The Triple Alliance.
Let's understand, from the developer perspective, what this mean. (this will require a flashback of Struts 1)
While coding, the developer has to look and take care of, at least, three files at the same time. And how these three files are connected? With SOP - String Oriented Programming. Yeah. He/She has to create an ActionForm (Java) and/or an Action (Java), declare it in struts-config (XML) and code/maintain the webpage (JSP: Java, Tag Libraries, HTML, etc...). And all properties, names, etc, are binded by typing their names/ids in fields, like:
struts-config: [..] name="myProperty"And this is the same process with JSF. You have to code JSP pages with Tag Libraries (XML), you have to code Managed Beans (Java) and you have to declare a lot of things within faces-config.xml. All that with SOP... Triple Alliance! Ok, you can develop JSF with tools, auto-completion, hints and many other features. But why should you need a tool to develop a JSF web application? We want simplicity in the first place, not toolability.
Java: getMyProperty()
JSP:
Why I say Struts is not cool anymore and why JSF followed the wrong idea? Because the developer has to know a lot of things, has to control a lot of artifacts, do SOP coding and been dependent of tools. The conclusion: Struts solved several issues but created new ones (JSF). But I must agree, Struts had market acceptance in the past because it was simple to start developing web applications with it. And addressed a hole of ideas and solutions (MVC) that were needed at that time. Craig, contratulations, really. You did an outstanding work here.
I liked Struts, I worked with it for 2,5 years. But, it wasn't a standard. So, let's recapitulate: if we need a standard [to sell tools, training, courses, books, facilitate the introduction of vendors, and not forgetting the ease of components customization], why not stick with what already is a [market] standard? That's why Struts is the base of JSF's View tier. Is this cool? No it isn't!
They took a market standard and turned that into a specification. Tapestry 3 was there, Echo 1 too and both with very cool ideas. Shouldn't Ed and Craig took a look at them? Yes for sure! If JSF 1.0 was a compilation of Struts 1, Tapestry 3 and Echo 1, I think I wouldn't be here. Now, let's talk about the present...
JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don't even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.
OSS frameworks, specially Web Frameworks, keeps demonstrating that the key for a good software is innovation. And from innovation, comes productiveness, because everybody wants to do more with less time. But, to get to innovation, speed is important. Bureaucracy is the enemy!
What JSF 2.0 (JSR 314) offers, and will deliver only next year (target: JavaEE 6, after April 2008), you can get from any framework today. Google Web Toolkit is an example of that. Wicket is another good example. These frameworks grown up faster than anything else, because they aren't standards. They doesn't has to wait for a series of other specs to be launched.
[I can't forget to show you why I think Wicket is cool]
To have productiveness, there must be simplification in the development process and, from the developer perspective, simplification of coding. There's no Triple Alliance in Wicket. There is some SOP, yes, but not in the same way. There aren't tag libraries and no XMLs. It's pure Java and pure HTML. Take a look.
Ed, one advice: invite Eelco, Matijn and the hole crowd of Wicket commiters to a small talk! :D
Post note:
You may think this post is just FUD, you may even think it's just to promote other frameworks like Wicket, which I post about sometimes. But believe me, it's not.
The purpose of this post is to share with you, my ideas and thoughts of why JSF is not cool [yet], why it doesn't has the productiveness I want [and need] and why you should consider moving to some Non-Standard OSS Web Framework. Still, I hope newer releases of JSF, like 2.0, brings ideas from the frameworks I mentioned here.
13 comentários:
Nice read.
For a detailed comparison of Wicket and JSF you can have a look at this:
http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/
I'm not sure whether I agree Craig was a bad choice for the job. We all learn by doing and learning from ours or other's mistakes. Around the time that Struts was released for the first time (and about a year before I even heard of it), I coded an in-house MVC framework for a project that was very similar in concept to Struts. I think it was kind of the logical thing to come up with at that time. There were a couple much better ideas in hind-sight, like Barracuda and WebObjects. But back then, I didn't really recognize the kind of problems component oriented framework like Wicket try to solve (reusability, scalability of the development effort, etc), and without that knowledge, component based frameworks look bloated.
I can't speak for Craig, but I can imagine that having to deal with corporate issues (like the fact that JSP was pushed as the big alternative for ASP back then) and not having the luxury of just putting your ideas in the open and getting people to join in and work on them makes it very hard to get a successful project off the ground. Especially when it has to support technology that is in full motion. Probably more than half of where JSF is now is due to the process, probably less due to the people who worked on it.
My 2c :-)
Sorry for the bad grammar :-)
I fail to see how Wicket improves the string-matching style problem, but I can't reallyh stand full Java-based solutions either (Echo2 for example). I think the world is moving towards something like Ext.JS with DWR... but we'll see :)
This post seems out of date to me.
At this point, JSF's advantages and disadvantages are very well known. And, OSS has done so much to help JSF (Facelets, Seam, Orchestra, Spring Web Flow, Shale, etc.) that I'm surprpised that side of the coin isn't even mentioned. Even though JSF as a whole must go through the standards process, OSS has build an amazing set of capabilities _on top of a standard_. Some of these fill in deficiencies (like many parts of Shale), and others add whole new capabilities (Comet features of ICEfaces).
Moreover, all of the drawbacks mentioned here can be avoided today using some OSS add-ons, and will be gone with JSF 2.0. It's also fair to mention that JSF 1.0 started in 2001, long before some of these issues were apparent.
Kito D. Mann
Author, JSF in Action
http://www.jsfcentral.com
Nice post Bruno!
I agree with what you're saying, pretty much how I feel about this .
Cheers,
Freddy
@Kristof
What 'string-matching style problem'? :-)
Wicket is trying to provide a solution for building a user interface that runs in web browser. So you'll find concepts in Wicket that represent that.
Sure, you can get far with seeing it as a string matching problem. However, if you care about static typing (as I do), reuse and things like an API that is discoverable, that won't help you much. Anyway, if you're happy with Ext.JS and DWR, stick to that. I imagine that can work fine for Ajax based web sites. As for what 'the world is moving to'... why care so much what other people do? Just determine what you need yourself, and go for it.
Eelco, I remember you being a Wicket lead. Years ago (before the 1.0 release) I tried out Wicket and while some minor things wasn't up to my taste, I was rather impressed with your team's work. I still know many people who are pretty excited about Wicket and I understand them. My comment about where 'the world is moving to' was a wild guess about the main direction of the future of webapp development and by no means was set as a critic towards your framework, it's still one of the most clever ones available these days.. Are we all right? :)
:-) I really don't care that much about critic on Wicket; I'm pretty old-skool when it comes to why I'm participating in an open source project: primarily to scratch my own itch/ out of curiousity/ to satisfy my hunger for creating stuff.
I think that one of the reasons why there are so many web frameworks out there is because there are so many different choices to make (though on the other hand, more than half make the same...). For the record, I think there is something to say for an approach like combining a Javascript/ Ajax lib with DWR, but it depends on what you think is important in your project.
Hi, Bruno. I'm Leonardo, I read your post and I decided to comment in my blog. I must say that I didn't agree with you, but please, do not take it personally. I apologize for those who has reading it and don't speak Portuguese, but it's harder for me to write text in English. Who wants click here.
Oi Bruno, eu sou o Leonardo, li o seu post e resolvi fazer um comentário no meu blog. Tenho que te dizer que não concordei com você, mas por favor não leve isso para o lado pessoal. Desculpe aqueles que estão lendo isso e não sabem português, mas é mais difícil pra mim escrever textos em inglês. Quem quiser clique aqui.
Good thing there is Google translate
:)
Also see a related post
I don't think you can count someone even as a semi-decent java dev until he wrote his very own web framework at least once in his life :) (I had a very lightweight one based on picocontainer and later a bit smarter one capable of scanning and reloading controller classes on the fly automatically))
I'm still curious, what you think you have to say about a DWR+JS approach?
Haha. Yeah, writing one is a good way to learn :-)
DWR + JS is nice if you want to avoid any possible bloat and if you're going Ajax all-the-way. Because of it's simplicity, you won't run into a lot of troubles with the framework, and you can easily tweak you app exactly how you like it. Using a component based framework like Wicket has the advantage that it is easier to break up (and reuse!) work in smaller pieces - self contained components -, and that you'll build up an API that is easier to maintain and explore because much of it is based on (statically typed) Java.
For the application I'm building, Wicket is a good choice. We're building a container system where we plug-in components that contribute their own user interface on top of their business logic. Kind of like a portal system, but with extra things such as hooks for installation and de-installation wizards (which are also contributed as Wicket components), cloning and archiving functions, etc. Were we to use DWR + Javascript, we'd have to build a mini framework ourselves first to do what is possible with Wicket out of the box.
Which of the two would be faster to build with is a tough question. My hunch is that the more complex the UI, the more you'll benefit from Wicket, whereas if your UI isn't too complex, or just limited in scope like Gmail is for example, having less abstraction might actually enable you to work faster.
Entirely my 2c of course. You'll have the same kind of pro-con considerations for other things, like ORM vs plain JDBC or something in between (like iBatis)
Postar um comentário