Whiteboard dos frameworks Web

Neste post do Enter The Jboss Matrix, o autor Shaun Connolly apresenta o resultado de um whiteboard poll, sobre o uso de Application Servers e Web Frameworks. O resultado apresenta forte liderança pelo JBoss e JSF.


Vou falar aqui sobre os resultados da votação de Web Frameworks. Vendo este whiteboard, levanto algumas questões:

• Porque JSF é lider?
• Porque tem gente que ainda utiliza Struts e Struts 2?
• Quem são os malucos que utilizam Spring MVC?
• Que tipo de desenvolvedores utilizam Tapestry?
• Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?

Perguntas pertinentes, que me arrisco a dar algumas respostas neste post que, sem dúvida será bem controverso. :)

Porque JSF é lider?
Para mim, o principal motivo é simples: JSF é uma especificação definida pelo JCP. Isto favorece a adoção por grandes empresas e projetos que preferem algo padronizado e que possui uma grande oferta de cursos, livros e produtos.

Mas me questiono: o JavaServer Faces puro (Reference Implementation) não tem nada demais. A produtividade com ele é baixa, o suporte das IDEs só é bom quando amarrado a componentes de terceiros e como comentei num post anterior, usa-se muito SOP (String Oriented Programing.) A solução para torná-lo verdadeiramente produtivo é sempre abraçar algum framework JSF mais robusto (leia-se: mais componentes e uma arquitetura engessada), como o JBoss Seam, Oracle ADF Faces ou o da Sun (experimente o NetBeans 6 e notará que vários componentes são específicos da Sun... não sei exatamente de onde vem, qual o projeto, mas sei que tem.)

Abraçar um produto JSF implica em se amarrar a este produto e seus componentes customizados, não podendo mudar de Vendor assim como é prometido pela especificação e tantos desenvolvedores, gerentes e arquitetos ainda, sendo enganados pelo marketing, acreditam.

Sei, e concordo, que há espaço para o JavaServer Faces, mas vamos parar com o euforismo de que JSF é produtivo, padronizado e livre de implementação, ok? Ninguem mais vai trabalhar com JSF RI. A solução será sempre escolher entre uma especialização ou outra (Seam, ADF, etc ...) para tornar essa máxima verdadeira.

Porque tem gente que ainda utiliza Struts e Struts 2?
Desenvolvi em Struts 1.x durante boa parte da minha carreira, e assim como postei da outra vez, acredito que foi-se o seu tempo. Entramos numa era de programação baseada em componentes, e não actions. Reutilização de código na composição de paginas agrupando componentes: este sim é o modelo de hoje (visto no JSF, no Tapestry, Wicket e alguns outros).

Então porque tem gente que ainda utiliza Struts e Struts 2? O primeiro é simples: manutenção. Tem muito sistema que foi feito em Struts e por falta de tempo ($$) não existe o interesse em migrar para outro framework (nem que fosse o Struts 2). O segundo fica difícil de dizer exatamente o porque, mas me arrisco a dizer que é pelo simples fato de ser a junção de duas fortes comunidades (Struts e WebWork) que são devotos do modelo Action-based. Esta comunidade está presa a um modelo de construção Web, onde se sintam confortáveis e confiantes na hora de construir suas telas. Eu entendo. Já me senti assim um dia... :) Mas só por um dia.

Acho que o número de projetos em Struts e Struts 2 diminuirá com o tempo. Minha previsão é que, assim que JSF 2.0 sair oficialmente, teremos uma queda drástica na adoção de Struts 2 como framework web para novos projetos. Deste modo, dois frameworks irmãos irão se encontrar no limbo da manutenção.

Quem são os malucos que utilizam Spring MVC?
Alguém ae utiliza Spring MVC? Por favor, comenta aqui quais os motivos que o levaram a adotá-lo! Porque eu não faço a menor idéia. Na minha opinião, é apenas um Action-based amarrado ao Spring. O que ele tem que outros frameworks neste modelo não oferecem?

Deixo a resposta desta pergunta para os comentários... :)

Que tipo de desenvolvedores utilizam Tapestry?
O tipo que quer correr riscos e gosta de seguir um Pastor. O risco de sair uma versão nova com mudanças tão grandes na API que o forçam a duas únicas opções: ficar largado na versão anterior ou migrar para a última. Se você não sabe, o Tapestry é escrito praticamente, por um único desenvolvedor chamado Howard Lewis Ship. Isso implica que, se o cara decidir (como já fez entre as versões T3, T4 e T5) ter idéias novas e implementá-las, ele o fará sem dó nem piedade da comunidade que utiliza o framework.

Minha sugestão: fique longe de frameworks sem compromisso com seus usuários.

Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?
Foi uma surpresa para muitos, quando o framework foi incorporado pela Apache rapidamente. O processo na incubadora foi rápido, o que demonstra a maturidade e o compromisso dos desenvolvedores. Além disso, é notável ver que este compromisso é diário visto o número de dúvidas respondidas (muitas até instantâneas via IRC) pelos commiters e usuários avançados.

Não há como negar que a comunidade Wicket já está consolidada, ao ponto de ultrapassar a do Tapestry e Grails. Mas não basta ter comunidade (voltemos ao exemplo do Struts), é preciso mais que isso. Aos que já colocaram seus dedos em algum exemplo de Wicket, viram o quanto é produtivo e rápido a construção de telas e componentes genéricos. Mas ainda, não é isso que atrai novos adeptos ao framework. É divertido desenvolver com Wicket.

Foi-se o tempo de apanhar para XMLs e Strings escritas por engano. Ou de taglibs monstruosas cheias de parâmetros. O conceito de POJO + POH é o que faz a diferença em relação aos outros frameworks. Some isso a uma API bem moldada a ponto de ser comparada com a do Swing, e você terá uma facilidade incrível para entender os métodos e classes do framework.

Para 2008, o plano é apresentar ainda mais a capacidade do Wicket a vocês que frequentam este blog. Não que eu queira iniciar uma religião com isso, mas apenas mostrar que existem alternativas mais produtivas. :)

[]'s
miojo

Slides do Wicket

Eu sabia que haveria uma palestra no Javapolis deste ano sobre o Wicket, então fui atrás e caí de paraquedas no site SlideShare. O legal é que, não apenas encontrei os slides da palestra Wicket in Action, apresentada pelo Martijn Dashorst (um dos Core Commiters.) Aproveitei também para fazer o upload da minha palestra deste ano e incrementar ainda mais a quantidade de slides sobre o framework!

Com pressa em ver a palestra que o Martijn deu no Javapolis? Confere logo abaixo:

| View | Upload your own

[]'s!

Beowulf: 3D nas telonas!

Para quem nunca ouviu falar, Beowulf é um filme em IMAX 3D e isto significa usar aqueles óculos bizarros no cinema! O legal disso? Ter a sensação de estar dentro da tela. O filme estréia nos EUA dia 16 de Novembro, nesta Sexta-feira.

Não sei quando chega ao Brasil, nem se tem algum cinema com alta qualidade para este filme, mas sei que quero ver! Assista ao novo trailler:



Finalmente um filme 3D que não é para criancinhas!! Aquele "A Família do Futuro" é legalzinho, mas Beowulf é do caceta!

Java 7 with Chained Invocation

This weekend Claudio Miranda, a friend and co-worker of mine from Brasília, came to São Paulo to assist give a presentation about "Tools and Tips to Solve Performance Issues in Java Applications" (yes, this is his presentation name) at Conexão Java. After some beers and talks about Java, I introduced him an idea I have been thinking about for a few days.

In Ruby, the return statement is implicit. In Java, we always have to declare which return type the method has. But what's happening is that this kind of method declaration is becoming common these days:

class Foo {
   public Foo doSomething() {
       ...
       return this;
   }
   ...
}

This gives us a shortcut to do some chained invocations, for example:

Foo foo = new Foo().doSomething().doAnotherThing();

To give developers a better shortcut, my idea is to let them code methods with return type declared as "this":

    public this doSomething() {
       ...
   }

After I showed Claudio my idea, he told me somebody already thought something like that, and there's a lot more suggestions than just this one. So don't think this is a worthless improvement. Somebody else thinks the same as I do :D

The difference between my suggestion and the one from Matthias Ernst, is that void would continue to be void. No return. The use of this, which has the concept of the current object,
would be convenience and not something magic, as declaring void and expect that to return the object itself. Another great interesting point to look is the integration with Covariant Types.

Let's take the Bar example:

class Bar extends Foo {}

// with current JSL and explicit return this; this would not compile
Bar bar = new Bar().doSomething();

// to fix, you must explicitly cast the returning object
Bar bar = (Bar) new Bar().doSomething();

Mixing implicit return this and covariant types, no cast is needed and we would have chained invocations easily! Besides, this is a small change into Java Compiler. The generated bytecode should be compatible with Java 1.3. Comments?

JSF Today: Standards versus OSS

It's true to say that JavaServer Faces came to standardize the way developers build user interface, defining a common API to facilitate the creation of components for web development (and other things). For those who don't know, JSF 1.0 (or JSR-127) had Craig McClanahan as Co-Spec Leader together with Ed Burns.

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"
Java: getMyProperty()
JSP:

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.

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.