A Page to rule them all - English Version

Can you imagine a web application/site composed entirely of a single page? This is the proposal of the Single Page Interface Manifesto, published recently by Jose Maria Arranz Santamaria.

Driven initially by curiosity, I decided to check out this manifesto. This post summarizes the proposal of the manifest and the discussions that it motivated.

Motivation

The Internet was conceived as a way of sharing scientific papers, which usually contains references to other related documents. Hence its pages and links based nature.

Today the Internet holds much more than scientific documents. The ability to generate content dynamically opened the door for general purpose web applications. Truth be told, today the HTTP protocol is used to support things it definitely was not designed to.

This is why developing for the Web has always been so complex. One can say that a good portion of the evolution of web development occurred in the direction of becoming more like desktop development – which is more simple and natural. In this sense, we saw the emergence of front controllers that "capture" requests for pages that do not exist, creation event-based web frameworks, and extensible use of Ajax for creating more "desktop-like" interfaces.

SPI (Single Page Interface) would be the last step of this journey. The idea is to have a web application running entirely on a single page, just like a desktop application runs on a single main window. This approach would end a series of problems that takes the web developers' sleep away: back button, caching, navigation and forms' automatic completion, just to name a few.

Principles

The main idea behind SPI is replacing the concept of "page" for concept of "state". An application consists of a set of states (primary and secondary) that determine, among other things, the interface to be displayed.

The state control is made through URL references (the final part, which comes after '#'). Any changes in this part of the URL do not cause reloading of the page.

Ajax is a fundamental technology for SPI - without it such approach would be unworkable. In fact an SPI application makes heavy use of Ajax calls to avoid full page reload.

Of course such approach would not go without its criticisms. One can´t ignore the difficulties in integration with search and booking of visits. The manifesto proposes solution to such problems in the form of various Javascrit codes.

Following the paradigm associated with the development of web applications, this new approach could be called model 4.

Conclusion

I consider the SPI idea valid as an alternative approach for individual cases, primarily the ones involving complex interaction with the user - that would result in complex navigation rules on pages based web applications.

The fact that the solutions presented in the manifest consists mostly of "workarounds" exposes the need for maturation of the approach.

Despite the manifest to show the technical feasibility of the approach, much more is needed to gain space in the community: Productivity. There must be frameworks and toolkits that embrace SPI.

After all the idea is quite intriguing. Would that be the future of web development?

The Law of the Leaky Abstraction - English Version

Some time ago, looking for interesting content on the Internet, I came across the excellent article "The law of the leaky abstraction." I liked it so much that I decided to make of it subject of the first post in the Java.lang.Blog.

I recommend everyone to read the article, but briefly, it calls attention to the fact that the abstractions we create in the computer world, whose goal is usually encapsulate determined complexity, end up leaving, under some circumstances, this complexity 'leak' ie, we end up having to deal with the complexity anyway.

Thus, the author proposes the law of the leaky abstraction, set out as follows:

All non-trivial abstractions, to some degree, are leaky.

I will not go into the many abstractions we use in the computing environment. In fact, the article does that very well (Do not miss it!). I would, however, invite readers to reflect on the JEE platform’s abstractions. Are they also victims of the law of leaky abstraction?

I think so. And to illustrate, I’ll cite two examples in the JEE specification key technologies: JSF and EJB. Also, I'm sure the reader will be able to identify other leaks in the JEE platform.

Leaks and Java Server Faces (JSF)

Like most web frameworks, JSF tries to disregard the "details" pertinent to the development of such applications, such as form submission and type conversion. The framework would have us believe, for example, that you can simply associate a method or property on a managed bean (server-side) at the click of a button or value of an input interface (client side).

Although laudable, this abstraction is subject to leakage. What happens when the property in the managed bean is not a String? Some conversion is necessary. And what if this conversion fails for some reason? If the user decides to type "fg%# 4" in an input field connected to an Integer in the managed bean property? Unless the developer has instructed the framework how to notify this type of failure, the user will remain clicking on the submit button and the same page will remain being re-rendered as no method will be called on the server side at all. Realize the leak?

The developer must now infiltrate the complex JSF life cycle and understand, in this potentially new context, how the framework handles conversions and how to handle possible failures.

Leaks and Enterprise Java Beans (EJB)

Despite having gone out of vogue in recent times, one of the central issues of EJB technology is support for distributed systems. Even when running on a remote machine, EJB clients are able to call these components as if they were local. The complexity of the remote method call (RMI) is therefore abstracted by this technology.

This abstraction, however, is also subject to leakage - and in a very subtle way: parameters to methods calls on a remote EJB must be serializable. That's because these objects must travel through the network, being rebuilt on the remote machine that trully houses the EJB component. Thus, the fact that the EJB component is remote becomes apparent as the parameters to its methods are required to be serializable, featuring the leak.

Remember that this leak was more visible in the earliest versions of the specification, when an EJB client was required to deal with checked exceptions related to remote calls (RemoteException and subclasses). This aspect has been improved from version 3.0, replacing the checked exceptions with unchecked equivalents.

Consequences

Some consequences of the law of the leaky abstraction:

1. Abstractions do not help us much as we imagine. In an environment that so constantly refers to this feature, this is something important to keep in mind.
2. Paradoxically, the more layers of abstraction are created to simplify the development, the more difficult becomes the task of becoming a proficient developer. This is perhaps the most intriguing result. Will the efforts to simplify the development on the Java platform would be having the opposite effect than expected?
3. Be wary of tools that promise, as in magically, simplified development and multiply the productivity of the team (code generators, someone?). The abstractions in which these tools are based could leak and when that happens, often the cost is quite high.

A Page to rule them all

Você é capaz imaginar uma aplicação web/web site composto inteiramente de uma única página? Esta é a proposta do Single Page Interface Manifesto, publicado recentemente por Jose Maria Arranz Santamaria.

Movido inicialmente pela curiosidade, resolvi conferir o tal manifesto. Este post resume a proposta do manifesto e as discussões que ele motivou.

Motivação

A internet foi concebida como uma forma de compartilhar documentos científicos, que comumente contém referências para outros documentos relacionados. Daí sua natureza baseada em páginas e links.

Hoje a internet abriga muito mais que documentos científicos. A possibilidade de gerar conteúdo dinamicamente abriu as portas para aplicações web de propósito geral. Verdade seja dita: hoje o protocolo HTTP é usado para suportar funcionalidades para as quais definitivamente não foi planejado.

Por este motivo desenvolver para a web sempre foi demasiadamente complexo. Pode-se afirmar que toda evolução do desenvolvimento web se deu no sentido de tornar-se mais parecido com o desenvolvimento desktop - mais simples e natural. Neste sentido, vimos o surgimento de front controllers que "capturam" requisições para páginas que sequer existem, criação de frameworks web baseados em eventos, e uso extensível de Ajax para criação de interfaces mais "desktop-like".

SPI (Single Page Interface) seria o último passo desta jornada. Seria possível ter uma aplicação web rodando inteiramente em uma única página- exatamente como uma aplicação desktop roda em uma única janela principal. Esta abordagem acabaria com uma série problemas que tira o sono de desenvolvedores web: back button, caching, navegação e preenchimento automático de formulários só para citar alguns.

Princípios

A principal idéia por trás de SPI é a substituição do conceito de página pelo conceito de estado. Uma aplicação é composta por um conjunto de estados (primários e secundários) que determinam, entre outras coisas, a interface a ser exibida.

O controle dos estados é feitos através das referências da URL (a parte final, que vem depois do '#'). alterações neste trecho não causam recarga da página.

Ajax é a tecnologia fundamental para SPI - sem ela esta abordagem seria inviável. De fato uma aplicação SPI faz uso intenso de chamadas Ajax para evitar recarga completa da página.

Entre as críticas a SPI, encontramos dificuldades de integração com sistemas de busca e de contabilização de visitas. O manifesto propõe solução para tais problemas na forma de diversos códigos javascrit.
Seguindo o paradigma associado a evolução das aplicações web, esta nova abordagem poderia ser chamada de model 4.

Conclusão

Considero a idéia SPI válida como abordagem alternativa em casos particulares, fundamentalmente que envolvam iterações complexas por parte do usuário - que resultariam em regras de navegação complexas em aplicações baseadas em páginas.

O fato das soluções apresentadas no manifesto constituírem-se majoritariamente de "workarounds" mostra a necessidade de maturação da abordagem.

Apesar do manifesto mostrar a viabilidade técnica da abordagem, é preciso muito mais para ganhar espaço na comunidade: é preciso produtividade. É preciso que surjam frameworks e toolkits que abracem SPI.

Apesar de tudo a idéia é bastante instigante. Seria esse o futuro do desenvolvimento web?

The Law of the Leaky Abstraction

Algum tempo atrás, buscando conteúdo interessante na internet, me deparei com o excelente artigo “The law of the leaky abstraction”. (lei da abstração sujeita a vazamentos em uma tradução livre – por falta de termos mais adequados, decidi usar a expressão na língua inglesa ao longo do texto.) Gostei tanto, que resolvi fazer dele tema do primeiro post no Java.lang.Blog.

Recomendo a todos que leiam o artigo, mas resumidamente, ele chama atenção para o fato de que as abstrações que criamos no mundo da informática, cujo objetivo em geral é encapsular determinada complexidade, acabam deixando, sobre determinadas circunstâncias, esta complexidade “vazar”, ou seja, acabamos tendo que lidar com a complexidade anyway. 

Desta forma, o autor propõe a law of the leaky abstraction, enunciada da seguinte forma:

“Toda abstração não trivial é, em certo grau, sujeita a vazamentos”

Não vou entrar aqui nas inúmeras abstrações das quais fazemos uso no ambiente da computação. De fato, o artigo faz isso muito bem (Não deixem de ler!). Gostaria, no entanto, de convidar os leitores a refletir sobre as abstrações que temos na plataforma JEE. Seriam elas também vítimas da law of the leaky abstraction?

Penso que sim. E para ilustrar, vou citar exemplos em duas tecnologias chaves da especificação JEE: JSF e EJB. Além disso, tenho certeza que o leitor será capaz de identificar outros “vazamentos” na plataforma JEE.

“Vazamentos” e Java Server Faces (JSF)

Como a maioria dos frameworks web, JSF tenta abstrair “detalhes” pertinentes ao desenvolvimento deste tipo de aplicações, como submissão de formulários e conversão de tipos. O framework quer nos fazer crer , por exemplo, que é possível simplesmente associar um método ou uma propriedade em um managed bean (server-side) ao clique de um botão ou valor de um input na interface (client-side).

Apesar de louvável, esta abstração é sujeita a “vazamentos”. O que acontece quando a propriedade no managed bean não é uma String? Alguma conversão é necessária. E se esta conversão falhar por algum motivo? Se o usuário resolver digitar “a#4%fg” em um input associado a uma propriedade Integer no managed bean? A não ser que o desenvolvedor tenha instruído o framework como notificar este tipo de falha, o usuário permanecerá clicando no botão e a página seguirá sendo re-exibida pelo browser. Nenhum método de nenhum managed bean é chamado no server-side. Perceberam o “vazamento”?

O desenvolvedor agora deverá infiltrar-se no complexo ciclo de vida JSF e entender, neste contexto potencialmente novo, como o framework processa conversões e como lidar com possíveis falhas.

“Vazamentos” e Enterprise Java Beans (EJB)

Apesar de ter saído de voga nos últimos tempos, uma das questões centrais da tecnologia, EJB é o suporte a sistemas distribuídos. Ainda que estejam rodando em uma máquina remota, clientes EJB são capazes de fazer chamadas a estes componentes como se fossem locais. A complexidade envolvida na chamada de método remota (RMI) é, portanto, abstraída pela tecnologia.

Essa abstração, no entanto, também é sujeita a "vazamentos" – e de uma forma bastante sutil: parâmetros as chamadas dos métodos de um EJB remoto devem ser serializable. Isso porque estes objetos deverão trafegar pela rede, sendo reconstruídos na máquina remota que abriga, de fato, o componente EJB. Desta forma, o fato que o componente EJB é remoto transparece na necessidade dos parâmetros de seus métodos serem obrigados a ser serializable, caracterizando o "vazamento".

Vale lembrar que este "vazamento" era mais visível nas primeiras versões da especificação, quando o cliente de um EJB era obrigado a tratar exceções checadas relacionadas a chamadas remotas (RemoteException e subclasses). Esse aspecto foi melhorado a partir da versão 3.0, substituindo as exceções checadas por equivalentes não checadas.

Consequências

Algumas consequências da law of the leaky abstraction:

1) Abstrações não nos ajuda tanto como imaginamos. Em uma ambiente onde se recorre tão constantemente a este recurso, isso é algo importante de se ter em mente.

2) Paradoxalmente, quanto mais camadas de abstração são criadas visando simplificar o desenvolvimento, mais difícil se torna a tarefa de se tornar um desenvolvedor proficiente. Esta talvez seja a consequência mais intrigante. Será que os esforços no sentido de simplificar o desenvolvimento na plataforma Java estariam tendo o efeito oposto do esperado?

3) Desconfie de ferramentas que prometem, como em um passe de mágica, simplificar o desenvolvimento e multiplicar a produtividade da equipe (alguém falou em geradores de código ai?). As abstrações nas quais estas ferramentas se baseiam certamente iram "vazar", e quando isto acontece, muitas vezes o custo é bastante alto.