Dev approcci a complessi dell'interfaccia utente JavaScript [chiusa]

La maggior parte delle app Web che vedo (e gli sviluppatori Web con cui ho parlato) che si stanno muovendo in questa direzione utilizzano jQuery come base.

L'intero ragionamento alla base di GWT (e di linguaggi multilivello simili) è che JavaScript è troppo flakey / troppo fragile / troppo mutevole per essere utilizzato dai "veri programmatori". Ma se hai un framework che gestisce i bit flakey / fragili / mutevoli per te, allora non c'è motivo di aggiungere un ulteriore livello di complessità.

Solo la mia opinione ...

Direi che GWT è rischioso. Una volta che hai deciso di usarlo, sei bloccato con esso. Fondamentalmente significa che tratti il tuo markup, DOM e alcuni aspetti del CSS come ambiente di esecuzione. Sta diventando davvero difficile mescolare JavaScript scritto manualmente con GWT mentre il codice client diventa sempre più sofisticato. GWT ha metodi nativi, ma quelli sono abbastanza limitati in termini di possibile applicabilità. Questo è un grande scambio ed è una grande scommessa.

Google cerca di vendere GWT come un ambiente di esecuzione della piattaforma X molto veloce con una discreta integrazione lato server. Ma come già sottolineato da altri, non è più il caso: JQuery e YUI sono altrettanto veloci se non più veloci. Ed è molto più facile profilare e ottimizzare le tue pagine quando vengono assemblate manualmente in modo da avere il pieno controllo su CSS, markup e JavaScript.

GWT cerca di nascondere la piattaforma sottostante da te che potrebbe essere in realtà un modo sbagliato di fare le cose. Un sacco di cosiddetti componenti web framework hanno fatto lo stesso. Dovevi scrivere un codice ambiguo derivato da XML con EL e tag personalizzati inseriti. L'output sarebbe un casino di HTML mal formato con piccoli pezzi di crappy JavaScript sparsi ovunque. Le pagine erano lente, buggy e totalmente non gestibili.

Nel nostro progetto attuale usiamo Stripes - un framework basato su azioni di basso livello, - e JQuery su un lato client. È molto facile fare Ajax una volta che vedi chiaramente tutti i pezzi di un puzzle: ecco il tuo codice lato server che opera sui dati. Ecco il tuo codice lato client - per il recupero dei dati e per far accadere le cose su una pagina. Ecco il tuo CSS, ecco il tuo markup, ecco il tuo template - tutto è pulito e disaccoppiato. Facilmente estensibile, hackable, sintonizzabile e debugabile. Lo adoro.

Adoro JQuery con il suo atteggiamento verso la velocità e la semplicità. Adoro YUI3 per modularità e widget completi. Adoro i CSS di YUI per darmi coerenza tra i vari browser. Adoro JavaScript per Good Parts. Adoro Java per avermi fatto fare un lavoro.

Solo KISS, e starai bene!

Ho sentito queste chiamate "Applicazioni a pagina singola".

Questo è un nuovo ambiente e le regole non sono ancora completamente scritte. Ho lavorato a un'applicazione a pagina singola relativamente importante l'anno scorso (2010), e questi sono gli strumenti che abbiamo usato.

Il back-end era Java, che utilizza servlet per fornire un servizio JSON, che la pagina usava per inviare l'ordine preparato alla fine. Questo servizio è stato utilizzato anche per alcuni passaggi di convalida e prezzi.

Il codice front-end era javascript. Abbiamo utilizzato jQuery per manipolare gli elementi della pagina, Pure per i modelli e RequireJs per suddividere il codice in moduli. (È stato utilizzato lo strumento di compilazione di RequireJs per fornire download più ottimali.)

Abbiamo scritto i nostri test utilizzando qUnit e abbiamo avuto un test jUnit che utilizzava htmlunit per eseguire ogni test qUnit, quindi raschiare l'output per i risultati e passare o fallire in base allo stato qUnit pass / fail. Questi sono stati aggiunti ai nostri test jUnit per il back-end e sono stati inseriti nel nostro ci, utilizzando Hudson / Jenkins .

Lavoro su questa app, costruita su Ext JS. L'app è organizzata in modo modulare. Diversi moduli vengono implementati come componenti autonomi che si puliscono da soli quando vengono rimossi dalla gerarchia del componente Ext. I caricatori su richiesta caricano componenti aggiuntivi prima che siano necessari (un file js = un componente).

Ho scoperto che questo approccio non è così difficile da scalare. Gli unici limiti reali che ho incontrato sono legati all'eccessiva presenza di troppi elementi DOM nell'albero in IE. La soluzione è quella di scaricare strategicamente parti nascoste dell'applicazione. Poiché tutta la manipolazione DOM avviene tramite la gerarchia di componenti Ext, il DOM è quasi completamente estratto e lo sviluppo rimane semplice.

Personalmente ritengo che i framework come jQuery siano vitali non solo per gestire le variazioni tra diversi browser, ma anche per eliminare quelle differenze in modo che non aggiungano rumore al codice. Strumenti come GWT, Websharper e altri lo fanno più lontano e sicuramente hanno un posto, ma mi chiedo se nella maggior parte dei casi si tratti solo di un ulteriore livello di riferimento indiretto .

Qualcosa che mi ha sorpreso che nessuno ha menzionato è il test unitario. È ormai generalmente accettato che le complesse applicazioni lato server debbano avere test unitari automatizzati e penso che sia già arrivato il momento in cui il JS nelle app RIA è abbastanza complesso da richiedere un test unitario - insieme all'architettura / codice che lo rende possibile.

Tuttavia, a differenza delle complesse applicazioni lato server, la mia sensazione istintiva basata su ciò che vedo e sento è che la maggior parte delle complesse app lato client non ha assolutamente test di unità (non sto parlando di test sul selenio qui, unità reale test).

Penso che la prossima tendenza emergente sarà l'introduzione del test unitario (e il codice che è unit-testabile). Avendo appena completato un progetto con una quantità moderata di JavaScript non testato unitamente, spero che sarà l'ultimo.