GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

JSP para novos projetos


#1

Olá,

Vocês usariam JSP para um novo projeto? Ele não pode ser considerado desatualizado? Qual tecnologia alternativa escolheriam?

(P.S.: estou desconsiderando JSF, pois não gosto da abordagem component-based do mesmo. Prefiro algo action-based).


#2

Eu uso o JSP com SPRING MVC E JSTL. Fica muito bom. Não gosto do JSF


#3

JSP é engine oficial do Java para renderização de paginas. Não esta desatualizado não. Esta normal e funciona muito bem. Não anda tendo muita atualizações por que ja chegou ao auge ai do produto.
Se vc prefere MVC action Like…JSP é otimo para vc!

Eu uso JSF e adoro component base…mas tb tenho projetos action like e JSP esta la funcionando perfeitamente!


#4

Depende do tipo de projeto.
Se quer copiar o modelo de interação das apps nativas, como todo programador web parece estar tentando fazer hoje em dia, você não vai conseguir usando renderização no servidor. A nova versão do GUJ por exemplo, não é possível com renderização no lado servidor.

Mas se você quer criar um site tradicional, não vejo problema.


#5

Poderia ser mais específico? O que você quer dizer com “imitar aplicações nativas” e qual seria a limitação de renderizar do lado do servidor nesse caso? Só para eu compreender melhor.


#6

Você lembra como era o GUJ quando se registrou em 2011?

Pra quem não lembra, era um site tradicional que sempre exibia o mesmo layout, independente de qual dispositivo vc usava pra acessar. Hoje o GUJ exibe de um jeito se vc tiver no desktop, de outro no mobile.

Sobre imitar apps nativas, estou falando dessas efeitos dinâmicos que estamos acostumados nas apps nativas e que hackers de JavaScript passaram a criar tb na web para demonstrar o quanto eles são fodas, mas é só desligar o JS e tudo para de funcionar.


#7

@pfk66 Também não entendi muito bem isso que tu disse. Não dá para usar CSS e JS em JSP? o.O
Se utilizar AJAX então… As aplicações webs ficam MUITO parecidas com apps nativas.

Sou iniciante e não consigo visualizar muito bem a desvantagem de utilizar JSP, além de ter que fazer tudo na unha(o que é uma grande desvantagem).


#8

Como funciona isso? Você usa ajax pra baixar alguma coisa e depois manipula o DOM pra adicionar o novo conteúdo a pagina que já foi renderizada no servidor?

Como você faz pra adaptar o layout ao dispositivo do usuário com AJAX?

Sinceramente, não tenho ideia.

As aplicações webs ficam MUITO parecidas com apps nativas.

Eu adoraria ver isso. Pode citar algum exemplo?

Como falei, depende do tipo de projeto. Se você quer fazer um web site tradicional sem muita firula, use JSP. Se quer fazer uma app web “moderna”, como o GUJ, vai ter que renderizar tudo no cliente.


#9

Desculpa se pareceu ignorante minha mensagem, a intenção foi mais tirar uma dúvida mesmo.

Como funciona isso? Você usa ajax pra baixar alguma coisa e depois manipula o DOM pra adicionar o novo conteúdo a pagina que já foi renderizada no servidor?

Então, envia e captura as requisições com o servidor utilizando AJAX e modifica apenas o conteúdo de interesse com Javascript.

Como você faz pra adaptar o layout ao dispositivo do usuário com AJAX?

Para adaptar o layout eu utilizo CSS, não AJAX.

Eu adoraria ver isso. Pode citar algum exemplo?

Não é dai que vem o conceito de PWA? Fazer uma app mobile e web utilizando apenas programação web, o que me dá a entender que poderia ser feito com JSP. (Java, HTML, CSS e Javascript por exemplo)
/\ É uma dúvida real.

Como falei, depende do tipo de projeto. Se você quer fazer um web site tradicional sem muita firula, use JSP. Se quer fazer uma app web “moderna”, como o GUJ, vai ter que renderizar tudo no client.

E desculpe, eu não entendo muito sobre renderizar tudo no client ou no server.
Vou dar uma pesquisada, obrigado pela informação.


#10

Não pareceu.

Esse é o modelo tradicional “web 2.0” que tem como objetivo oferecer uma experiência semelhante à de aplicativos desktop. Como falei, se o objetivo for criar um site tradicional não vejo problema em usar esse modelo.

Faz sentido. Então, até aqui a aplicação web já é responsável por acessar banco de dados para realizar consultas, construir as paginas, retornar o resultado com o layout específico para cada cliente ou o JSON se for uma requisição AJAX.

Bom, se for uma aplicação intranet corporativa com não mais de 5 usuários simultâneos, não vejo problema.

Você citar alguma PWA que é parecida com uma app nativa?


#11

Faz sentido. Então, até aqui a aplicação web já é responsável por acessar banco de dados para realizar consultas, construir as paginas, retornar o resultado com o layout específico para cada cliente ou o JSON se for uma requisição AJAX.

A parte do client só é responsável por realizar as requisições no servidor, como em qualquer aplicação web. Quem realiza as consultas é o servidor e retorna os resultados em JSON, por exemplo, que é um formato minúsculo e utilizando AJAX modifico apenas os dados necessários da página, sem a necessidade de recarregar a página.
Porque não suportaria mais do que 5 usuários simultâneos?

Você citar alguma PWA que é parecida com uma app nativa?

Através do seu mobile, acesse a página pwa.rocks, assim que você entrar na página, será solicitado para adicionar o PWA no seu dispositivo. Adicionando-o, você conseguirá acessá-lo através dos apps instalados no seu dispositivo como uma app nativa, e através dele, você poderá instalar outros PWAs, como Telegram ou Aliexpress.
Esses mesmos apps você consegue acessar através do seu navegador também.


#12

Respondendo a galera:

Eu sou mais iniciante que você, não consigo nem enxergar isso que você diz que é desvantagem. :slight_smile:

Eu entendo que é possível fazer assim e com isso ter uma experiência parecida com a de uma aplicação desktop, por isso não acho que a renderização server-side tenha alguma incapacidade em relação à client-side. Só não é muito claro para mim o que é esse “alguma coisa” que é baixado. Pode ser simplesmente dados (uma string, um json) ou então um trecho de HTML já preparado que é adicionado ou substitui um outro trecho na página renderizada. Tenho pouca experiência com front-end e não tenho essa visão. Preciso formar melhor isso na cabeça ainda.

Aproveitando o ensejo, alguém sabe quais são as tecnologias por trás do GUJ atualmente?

Vixe. PWA? Já entrou em coisa avançada pra mim. :slight_smile:

Aqui fiquei na dúvida. Um site “web 2.0”, que tenta oferecer a experiência do desktop, é tradicional ou moderno? Aqui eu entendi que é tradicional, lá em cima eu entendi que era moderno. :slight_smile:


#13

Ok, eu exagerei vai. Talvez você consegue uns 10 a 15 usuários simultâneos, ou até mais se não usar HttpSession.

Acabei de acessar aqui no mobile… maaaaaano, essa foi uma das experiências web mais sofríveis que tive na minha vida.

Não tenho nem idéia como alguém pode comparar isso com uma app nativa para iOS.


#14

Web 2.0 é tradicional já que é um termo popularizado em 2004. Nessa época não havia internet movel, muito menos iPhone ou Android.

Depois, com a explosão mobile e app-tizaçao de tudo, é que surgiu as soluções “modernas” (SPA, PWA) pra tentar competir com apps móveis nativas.

Mas essas soluções modernas geralmente são tão ruins que a primeira coisa que procuro quando acesso um site no smartphone é uma forma de ativar a versão clássica para desktop. Infelizmente não é sempre que ela esta disponível. :frowning:


#15

Desculpe o meu desconhecimento. Por que só 10 a 15 usuários simultâneos? Seria por gargalo no banco ou na aplicação? Não me lembro de ter ouvido falar que a capacidade de uma aplicação web feita no Java fosse tão baixa assim.


#16

Pra min faz, sentido.

Basicamente você acaba aplicando o modelo MVC.
Imagine que você tem um site de compras com milhares de acessos simultâneos.

Na primeira requisição o usuario recebe a view, que pode ser renderizada usando html, css e JS.
Ao mudar de página, receberia outra view, com html, css e JS personalizados.
Como a atualização do conteúdo é assincrona, por meio de ajax, somente o essencial é consumido, logo não seria justificativa para afetar o desempenho.

Com relação ao dispositivo, seria necessário conhecer apenas as dimensões da tela e o site deveria ser responsivo.

Então como o site é responsivo, ele, o site, não está preocupado com o dispositivo, mas sim com o tamanho da view.
Se utilizar o conceito de cluster, você acaba aliviando a carga no servidor, que ficaria responsável pela camada model e indiretamente o JS, com a camada controler.

A camada de persistência ficaria abaixo da model;

Quando se justificaria a aplicação nativa.
Quando o poder de processamento tivesse que ser maior que o oferecido por navegadores, mantendo o servidor leve.

Ex.: um jogo em android.

Para isto, tem que ter em mente a “clusterização”.

Não vejo como a escolha da forma de implementação bem feita afetar o desempenho do servidor, seja usando aplicações nativas ou não.

Se parar para observar, vai ver que a princípio tudo devia ser MVC e a escolha entre nativo ou não dependeria apenas do tipo de processo a ser realizado.

Assim, eu não gastaria dinheiro criando arco e flecha para “indios nativos” que caçam com com rifle de curto alcançe.

Cabe lembrar que o que é mal feito, é mal feito e pronto.


#17

Crie servicos REST no backend e faca o front com Angular, Vue, React… assim o front fica desaclopado do backend, cada um com sua responsabilidade.


#18

Você já ouviu falar de uma aplicação JSP com interface dinâmica e que suporta alta capacidade? Apenas uma pergunta retórica, não precisa responder.

Sistemas internos corporativos não precisam mais capacidade que isso, e nem interface cheia de firulas, por isso não vejo problema.

Com relação aos sistemas que precisam de mais capacidade, existe um risco em adotar uma arquitetura que concentra tanta responsabilidade em 1 único servidor, porque se não for o suficiente, você vai ter que adotar as técnicas de magia negra sugeridas pelo @addller para escalar sua aplicação web.

Além de não ver vantagem nenhuma, uma vez que não é muito mais difícil começar com o que sugeriu o @igor_ks, desaclopando cliente e server. Provavelmente mais simples no início, quando um serviço/API é suficiente e cada componente tem sua responsabilidade bem definida, servir e apresentar. Agora se depois precisar de mais capacidade, tu pode distribuir a carga sobre o servidor adicionando mais serviços, o que vai aumentar a dificuldade da sua arquitetura, é verdade. Ainda assim, nem de perto a complexidade de rodar sua app web em cluster ou em um servidor de aplicação!


#19

O antigo guj usava jsp e aguentava melhor que essa versão moderna que usa api xP

o coderanch continua usando jForum que é feito com jsp,

e o site zeef.com é feito em (pasmem) jsf xD
http://adam-bien.com/roller/abien/entry/a_java_ee_startup_filtering

pessoal taca muito terror sem motivo, jsp aguenta de boa… o dia que não aguentar mais vc provavelmente estará ganhando o suficiente pra pagar alguém pra melhorar xP


#20

Apesar desses sites funcionarem perfeitamente, eles tem a mesma influência na web de hoje quanto uma aplicação corporativa interna, ou seja, zero.

Hoje quem define o que é tendência na web é o google e facebook, e se eles dizem que o browser tem que suportar um modelo de interação rica pra competir com apps nativas, então é isso que nós vai fazer, se tornar JavaScriptBoy (ainda que a maioria das apps usadas no dia-a-dia, como email, banco, rede sociais, games, etc. sejam nativas, especialmente mobile).