Model de components per la web
A la llista de discussió de Django hi ha un fil força interessant anomenat Ajax support, there is no need for reinventing the wheel. La cosa va de si és necessari que hi hagi una llibreria d'Ajax dins del bastiment o no.
Qui inicia el fil és partidari de que sí, de que hi hauria de ser, i que es podria copiar el que ja hi ha a altres bastiments, com Ruby per exemple, tot i que algunes opnions consideren que la implementació de RoR és un poc nyap, ja que facilita un disseny pobre de l'aplicació.
Particularment me pareix que l'opció més assenyada és la de no fer la integració amb un bastiment determinat, començar amb un disseny de l'aplicació clàssic, accessible per tots els navegadors, i després anar incorporant les característiques d'usabilitat basades en AJAX, DHTML, fulles d'estil, etc. que millorin l'experiència als nostres usuaris.
En el fons d'aquest fil, però, hi ha dos conceptes, dues preguntes, que podriem tractar per separat
- Davant les noves tecnologies, els nous corrents de pensament en pogramació, quin hem de triar?
- La programació web s'ha d'assemblar cada cop més a la programació de client gruixat, on hi ha components que ho encapsulen tot? Es a dir, encapsular HTML+css+javascript+connexió al servidor és el futur?
La primera pregunta ve de la por a equivocar-se, de triar una opció que després no sigui la majoritària. Davant això hem de recordar que el millor que té la web és que el llenguatge no importa, la tecnologia que hi ha darrera no importa, el que importa és el que veu l'usuari final i la compatibilitat que tengui la nostra aplicació amb el màxim nombre de navegadors. Així doncs, que la opció que triem resulti que no és la majoritària no té perquè afectar negativament a la nostra aplicació, sempre que tinguem la capacitat d'evolucionar-la. En aquests moments, la capacitat d'elegir marca el que l'aplicació pugui estar al mercat abans, el time-to-market import molt més que el risc de triar el bastiment o la llibreria incorrecta.
El no saber què elegir no ens ha de paralitzar. Es bo triar i remanar, provar distintes opcions i triar aquella que més ens agradi, que més s'adapti al nostre estil de feina o a la filosofia de l'empresa per la qual treballam. En tecnologia no hi ha res segur, i per tant, sempre hi ha el risc que d'aqui un parell de mesos surti quelcom millor que el que hem triat. L'elecció de tecnologies fonamentades en programari lliure minimitza el risc de la tria, ja que sempre tendrem el codi font i aplicar les millor nosaltres mateixos si cal.
L'altra punt d'interés és el de l'encapsulació, la componentització de la web. Això és quelcom que la gent que fa portlets de Java fa als portals. El perill és que es perd part de la flexibilitat que ens dona la programació clàssica, i es posa un nivell d'abstracció, que com comenten de RoR pot fomentar les males pràctiques de programació.
També s'ha de tenir en compta que a la web, a més d'usabilitat i aplicacions hi ha una part molt important de disseny. Aquesta part, la part de presentació, en la majoria de bastiments actuals està clarament separada de la part de negoci. El dissenyador no té perquè conèixer res més enllà del llenguatge de plantilles que es farà servir, i en tot cas, del nom de les variables que se li passaran i el seu tipus.
L'encapsulació d'html+javascript+css dins un component, de manera que es generi tota la part de presentació a partir del component, té però avantatges indubtables per a una empresa. Una vegada establerta l'aparença dessitjada i sempre que no volguem disseny, tendrem un mètode ràpid per a fer aplicacions, de la mateixa manera que es fan al clients gruixats. Estam sacrificant, però la part visual davant la part funcional. Això pot estar bé en entorns empresarials, però limita força la creativitat.
Aquesta conversió a model de components ja la podem trobar a alguns bastiments actuals, implementats amb major o menor fortuna i amb diferents graus d'implementació
Alguns d'aquests bastiments són impressionants, però tenen el perill de que les nostres aplicacions web s'acabin assemblant totes, encara que això no té perquè ser dolent.
Així doncs, hem de tirar cap a la componentització o cap al model actual amb les millores ad-hoc que necessitem. La resposta és: depén.
Si us dedicau a fer apliccions web de manera professional i per a diferents clients i aquestes han d'estar accesibles a través d'Internet per un gran públic ara per ara tiraria cap a la no componentització. Si pel contrari feim apliccacions web pel client intern on el públic pràcticament no hi tendrà accés i la uniformitat no és un emperò sinó una virtud, la componentització ens pot estalviar molta feina i fer-nos molt més productius.
Si ens atracam per primer cop a la programació web, el model de component ens pot abstreure massa que el que feim al cap i a la fi són pàgines web en HTML , CSS i Javascript, i que encara que tirem per la componentització convé no oblidar-ho. Després haurem de veure si els emperòs del model en els aspectes d'arquitectura del programari i flexibilitat en quant al disseny, són compensats per la major velocitat de programació.
