Discussões 3.0 - Front-end

[juliancesar]

Olá pessoal, convido todos e participar das discussões sobre a nova versão do Framework Demoiselle.

Essa issue trata o tema Frontend, que tem ganho destaque, e será tratada como um projeto Demoiselle. Queremos ouvi-los sobre as tecnologias que podem nos ajudar a construir interfaces que possam melhorar a experiência dos nossos usuários.

Vide vídeo: https://youtu.be/bP72IQEQzhU

Deixe aqui suas expectativas e comentários sobre o assunto.

[AngelPortal]

Vai haver algo sobre o demoiselle para Mobile?

[cynarar]

Seria possível usar o Yeoman e o Primefaces?

[tucamefe]

Estamos querendo utilizar o demoiselle 3.0.0, mas queremos poder utilizar o demoiselle com REST + um front end que não tenha JSF ou AngularJS. A idéia é utilizar, em aplicações bem simples, templates engines simples, que evitem ao máximo utilizar java script. Existe essa liberdade de usar um template como o Mustache, sem a necessidade de carregar tanta coisa do demoiselle.

[marciofrayze]

Acho que de todas as partes de um projeto web, atualmente a view é a que sofre evolução com maior frequencia. E infelizmente o histórico do Demoiselle nos mostrar que a evolução geral do mesmo é lenta (ainda não tem suporte a Java 8 por exemplo, que foi lançado em 2014).

A demora em evoluir atrapalha em todas as camadas, mas a view é a que mais sofre com isso. Antigamente o JSF tinha bastante força, depois, até pouco tempo atrás, a "moda" era usar Angular 1 (e o modelo two way data binding). Hoje existe uma tendencia forte em abandonar este modelo sendo que o próprio Angular 2 está indo para um caminho bem diferente. Existe também muita gente indo para o React.js. Tem ainda os Web Components (junto com polyfills), que acho que vão ganhar mais força nos proximos anos.

O que quero dizer é que quanto menos o Demoiselle se intrometer nesta camada, melhor. Se formos seguir um modelo de API/Restfull (que parece ser o caminho que o Demoiselle pretende seguir), a camada view vai ficar praticamente 100% no lado cliente/browser. Desta forma, cria-se uma barreira muito bem delimitada (cliente trata toda camada visual e servidor cuida apenas da lógia de negócio retornando e recebendo json).

Quem quiser usar Angular 2: ótimo! Quem quiser usar React.js, Riot.js, Web components com pollyfills... melhor ainda! Mas para o servidor, não vai fazer diferença nenhuma, vai estar tudo na camada visual (de preferência fora até do servidor de aplicação, servindo conteúdo estático via Apache ou Nginx).

Quanto ao JSF: Deixe-o morrer em paz! (https://www.thoughtworks.com/pt/radar/languages-and-frameworks/jsf). O modelo do JSF não combina com uma arquitetura Restfull (embora seja possível fazer isso, não faz muito sentido - o JSF nasceu com uma proposta completamente diferente, e que não vingou).

[botelhojp]

Primeiro gostaria de esclarecer que os projetos Demoiselle JEE e o Demoiselle Frontend são distintos e como bem lembrado possuem baixo acoplamento entre eles, ou seja, posso usar o Demoiselle JEE com várias tecnologias de Frontend.

Observamos que “mundo” Frontend é muito mais heterogêneo que o backend. O leque de possibilidades pode deixar equipes menos experientes sem norte. Além disso, quando tratamos projetos multi equipe, com rotatividade de pessoas e até rotatividade de equipes inteiras é importante haver padrões tecnológicos para apoiar as mudanças.

O projeto Demoiselle Fronend visa selecionar um conjunto tecnologias como um ponto de partida. A liberdade de escolha estará sempre presente, mas queremos construir uma massa crítica sobre desafios comuns e formas de convergir nossos esforços.

[PauloGladson]

Só complementando, @botelhojp e @tucamefe , o que vamos oferecer para frontend são alguns facilitadores para aumentar a produtividade, como gestão de segurança, tratamento de exceções, mensagens, websocket, dentre outros, mas claro, a escolha fica sempre com a equipe, acho que vale a pena ver esses facilitadores e levar para seu framework de preferência, pois vai poupar retrabalho. @cynarar o generator-demoiselle já usa o yeoman e a ideia e ter mais funcionalidades trazendo facilitadores para o maior número de projetos. @AngelPortal temos alguns casos de sucesso com o IONIC para apps em dispositivos móveis, acho que podemos fazer facilitadores para ele, mas ainda não está no roadmap.

[rafaelodon]

boas colocações do @mfdavid, mas pode gerar um impasse, pois, se for pensar por essa linha de que o Demosielle deve se intrometer o mínimo, não precisaríamos nem do demoiselle no back-end, pois o Java EE 7 já nos forneceria tudo que precisamos, o que é uma dentre as várias opiniões válidas por sinal. Daí eu me pergunto, e lanço a pergunta para todos: qual a missão do Demoiselle 3? Se isso não for bem definido agora no início dessa discussão, jamais iremos convergir. Um abaraço

[PauloGladson]

@rafaelodon e @mfdavid, complementado as observações de vocês, o Demoiselle nunca teve a vocação de "se intrometer" no código, ele apenas tem facilitadores que visão a melhoria do reuso para buscar produtividade. Fazer um sistema sem os facilitadores é possível, mas muito provavelmente as equipes terão de implementar pontos de reuso, para ter proveito da reutilização de código e produtividade, se isso fosse realidade teríamos dezenas de equipes fazendo as mesmas funcionalidades das mais diversas formas, agora imagina produzir as mais de 1000 apps que produzimos em Demoiselle, fossem em qualquer linguagem, usassem quaisquer componentes. A JEE7 já conta com alguns facilitadores que a JEE6 não tinha, mas tanto uma quanto outra é possível construir um crud simples sem nenhum facilitador, mas de toda forma, quando houver necessidade de uma camada CRUD, Segurança, Configuration, Lifecycle, dentre outros, vai exigir implementação sua ou buscar componentes de terceiros para isso. O Demoiselle 3.0 será focado em buscar o máximo da JEE7 que é o microservice, microcontainers, multitenancy, nuvem, porque trocar de JEE6 para JEE7 e continuar no "padrão monolítico" o ganho é muito pouco em relação ao que podemos ganhar explorando essas novas propriedades do JEE7. A quebra de paradigma que houve da 2.4 para a 2.5 nos trouxe ganhos extremos, quando saímos de "JSF" para "REST/HTML5", da mesma forma temos que quebrar mais uma vez o paradigma da programação, saindo da "monolítica" para a "microservices", essa será a vocação da versão 3.0 do Demoiselle.

[hbobenicio]

Muito bem lembrado, @botelhojp , é importante mesmo esse baixo acoplamento entre Backend e Frontend. Outra lembrança muito importante é a heterogeneidade do mundo Frontend. Hoje no mercado existem incontáveis Frameworks JS, muitos são criados todos os dias e muitos são atualizados para versões incompatíveis (a exemplo do Angular 1 e 2, que a meu ver não deveriam nem ter o mesmo nome, pois são completamente diferentes e incompatíveis).

Dado a importância e a longevidade dos projetos do Serpro, é importante cautela na hora de se "abraçar" com Frameworks JS. Hoje o que pode ser bom, amanhã pode estar bem defasado. Até quando o Angular 1 será mantido pela comunidade? Seria o Angular 2 viável, estável sem Typescript (desenvolver um código e debugar outro = dor de cabeça)? Seria o EmberJS uma alternativa mais viável? ReactJS, sendo apenas um framework de camada de Visão, poderia suprir as necessidades de alguns projetos? Não estaria certo o Rob Einsenberg em dizer que Angular 2 não é o caminho? Qual a estabilidade do Aurelia, com sua abordagem totalmente ES2016? E quanto a plain ES2015/2016 com alguns padrões de camada? Gulp vs Grunt (performance, manutenção e escalabilidade)?

Ainda há muito o que se discutir... talvez a palavra chave seja Flexibilidade de Escolha.

[PauloGladson]

@hbobenicio , exatamente isso, hoje já existem apps em produção no modelo REST/HTML5 usando o AngularJS, que se mostrou muito estável e bastante maduro, no generator-demoiselle, usamos o AngularJS na versão 1.5 para ajudar as pessoas no início dessa nova forma de implementar, nele tem uma "cola" Demoiselle para facilitar a integração com segurança, exceções, mensagens, crud, websocket, etc. O ideal é que esses facilitadores possam ser levados para a outras frameworks de frontend e podemos divulgar junto com o AngularJS para os usuários se beneficiem do JS que mais lhe agradar.

[leonardofl]

Indo na proposta da @tucamefe, um sistema de template que parece bem promissor é o http://www.thymeleaf.org/. Pelo o que vi, parece bem similar ao sistema de templates do Python Django (ponto positivo hehe) e não é tão distante do paradigma JSF, mas muito mais simples e focado direto no HTML. Bom, só jogando uma opção a mais para ser considerada : )

[brunopalaoro]

Como já foi comentado por muitos, o cenário front-end está mudando constantemente, por isso não acho legal que o demoiselle bata muito forte em um framework só, pois isso pode acabar prejudicando o desenvolvimento com o passar do tempo. Veja a versão 2 por exemplo, que pregava forte o JSF, e foi um demora bem grande para conseguirmos ter a liberdade de desenvolver numa arquitetura usando o Angular (ainda se encontra resistência em alguns setores).

Me parece que atualmente o Angular 1 está meio como o framework "oficial" do demoiselle, sendo que o mercado já está seguindo por outro caminho, se voltando mais para as especificações dos Web Components, como React, Vue, Polymer ou até o Angular 2 para citar os mais famosos. É preciso cuidado para o demoiselle não ser lançado e já se mostrar defasado.

Sei que é importante fornecer pelo menos um norte para equipes que estão começando agora, mas espero que não seja freado o avanço de equipes que já estão mais avançadas nessas tecnologias.

Caso seja escolhido algum para ser esse "norte", deve-se pelo menos fornecer exemplos utilizando os padrões mais atuais do mercado. Por exemplo, se for usar o Angular 1, é legal já dar um projeto inicial utilizando o ES2015, com o novo styleguide sugerido em https://github.com/toddmotto/angular-styleguide, talvez até já com o webpack configurado para já ter o ambiente de desenvolvimento pronto. O demoiselle-generator é uma boa ideia como ponta pé que já te dá uma aplicação básica, mas o código que ele gera já está com uma cara bem datada.

[PauloGladson]

@brunopalaoro Estamos fazendo uma app de referência para o Demoiselle 3.0 com AngularJS 1.6 usando o ES6 com webpack que irá funcionar com Demoiselle 2.5 também, e nosso desafio será lançar outro frontend com AngularJS 2.0 (mas sem previsão, por enquanto), aceitamos outros exemplos enviados da comunidade em outros frameworks para a app de referência e iremos divulgar também. Na questão corporativa temos que ter uma definição, pois se as dezenas de equipes escolherem seus frontends, como ficará o suporte e homogeneidade de conhecimento entre equipes, teremos um problema gerencial gigantesco. Juntos vamos debater até encontrar uma framework/versão mais adequada para nossa empresa, mas para a comunidade faremos a divulgação de todas as contribuições que nos forem enviadas para ajudar outras equipes inclusive as nossas para sempre acompanharmos a evolução tecnológica

[marciofrayze]

Até agora parece que o que vocês querem fazer não é um framework, mas apenas um template para servir de ponto de partida (o que eu acho ótimo). @PauloGladson seria possível (a título de curiosidade) você me enviar este levantamento das 1000 aplicações em produção que foram produzidas utilizando Demoiselle?

[reinaldovale]

Segundo minha visão, a estratégia do Demoiselle Backend, até então, consisti em abraçar as especificações sobre a tutela do JCP, criando extensões para melhorar ou facilitar a utilização do guarda-chuva JEE. Também, o Demoiselle Backend, disponibiliza componentes para tampar os buracos das omissões do JCP. Na minha opinião, estratégia acertada, pois além de dar um norte para o framework também permite restringir ou disciplinar a entrada de tecnologias "aventureiras".

Portanto, para o Demoiselle Frontend, minha sugestão, consiste em seguir com a mesma estratégia mudando apenas as entidades, ou seja, abraçar as especificações do W3C (html5, CSS3, javascript vanilla ES6) e tampar os buracos das omissões do W3C e suporte a browsers com micro bibliotecas e polyfills.

Para mim, frameworks como angularjs, angular2 (sim, não são o mesmo framework, nem compartilham o mesmo nome) e afins estão para o Demoiselle Frontend do mesmo modo que frameworks como Spring, VRaptor e afins estão para o Demoiselle Backend.

Por último, penso que a equipe do Demoiselle, em se tratando de frontend, deveria focar em disseminar boas práticas e tutorias, pois nem só de receita de bolo vive um profissional de TI.

[rafaelodon]

Absorvo de tudo que foi dito por todos que o Demoiselle 3 deve buscar facilitar o desenvolvimento front-end sem limitar as escolhas das equipes e ao mesmo tempo fornecendo uma linha de guia para que equipes iniciantes possam seguir um caminho arquitetural confiável. Isso é um enorme desafio, dado a efervescência (pra não falar bagunça) que está o mundo Javascript hoje em dia. Estamos longe de conseguir um stack tecnológico estável e promissor no Front-End.

[lucasa]

Pelo que pude observar nas discussões aqui, há um certo conflito de interesses entre o que esperar de um framework comunidade e de um framework balizador do trabalho interno da empresa. Pode ser interessante deixar o framework comunidade mais agnóstico e menos prescritivo e fazer uma extensão do Demoiselle mais direcionada para uso interno, projeto separado e tal.

Nessa extensão interna pode-se ser mais enfático no direcionamento de tecnologias para frontend, pois realmente é necessária essa padronização para que nosso desenvolvimento web não vire um zoológico de tecnologias.

[botelhojp]

A discussão está excelente. Compreendo os pontos de vista e na minha opinião teremos benefícios com o Projeto Frontend.

Buscar direcionadores, padrões, facilitadores, pode ajudar muitas equipes que estão entrando nesse mundo relativamente novo. Porém não acredito que o Demoiselle Frontend será um “cabrecho” para o desenvolvimento.

Na minha humilde experiência como suporte em tecnologia, percebo que há diversos pontos em comum nas várias equipes que atuei e penso que os sucessos e os fracos delas podem convergir para um ambiente colaborativo.

Quem acreditar que é cada um por si e Deus por todos, também é uma forma de pensar, mas no meu entendimento agrega menos valor ao coletivo.

E que continuem as discussões :-)

[ronaldoveras]

A nova versão não dará suporte a JSF? Eu até entendo que o javascript venceu a briga no browser, mas não gosto do pensamento excludente. Pode ser que faça sentido eu desenvolver um sistema em JSF para poucos usuários, pela produtividade de minha equipe, etc. Além disso, apesar de a Oracle encontrar-se em uma posição bem fechada com relação ao futuro do JEE 8, não há ainda uma descontinuidade da tecnologia oficialmente, até onde eu sei, embora saibamos as limitações do JSF.

[brunopalaoro]

@botelhojp concordo com você que pensando como serpro é bem interessante ter um ponto de referencia que equipes novas possam seguir, até pela questão de treinamento e capacitação de pessoas. Por outro lado, falando como equipe de desenvolvimento, as vezes fica a impressão que você tem que seguir o que foi recomendado para evitar problemas burocráticos. Um ponto difícil de balancear, para não virar uma bagunça também como o @lucasa comentou.

Achei bastante interessante o comentário do colega @reinaldovale, dar destaque para um cardápio de componentes e boas práticas. Realmente não seria um framework, e sim um conjunto de componentes que podem ser usados de acordo com a necessidade, seguindo as especificações do mercado. Assim você tem um norte, que seria como os componentes são implementados, mas dando a liberdade para a equipe tomar algumas liberdades se quiser. Talvez um exemplo seja a documentação do Angular 2, onde todos os exemplos são em Typescript e é o recomendado pela equipe, mas deixa a opção de de usar javascript puro a quem preferir.

[PauloGladson]

@mfdavid essa informação você pode ter acesso por solicitação da DIDES, somente eles podem te informar isso.

[marciofrayze]

@PauloGladson Como faço esta solicitação?

[marciofrayze]

@leonardofl Cheguei a testar o Thymeleaf (quando estava estudando um pouco de Spring MVC) e gostei bastante também! Só achei o repositório github deles meio "morto"...

[lucianojs]

Um ponto que deveria ser pensado no escopo do Front-end é como facilitar o trabalho de automação dos testes. Será que vale a pena seguir pelo caminho do Jbehave + Selenium/Webdriver ou utilizar ferramentas mais indicadas pelos Frameworks, como o Protractor para Angular. Como isso se integraria ao DBehave?

[coelhotopetudo]

Sobre o React (https://github.com/facebook/react)... tem que ver a questão da licença (e/ou patente) dele.

Acredito que devemos levar em consideração o apoio e tamanho da comunidade do framework.

[daaneto]

Caros,

voltando um pouco a discussão, destaco a questão que @rafaelodon levantou alguns dias atrás:

Qual a missão do Demoiselle 3? Se isso não for bem definido agora no início dessa discussão, jamais iremos convergir.

Concordo com esta afirmação.

Nesta discussão, o mais próximo de responder esta questão foi a resposta de @PauloGladson, quando afirmou:

O Demoiselle 3.0 será focado em buscar o máximo da JEE7 que é o microservice, microcontainers, multitenancy, nuvem, porque trocar de JEE6 para JEE7 e continuar no "padrão monolítico" o ganho é muito pouco em relação ao que podemos ganhar explorando essas novas propriedades do JEE7

Mas gostaria de entender ou ver relacionado quais são os problemas que o Demoiselle 3 quer resolver, pois poderíamos buscar uma solução do mercado que já resolva estes problemas e assim evitaríamos reescrever a roda.

Sinto falta de uma a descrição clara para o objetivo do Demoiselle 3.

Até agora, essa indicação de "buscar o máximo da JEE7 que é o microservice, microcontainers, multitenancy, nuvem...", de uma forma geral é interessante mas acho isso muito vago e abstrato, por isso as questões:

• Qual a missão do Demoiselle 3?
• Concretamente, quais são os problemas que o Demoiselle 3 quer resolver?
• Não existe uma solução de mercado que seja mais madura e experimentada, que já resolva estes problemas?
• Por que não utilizar esta solução para tapar os buracos das especificações?

[botelhojp]

Quero separar a resposta em duas frentes: uma coisa é a missão da v3 que visa a modernização ao JEE7. Discutir a existência do Demoiselle em detrimento de outros frameworks é uma outra história. Desde 2008 ouço este questionamento. Naquela época o EE havia muito mais lacunas e os frameworks “de mercado” agregavam muito mais valor. O princípio do Demoiselle sempre foi valorizar as especificações e “abrir mão” das suas próprias implementações a medida que as especificações evoluem. Posso afirmar que a versão 3 será bem menor que a v2, portanto nessa altura do campeonato seria mais fácil questionar o uso puro do EE7 a ter que abraçar um framework de mercado.

[thkprado]

Como insumo para a discussão, segue alguns links: Choosing a JavaScript Framework - Rob Eisenberg The rise of functional programming & the decline of Angular 2.0 Angular 2 vs React: The Ultimate Dance Off The State Of JavaScript survey 2016 - Front-end Frameworks

Um framework que não foi discutido pelo Rob Eisenberg, mas que está se popularizando rápido (considerando as estrelas no github) é o Vue.js. Acho que é porque ele foi adotado por várias empresas conhecidas internacionalmente, principalmente chinesas (Alibaba, Baidu, Xiaomi, etc). Além disso, ele foi adotado como framework frontend padrão do Laravel (framework PHP muito popular).

Por último, segue este artigo comparando desempenho entre alguns frameworks.

[lusabo]

Apesar do Angular 2 ser a bala de prata da vez, criar um arcabouço tecnológico em cima dele pode ser um tiro no pé, assim como foi o Demoiselle 1, difícil de migrar para o que será a próxima bala de prata e ter que manter uma equipe para dar suporte.

Uma sugestão seria tornar o projeto Demoiselle Front-End um conjunto de arquétipos (mostrando as mais diversas tecnologias - ES 6, Angular, Reacj etc) agregado de tutoriais e exemplos de boas práticas. Cada um que escolha o melhor para seu projeto e dessa forma deixa-se claro que essa parte de visão é de responsabilidade da equipe.

Às vezes "I need to display data on a page, not perform Sub Zero’s original MK fatality."

Esse arquétipos poderiam já agregar um conjunto mínimo do que é um projeto web precisa: autenticação, testes, auditoria e por aí vai. O site http://todomvc.com/ é uma ideia do que imagino que o Demoiselle Front-End seria.

[marcelofns]

Vejo que trabalhar com módulos (http://jsmodules.io/) reduz muito o impacto de migrar por exemplo de um framework para outro. Verificamos que é relativamente simples migrar um módulo feito com Angular1.5 + ES6 para Angular2 + Typescript.

Módulos devem ser independentes, mínimo de dependências, funcionalidade específica, aumento da reutilização, etc

Inclusive quando as equipes estão desenvolvendo suas features (clientes, fornecedor, financeiro, etc), cada uma delas deve ser escrita como um módulo. Frameworks que não fornecem essa capacidade deveriam ser evitados.

Para o Frontend Demoiselle podemos construir os módulos principais (autenticação, validação, mensagens, exceção, etc). Seria possível utilizá-los com "npm install" e importá-los nos módulos da aplicação. O gerador com Yeoman já poderia ser o facilitador para adicionar as dependências de forma automática, de acordo com o que o usuário informar que deseja utilizar no projeto.

[egrohs]

Pessoal, e o framework vaadin? O demoiseile atual tem alguma integração com ele? Já fiz um projeto com ele, é bem interessante programar interface sem se preocupar com js (ele usa estilo swing). Se precisar fazer "firulas" na interface basta colocar um css na pasta resources e configurar a aplicação.

[botelhojp]

Olá @egrohs no momento o vaadin não está priorizado para a versão 3. O baixo acoplamento entre back end e fron end permitirá escolher seus frameworks preferidos para construção de GUI. Entendo não ser oportuno construir dependência direta com o Vaadin.

[botelhojp]

Lançada hoje versão 3.0.0-BETA2: http://repo1.maven.org/maven2/org/demoiselle/jee/

[egrohs]

Há algum treinamento ou material disponivel para versão 3.0?

[botelhojp]

Material de treinamento apenas para o segundo trimestre de 2017. A documentação de referência está em construção, mas pode ser acessada em: https://demoiselle.gitbooks.io/documentacao-jee/content

Coma está em construção, não ligue para as inconsistências, recomendo inicialmente ler o roteiro rápido: https://demoiselle.gitbooks.io/documentacao-jee/content/roteiro_rapido.html

[hbobenicio]

Technology Radar da ThoughtWorks 2016: https://www.thoughtworks.com/pt/radar/languages-and-frameworks

[marciofrayze]

@hbobenicio esse radar da thoughworks é fantastico... sempre acompanho. Pra front-end tem um "concorrente" que eles chegam a citar que achei bem interessante: aurelia (http://aurelia.io/). Cheguei a fazer uns testes com ele e gostei bastante do que vi.

[coelhotopetudo]

Sobre a ida para a Microsoft de um, se não for o, dos "cabeças" do Aurelia:

https://www.infoq.com/news/2016/09/aurelia-rob-eisenberg-microsoft

[marciofrayze]

@coelhotopetudo pois é, quando vi o anuncio dele indo pra MS confesso que ficou meio com pé atrás. Mas no proprio link que voce colocou tem a reposta do Rob Eisenberg la: "I have to say...I'm getting pretty ticked off by this idea that I'm the only person that works on Aurelia. That is an insult to the entire team. There are almost 30 people who work very hard on Aurelia. It's extremely insulting to discount the people who are doing the majority of the work." (...) "The only thing I do is provide vision, merge PRs, perform repo maintenance and write a few blogs posts. The hard, meaningful work is done by everyone else."

[marciofrayze]

Outro projeto que considero que poderia ser interessante para o Serpro é o polymer (polymer-project.org). É bem tranquilo de usar e para o Serpro seria interessante o fator de poder criar componentes reutilizaveis e muito bem isolados. Seria possível por exemplo criar até componentes com interfaces e comportamentos em comum padronizadas (com css, javascript e html bem isolados). Poderia ter uma equipe mais dedicada a isso e as demais equipes precisariam apenas importar os componentes e sair usando no html como se fossem componentes "nativos" do html. Além disso, o polymer (assim como o framework aurelia) tentam ficar bem próximos das especificações (web components), adicionando apenas o que realmente falta (exemplo: data binding e templating). Pensando que os projetos do governo federal em geral tem uma vida util bem grande, ficar o mais próximo possível dos padrões adotados pela w3c considero que seja uma boa ideia, já que vai facilitar a migração aos poucos para novas tecnologias sem ter grande impactos (ao contrário do que acontece com o Angular por exemplo, que vive quebrando compatatibilidade, até mesmo em releases minor). A versão 2 do polymer (que ainda está em preview) vai usar ES6 e acho que está ficando beeem legal.

[botelhojp]

Excelentes dicas, sem dúvida os projetos citados devem ser observados. Se alguém evoluir em experimentos ou pilotos, podemos combinar um momento para compartilhar essas experiências. No momento estamos nos preparando com o Angular 2, mas havendo oportunidade podemos ter outras “balas na agulha”. De toda forma é muito bom ver que a discussão continua aberta.

[hbobenicio]

@mfdavid Pois é, também fiz uns testes com o Aurelia e com o EmberJS. Acho que o Aurelia teve um conceito muito bacana, mas acho que o EmberJS no momento possui documentação mais completa e está mais estável. Pessoalmente gosto também do CLI e das ferramentas de navegador que o Ember fornece. Esse Polymer já tinha ouvido falar para Rails, mas não conhecia esse projeto JS, vou conferir. Valeu a dica. Acho interessante a ideia de compartilhamento de experiências, @botelhojp . Boa ideia.

[marciofrayze]

@hbobenicio eu ia comentar do Ember agora rs Embora o aurelia seja um projeto relativamente recente eu até achei bem legal a documentação de introdução. Me lembra um pouco a documentação do vue.js, que também achei bem legal e bem fácil de novatos entenderem (ao contrário da documentação de introdução do Angular, que na minha opinião é beeem desorganizada e nada amigavel). Mas realmente não fui a fundo pra ver melhor, mas claro, angular e Ember vão ter muito mais coisa espalhadas pela internet (pelo tamanho da comunidade e pelo tempo de vida dos projetos). Sobre o Ember, nunca usei, mas pelo que li parece ser uma ótima opção mesmo para projetos que precisem de um framework estavel e confiável, que não vá ficar tendo quebras a todo momento. O proprio Rob Eisenberg fala muito bem dele em uma palestra: https://www.youtube.com/watch?v=6I_GwgoGm1w&t=23s

[marciofrayze]

Se alguém tiver interesse em conhecer o google polymer, gostei bastante deste tutorial no youtube: https://www.youtube.com/watch?v=MaWcS-10NIw&t=1s

[PamelaBeatriz]

@botelhojp no caso a versão 3.0.0- BETA2 está trabalhando com o AngularJS 1.6 usando o ES6 a versão 3.0.0 realese vai trabalhar com Angular 2?

[botelhojp]

Olá @PamelaBeatriz, atualizamos nossos projetos de frontend para o Angular versão 2.3

[cesarrew]

Gostaria de saber se existe algum motivo da biblioteca PrimeNG não ter sido definida como padrão nesta nova versão do framework. Ela é de longe a mais completa, já é bastante utilizada e muito simples de usar. Componentes complexos como datatable com filtro, ordenação, paginação, etc.. são requisitos comuns nas aplicações. Além disso, ela é compatível com boa parte do CSS já feito para quem utiliza PrimeFaces / PrimeUI, evitando um pouco o retrabalho em caso de migrações.

[marcelofns]

Olá @cesarrew , chegamos a fazer alguns experimentos com a biblioteca PrimeNG, realmente ela é bem completa. Porém verificamos que a maioria dos projetos utilizando Angular estavam utilizando o Bootstrap e para manter o CSS compatível optamos por não utilizar o PrimeNG como padrão.

[rogernobre]

Olá @cesarrew, ultima vez que olhei a biblioteca PrimeNG, existia uma refatoração do CSS dos componentes para que ficar totalmente compatível com algumas bibliotecas como o Bootstrap. Sabe se essa refatoração já está concluida?

[botelhojp]

Pesamos o esforço para customizar a camada CSS do PrimeNG, isso foi bem relevante para não utilizarmos neste momento. Caso a identidade visual do sistema não ser importe ou até prefira ter a "cara" do PrimeFaces é uma boa alternativa.