L'azienda ha deciso recentemente (con generale e persistente rammarico di tutti) di abbandonare lo sviluppo di
RIA su piattaforma
ASP .NET e di migrare verso altri misteriosi e minacciosi net-lidi.
Hallelujah. ;-)
Cercando di scrollare di dosso la ruggine ho quindi rastrellato il web alla ricerca del miglior mix di tecnologie correnti per lo sviluppo di front-end web avendo in mente questi obiettivi:
- parallelizzazione design/development
- rapidità di implementazione
- scalabilità
- riuso
- flessibilità
- compatibilità cross-browser
E la mia salute mentale ha vacillato...
Troppi framework, troppi componenti, troppe librerie, TROPPO di tutto!
Ma alla fine (forse) ho trovato un approdo.
Grazie anche al pregevole tentativo di metter ordine da parte di
BoilerPlate e
Initializr.
Qualche appunto sul percorso fatto...
Pattern
Forti della solida e gratificante esperienza sul paradigma
MVVM maturata con WPF/Silverlight, non potevamo rinunciare alle potenzialità di questo modello, soprattutto nella separazione delle professionalità... ma non solo.
E quindi abbiamo optato per l'incredibile framework
KnockOut, dribblando il diffusissimo (e pur potente ed efficace)
ASP.NET MVC.
Razor resta
relegato, eventualmente, al semplice assemblaggio delle pagine nelle composite application e al modello di navigazione.
C'è un contro...
Il pattern MVVM mette in crisi l’applicazione di alcuni comportamenti di UI, soprattutto quando vengono iniettati in modo asincrono frammenti del DOM (per esempio con i template): quando accade cosa?
E quindi? Implementare un’instrumentazione nel “code-behind” delle view?
Funziona, ma non è una soluzione particolarmente performante e snella.
Pare molto più compliant al pattern ed efficace l’uso di
custom bindings di KO, come quelli, per esempio, già disponibili in rete per jQueryUI (
qui e
qui).
Non affronto intenzionalmente il tema dell'accesso al datamodel: non è mia competenza.
UI Components
jQueryUI pare scelta obbligata.
Ma....
Trovo che soffra di una certa
legnosità, che conti troppo sulla stesura di codice javascript per l'implementazione e troppo poco sul markup, che sia poco moderno nell'aspetto e ostico da customizzare, che sia ancora molto incompleto nella dotazione di serie.
Ok, ci sono zillioni di plugin, ma il rischio è di perdere in uniformità e di riempire l’applicazione di scripts).
L'alternativa:
Twitter Bootstrap.
Pulito, versatile, leggero, veloce, completo,
smart.
La maggior parte dei componenti viene istanziata nel markup con la semplice applicazione di classi CSS predefinite
CSS
Trovo molto interessanti
Sass e
LESS: entrambi estendono il CSS portandolo al livello di un vero e proprio linguaggio di programmazione dinamico e superando le sue rigide limitazioni (per esempio l'impossibilità di utilizzare variabili).
[Ci sono anche Stylus, CSSCrush, CleverCSS, HSS, XCSS e ilMioCSSèpiùBellodelTuo... e via così...]
Questo obbliga a
compilare i sorgenti scritti con queste sintassi per ottenere un output compatibile con il vero CSS. E' possibile farlo in fase di deploy o al volo su web server.
Quale dei due preferire (
qui,
qui e
qui a confronto)?
Sono molto simili, ma LESS offre in più:
- javascript DENTRO il css
- compilazione on-the-fly sul client via javascript (può essere utile in fase di sviluppo)
- è usato in Bootstrap
Sass ha dalla sua un compagno usatissimo:
Compass, che agevola il mixin soprattutto per quanto riguarda il CSS3.
Però per LESS si trova una tonnellata di mixins già pronti come
Less Elements o
-lessins-.
Il contro di questi processori è che non si può fare (ancora) editing WYSIWYG dei CSS, ma credo che con un po’ di fatica in più si possa lavorare di cut&paste dall'ottimo
Stylizer.
Per concludere, ecco il nostro
kit:
Ah, poi si sono SproutCore, Wijmo, Kendo UI, ecc...
Ma bastaaaaa! ;-)