JSF é o futuro nas empresas?

Front-end
#101

Se você quer homem-hora, concordo plenamente. Mas eu não poderia responder a isso melhor que o Paul Graham.

Mas 90% de Java é Struts, JSF, EJB. Eu sei que para alguém que desenvolveu seu próprio framework é difícil de engolir isso, mas hoje, 4 de dezembro de 2007, tem gente começando projeto com Struts 1 e DAO feito na unha. Tem gente para quem JSF ainda é o futuro. Existe muita inovação em Java? Claro. Mas até aí, existe Cobol Orientado a Objetos e até Cobol.NET.

Se todos os desenvolvedores Java do mundo morassem numa cidade, ela teria a população do Rio de Janeiro. É claro que existe uma inércia enorme aí, mas essa inércia é uma espada de dois gumes. As comunidades Ruby e Rails ainda são pequenas e muito mais ágeis. Houve mudanças bastante significativas entre as versões 1.0 e 1.2 de Rails, mas a comunidade está acompanhando. Conforme ela crescer, as mudanças vão se tornar mais difíceis, mas pelo menos elas vão se solidificar em torno de uma arquitetura mais sólida que Struts.

Ruby on Rails não depende de custom classloader e geração de bytecode, então toda a “mágica” fica em Ruby e pode ser estendida em plugins que vão muito mais fundo que um componente ou uma biblioteca. Veja por si mesmo a variedade de plugins disponíveis.

#102

Sim, existe cacas enormes por ai, sinceramente, eu já dei manutenção em sistemas legados em C que se hoje cair na minha mão, ou eu peço demissão ou eu peço alguma coisa na casa de 6 digitos. Mas na época eu precisava de grana, sabe como é. :slight_smile:
O ponto é que o problema não é a linguagem e sim a cultura do desenvolvedor. Acredite, deixe RoR cair na “massa” de desenvolvedores e você vai ver código em Ruby que vai dar vontade de sentar e chorar.

A luta não é pela melhor linguagem, mas pelo desenvolvimento de forma mais profissional.

[quote=cv]
Eu tenho 25 anos agora, e eu me preocupo em aprender coisas novas e me livrar das ultrapassadas o quanto antes pq eu nao quero ser um programador de 60 anos que ganha dinheiro limpando as cagadas feitas ha meio seculo atras, como vemos hoje com o pessoal de COBOL e outras 4GL. Pode apostar que Struts e EJB 1.x e 2.x vao ser uma dor de cabeca tao grande quanto.[/quote]

Eu tenho 30, vi Java nascer e brigar para se firmar da forma que ele esta hoje. Java trouxe muitas boas idéias, e acredito que ainda tenha potencial para mais. Acredite, um dia você vai estar no forum GUR defendendo seus pontos de vista sobre RoR argumentando que ele tem seus pontos positivos, apesar do pontos negativos, para adeptos de uma nova tecnologia que vai surgir. :wink:

Sistemas legados sempre vão existir, as pessoas/empresas não querem e nem podem largar aquilo que esta funcionando e custou muito dinheiro apenas porque tem algo mais cool no mercado.
Struts 1.x não sei se vai dar tanta dor de cabeça, mas EBJ 2.x vai custar milhões de horas de sono ainda. :slight_smile:

Mesmo assim, não acho que seja a culpa do EJB2.x e muito menos do Java, e sim da cultura de usar EJB para tudo que tinhamos a 3 anos atràs. Eu mesmo assumo minha parcela de culpa.

Gosto da ideía da ferramenta certa para certo problema. Mas não acho que Java seja tão diabólico assim.

[]'s

#103

Olá

Cara, gostei do que você escreveu e concordo plenamente.

Aliás, no RejectConf07 falei com o Carlos Brando sobre isto. As tecnologias chegam, parecem a melhor coisa do mundo e depois aparece outra coisa que apresenta vantagens.

Estudei Ruby e achei uma linguagem bem mais poderosa do que Java. Hoje entendo porque algumas aplicações Ruby bem complexas podem ser feitas escrevendo MUITO menos código que uma outra similar feita em Java. Ando estudando RoR e também me impressiono com a possibilidade bem maior de me focar no problema a resolver ao invés de precisar de atitudes ninjas.

Tive meu primeiro contato com Java em 1996 e fui um dos presentes naquelo famoso evento Java World Tour de 1997 que apresentou o Java no Brasil. Comecei a desenvolver profissionalmente com Java em 1999 pois até então sabia programar mas não conseguia clientes.

Posso dizer que gosto muito de Java.

Mas meu testemunho é a impressão de que a maioria dos sites que a gente faz usando Java ficariam prontos mais rapidamente se fossem feitos usando RoR.

Se alguém acredita na experiência de um velho de 62 anos que já passou por Fortran, Basic, Cobol, PL1, Assembler (vários), APL, Clipper, C/C++, Pascal, Delphi, Visual Basic e Java, corra para aprender Ruby e RoR.

Java significa a empregabilidade atual. RoR pode significar continuar trabalhando com projetos inovadores no futuro.

[]s
Luca

#104

Gostei do que o pessoal está falando do RoR. Eu mesmo, venho trabalhando em um projeto onde estou, feito em JRuby on Rails. Começou instável, devido a falta da evolução do JRuby no princípio e agora, com as melhorias da nova versão do JRuby, vem acelerando.
Eu diria que Ruby é ótima e o framework Rails bem bolado. Conheci Ruby em 2003 e não dei tanta bola na época, aprendi para um projeto Linux e parei por ai. Preferi o Python (e ainda prefiro) como linguagem.
Bom, vejo todos falando como se Java fosse ser enterrado, mas não penso assim. Acredito que a Sun está chegando em um novo estágio. Eu costumo fazer uma analogia ao meu modo de vida de antigamente. Eu gostava muito de jogar games de mesa . Com o passar do tempo, perdi a vontade de jogar e passei apenas a assistir e ensinar. A Sun está fazendo o mesmo. Veja o Groovy, é a primeira vez que surgiu uma segunda linguagem oficial para a plataforma JVM (isso poderia ter sido feito a muito tempo). Creio que a terceira será JRuby e a quarta…
Bom, enfim, a plataforma Java agora terá novos rumos. Focar na excelência da Virtual Machine e deixar com que os outros criem seus próprios “jogos” sobre ela. Isso eu chamo de amadurecimento.
Quanto a frameworks, minha nossa, Java tem demais isso. De certa forma, foi incentivo deles mesmos, uma vez que a linguagem não ajudava na produtividade. De repente, aparece RoR. Isso me lembra uma outra história, do imã da porta da geladeira. Enquanto uma empresa norte-americana havia desenvolvido a porta da geladeira com abertura pela parte de dentro (crianças morriam antigamente se ficassem presas dentro da geladeira) e JÁ estava treinando as pessoas em como usar, veio uma invenção simples, de um imã em uma borracha que além de vedar, não deixava a porta presa. Bom, dá pra imaginar o resto.
O problema é que muitos estão comparando o novo com o velho. Não dá pra comparar RoR com JSF, porque o último nasceu pra combater o ASP.NET, que na minha humilde opinião, não fez ainda jus ao seu legado, pois o .NET é melhor, mais simples e mais rico que o JSF.
RoR não parece com outros frameworks Java, mesmo o Grails com suas características similares (mas ainda nada tão fácil), porque este paradigma ainda não existia. Mas vejam que outros frameworks estão sendo criados partindo agora deste princípio “novo” e acredito que em breve surgirão vários fazendo o mesmo (em Java mesmo). Isso não é exclusividade mais do RoR, caiu na comunidade, vai ser imitado até que “alguém”, sei lá quando, inove novamente.
Agora, vejo o pessoal da ThoughtWorks comemorando o empenho do JRuby com o site feito para a Oracle. Convenhamos, uma empresa grande como a Oracle (meu momento “visão empresário”), claro que tem que saber o potencial de uma “novidade” como JRuby. JRuby ainda não foi testado a ferro e fogo em sistemas com grandes requisições. Mas todos sabemos que a ThoughtWorks tem tudo para dar certo, uma vez que um de seus desenvolvedores é nada mais que Ola Bini, que participou do projeto diretamente.
Agora porque JRuby e não Ruby? Meus amigos, todos sabemos que o potencial da JVM. E a integração com Java é simples.
Agora, porque muitos gostam de RoR? Bom, a verdade é nua e crua. Qualquer sistema, seja qual for, tem sempre as mesmas características básicas centrais (pra não dizer banais). Passamos a maior parte do tempo desenvolvendo e resolvendo isso.
RoR é fácil, mais que fácil, é quase “humano”. Agora é mais simples desenvolver qualquer coisa pra Web que usar PHP do modo mais macarrônico que existe.
A pergunta que fica é: Quantos de vocês acreditam que no futuro, profissionais desenvolvedores sejam bem pagos, como ocorre com Java hoje, uma vez que RoR não exige que tenhamos alguns “anos” de experiência para se tornar bons em “corrigir” problemas?

[]'s a todos e bom debate

#105

[quote=xandroalmeida]

Será? Obviamente em breve vai surgir algo muito mais simples e eficiente que Rails para aplicações web mas pelo que eu conheço do Carlos provavelmente ele vai ser a primeira pessoa a postar isso aqui. É uma das pessoas mas pragmáticas que eu conheço, não se apega à tecnologia ou ao framework específico e sim ao que importa: boa escolha tecnológica.

Seja Jara->Ruby, Ruby->Java, JRuby->Bainfuck… o que importa é que a indústria evolua e que não barremos esta evolução pelo medo da mudança.

#106

E vai ser escrita em Clojure! :slight_smile:

Isso, se não saírem com JErlang e JHaskell até lá.

#107

[quote=louds][quote=Kenobi]
Com relação ao meu projeto, will see … embora grande parte dos projetos atuais não se baseiam em arquiteturas ultra-sofisticadas , vide Django utilizando à torto e direito, além de me preocupar com os paradigmas de negócio também quero algo escalável e confiável, pelo menos para segurar o crescimento mínimo.
[/quote]

Arquiteturas sofisticadas são apenas isso, elas não conferem nenhuma vantagem quanto a escalabilidade, por exemplo. A lingua inglesa, curiosamente, pode explicar sua predileção por elas, no ingles podemos usar fancy ou poch para qualificar aquilo que vem falando. Desculpa te avisar, mas normalmente aquilo que escala melhor são as arquiteturas simples.

Já desenvolvi sistemas que tinham um volume razoavel, sustentam mais de 100 requisições por segundo durante o dia todo e a arquitetura não nem nada JEE’sh nela, pelo contrario, usamos o mais simples possivel - e funciona bem. Pela minha experiência o sistema poderia ter sido escrito em Java, perl, ruby, groovy ou mesmo em bash sem comprometer o resultado.

Escalabilidade é um treco complicado demais para simplesmente assumir que ela existe por padrão e que se isso for possivel, é desejavel. Qualquer plataforma hoje possui uma escalabilidade vertical razoavel, suficiente para a grande maioria das aplicações enterprise. Falo isso por experiência própria, metade dos sistes do UOL poderiam ser escritos com RoR, rodar em uma máquina só e estariam muito bem.

“Otimization is the root of all Evil”, por um terno no capeta não ajuda a esconder os chifes, o rabo e, principalmente, o cheiro de enxofre.

[/quote]

Louds, a maior parte dos projetos do UOL tratam ContentManagement , uma ou outra aplicação é um pouco mais softisticada (Ao menos até 2003, pois prestei consultoria ao UOL).

Completamente diferente de um software para gestão de fundos de investimento, por exemplo, que requer uma série de regras, segurança e por aí vai.

Você me deu um número de performance, e eu falei em escabilidade, que aliás foi a justificativa que você me deu para o desenho da arquitetura da NEC (sua arquitetura), projeto que fui contratado para fazer refactoring de algumas partes e que faz uso intensivamente de EJB.

Não estou dizendo que é a única solução para escabilidade, deixo claro isso. É apenas uma alternativa viável.

Poderia pensar em GigaSpaces por exemplo, trablhar com Pojos e Spring integrado ao mesmo de maneira simples e eficiente.

#108

Tá aí. Gostaria que alguém me provasse por A + B que EJB é escalável.

Tenho esse voto de desconfiança desde o dia em que eu, um programador inexperiente, fui instruído por um arquiteto sem noção a fazer uma separação em uma camada de EJB de persistencia (tipo: save, load…) em baixo de um EJB de negócio. A idéia era resolver problemas de escalabilidade, porém, IN-CRI-VEL-MEN-TE, não escalou nada!

#109

caramba e afinal, sem querer ser chato

qual foi a conclusão da pergunta do tópico?! JSF é o futuro nas empresas

tomara que seja, senão morrerei de fome rsrs

#110

[quote=Leozin]caramba e afinal, sem querer ser chato

qual foi a conclusão da pergunta do tópico?! JSF é o futuro nas empresas

tomara que seja, senão morrerei de fome rsrs[/quote]

O projeto precisa melhorar muito ainda…Há o senão do renderkit para flex/flash e afins, se não vingar, duvido que fique muito tempo.

#111

Pelo que eu entendi, a conclusao ate agora foi “nao, JSF eh irrelevante. Aprenda Rails” :wink:

#112

O sucesso de tecnologias como JSF e ASP.NET depende mais do uso de boas práticas por parte da equipe de desenvolvimento. É possível sim criar software limpo e elegante com uma camada de apresentação orientada a componentes com suporte nativo a AJAX e cross-browser. O problema é que muitos desenvolvedores acostumados a frameworks como Struts não tem tempo para (ou não querem) adaptar-se adequadamente ao modelo orientado a componentes - um paradigma que obviamente favorece a criação ágil de interfaces com o usuário, mas não necessariamente transforma tudo em “espaguete”, como alguns pensam.

Na empresa em que trabalho criamos algumas aplicações avançadas, como um cliente B2B e um Dasboard, utilizando ASP.NET e consumindo Web Services. Os resultados superam as expectativas em termos de facilidade de manutenção (isso mesmo) e TTM. Acredito que resultados semelhantes poderiam ser obtidos com JSF + NetBeans 6.0.

That’s All!

#113

[quote]realjn wrote.: Na empresa em que trabalho criamos algumas aplicações avançadas, como um cliente B2B e um Dasboard, utilizando ASP.NET e consumindo Web Services. Os resultados superam as expectativas em termos de facilidade de manutenção (isso mesmo) e TTM. Acredito que resultados semelhantes poderiam ser obtidos com JSF + NetBeans 6.0. [/quote]Como vc. pode afirmar isso, vc. está fundamentado em quais exemplos ou modelos.

#114

olha, aplico JSF a mais de 1 ano e meio e sinceramente, não troco ele por nada

integração com o Spring está super legal, facilidade de manutenção e afins, já participei de 3 projetos grandes com JSF e to fazendo um agora

é muito fácil falar mal sem sequer saber como faz um HelloWorld ou parar em qualquer problema

#115

Se está referindo-se ao fato de que JSF poderia dar os excelentes resultados obtidos com ASP.NET, não trata-se de “afirmação” mas “suposição” baseado na abordagem orientada a componentes que as duas tecnologias utilizam e que obviamente as torna semelhantes entre sí. É claro que JSF levava uma série desvantagem até o lançamento do NB 6.0 o qual introduziu melhorias significativas no suporte JSF da IDE e que (guardadas as diferenças entre as tecnologias) faz lembrar o suporte oferecido pelo VS ao ASP.NET 1.1.

O grupo responsável pela JSR-127 está constantemente revisando as especificações do Java Server Faces e devemos esperar que alguns avanços (como melhor integração com XML Web Services) sejam introduzidos posteriormente e quem sabe a comunidade Java passe a acreditar mais na tecnologia, pois o feedback que tenho visto é decepcionante.

Como não tive ainda oportunidade de criar uma aplicação JSF feita para o Mundo Real, deixarei a prova de conceito como dever de casa para algum colaborador que esteja acompanhando o post.

That’s All !

#116

Eu não vi até agora ninguém falar mau porque não conhece ou encontrou algum problema.

Da uma lida nos posts anteriores que você vai ver que o problema é outro.

#117

Onde tah o “obvio”, que eu nao vi?

E o que JSF tem de agil?

#118

Essas coisas servem pros caras criarem ferramentas que engessam a arquitetura e são cheias de wizard tipo JCompany, que estão querendo colocar aqui na empresa. :cry:

#119

[quote=cv]
Onde tah o “obvio”, que eu nao vi?

E o que JSF tem de agil?[/quote]

Amigo, como enxergar isso é um dos segredos mais bem guardados que existem. Para descobrí-lo por sí só, alguém precisa desenvolver e manter durante alguns anos aplicações Web de missão crítica em um framework como o Struts, que suporte Ajax, cross-browser, com interface complexa e customizações quase semanais. Depois aparece uma Fada que apresenta JSF ou ASP.NET para o cara… Quem já passou por isso, sabe do que estou falando.

Apesar disso, reconheço que a maioria das pessoas se sente mais à vontade ao utilizar a tecnologia que conhece melhor - mesmo que esta não seja a melhor opção existente. E a melhor parte é esta: no final das contas, a tecnologia do futuro é aquela que vai pagar nossas contas - gostemos disso ou não.

That’s All!

#120

[quote]realjn wrote: O grupo responsável pela JSR-127 está constantemente revisando as especificações do Java Server Faces e devemos esperar que alguns avanços (como melhor integração com XML Web Services) sejam introduzidos posteriormente e quem sabe a comunidade Java passe a acreditar mais na tecnologia, pois o feedback que tenho visto é decepcionante. [/quote]Poxa agora fiquei mais tranquilo pois a JSR-127 (JSF 1.0) de 03/2004 tinha tantos bugs que para usar erá necessário ser um bom contorsionista.O que estamos falando hoje é da JSR-252(JSF 1.2.0x)-JEE5 e, não precisamos esperar por avanços de WEB Services, SOA,J2ME,Java Card etc.etc. elas estão presentes no nosso dia a dia e integradas entre si vide os projetos da SRF. O feedback da comunidae é esse que vc. está lendo “JSF é o futuro nas empresas???”=22/08/2005 = e está super atualizado se voltar a ler o post vai ver que as discussões e as informações são de um nível muito superior ao simples devaneio esóterico [quote] Amigo, como enxergar isso é um dos segredos mais bem guardados que existem. Para descobrí-lo por sí só, alguém precisa desenvolver e manter durante alguns anos aplicações Web de missão crítica em um framework como o Struts, que suporte Ajax, cross-browser, com interface complexa e customizações quase semanais. Depois aparece uma Fada que apresenta JSF ou ASP.NET para o cara… Quem já passou por isso, sabe do que estou falando. [/quote] Mais ainda assim retorno a minha pergunta:
“Como vc. pode afirmar isso, vc. está fundamentado em quais exemplos ou modelos.”.