JSF possui inflexibilidade

Acho que uma das piores infelicidades na vida de desenvolvedor talvez seja realizar que, talvez, uma coisa que você gostaria de desenvolver muito pode estar fadada ao fracasso por inflexiblidade.

Vou explicar.

Eu comecei recentemente um projeto de construir um pequeno E-commerce, inclusive, projeto está configurado e também com um conjunto de issues bem bacana para me ajudar no desenvolvimento.

Eis que decido usar apenas o arsenal que o Java EE me proporciona para desenvolver isso, incluindo o, temido por alguns, JSF.

Para quem não sabe, JSF é um framework de UI muito poderoso, que abstrai muito do ajax da parte de client side fazendo com que foquemos somente em aplicar as regras de negócio utilizando somente Java (+ a adição de algumas sintaxes e regras de UI).

Mas como o JSF funciona?
Sendo simplista aqui, você vai montar sua UI utilizando xhtml, juntamente com tags que são adicionadas sob os namespaces declarados no JSF.

Além disso, você tem classes que suportam essas páginas, fornecendo dados e lógica.

Quando pensei no e-commerce como um projeto, uma das coisas que visualizei seria: ora... eu tenho que montar componentes para que possa reusar na aplicação.

Daí tive uma ideia de montar uma ferramenta que já é utilizada bastante no mundo frontend: um storybook.

Porém esse storybook não poderia ser qualquer coisa. Deveria ser, de forma fácil, para visualizar e experimentar com composite components e custom UIElements, confesso que mais para composite components do que para um elemento customizado. Minha divagação começa aí.

Primeiro, como montar componentes que sejam independentes, onde só preciso vir com uma lógica por cima deles?

Acontece que, para o caso do JSF, o componente fica muito amarrado a sua backing bean e separado ao mesmo tempo.

O .xhtml fica na pasta resources e a backing bean fica no java, e por "mágica" o JSF cola os dois. Eu vejo isso como uma certa inflexibilidade.

Uma possível solução seria utilizar injeções com interfaces para que essas provenham uma lógica e empacotar tudo.

Porém você resolve uma inflexibilidade e adiciona outra, pois, caso precise mudar alguma coisa em algum componente, teria que rebuildar e refazer um .jar. Imagine agora no seu projeto que seus componentes estejam em um jar separado...

Outra coisa, para adicionar esses componentes no storybook hipotético, não poderia simplesmente colocar o código. Você tem que juntar uma backing bean com um .xhtml. Você faz isso empacotando eles. Então, um jar de dev pra ser visto em outro jar? Não me pareceu boa ideia.

Voltando ao problema das interfaces injetáveis, também não me parece boa ideia de fato, pois imagine que num projeto você tenha mais de uma implementação de uma interface (e espero que sim). Como decidir qual vai ser injetada? Lembre-se que JavaEE possui injeção de dependencia

E não é somente coisa de possuir, é pattern consolidado.

E assim, pensando nisso tudo, mais uma ideia não vinga.