Lo sviluppatore si avvicina all'interfaccia utente complessa di JavaScript [chiuso]

Sto cercando di comprendere il panorama dei diversi approcci e delle migliori pratiche sullo sviluppo di JavaScript complessi lato client.

Non sono sicuro di cosa etichettare questa classe di applicazioni, forse AJAX o RIA pesanti (ma non plugin come Flash / Silverlight). Mi riferisco alle app Web con queste caratteristiche:

• Emula UX desktop ricco / nativo in JavaScript
• Contiene la maggior parte / tutto il comportamento in JS sul lato client, utilizzando il server come API dati (modelli JSON / Html).

Ciò è in contrasto con l'utilizzo del web server per il rendering dell'interfaccia utente, producendo tutto l'HTML in un modello di aggiornamento della pagina.

Alcuni esempi sono:

• Google Docs / Gmail
• MindMeister
• Pivotal Tracker

Mentre avanziamo in HTML5, posso vedere questo stile di sviluppo RIA, con JavaScript pesante, che diventa sempre più comune e necessario per competere.

DOMANDA: Quindi quali sono gli approcci comuni che emergono nella gestione di questo tipo di pesanti sviluppi JS?

Il codice lato client, man mano che un'app cresce di funzionalità, è diabolicamente complicato. Ci sono problemi nel ridimensionare uno sforzo di sviluppo tra più team con JS crudo (o almeno così ho sentito, e posso ben crederci).

Google ha affrontato il problema costruendo GWT che si compila da un linguaggio di livello superiore (Java) a JS, appoggiandosi all'infrastruttura di sviluppo esistente che ha il linguaggio di livello superiore (Eclipse, strumenti di tipizzazione forte, refactoring), insieme ad astrarre la compatibilità del browser e altri problemi lontano dallo sviluppatore.

Ci sono altri strumenti, come Script # per C # che fanno qualcosa di simile. Tutto ciò mette JS di più nel ruolo di un IL (Intermediate Language). vale a dire. "Non scrivi più in quel" linguaggio di basso livello "."

Ma questa "compilazione in JS" non è l'unico approccio. Non è evidente che GWT sia l'approccio dominante ... o in effetti lo diventerà.

Cosa stanno facendo le persone con JavaScript rich-client? Alcune domande di orientamento:

• La maggior parte dei negozi produce manualmente JS (in cima a librerie come jQuery et al)?
• O ci sono molti approcci diversi, senza che emergano chiare migliori pratiche?
• La maggior parte dei negozi sta evitando lo sviluppo su scala RIA a favore del modello più semplice per gli sviluppatori lato server / ridisegno della pagina? Se è così, questo durerà?
• La compilazione per JS è forse una tendenza emergente futura? O è solo sbagliato?
• Come gestiscono la complessità e il refactoring del client JS?
• Modularizzazione e distribuzione del lavoro tra i team?
• Applicazione, applicazione e test di modelli lato client come MVC / MVP ecc.

Quindi, quali sono le tendenze emergenti in questo nostro futuro JavaScript e HTML5 pesante?

Grazie!

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 simili linguaggi multilivello) è che JavaScript è troppo debole / troppo fragile / troppo mutevole per essere utilizzato da "veri programmatori". Ma se hai un framework che gestisce i bit flakey / fragili / modificabili per te, allora non c'è motivo di aggiungere quel livello extra 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 un ambiente di esecuzione. Sta diventando davvero difficile mescolare JavaScript scritto manualmente con GWT man mano che il codice client diventa sempre più sofisticato. GWT ha metodi nativi ma quelli sono abbastanza limitati in termini di possibile applicabilità. Questo è un grande compromesso 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 altri hanno già sottolineato, non è più il caso: JQuery e YUI sono altrettanto veloci se non più veloci. Ed è molto più semplice 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 nasconderti la piattaforma sottostante che potrebbe effettivamente essere un modo sbagliato di fare le cose. Molti cosiddetti web framework dei componenti hanno fatto lo stesso. Avresti dovuto scrivere un ambiguo codice derivato XML con EL e tag personalizzati inseriti. L'output sarebbe stato un disastro di HTML mal formato con piccoli pezzi di JavaScript scadente sparsi dappertutto. Le pagine erano lente, buggy e assolutamente non mantenibili.

Nel nostro progetto attuale utilizziamo Stripes - un framework basato su azioni di basso livello - e JQuery sul lato client. È molto semplice fare Ajax quando 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 modello: tutto è pulito e disaccoppiato. Facilmente estensibile, hackerabile, sintonizzabile e debug. Lo adoro.

Adoro JQuery con il suo atteggiamento verso la velocità e la semplicità. Adoro YUI3 per modularità e widget completi. Adoro YUI CSS per avermi dato coerenza tra i browser. Adoro JavaScript per le buone parti. Adoro Java per avermi permesso di fare un lavoro.

Solo BACIO, e starai bene!

Ho sentito queste chiamate "Applicazioni a pagina singola".

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

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

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

Abbiamo scritto i nostri test usando qUnit e abbiamo avuto un test jUnit che ha usato htmlunit per eseguire ogni test qUnit, quindi raschiare l'output per ottenere 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 nei nostri ci, usando Hudson / Jenkins .

Lavoro su un'app simile, costruita su Ext JS. L'app è organizzata in modo modulare. Diversi moduli sono implementati come componenti autonomi che si ripuliscono dopo essere stati rimossi dalla gerarchia dei componenti Ext. Caricatori su richiesta caricano componenti aggiuntivi subito prima che siano necessari (un file js = un componente).

Ho scoperto che questo approccio non è così difficile da ridimensionare. Gli unici limiti reali che ho incontrato sono legati al fatto di avere troppi elementi DOM nella struttura contemporaneamente in IE. La soluzione è quella di scaricare strategicamente parti nascoste dell'applicazione. Poiché tutta la manipolazione del DOM avviene tramite la gerarchia del componente Ext, il DOM viene quasi completamente estratto e lo sviluppo rimane semplice.

Personalmente penso che quadri come jQuery siano fondamentali non solo per gestire le variazioni tra browser diversi, ma anche per nascondere quelle differenze in modo che non aggiungano rumore al codice. Strumenti come GWT, Websharper e altri lo portano oltre e sicuramente hanno un posto, ma mi chiedo se nella maggior parte dei casi sia solo un ulteriore livello di riferimento indiretto.

Qualcosa di cui sono sorpreso che nessuno abbia menzionato è il unit test. Ora è generalmente riconosciuto che le complesse app lato server dovrebbero avere test di unità automatizzati e penso che sia già giunto il momento in cui JS nelle app RIA è abbastanza complesso da richiedere test di unità, insieme all'architettura / codice che lo rende possibile.

Tuttavia, a differenza delle complesse app lato server, il mio istinto basato su ciò che vedo e sento è che la stragrande maggioranza delle app lato client complesse non ha assolutamente test unitari (non sto parlando di test di selenio qui, test di unità reali).

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