Pourquoi JavaScript ?

Dans mon précédent article, « Développer des applications client-side avec SharePoint« , je tentais de dresser un panorama des solutions de développement client-side pour SharePoint :

  • BCS
  • .NET
  • Silverlight
  • JavaScript

Parmi les solutions étudiées, j’ai choisi ici de me concentrer sur JavaScript. Pourquoi ? Parce que ce serait la meilleure solution de manière absolue ? Naturellement non.

Pour vous présenter mon argumentation, je vais tout d’abord simplement exposer certaines des limitations et contraintes des autres solutions, puis vous donner mon point de vue sur les points positifs et négatifs de JavaScript pour SharePoint.

Les contraintes des autres solutions

Les solutions server-side

Bon, je coupe court aux remarques avant même qu’elles ne surviennent, oui c’est « puissant » de développer sur SharePoint côté serveur avec .NET et Visual Studio.

Oui :

  • On peut tout faire et intervenir sur l’ensemble des artefacts SharePoint (Web Parts, Services applications, Timers, Solutions Farm-level…)
  • Depuis Visual Studio, c’est confortable un IDE complet
  • Microsoft promeut cette option, et la préconise dans ses best practices par exemple pour la création de templates de sites

Oui… mais :

  • Il faut Visual Studio et ce n’est pas gratuit
  • Cela impose de développer en .NET ce qui n’est pas dans les cordes de tout le monde
  • Cela implique une grosse montée en compétences spécifique à SharePoint, tant sur les API serveur que sur les problématiques de packaging, features, feature stappler…

Les solutions Silverlight

Les solutions Silverlight offrent un grand nombre de possibilités et présentent de bons arguments pour créer des applications RIA dans SharePoint :

  • Développement .NET et forte intégration avec Visual Studio
  • Richesse des composants graphiques, notamment d’éditeurs tiers
  • Un CSOM dédié très proche du modèle serveur
  • Possibilité de créer des applications out-of-browser

Mais cette option présente aussi un grand nombre de contraintes :

  • Déploiement d’un plug-in spécifique
  • Des différences notables de fonctionnement et de support entre les navigateurs
  • Pas de support des terminaux mobiles, même pas Windows Phone !

Un dernier point tout de même, l’avenir de Silverlight est pour le moins incertain… Alors que Silverlight 5 est tout juste arrivé, il n’est pas sûr qu’une version 6 verra le jour… quel avenir pour Silverlight ?

Mais n’ouvrons pas ce débat ici…

L’heure du bilan

Le sourcing

Voilà un vrai problème. Trouver des compétences réellement qualifiées en développement SharePoint est particulièrement délicat. En effet, on trouvera relativement peu d’écoles informatique qui traitent de ce sujet en profondeur, et par ailleurs, bon nombre de développeurs SharePoint (sans trop vouloir généraliser naturellement 😉 n’ont pour seule connaissance du produit que :
  • Ce qu’ils connaissent de la version « légère », SharePoint Foundation, généralement en tant qu’end-user
  • Ce qu’ils ont retenu des 5 jours de formation standard au développement SharePoint avec pour seul prérequis de savoir développer en .NET
On trouve donc beaucoup de développeurs capables de produire très correctement des fonctionnalités unitaires, mais qui ne maîtrisent pas du tout l’ensemble de la plateforme. Ce manque de vision globale conduit à d’inévitables difficultés :
  • Travail parcellaire et moins valorisant / valorisable
  • Manque d’anticipation des difficultés de packaging, d’intégration et déploiement
  • Parfois même le développement spécifique de fonctionnalités qui existent déjà nativement

L’agilité et le time to market

C’est un des points les plus délicats des projets SharePoint, l’ALM (Application Licecycle Management).

Schématiquement, l’ALM consiste à maîtriser votre projet dans l’ensemble des évènements du cycle de vie de l’application :

  • Packaging
  • Gestion des environnements
  • Déploiements automatisés
  • Mise à jour entre versions mineures et majeures
  • Distribution à la demande…

De ce point de vue, SharePoint propose un certain nombre de solutions, plus ou moins adaptées, et plus ou moins délicates à mettre en oeuvre.

Car si les évolutions de Visual Studio ont simplifié un certain nombre d’opérations, comme le packaging ou le déploiement vers un environnement debug, l’industrialisation complète de la chaine de production logicielle reste une question complexe, délicate et surtout longue à mettre en oeuvre.

De plus, ce qui fonctionne relativement simplement pour la V1 de votre projet, comme les déclarations de modèles de sites en mode déclaratif XML, se révèle particulièrement délicat à manier lorsqu’il s’agit de mise à jour vers une version ultérieure.

Ces problématiques de change management, contrôle de version et de versionning de schéma (si l’on admet le parallèle entre les typologies de contenus SharePoint et un modèle SQL) est désormais bien outillée dans les environnements SQL (Par exemple avec RedGate SQL Compare), mais encore peu sur SharePoint, sauf à utiliser des solutions complètes de type AvePoint Replicator ou Quest Deployment Manager.

JavaScript, la troisième voie

Naturellement, tout ne peut être réalisé en JavaScript, ou tout du moins pas simplement. Ceci étant, l’idée d’utiliser JavaScript avec SharePoint vise à répondre à une particularité de cette plateforme, à savoir comment repousser le moment de l’écriture de la première ligne de code .NET.

En effet, un des points forts de la plateforme SharePoint réside dans sa capacité de configuration avancée, sans développement. Mais cette grande souplesse s’accompagne d’un inconvénient majeur, un très fort effet de seuil sur les coûts lors de la production de la première ligne de code.

Un exemple, si vous souhaitez afficher un message de bienvenue personnalisé à l’utilisateur en lieu et place de la traditionnelle zone :

Pour ce faire, en développement .NET classique, vous devrez :

  1. Créer une nouvelle solution SharePoint dans Visual Studio
  2. Définir la solution et les features
  3. Comprendre le système de « delegate »
  4. Développer le contrôle qui va « remplacer » le rendu original
  5. Builder
  6. Créer le package WSP
  7. Lancer quelques lignes de commande pour installer, déployer puis activer votre solution
  8. Vous assurer que cela fonctionne

C’est donc assez lourd, et je ne compte pas ici la moindre étape de mise à jour et l’ensemble des opérations liées à l’AML et l’industrialisation !

En conclusion, JavaScript offre une alternative pertinente pour bon nombre de situations, entre la configuration à la souris et le développement lourd.

C’est ce que certains auteurs tel Marc Anderson (créateur de l’excellente librairie SPServices), appellent le développement « middle-tier ».

Voici les points faibles et les points forts de cette option.

Les points faibles

Oui je sais, JavaScript c’est mal ! JavaScript ça tue des bébés phoques !
  • JavaScript est un langage non typé
  • C’est juste fait pour développer des animations de flocons de neige dans une page web (enfin si vous avez été enlevé par des Farcs depuis 20 ans et que vous n’avez pas suivi l’actualité)
Non plus sérieusement, développer avec Javascript pour SharePoint présente certaines limitations :
  • Si vous n’utilisez que le CSOM SharePoint (SP.JS), vous ne pourrez accéder qu’aux artefacts internes à la collection de sites (Site, Web, List…)
  • Si vous souhaitez accéder à d’autres objets, vous devrez faire des appels aux web service
  • Si vous développez en .NET habituellement, c’est une transition non négligeable et bon nombre de paradigmes de développement seront à revoir…

Les points forts

Certes la transition pour les développeurs .NET n’est pas neutre, mais pourrez-vous y échapper ?
Comme le laissent à penser les analyses du SDK (avec un renforcement du CSOM) et les leaks de SharePoint 15 (regardez ci-dessus le label « Drag files… »), la prochaine version de SharePoint reposera sur HTML5 et donc très fortement sur JavaScript… (Je précise que je ne suis pas soumis à la NDA et que le screenshot ci-dessus est public)
Outre cet investissement sur l’avenir, parier sur JavaScript vous permettra aussi de :
  • Simplifier vos process de déploiements
  • Réduire certains coûts initiaux de développement
  • Intégrer à vos équipes des profils orientés IHM
  • Utiliser des frameworks MVC puissants et légers
Par ailleurs, la maturité de ce langage n’est plus à démontrer, et l’écosystème JS propose désormais une large palette d’outils d’ingénierie et d’industrialisation pour les tâches traditionnelles de développement :
  • Audit de code
  • Qualimétrie
  • Automatisation des tests TDD et BDD
  • Intégration continue

Des perspectives passionnantes

Aujourd’hui j’ai tenté de vous convaincre en vous exposant « Pourquoi développer avec JavaScript pour SharePoint ». Dans mon prochain article nous verrons ensemble « Comment développer avec JavaScript pour SharePoint », en abordant notamment :

  • Best practice de déploiement des scripts et des dépendances
  • Comment choisir son framework : sp.js ou SPServices ?
  • Exécuter son code JavaScript à distance (Mobile, Node.js sur Azure…)

Alors à très bientôt pour la suite !