Laszlo x JSF

Sao duas coisas completamente distintas, e nao eh tao simples dizer o que eh melhor: depende, pra variar, do seu projeto e objetivos.

Mais info sobre o Laszlo: http://www.openlaszlo.org

Marcos,

Uma mensagem postada na lista do JavaCampinas pode responder a sua dúvida, segue abaixo.

Aproveitando, existe uma lista de discussão q trata sobre esses paradigmas, veja:

RIA (Rich Internet Applications)
http://br.groups.yahoo.com/group/ria-br

Att,

Anselmo

Data: Fri, 24 Jun 2005 12:03:38 -0300
De: “Paulo Alvim” [email removido]
Reply-To: [email removido]
Para: [email removido]
Assunto: [SouJava-Campinas] Just Java 2005 - Ao escolher entre Struts ou JSF, prefira o Laszlo!

Um movimento frequente que vemos nas listas de discussão e que também se
manifestou no Just Java foi o interesse pelo futuro das letras V e C do
MVC: Struts ou JSF?

Craig McClanahan, idealizador da Struts e um dos especificadores do JSF,
catapultado pela SUN para trabalhar com James Gosling em sua ferramenta
(caixa-preta) com base em JSF, promete competição com o WYSIWYG RAD do
.NET…mas será esta a melhor opção para suceder o - já maduro - framework
Struts em nossas arquiteturas MVC J2EE? O paradigma WYSIWYG RAD é mesmo o
melhor para produção de interfaces Web?

Identificamos no Just Java, a partir das visitas que recebemos em nosso
stand, o desconhecimento da maioria acerca do mais novo ingrediente nesta
briga, o OpenLaszlo! ( http://www.openlaszlo.org )

Quando os visitantes indagavam a respeito: “o jCompany irá para JSF ou se
manterá na Struts?” Respondíamos com outra pergunta: “Você já conhece o
Laszlo?”. E 100% das respostas ainda eram: “Não”! Após apresentarmos o
Laszlo, conseguíamos uma preferência “unânime” pelo produto, e não é
difícil compreender o porquê…

Por este motivo, através deste email pretendo apresentar o Laszlo como
contribuição para quem não pôde ir ao Just Java e ao stand da Powerlogic,
e que está às voltas sobre qual rumo a tomar; ou mesmo para aqueles que já
se decidiram, mas ainda estão em tempo de recuar…

Laszlo - Rich Internet Application

O Laszlo é um produto focado na camada Visão, tal qual o JSF. Ambos têm 90%
de “área comum”. O JSF tem intenções de “cobrir” a camada controle, mas
ainda é muito fraco neste setor, tanto que estamos para ver nascer o Struts
Shale, do próprio Craig, para complementá-lo - em suma, ou usamos Laszlo
ou usamos JSF!

O Laszlo tem origem comercial e já competia com diferenciais com o Flex da
Macromedia e outras iniciativas menos robustas com base no plugin Flash.
Mas em dezembro do ano passado a empresa recebeu um aporte de capital de
investidores japoneses e abriu seus produtos para o mundo Open-Source!

Como outros produtos Open-Source de origem comercial, o Laszlo é bem acabado
e possui documentação estensiva, além de um portal e suporte bem
organizados. Mas qual seria a estratégia dos japoneses? Bom, segue o rumor
de que o Laszlo será utilizado como padrão de interface interativa da TV
Digital no Japão (e veremos que tem qualidade potencial para isso), e daí
podemos desconfiar de alguma coisa…

Laszlo x JSF

O Laszlo, com suas interfaces “cinemáticas” (coisa de cinema!), tem poder de
ruptura na camada Visão (quem não estava usando MVC poderá ser obrigado a
refazer suas aplicações em alguns anos) e tem o poder de “encantar” usuários
finais, entregando real diferenciação se comparado a modelos de interface
Web anteriores, com base em HTML ou variantes.

Se valendo da onipresença do plugin Flash, o Laszlo possui características
de animação built-in como “tab panels com fadings, multi-skin, controles
de alto nível, acompanhamento de foco animados, drag-and-drop, etc.”,
inclusive superiores às APIs gráficas de interfaces desktop! Tudo isso sem
abrirmos mão de aplicações Web integradas a portais (impossibilidade do
mundo desktop), J2EE MVC, sendo acessadas por clientes, parceiros e
fornecedores - o Laszlo tem um bundle com o Tomcat e um exemplo “hello
word” integrando com o Struts.

Já o JSF, em contrapartida, hoje atenderá meramente ao objetivo de seguirmos
a especificação J2EE (refactoring), mas não irá agregar resultado visível
para usuários finais de nossas aplicações. Estes continuarão vendo o velho
“HTML” em Browser ou algo similar ao que já conhecíamos no Struts - aliás,
em estágio muito mais avançado e maduro, incluindo integração com JSTL,
Tiles (OO na camada View) e com muitos cases em produção.

Vejam exemplos em Laszlo nos links (veja todos, com atenção, pois cada um
possui um “insight” diferenciado):

http://www.laszlosystems.com/partners/support/demos/

http://www.laszlosystems.com/customers/case/

A IBM já produziu plugins Eclipse WYSIWYG para o Laszlo, que também podem
ser baixados em:

http://alphaworks.ibm.com/tech/ide4laszlo

Conclusão

Em enquetes que fizemos com nossos clientes, sobre iremos para JSF ou
fazermos, em um primeiro momento, um suporte Viewer para Laszlo, a decisão
foi unânime pelo Laszlo.

Portanto, estamos para ver se o JSF irá sobreviver ao Lazslo ou conviver com
ele…mas o Laszlo já mostrou a que veio!

Paulo Alvim
Diretor de Tecnologia
Powerlogic

Apêndice - “Lei de Darwin” (Open-Source) x “Lei do JSR” (Comitês J2EE)

Para aqueles que, mesmo após conhecerem o Laszlo, ainda se interessarem pela
discussão JSF, segue este apêndice:

Todos já conhecemos vários exemplos sobre o sucesso de padrões “de-facto”,
surgidos da “seleção natural” promovida pelas comunidades Open-Source,
sobrepujando os padrões “de comitês” J2EE. O exemplo mais gritante é o
fracasso do JDO (para quem nem conhece, é o padrão J2EE para persistência
de objetos) em prol do perante o Hibernate (este todos conhecem):

A especificação do JDO pretendia uma persistência que funcionasse para
SGBD-R, LDAP, Arquivos Convencionais ou toda a sorte de “meios de
persistência” que possam surgir. O Hibernate se ateve aos SGBD-Rs, e
procurou fazer isso bem feito. O primeiro hoje é conhecido como o “pato” -
nada, anda e voa, mas não faz nada direito! Já o segundo, é o padrão que
está sendo agora incorporado em grande parte da especificação EJB 3.0…

Preocupados em seguir a especificação pré-definida (JSR), os implementadores
perdem a capacidade de se adaptar quando se deparam com inviabilidades
manifestadas na concretização da “concepção teórica” inicial, ao contrário
do Open-Source, conduzido de forma “agile”. E assim entendemos porque os
princípios ágeis funcionam com mais frequencia:

• a evolução de um produto Open-Source de sucesso nasce de uma idéia, logo
  seguida de uma implementação prática, e de experimentações e adaptações a
  partir do uso. Como não há grandes valores envolvidos, produtos ruins são
  logo descartados (ao contrário do “agora temos que engolir” de opções
  comerciais dispendiosas), produzindo um ambiente propício para a “seleção e
  evolução natural” do mais apto, bem similar às leis que regem a natureza
  (Lei de Darwin).

• a evolução em comitês do J2EE nasce de um interesse combinado entre
  fabricantes de produtos e o mercado, gerando um documento (especificação
  em si), seguido de implementação básica de referência (sem muita
  experimentação) buscando atender a esta flexibilidade “antecipada” pelo
  comitê. Um processo parcialmente democrático, mas ainda assim “monumental”,
  que dificulta a adaptação (vide como é lenta a adaptação dos
  implementadores de produtos EJB e JDO, mesmo após se depararem com as
  deficiências práticas no mercado)

Struts e JSF

O JSF está hoje tentando fazer hoje, na camada de Visão (principalmente), o
que o JDO tentou fazer na camada de Persistência, sem sucesso: um modelo
independente de formato de saída (html, xml ou o que for). Muitos argumentam
que a melhor opção seria usar uma IDE/plugin apropriada para cada formato
(especializada)…

Um outro objetivo questionável (para a comunidade, não para a SUN) seria o
interesse específico desta empresa em ganhar dinheiro com ferramenta
fechada, concorrendo com o .NET com as mesmas “armas”: um modelo de eventos
RAD para Web. Mas esta seria mesmo a melhor opção para desenvolvimento Web?
Quando fazemos coisas fáceis, pode ser, mas quando necessário nos
recorrermos ao código (para as coisas difíceis - e isso vai acontecer),
então fica quase impossível se caminhar na pesada camada de eventos…