Approches des développeurs pour les interfaces utilisateur JavaScript complexes [fermé]

J'essaie de comprendre le paysage des différentes approches et meilleures pratiques autour du développement de JavaScript côté client complexe.

Je ne sais pas quoi étiqueter cette classe d'application, peut-être AJAX ou RIA lourde (mais pas des plugins comme Flash / Silverlight). Je fais référence aux applications Web avec ces caractéristiques:

• Émuler une UX de bureau riche / native en JavaScript
• Contiennent la plupart / tous les comportements dans JS côté client, en utilisant le serveur comme une API de données (JSON / Html-Templates).

Cela contraste avec l'utilisation du serveur Web pour le rendu de l'interface utilisateur, produisant tout le HTML dans un modèle de rafraîchissement de page.

Quelques exemples sont:

• Google Docs / Gmail
• Mindmeister
• Pivotal Tracker

À mesure que nous progressons vers HTML5, je peux voir ce style de développement RIA, avec JavaScript lourd, devenir de plus en plus courant et nécessaire pour rivaliser.

QUESTION: Quelles sont donc les approches communes émergeant autour de la gestion de ces types de développements JS lourds?

Le code côté client, à mesure qu'une application grandit en fonctionnalités, est diaboliquement compliqué. Il y a des problèmes de mise à l'échelle d'un effort de développement sur plusieurs équipes avec JS brut (ou du moins j'entends, et je peux bien le croire).

Google a abordé le problème en créant GWT qui compile à partir d'un langage de niveau supérieur (Java) vers JS, en s'appuyant sur l'infrastructure de développement existante du langage de niveau supérieur (Eclipse, typage fort, outils de refactoring), ainsi que la compatibilité abstraite du navigateur et autres problèmes loin du développeur.

Il existe d'autres outils, comme Script # pour C #, qui font quelque chose de similaire. Tout cela place JS davantage dans le rôle d'un IL (Intermediate Language). c'est à dire. "Vous n'écrivez plus vraiment dans ce 'langage de bas niveau'."

Mais cette «compilation en JS» n'est pas la seule approche. Il n'est pas évident que GWT soit l'approche dominante ... ou le deviendra.

Que font les gens avec du JavaScript client riche? Quelques questions d'orientation:

• La plupart des magasins créent-ils JS manuellement (au-dessus de bibliothèques comme jQuery et al)?
• Ou existe-t-il de nombreuses approches différentes, sans qu'aucune meilleure pratique claire n'émerge?
• La plupart des magasins évitent-ils le développement à l'échelle RIA en faveur du modèle plus simple à développer côté serveur / redessin des pages? Si oui, cela durera-t-il?
• La compilation vers JS est-elle peut-être une tendance future émergente? Ou est-ce juste mal dirigé?
• Comment gèrent-ils la complexité et la refactorisation du JS client?
• Modularisation et répartition du travail entre les équipes?
• L'application, l'application et le test de modèles côté client comme MVC / MVP, etc.

Alors, quelles sont les tendances émergentes de notre futur lourd JavaScript et HTML5?

Merci!

La plupart des applications Web que je vois (et des développeurs Web à qui j'ai parlé) qui vont dans ce sens utilisent jQuery comme base.

Le raisonnement derrière GWT (et les langages à plusieurs niveaux similaires) est que JavaScript est trop floconneux / trop fragile / trop modifiable pour que les "vrais programmeurs" puissent l'utiliser. Mais si vous avez un framework gérant les bits floconneux / fragiles / modifiables pour vous, alors il n'y a aucune raison d'ajouter cette couche supplémentaire de complexité.

Juste mon avis…

Je dirais que GWT est risqué. Une fois que vous avez décidé de l'utiliser, vous êtes coincé avec. Fondamentalement, cela signifie que vous traitez votre balisage, DOM et certains aspects de CSS comme un environnement d'exécution. Il devient très difficile de mélanger JavaScript écrit manuellement avec GWT à mesure que votre code client devient de plus en plus sophistiqué. GWT a des méthodes natives mais celles-ci sont assez limitées en termes d'applicabilité possible. C'est un gros compromis et c'est un gros pari.

Google essaie de vendre GWT comme un environnement d'exécution de plateforme X très rapide avec une intégration côté serveur décente. Mais comme d'autres l'ont déjà souligné, ce n'est plus le cas - JQuery et YUI sont aussi rapides sinon plus rapides. Et il est beaucoup plus facile de profiler et d'optimiser vos pages lorsqu'elles sont assemblées manuellement, vous avez donc un contrôle total sur CSS, le balisage et JavaScript.

GWT essaie de vous cacher la plate-forme sous-jacente, ce qui pourrait en fait être une mauvaise façon de faire les choses. Beaucoup de soi-disant frameworks Web à composants ont fait de même. Vous étiez censé écrire du code dérivé de XML ambigu avec EL et des balises personnalisées. La sortie serait un désordre de HTML mal formé avec de petits morceaux de JavaScript merdique saupoudrés partout. Les pages étaient lentes, boguées et totalement incontrôlables.

Dans notre projet actuel, nous utilisons Stripes - un cadre basé sur l'action de bas niveau - et JQuery côté client. Il est très facile de faire Ajax une fois que vous voyez clairement toutes les pièces d'un puzzle: voici votre code côté serveur qui fonctionne sur les données. Voici votre code côté client - pour la récupération de données et pour faire bouger les choses sur une page. Voici votre CSS, voici votre balisage, voici votre modèle - tout est propre et découplé. Facilement extensible, piratable, réglable et débogable. J'aime cela.

J'adore JQuery avec son attitude envers la vitesse et la simplicité. J'adore YUI3 pour sa modularité et ses widgets complets. J'adore YUI CSS pour me donner une cohérence entre les navigateurs. J'adore JavaScript pour les bonnes pièces. J'adore Java pour m'avoir laissé faire mon travail.

Baiser juste et tout ira bien!

J'ai entendu ce qu'on appelle des «applications d'une seule page».

Il s'agit d'un nouvel environnement et les règles ne sont pas encore totalement écrites. J'ai travaillé sur une application d'une seule page relativement importante l'année dernière (2010), et ce sont les outils que nous avons utilisés.

Le back-end était Java, utilisant des servlets pour fournir un service JSON, que la page utilisait pour soumettre finalement la commande préparée. Ce service a également été utilisé pour certaines étapes de validation et de tarification.

Le code frontal était javascript. Nous avons utilisé jQuery pour manipuler des éléments de page, Pure pour les modèles et RequireJs pour diviser le code en modules. (L'outil de construction de RequireJs a été utilisé pour fournir des téléchargements plus optimaux.)

Nous avons écrit nos tests à l'aide de qUnit et avons eu un test jUnit qui a utilisé htmlunit pour exécuter chaque test qUnit, puis gratter la sortie pour les résultats et réussir ou échouer en fonction de l'état de réussite / échec de qUnit. Ceux-ci ont été ajoutés à nos tests jUnit pour le back-end et intégrés à notre ci, en utilisant Hudson / Jenkins .

Je travaille sur une telle application, construite sur Ext JS. L'application est organisée de manière modulaire. Différents modules sont implémentés en tant que composants autonomes qui se nettoient eux-mêmes lorsqu'ils sont supprimés de la hiérarchie des composants Ext. Les chargeurs à la demande chargent des composants supplémentaires juste avant leur utilisation (un fichier js = un composant).

J'ai trouvé que cette approche n'est pas si difficile à mettre à l'échelle. Les seules vraies limites que j'ai rencontrées sont liées au fait d'avoir trop d'éléments DOM dans l'arborescence en même temps dans IE. La solution consiste à décharger stratégiquement les parties cachées de l'application. Étant donné que toutes les manipulations DOM se produisent via la hiérarchie des composants Ext, le DOM est presque entièrement abstrait et le développement reste simple.

Personnellement, je pense que les frameworks tels que jQuery sont essentiels non seulement pour faire face aux variations entre différents navigateurs, mais aussi pour ranger ces différences afin de ne pas ajouter de bruit au code. Des outils comme GWT, Websharper et d'autres vont plus loin et ont certainement une place, mais je me demande si ce n'est qu'une couche supplémentaire d'indirection dans la plupart des cas.

Quelque chose que je suis surpris que personne n'a mentionné est le test unitaire. Il est désormais généralement admis que les applications côté serveur complexes devraient avoir des tests unitaires automatisés et je pense que le temps est déjà venu où le JS dans les applications RIA est suffisamment complexe pour nécessiter des tests unitaires - ainsi que l'architecture / le code qui rend cela possible.

Cependant, contrairement aux applications côté serveur complexes, mon intuition, d'après ce que je vois et entends, est que la grande majorité des applications côté client complexes n'ont absolument aucun test unitaire (je ne parle pas ici de tests de sélénium, de vrais tests unitaires).

Je pense que la prochaine tendance émergente sera l'introduction des tests unitaires (et du code testable à l'unité). Je viens juste de terminer un projet avec une quantité modérée de code JavaScript non testé, j'espère que ce sera le dernier.