Відповідь з прямої точки зору:
Не слухайте всіх, хто говорить, що цього не можна зробити, тому що експериментальний веб-сервіс Державного університету Сан-Франциско, який я написав у 1996 році, нарешті, вийшов на небо в Інтернеті пару років тому, і ніколи не знадобилося жодного виправлення сумісності браузера в той час. ; це майже половина вашої 40-річної мети. І цей інтерфейс на основі JavaScript, який я створив у 1998 році для проекту Стенфордського інституту досліджень, через кілька років був замінений чимось швидким, але немає причин, що початковий інтерфейс не міг би працювати сьогодні з незначними виправленнями сумісності.
Трюк полягає в тому, щоб ваш додаток використовував лише широко підтримувані стандарти W3C / ECMA і чистий дизайн був під вашим контролем. Хоча багато веб-додатків, написаних за модною технологією епохи 90-х років, не спрацюють добре або взагалі сьогодні, веб-додатки епохи 90-х років, написані відповідно до основних стандартів, все ще є. Вони можуть виглядати пасе, але вони працюють.
Ціль тут не в тому, щоб написати веб-додаток, який працюватиме на їхньому сервері і залишатиметься там протягом 40 років, без того, щоб хтось знову його торкався. Це створити фундамент, який все ще може бути використаний десятиліттями вниз, який може перерости в підтримку нових функцій без необхідності перебудовуватися з нуля.
Перш за все, ви повинні кодувати до офіційних стандартів і лише до офіційних стандартів. Ніякі функції JavaScript не є частиною ратифікованого стандарту ECMAScript; ES5.1 - це поточна версія, і вона, як правило, підтримується, тому безпечно для націлювання. Так само хороші поточні версії HTML5, CSS та Unicode. Немає експериментальних функцій JavaScript, CSS3 або HTML (ті, що мають префікси постачальника або без 100% узгодження між браузерами). І жодних хакерських можливостей щодо сумісності. Ви можете почати використовувати нову функцію, як тільки вона буде в стандарті, і всі підтримують її без префіксів.
Підтримка ES5 означатиме скасування IE8 або попередньої версії, що я все одно пропоную, оскільки для нього потрібні хакерські програми, які будуть непридатними через пару років. Я б запропонував жорсткий режим ES5 для найкращого шансу на довголіття, який фактично встановлює базову сумісність браузера на IE10 та останніх версіях усіх інших . Ці браузери також мають вбудовану підтримку багатьох функцій перевірки форм HTML5 та заповнювачів, що буде корисним дуже довго.
Нові видання ECMAScript підтримують сумісність із старими версіями, тому буде набагато простіше прийняти майбутні функції, якщо ваш код буде написаний відповідно до діючих стандартів. Наприклад, класи , визначені з допомогою наступаючого classсинтаксису будуть повністю взаємозамінні з класами , визначених з поточним constructor.prototypeсинтаксисом. Тож за п’ять років розробник може переписати класи у формат ES6 по кожному файлу, не порушуючи нічого, якщо, звичайно, припустити, що у вас також є хороші одиничні тести.
По-друге, уникайте модних рамок додатків JavaScript, особливо якщо вони змінюють спосіб кодування програми. Хребтики були у всіх гнів, потім були SproutCore і Ember, і тепер Angular є основою, яку всі люблять просувати. Вони можуть бути корисними, але вони також мають щось спільне: вони часто ламають програми та вимагають зміни коду, коли виходять нові версії та їх довговічність сумнівна. Я нещодавно оновив додаток Angular 1.1 до 1,2, і зовсім небагато довелося переписати. Так само для переходу з хребта 2 на 3 потрібно багато змін HTML. Стандарти є повільними з причини, але ці рамки швидко рухаються, і періодично руйнуються речі - це вартість.
Крім того, нові офіційні стандарти часто залишають застарілі рамки застарілими, і коли це відбувається, ці рамки або мутують (із порушеннями змін), або залишаються позаду. Ви знаєте, що станеться з усіма конкуруючими бібліотеками обіцянок у світі, коли ECMAScript 6 буде ратифікований і всі браузери підтримують його стандартизований клас Promise? Вони застаріють, і їх розробники перестануть оновлювати їх. Якщо ви вибрали правильний фреймворк, ваш код може адаптуватися досить добре, і якщо ви погано здогадалися, ви подивитесь на основний рефакторинг.
Тож якщо ви думаєте скористатись сторонніми бібліотеками чи рамками, запитайте себе, як важко буде їх видалити в майбутньому. Якщо це рамка на зразок Angular, яку ніколи не можна буде видалити, не будуючи додаток з нуля, це хороший знак, що він не може бути використаний в 40-річній архітектурі. Якщо це сторонній віджет календаря, який ви абстрагували певним спеціальним програмним забезпеченням, його заміна займе кілька годин.
По-третє, надайте їй гарну, чисту структуру додатків. Навіть якщо ви не використовуєте рамки програми, ви все одно можете скористатися інструментами для розробників, побудувати сценарії та гарний чистий дизайн. Я особисто прихильник управління залежностями Closure Toolkit, оскільки він легкий, а його накладні витрати повністю видаляються після створення вашого додатка. LessCSS та SCSS також є чудовими інструментами для організації ваших таблиць стилів та створення таблиць стилів CSS на основі стандартів для випуску.
Ви також можете організувати власний код у класи одноразового використання зі структурою MVC. Це дозволить набагато простіше повернутися через кілька років у майбутнє і знати, про що ви думали, коли щось писали, і замінити лише ті частини, які цього потребують.
Ви також повинні дотримуватися порад W3C і повністю зберігати презентаційну інформацію від свого HTML. (Це включає чіти, як надання елементів імен класів презентаційних класів, таких як "великий зелений текст" та "двоколонний".) Якщо ваш HTML - семантичний, а CSS - презентаційний, буде набагато простіше підтримувати та адаптувати його до нових платформ у майбутньому. Також буде простіше додати підтримку спеціалізованих веб-переглядачів для незрячих або інвалідів.
По-четверте, автоматизуйте свої тести та переконайтесь, що ви майже покриті. Пишіть одиничні тести для кожного класу, незалежно від сервера чи JavaScript. На передньому кінці переконайтеся, що кожен клас працює відповідно до своїх специфікацій у кожному підтримуваному браузері. Автоматизуйте ці тести у свого робочого бота для кожного вчинення. Це важливо як для довговічності, так і для надійності, оскільки ви можете ловити помилки рано, навіть коли сучасні браузери їх затьмарюють. Як рамки тестування на базі JSUnit, засновані на Жасмін та Google Закриття, хороші.
Ви також хочете запустити повнофункціональні тести на користувальницький інтерфейс, у яких Selenium / WebDriver хороші. В основному ви пишете програму, яка переходить через ваш інтерфейс користувача і використовує її так, ніби людина тестує її. Підключіть їх також до бота для складання.
Нарешті, як інші згадували, ваші дані є королем. Подумайте над своєю моделлю зберігання даних і переконайтеся, що вона побудована до останнього. Переконайтеся, що ваша схема даних є надійною, і переконайтесь, що вона ретельно перевірена також на кожному здійсненні. І переконайтеся, що архітектура вашого сервера масштабована. Це навіть важливіше за все, що ви робите на передній частині.