Réponse d'un point de vue frontal:
N'écoutez pas tout le monde en disant que cela ne peut pas être fait, car un service Web expérimental de l'Université de San Francisco, que j'ai co-écrit en 1996, est finalement devenu un paradis sur Internet il y a quelques années et qu'il n'avait jamais eu besoin d'un correctif de compatibilité de navigateur à cette époque. ; c'est presque la moitié de votre objectif de 40 ans. Et ce front-end basé sur JavaScript que j'ai créé en 1998 pour un projet du Stanford Research Institute a été remplacé par quelque chose de plus éclatant quelques années plus tard, mais rien ne s'oppose à ce que l'interface utilisateur d'origine ne puisse toujours pas fonctionner aujourd'hui avec des corrections mineures de compatibilité.
L'astuce consiste à vous assurer que votre application utilise uniquement les normes largement reconnues du W3C / ECMA et a un design épuré sous votre contrôle. Alors que de nombreuses applications Web écrites avec la technologie à la mode des années 90 ne fonctionnent pas bien ou pas du tout aujourd'hui, les applications Web des années 90 écrites selon les normes principales le sont toujours. Ils peuvent sembler dépassés, mais ils fonctionnent.
L’objectif ici n’est pas d’écrire une application Web qui sera installée sur leur serveur et qui restera là pendant 40 ans sans que personne ne la touche à nouveau. Il s'agit de créer une base qui peut encore être utilisée pendant des décennies sur toute la ligne, et qui peut évoluer pour prendre en charge de nouvelles fonctionnalités sans avoir à être reconstruite à partir de zéro.
Tout d'abord, vous devez coder selon les normes officielles et uniquement selon les normes officielles. Aucune fonctionnalité JavaScript ne fait partie d'une norme ECMAScript ratifiée; ES5.1 est la version actuelle et est généralement prise en charge, ce qui permet de cibler en toute sécurité. De même, les versions actuelles de HTML5, CSS et Unicode sont bonnes. Pas de fonctionnalités expérimentales JavaScript, CSS3 ou HTML (celles avec préfixes de fournisseur ou sans accord à 100% entre les navigateurs). Et pas de piratages de compatibilité spécifiques au navigateur. Vous pouvez commencer à utiliser une nouvelle fonctionnalité une fois qu'elle est dans la norme et que tout le monde la prend en charge sans préfixe.
La prise en charge de ES5 signifierait abandonner IE8 ou une version antérieure, ce que je suggère de toute façon, car elle nécessite des piratages spécifiques au navigateur qui seront inutiles dans quelques années. Je suggérerais le mode strict d'ES5 pour la meilleure chance de longévité, qui définit en fait la compatibilité de votre navigateur de base avec IE10 et les versions récentes de tous les autres . Ces navigateurs prennent également en charge, de manière native, de nombreuses fonctionnalités de validation de formulaire et d’espace réservé de HTML5, qui seront utiles très longtemps.
Les nouvelles éditions d’ECMAScript conservent la compatibilité avec les versions antérieures. Il sera donc beaucoup plus facile d’adopter les fonctionnalités à venir si votre code est écrit conformément aux normes en vigueur. Par exemple, les classes définies à l'aide de la class
syntaxe à venir seront totalement interchangeables avec les classes définies à l'aide de la constructor.prototype
syntaxe actuelle . Ainsi, dans cinq ans, un développeur peut réécrire les classes au format ES6 fichier par fichier sans rien casser - à supposer, bien sûr, que vous disposiez également de bons tests unitaires.
Deuxièmement, évitez les cadres d'application JavaScript à la mode, en particulier s'ils modifient la façon dont vous codez votre application. Backbone faisait fureur, puis SproutCore et Ember, et maintenant Angular est le cadre que tout le monde aime promouvoir. Ils peuvent être utiles, mais ils ont aussi quelque chose en commun: ils cassent souvent des applications et nécessitent des modifications de code lorsque de nouvelles versions sortent et que leur longévité est discutable. J'ai récemment mis à jour une application Angular 1.1 vers la version 1.2 et il a fallu réécrire un peu. De même, passer de Backbone 2 à 3 nécessite beaucoup de modifications HTML. Les normes sont lentes pour une raison, mais ces cadres évoluent rapidement et le coût est cassé périodiquement.
De plus, les nouvelles normes officielles laissent souvent les anciens cadres obsolètes. Lorsque cela se produit, ces derniers mutent (avec des modifications radicales) ou sont laissés pour compte. Vous savez ce qu'il adviendra de toutes les bibliothèques de promesses concurrentes du monde une fois que ECMAScript 6 aura été ratifié et que tous les navigateurs prendront en charge sa classe standardisée Promise. Ils deviendront obsolètes et leurs développeurs arrêteront de les mettre à jour. Si vous avez sélectionné le bon framework, votre code pourrait s’adapter suffisamment et si vous avez mal deviné, vous envisagez une refactorisation majeure.
Donc, si vous envisagez d'adopter une bibliothèque ou un framework tiers, demandez-vous à quel point il sera difficile à supprimer à l'avenir. S'il s'agit d'un framework comme Angular qui ne peut jamais être supprimé sans reconstruire votre application à partir de zéro, c'est un bon signe qu'il ne peut pas être utilisé dans une architecture de 40 ans. S'il s'agit d'un widget de calendrier tiers que vous avez extrait avec un middleware personnalisé, son remplacement prendrait quelques heures.
Troisièmement, donnez-lui une bonne et propre structure d'application. Même si vous n'utilisez pas un cadre d'application, vous pouvez toujours tirer parti des outils de développement, des scripts de construction et d'une bonne conception. Personnellement, je suis un partisan de la gestion des dépendances de Closure Toolkit car elle est légère et que ses frais généraux sont totalement supprimés lors de la création de votre application. LessCSS et SCSS sont également d'excellents outils pour organiser vos feuilles de style et créer des feuilles de style CSS basées sur des normes pour la publication.
Vous pouvez également organiser votre propre code en classes à usage unique avec une structure MVC. Cela facilitera beaucoup la tâche de revenir dans plusieurs années et de savoir ce que vous pensiez lorsque vous écrivez quelque chose et de ne remplacer que les parties qui en ont besoin.
Vous devez également suivre les conseils du W3C et conserver les informations de présentation en dehors de votre code HTML. (Cela inclut les astuces consistant à donner aux éléments des noms de classe de présentation, tels que "grand texte vert" et "deux colonnes"). Si votre code HTML est sémantique et que CSS est un système de présentation, il sera beaucoup plus facile à gérer et à adapter. à de nouvelles plates-formes à l'avenir. Il sera également plus facile d'ajouter un support pour les navigateurs spécialisés pour les personnes aveugles ou handicapées.
Quatrièmement, automatisez vos tests et assurez-vous d'avoir une couverture presque complète. Écrivez des tests unitaires pour chaque classe, côté serveur ou en JavaScript. Sur le front-end, assurez-vous que chaque classe fonctionne conformément à ses spécifications dans chaque navigateur pris en charge. Automatisez ces tests depuis votre bot de construction pour chaque commit. Ceci est important pour la longévité et la fiabilité, car vous pouvez détecter les bogues plus tôt, même lorsque les navigateurs actuels les masquent. Les frameworks de test basés sur JSUnit de Jasmine et de Google Closure sont bons.
Vous voudrez également exécuter des tests fonctionnels complets de l'interface utilisateur, pour lesquels Selenium / WebDriver sont bons. Fondamentalement, vous écrivez un programme qui parcourt votre interface utilisateur et l’utilise comme si une personne le testait. Câblez-les également au bot de construction.
Enfin, comme d’autres l’ont mentionné, vos données sont roi. Réfléchissez bien à votre modèle de stockage de données et assurez-vous qu'il est construit pour durer. Assurez-vous que votre schéma de données est solide et assurez-vous qu'il est également testé minutieusement à chaque commit. Et assurez-vous que votre architecture de serveur est évolutive. Ceci est encore plus important que tout ce que vous faites au début.