LEAF - Light and Extensible Apps Framework

This message was edited 5 times. Last update was at 20/03/2010 22:06:38

.
E aí pessoal, tudo bem?!
Eu sou Leonardo Dutra, brasileiro, carioca e apaixonado por desenvolvimento (depois da minha mulher, é claro). Apresento a vocês um projeto que venho fazendo com muita atenção, estudo e pesquisa já há pouco mais de 1 ano, nas horas vagas. O projeto se chama LEAF - Light and Extensible Apps Framework, em inglês para entendimento global - e sim, é um framework para JavaScript. Mas o objetivo do framework LEAF não é ter milhares de funcionalidades como é de se esperar das mais famosas bibliotecas e frameworks para JavaScript, mas resolver o que coloco como problemas para qualquer projeto do tipo. Simplicidade do código e, principalmente, performance.

Os projetos mais famosos pretendem sempre atender ao maior número de possibilidades, começam pequenos e vão crescendo... mais funções, mais "classes" e mais bytes a serem transferidos. Sim, elas são feitas de forma a manter o mínimo de tamanho pra tudo isso... mas a que custo?

Sabendo que o JavaScript é mais orientado a objeto que o Java (até null e funções são objeto e as "classes" são dinâmicas - prototypes), interpretado e loose (sem tipagem e com vários tipos construção com funções), é fácil compreender também que é uma linguagem lenta. O parser interpreta o JavaScript como ao HTML. Um processo lento e que faz com que animações e outras necessidades de RIAs (Rich Internet Apps) sejam de difícil produção, gerando quase sempre animações com flicks e travadas.

O JavaScript utiliza a API Document Object Model (DOM) para controlar o HTML com o princípio da orientação a objeto, e o DOM está presente na maioria dos navegadores e agentes de execução. Porém as implementações não são totalmente iguais e apesar da maioria das funções estarem de acordo, outras são a catástrofe de aplicações em que a compatibilidade é uma característica essencial. Os frameworks em JavaScript corrigem isso, mas não com um empenho carinhoso para obter a melhor performance possível, e isso é importante já que muita coisa é construída "em cima" destes frameworks. Isso levado a níveis maiores ajuda a depreciar a execução de aplicações ricas.

Criei um estrutura simples para o LEAF. Tão simples que o intellisense do Aptana Studio, que apesar de genial e moderno tem problemas para apresentar bibliotecas emaranhadas, apresenta a LEAF para facilitar a codificação sem necessidade de nenhum plugin. E essa construção acabou por funcionar muito bem também no Adobe Dreamweaver CS4 e no plugin JSEclipse, entre outros que não me recordo agora. O mais importante é que a estrutura simples corrige incompatibilidades (principalmente do IE 5.5+) mantendo o máximo de performance possível (isso deu um trabalho brutal, apesar de parecer simples. Centenas de testes e melhorias antes mesmo de levar ao Google Code).

Então, o LEAF é atualmente simples e com uma excelente estrutura de dados e organizacional. Usa o "javascript namespace" leaf e é nativamente identificada pelos melhores intellisenses pra JavaScript. Não há funções sobrecarregadas com diversos tipos de entrada e retorno, não será incluso seletor de CSS (recomendo o uso da MooTools, YASS ou Sizzle) e qualquer implementação de audio ou canvas será separada... ficando no pacote principal a já excelente correção de compatibilidade e a veloz manipulação de DOM, usando o ElementHandler. A maioria vai ver que à semântica foi dada um bom espaço ao custo de alguns poucos bytes a mais, isso deixa a LEAF muito parecida com a API nativa de flash para ActionScript 3 e com implementação Java. Nada de chains do tipo "$().border().background().bla bla bla". É bonitinho, mas força você a olhar a referência para cada um dos métodos da cadeia (ou decorar), quais têm 1000 entradas, retornos e funcionamentos implícitos. Além de depreciar a performance isso atrasa o seu trabalho de desenvolvimento e faz seu gerente preparar as chuteiras. O intellisense já te agiliza muito, e ainda mais quando o ScriptDoc estiver pronto e deixando a referência ainda mais completa.

Dêem uma olhada no site do projeto, e se possível no código. Vai perceber que as funções apesar de pequenas têm o mínimo de tempos constantes e variáveis possíveis para um código ótimo e compatível. Afinal, ela terá de ser uma espécie de core para gadgets e apps, online ou para smartphones... e até outros frameworks. Ainda é alpha, mas fiz testes primários e avulsos, além de revisar e "benchmarkar". Então você pode testar e usar em projetos pessoais, reportando os bugs pra que sejam corrigidos rapidamente. O uso comercial ainda não é recomendado enquanto não houver um alpha estável, mas é só uma recomendação.

Obrigado pela atenção, um abraço!

http://leaf.googlecode.com
.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

LEAF, or Light and Extensible Apps Framework*, is a new and open JavaScript project. Created to ease the development of web, Adobe AIR*, IPhone* and IPod* apps...

Quando se refere ao iphone quer dizer aplicações web ou nativas? Nao ficou muito claro.

Em se tratando de web apps que eu imagino que seja, o que tem de especial em rodar no iphone ja que o browser dele é o mesmo usado pelo safari e google chrome?

This message was edited 4 times. Last update was at 20/03/2010 22:09:49

Sim, é em realação à web apps... ou nativas, desde que baseadas em HTML.

O especial é que o Aptana tem todo um pacote de desenvolvimento para o IPhone. O intellisense da LEAF é bem conduzido nas IDEs mais famosas, e espero futuramente adrentar mais o universo de desenvolvimento do IPhone, você poderá criar uma aplicação rica para o Chrome ou IE 5.5+ e ter a garantia que esta vai funcionar sim no IPhone... já que a engine é a mesma, mas com a melhor performance possível. Em cima disso podem surgir plugins para alteração do comportamento quando for identificado o IPhone como sistema final e outros pontos de inovação. Mas a performance é que espero ser o ponto forte depois da compatibilidade até com IE 5.5 (enquanto isso não virar passado realmente).

This message was edited 1 time. Last update was at 20/08/2009 13:54:25

No JavaScript com poucos "ifs" dá pra saber se o sistema final é o IPhone e a partir daí fazer diferentes interações. Esse é o legal dela usar bem o DOM.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Eu acho trabalhar com JavaScript um saco portanto parabens pela iniciativa de querer melhorar essa situação. Mas porque alguem escolheria o LEAF ao inves do Jquery por exemplo?

Muito boa sua iniciativa cara.
Sou um amante do javascript também.

Dê uma checada no meu projeto. Ainda esta em desenvolvimento mas já tem bastante coisa. E quem sabe não podemos fazer uma parceria.

http://code.google.com/p/jsool/

This message was edited 6 times. Last update was at 20/03/2010 22:10:58

Boa! A JSOOL está com bastante código pronto. Só queria lhe alertar para os namespaces muito grandes.
Por uma boa prática, nova e evidenciada pela Prototype, MooTools, Adober AIR JS library (esta principalmente, pois é muito bem modelada... e pelo Aptana podemos ver bem) e outras libs... o comum é um namespace curto. Isso porque existem pessoas excêntricas quanto ao tamanho de libs, mesmo na era da banda larga.

Eu comecei a desenvolver usando um namespace do tipo alias.dom.Element (chamava "Alias"... há um ano atrás, antes da abertura do o código). Mas mudei de idéia depois de ver a formatação pricipalmente do air... afinal, temos o grupo de pessoas que não usa intellisense ainda, devido ao acesso (conhecer) às ferramentas com um bom intellisense para JavaScript.

O mesmo se aplica à tratamento de erros. Muito cuidado com eles pelo tamanho que vão gerar no código e pela lentidão de "try... catch" no JavaScript.
É uma estrutura lenta e um simples benchmark mostra que é quase 100 vezes mais lento que um if. A LEAF terá um tratamento de erros... parecido com o de algumas libs conhecidas. Um pacote da lib terá "try... catchs" simples e o principal não. Assim, você pode debugar quando quiser e remover o tratamento quando não lhe importar.

Coloque também a licença em cada arquivo do seu trunk, que é uma boa prática e salvadora... segundo a Open Source Organization.

O andamento da LEAF é lento... pois tenho que otimizar ao máximo cada função. Ajuda é sempre vem vinda. E sim, uma parceria seria incrível.
Vamos chutar fora o DWR, que é um lixo para qualquer um que saiba o mínimo de JavaScript (de cara, DWR faz "eval" - "eval is evil").

Obrigado pelos comentários.

O código do JSOOL é focado, em grande parte, em performance. Estudei muito sobre performance do javascript e fico horas tentado deixar cada função cada vez mais rápida.

Pelo fato da biblioteca ser bem focada a orientação a objetos, e isso não ser um recurso tão fácil de implementar com javascript, estou estudando a possibilidade de construir um compilador simples para facilitar com o desenvolvimento.

Me manda uma mensagem eu eu te ajudo com muito prazer cara.

This message was edited 1 time. Last update was at 17/12/2009 17:00:46

LEAF v0.8 sairá dentro de alguns dias. Vou lançar um alpha estável para quem quiser poder usar sem problemas.

LEAF versão alpha 0.8.1 disponível
http://leaf.googlecode.com

This message was edited 1 time. Last update was at 27/08/2009 03:39:16

Obrigado ao pessoal que baixou a 0.7 alpha!

This message was edited 3 times. Last update was at 20/03/2010 22:11:43

Mochuara, a JQuery tem 3 aspectos que acho bem problemáticos:

1. o código interno é um JavaScript muito apoiado em reuso de funções, como disse, com mil entradas e mil saídas. Isso deixa o código menor porém degrada, significativamente, a performance. Estamos entrando na era da banda realmente larga e já não se acredita mais neste probleminha de alguns Kb. Mesmo assim a LEAF será sempre uma das menores;

2. o pessoal da JQuery, e o John Resig, resolveram alguns bugs com fixes que visam apenas browsers antigos. Ocorrerão problemas futuros devido a este esquema de POG aparentemente brilhante. E espere muito por uma 2.0. Eles estão ferrados se não tiverem excelentes documentos e modelo do ninho de rato mais querido do mundo;

3. a LEAF pretende ser uma base pra outras libs JavaScript. A minha pretensão não é competir com a JQuery (até porque no status atual, isso é tarefa pra Google... não pra mim com meia dúzia de pirados). O que eu quero é que Gadgets e libs pra Gadgets, libs pra IPhone e para a Web usem a LEAF apenas como um core... um DOM perfeito e "cross compatible". Fazendo isso da maneira ótima, com uma estrutura de dados também ótima.

Então, se você é bom em JavaScript, quer fazer uma lib pra sua empresa ou pelo menos fazer um script bem enxutinho apenas com os fixes e utilidades realmente úteis e que não vão aumentar o limbo de métodos vagabundos pela sua app... use a LEAF. A MooTools também é boa e você fragmenta o código pelo que vai usar. Mas a LEAF é brzona e aberta a idéias, mesmo!

Acabei de liberar a LEAF versão 0.8.3 alpha (compacted, quase estável). Quem quiser ajudar, pode testar usando o Aptana ou Dreamweaver (já que eles facilitam o uso sem documentação) e postar no tracker do site do projeto em "issues".

This message was edited 3 times. Last update was at 17/12/2009 17:03:06

Lançada versão 0.8.5 alpha. Muitas mudanças para melhor. Os métodos que forçam compatibilidade são construidos em tempo de carregamento, com uma implementação parecida com o "#ifdef" do C e C++. Controle melhorado de elementos no ElementHandler e outros detalhes de implementação.

Abraço

http://leaf.googlecode.com

Lançada a versão 0.8.8 alpha com muitas melhorias e correções.

Notícias, artigos e o maior fórum brasileiro sobre Java