Розробка веб-додатків на тривалий термін (20+ років)

160

Зараз я розробляю веб-додаток для урядового планування земель. Додаток працює в основному в браузері, використовуючи ajax для завантаження та збереження даних.

Я буду робити початкову розробку, а потім закінчую навчання (це студентська робота). Після цього решта команди додасть епізодичну функцію за потребою. Вони вміють кодувати, але в основному це експерти з землеустрою.

Враховуючи темп, з яким змінюються технології Javascript, як я можу написати код, який буде працювати ще 20 років відтепер? Зокрема, які бібліотеки, технології та ідеї дизайну я повинен використовувати (або уникати) для підтвердження майбутнього свого коду?

javascript web-development future-proof

— Ден
джерело

94

Я розпочав програмувати у Фортрансі наприкінці 1966 року, тому у мене було достатньо часу, щоб подумати саме про таку проблему. Якщо ви коли-небудь натрапите на надійну відповідь навіть на 50%, будь ласка, повідомте мене про це. Тим часом, просто подумайте про майже певне неминуче застарівання як про "безпеку роботи" :)

— Джон Форкош

11

Ніщо не триває вічно в програмі Software Engineering. Тільки HOST у банках і тому, що ніхто не наважується оновлювати такі критичні системи. Що ж, я думаю, що програма, яка працює у Voyager, також враховує.

— Лаїв

9

@Laiv Деякий час назад я працював над заявками на переказ грошей для Bankers Trust, використовуючи обмін повідомленнями Swift, що працює на Vax / VMS. Через кілька років Swift випустив всю підтримку VMS. Хлопчик, це спричинило деякі проблеми ... і надав мені ще один контракт у BTCo. Як я вже говорив вище, "безпека роботи" :). У будь-якому разі, я хочу сказати, що навіть критичні заявки на фінансовому ринку не застраховані від застарілості.

— Джон Форкош

102

Як щодо "Написати код, який може зрозуміти наступний розробник"? Якщо і коли код застаріє до того, що їм потрібно буде знайти програміста для його оновлення, найкращим сценарієм є те, що вони зрозуміють, що робить ваш код (і, можливо, чому були прийняті певні рішення).

— Девід Старкі

38

Просто використовуйте звичайний старий HTML, без JS, без плагінів, нічого фантазійного. Якщо це працює в Lynx, це добре для всіх часів.

— Гай

132

Планувати програмне забезпечення на таку тривалість життя складно, тому що ми не знаємо, що чекає майбутнє. Трохи контексту: Java була опублікована 1995, 21 рік тому. XmlHttpRequest вперше став доступний у вигляді власного розширення для Internet Explorer 5, опублікованого 1999, 17 років тому. Минуло близько 5 років, поки вони не стали доступними для всіх основних браузерів. 20 років, які ви намагаєтеся заздалегідь, - це приблизно час, коли навіть існували багаті веб-програми.

Деякі речі, безумовно, залишилися колишніми. Доклали зусиль із стандартизації, і більшість браузерів добре відповідають різним стандартам. Веб-сайт, який працював у веб-переглядачах 15 років тому, все ще працюватиме так само, за умови, що він працював тому, що націляв на загальний підмножину всіх браузерів, а не тому, що використовував обхідні шляхи для кожного браузера.

Інші речі прийшли і пішли - найбільш помітно Flash. У Flash виникли різноманітні проблеми, які призвели до її загибелі. Найголовніше - це контролювала одна компанія. Замість конкуренції всередині платформи Flash виникла конкуренція між Flash та HTML5 - і HTML5 переміг.

З цієї історії ми можемо зібрати декілька підказок:

Нехай це буде просто: виконайте те, що працює зараз, не використовуючи жодних обхідних шляхів. Ця поведінка, ймовірно, залишатиметься доступною в майбутньому з міркувань зворотної сумісності.
Уникайте опори на власні технології та віддайте перевагу відкритим стандартам.

Сьогодні JavaScript у світі порівняно нестабільний з великим потоком бібліотек та фреймворків. Однак майже жоден з них не матиме значення за 20 років - єдиний «каркас», на який я впевнений, що до цих пір буде використовуватися Vanilla JS .

Якщо ви хочете використовувати бібліотеку чи інструмент, оскільки це дійсно значно спрощує розвиток, спочатку переконайтеся, що він побудований на сьогодні добре підтримуваних стандартах. Потім потрібно завантажити бібліотеку чи інструмент і включити їх у свій вихідний код. Ваше сховище коду повинно містити все необхідне для роботи системи. Що-небудь зовнішнє - це залежність, яка може зламатись у майбутньому. Цікавим способом перевірити це є скопіювати свій код на палець, перейти на новий комп’ютер з іншою операційною системою, відключити його від Інтернету та побачити, чи зможете ви примусити свій інтерфейс працювати. Поки ваш проект складається з простого HTML + CSS + JavaScript, а також, можливо, деяких бібліотек, ви, ймовірно, збираєтеся пройти.

— амон
джерело

4

На сьогоднішній день великомасштабні програми не використовуються у ванільному js. ES6 вже якось виправляє проблему, але є причина, чому потік або TypeScript набувають популярності.

— Енді

34

@DavidPacker Безумовно, TypeScript тощо є чудовими та полегшують розвиток. Але як тільки я впроваджую процес збирання, усі інструменти, необхідні для процесу збирання, стають залежностями: NodeJS, Gulp, NPM - хто каже, що NPM все ще буде в мережі через 20 років? Мені доведеться запустити власний реєстр, щоб бути певним. Це не неможливо. Але в якийсь момент краще відпустити речі, які полегшують розвиток лише відразу, але не в довгостроковій перспективі.

— амон

30

@DavidPacker Є багато динамічних мов, і дивно, що багато маленьких успішних систем було побудовано з Smalltalk, Ruby, Perl, Python, навіть з PHP та JS. Хоча статично типізовані мови, як правило, є більш досяжними, тоді як динамічні мови, як правило, є кращими для швидкого прототипування, неможливо написати реконструйований JS. За відсутності компілятора висока медіанна майстерність у команді, майстерність та додатковий акцент на чіткій організації коду стає ще більш важливим. Я особисто думаю, що типи полегшують все, але вони не є срібною кулею.

— амон

4

Чи я щойно прочитав "взяти usb і тестувати на різних машинах"? Чому б не просто відкрутити віртуальну скриньку або просто використовувати режим анонімного перегляду (з відключеною етXX).

— Кислик

5

Я не впевнена, що ванільний JS буде впевненою річчю через 20 років. Його історія була кам'янистою та експериментальною, і вона зібрала неабияку кількість суворості по дорозі, навіть якщо вона стала чудовою та ефективною мовою (я особисто віддаю перевагу JavaScript або TypeScript сам). Не важко уявити, що постачальники можуть захотіти вирвати частину або всю цю суть, будь то означає починати пропонувати нову альтернативну мову - як Google, здавалося, пропонує з Dart, однак багато чого, схоже, нікуди не дійшло - або знецінення, а потім усунення частин JS.

— KRyan

178

Що ще важливіше, ніж ваш код зберігається протягом 20 років, це те, що ваші дані зберігаються протягом 20 років. Швидше за все, це те, що варто зберегти. Якщо з вашими даними легко працювати, побудувати альтернативну систему на ній за допомогою новішої технології буде просто.

Тому почніть з чіткої та добре задокументованої моделі даних.
Використовуйте створену, добре підтримувану систему баз даних, наприклад Oracle ^[1] або SQL Server.
Використовуйте основні функції, не намагайтеся втиснути кричущі нові.
Воліють просто більш розумний .
Прийміть, що майбутня ремонтопридатність може вийти за рахунок таких аспектів, як ефективність. Наприклад, ви можете спокуситися використовувати збережені процедури, але це може обмежити майбутні можливості ремонту, якщо вони не дозволять комусь перенести систему на більш просте рішення для зберігання.

Коли ви це зробите, додаток, що захищає майбутнє, простіше, тому що це обгортка навколо моделі даних, і його можна замінити, якщо, наприклад, через 10 років ніхто більше не використовує Javascript, і вам потрібно перенести додаток на ВАСМ чи щось. Зберігання модульних речей, менш взаємозалежних, дозволяє простіше у майбутньому.

^[1] Більшість коментарів до цієї відповіді займають рішучу позицію проти використання Oracle для БД, посилаючись на безліч цілком законних причин, через які Oracle болить працювати, має круту криву навчання та накладні витрати. Це цілком поважні проблеми при виборі Oracle як БД, але в нашому випадку ми шукаємо не БД загального призначення, а той, де головним питанням є ремонтопридатність . Oracle існує вже з кінця 70-х і, ймовірно, буде підтримуватися на довгі роки, і існує величезна екосистема консультантів та варіантів підтримки, які допоможуть вам продовжувати працювати. Це завищена безлад для багатьох компаній? Звичайно. Але чи збереже Ваша база даних 20 років ? Цілком ймовірно.

— Авнер Шахар-Каштан
джерело

141

Вибачте, але я мушу це сказати. Якщо ви користуєтесь Oracle, ви стріляєте всіх у ногу щодо "легкої роботи". Oracle є НЕ просто працювати в найменшій мірі . Багато функціональних можливостей, які спрощують SQL Server, PostgreSQL і, мабуть, навіть MySQL, Oracle або вирівнювати не має, або робить їх надто складними. Я ніколи не маю стільки дурних проблем з іншими БД, як у мене з Oracle; навіть просто налаштування клієнта - це величезний біль у задника. Навіть речі з Googling важкі. Якщо ви хочете "легко працювати", тримайтеся подалі від Oracle.

— jpmc26

4

+1 для збереження даних максимально просто. Використовуйте для цього стандартний SQL, наприклад, використовуйте OUTER JOIN замість специфічного оператора + . Використовуйте прості макети таблиць. Не нормалізуйте свої таблиці до абсолютного максимального рівня. Вирішіть, чи можуть деякі таблиці містити зайві дані або якщо ви дійсно повинні створити нову таблицю, щоб кожне значення існувало лише один раз. Чи специфічний постачальник зберігаються процедур ? Якщо так, то не використовуйте їх. Не використовуйте доступну функцію вашого поточного вибору мови: я бачив більше програм COBOL без функцій OOP, а потім із ними. І це абсолютно нормально.

— some_coder

3

@ jpmc26 Я погоджуюся з вашими почуттями щодо Oracle, але, як я вже сказав, "просто працювати з" не обов'язково є головною вимогою тут. Я віддаю перевагу міцно підтримуваній платформі, навіть якщо це біль з якою працювати. Тому що, коли амортизується понад 20 років, це не дуже погано.

— Авнер Шахар-Каштан

8

Дійсно уникайте Oracle. Єдина сьогодні існуюча БД, яка, ймовірно, не виглядає поганим вибором за 20 років, - це Postgresql.

— Джошуа

3

Я хотів би додати, що великі СУБД з відкритим кодом є кращими, оскільки є велика ймовірність, що вони не загинуть. Якщо Oracle перестане заробляти гроші через 10 років, то через 11 її вже не буде. PostreSQL здається найкращим конем, на який можна зробити ставку.

— Shautieh

36

Попередня відповідь Амона чудова, але є два додаткові моменти, які не згадувалися:

Йдеться не лише про браузери; пристрої теж мають значення.

Амон згадує той факт, що "веб-сайт, який працював у веб-переглядачах 15 років тому, все одно буде працювати так само" , що правда. Однак подивіться на веб-сайти, створені не п’ятнадцять, а десять років тому, які при їх створенні працювали в більшості браузерів для більшості користувачів. Сьогодні значна частина користувачів взагалі не зможе користуватися цими веб-сайтами не тому, що веб-переглядачі змінилися, а тому, що це зробили пристрої. Ці веб-сайти виглядали б жахливо на маленьких екранах мобільних пристроїв і з часом взагалі не спрацювали, якщо розробники вирішили покластися на clickподії JavaScript , не знаючи, що tapподія також важлива.
Ви зосереджуєтесь на неправильній темі.

Зміни технології - це одне, але більш важливим є зміни вимог . Можливо, виріб потрібно буде масштабувати, або може мати додаткові функції, або може знадобитися зміна його поточних функцій.

Не має значення, що буде з браузерами, пристроями, W3C або ... що завгодно.

Якщо ви введете свій код таким чином, що його можна буде відновити , продукт буде розвиватися за допомогою технології.

Якщо ви пишете свій код таким чином, щоб ніхто не міг його зрозуміти та підтримувати, технологія не має значення: будь-яка зміна навколишнього середовища все одно знизить вашу програму, наприклад, міграція до іншої операційної системи або навіть проста річ, як природне зростання даних .

Як приклад, я працюю над розробкою програмного забезпечення десять років. Серед десятків і десятків проектів було лише два, які я вирішив змінити через технології , точніше тому, що PHP сильно розвивався за останні десять років. Це навіть не було рішенням замовника: він не піклується про те, якщо на сайті використовуються простори імен або закриття PHP. Однак змін, пов’язаних з новими вимогами та масштабованістю, було багато!

— Арсеній Муренко
джерело

4

Прийняття різних розмірів екрана є загальною проблемою. На сьогоднішній день мобільний - це завищена річ, але якщо ви переглядаєте цей веб-сайт у повноекранному вікні браузера на екрані з достатньою роздільною здатністю, є багато порожнього (витраченого) місця. Зміна макетів та представлення інформації для найкращого використання наявних пікселів ніколи насправді не відбувалося розумним чином. Мобільний зробив це очевидним. Але мислення в іншому напрямку може бути важливішим для розглянутого питання.

— null

9

@null: хоча я погоджуюся з вашим коментарем, веб-сайти StackExchange не можуть бути найкращою ілюстрацією вашої точки зору. Враховуючи дані для відображення, я вважаю, що дизайнери / розробники StackExchange зробили чудову роботу, щоб відобразити їх, оскільки це потрібно відображати, в тому числі на великих моніторах. Ви не можете зробити основний стовпчик ширшим, тому що текст стане набагато складніше для читання, і ви не можете використовувати декілька стовпців, оскільки він не виглядатиме приємно для коротких запитань та відповідей.

— Арсеній Муренко

Ще один хороший приклад - подія "наведення", яка часто використовувалася в системах меню. Багато хто з цих меню погано спрацьовують із сенсорними пристроями.

— Юстас

Ви маєте 110% (або більше) прав щодо пристроїв, і я можу навести вам приклади, що старіють на десятки років. Ще в кінці 1980-х я працював над програмами CICS, що працюють на мейнфреймах IBM і синхронних 3270 терміналах. Область CICS є аналогічною застосункам на стороні сервера, що надсилає одночасно цілі екрани даних до синхронних терміналів, які, таким чином, є аналогами браузерів, що виділяються. А програмування CICS було, можливо, 80% Cobol, 20% PL / 1. Обидві ці мови нині здебільшого застаріли, і поява робочих станцій Unix (ВС та Аполлон) на початку 1990-х рр.

— Майже

31

Ви не плануєте тривати 20 років. Простий і простий. Натомість ви перекладаєте свої цілі на відділення.

Ваша база даних додатків агностична? Якщо вам довелося зараз перемикати бази даних, ви могли б. Ваша мова логіки агностик. Якщо вам довелося зараз переписати додаток абсолютно новою мовою, чи не могли б ви? Ви дотримуєтесь правильних дизайнерських рекомендацій, таких як SRP та DRY?

У мене проекти живуть більше 20 років, і я можу вам сказати, що все змінюється. Як спливаючі вікна. 20 років тому ви могли покластися на спливаюче вікно, сьогодні не можете. 20 років тому XSS не була річчю, тепер вам доведеться відповідати за CORS.

Тож те, що ти робиш, - переконатися, що твоя логіка добре розділена, і щоб ти не використовував БУДЬ-яку технологію, яка замикає тебе на конкретному постачальнику.

Це може бути дуже складним часом. Наприклад, .NET чудово піддається розкриттю логіки та методу для його адаптера бази даних MSSQL, який не має еквівалентів в інших адаптерах. MSSQL може здатися гарним планом сьогодні, але чи залишиться він таким протягом 20 років? Хто знає. Приклад того, як обійти це, щоб рівень даних був повністю відокремлений від інших частин програми. Тоді, в гіршому випадку, вам доведеться лише переписати весь рівень даних, решта вашої програми залишається без змін.

Іншими словами, думайте про це як про машину. Ваш автомобіль не збирається робити це 20 років. Але, з новими шинами, новим двигуном, новою коробкою передач, новими стеклами, новою електронікою тощо. Цей самий автомобіль може бути в дорозі дуже довго.

— котейр
джерело

2

"Якщо вам довелося зараз перемикати бази даних, чи не могли б ви цього? Це майже неможливо здійснити, якщо ви робите щось більше, ніж CRUD в одному рядку за один раз.

— jpmc26

1

Багато ORM - це агностики. Я міг би дати будь-який з проектів, над якими я працюю, щоб я міг без зусиль переходити з SQLLite, MySql та Postgre.

— coteyr

5

І ORM перестають бути дуже хорошими інструментами для роботи, коли ви робите більше, ніж прості CRUD на одному записі одночасно. Тому я це кваліфікував. Я намагався. Коли складність запитів зростає, навіть найкращі ORM стають більшими проблемами, ніж просто запит запиту, і навіть якщо ви змушуєте їх запит, ви досить швидко опинитесь, використовуючи особливості бази даних або оптимізацію.

— jpmc26

1

Визначте "складний". Це була об'ємна операція? Чи включав він запити вікон? Підзапити? ЦТЕ? Союзи? Складні умови групування? Складна математика для кожного ряду та сукупності? Скільки об'єднань в одному запиті? Які види приєднується? Скільки рядків було оброблено одразу? Справді, сказати що- небудь за один рядок CRUD (зауважте, це означає, що один рядок на запит, а не на веб-запит чи інше) - це трохи гіперболи, але шлях до того, коли ОРМ стане більше проблем, ніж варто, набагато коротший, ніж ти думаєш А кроки до того, щоб зробити запит успішним, дуже часто є специфічними для бази даних.

— jpmc26

4

"Ваша база даних додатків агностична? Якщо вам довелося зараз перемикати бази даних, чи не так? Чи є ваша логічна мова агностиком? Якщо вам довелося зараз переписати додаток абсолютно новою мовою, чи не могли б ви?" - Це АБСОЛЮТНО ГОЛОВНІ поради! Не обмежуйте себе штучно тим, що, на вашу думку, є найбільшим загальним знаменником мов програмування чи баз даних - це змусить вас постійно винаходити колесо. Натомість спробуйте знайти НАТУРАЛЬНИЙ спосіб виразити бажану поведінку у вашій мові програмування та базі даних.

— fgp

12

Відповіді @amon та деяких інших чудові, але я хотів би запропонувати вам поглянути на це з іншого погляду.

Я працював з великими виробниками та державними установами, які покладалися на програми або бази кодів, які використовувались понад 20 років, і всі вони мали одне спільне - компанія контролювала обладнання. Мати щось, що працює і розширюється протягом 20 років, не важко, коли ви контролюєте, на чому він працює. Співробітники цих груп розробили код на сучасних машинах, які були в сотні разів швидшими, ніж машини розгортання ... але машини розгортання вчасно застигли.

Ваша ситуація складна, тому що веб-сайт означає, що вам потрібно планувати два середовища - сервер і браузер.

Що стосується сервера, у вас є два загальні варіанти:

Покладайтеся на операційну систему для різних функцій підтримки, які можуть бути набагато швидшими, але означає, що ОС може знадобитися «застигнути в часі». Якщо це так, ви хочете підготувати кілька резервних копій установки ОС для сервера. Якщо через 10 років щось виходить з ладу, ви не хочете змусити когось з глузду намагатися перевстановити ОС або переписати код для роботи в іншому середовищі.
Використовуйте бібліотеки з розширеними версіями в заданій мові / рамках, які є повільнішими, але їх можна упакувати у віртуальне середовище і, ймовірно, працювати в різних операційних системах або архітектурах.

Що стосується браузера, вам потрібно буде розмістити все на сервері (тобто ви не можете використовувати глобальний CDN для розміщення файлів). Можна припустити, що майбутні веб-переглядачі все ще працюватимуть HTML та Javascript (принаймні для сумісності), але це справді здогадки / припущення, і ви не можете це контролювати.

— Джонатан Ванаско
джерело

11

Ви також повинні врахувати безпеку. 20-річна непідтримувана ОС, ймовірно, буде заповнена дірками безпеки. Я працював у компанії і успадкував цю проблему. Урядове відомство, стародавні ОС (всі довгі віртуалізовані, на щастя), але це була величезна проблема, і оновлення було майже неможливим через необхідність повністю переписати програмне забезпечення (сотні індивідуальних сценаріїв PHP-коду спагетті, кожен з яких мав дзвінки до бази даних жорсткий код, використовуючи застарілі функції, які новий драйвер не підтримував / здригався).

Якщо ви відправляєтесь по маршруту ОС, в кращому випадку можна сподіватися, що застосовано виправлення безпеки та що майбутні технічні працівники зможуть захистити речі на мережевому шарі. Для того, щоб планувати, щоб такі речі працювали таким чином у довгостроковій перспективі (особливо за відсутності великого бюджету, оскільки ОП - студент), вам потрібно погодитися з тим, що ваша програма та сервер згодом стануть небезпечними. Наприклад, через 20 років з часом існуватимуть відомі подвиги для версії SSL на сервері ... але ця ОС може не бути сумісною з версіями opensl через 10 років. Це все про мінімізацію компромісів.

— Джонатан Ванаско

@FighterJet, ви завжди можете запустити брандмауер на підтримуваній ОС, тоді у вас є кілька ризиків, крім ін'єкцій SQL тощо, які ви б у будь-якому випадку повинні бути закодовані.

— Ян

@Ian: Я бажаю. З'явився брандмауер. Але я не писав код, я успадкував його. І так, було тисячі вразливостей SQL, які, як я хотів би, я міг би виправити, але справжня проблема полягала в тому, що код залежав від конкретної версії PHP4 (яка назавжди застаріла і є заповнена дірками безпеки) і Конкретна версія драйвера бази даних (яка не працювала на новіших ОС), яка завадила нам перейти на більш нову версію бази даних ... Справа в тому, що покладатися на те, що залишитися таким же не завжди працює. Скажімо, я радий, що більше не працюю там.

1

@FighterJet Це насправді гарний приклад того, про що я мав намір поговорити. Ви закінчили успадковувати код, який працює лише на певній версії PHP4, і драйвер, який працює лише на певній ОС ... тому ви не можете оновити сервер. Я б не виступав за те, щоб хтось робив це, але це трапляється. -- багато. FWIW, я згоден з вами, але я хотів, щоб моя відповідь сприяла роздумуванню над тими сценаріями, а не давала рекомендацію.

— Джонатан Ванаско

6

Основою більшості програм є дані. Дані назавжди. Код є більш витратним , змінним, плавним. Однак дані повинні зберігатися. Тому зосередьтеся на створенні дійсно надійної моделі даних. Зберігайте схему та дані чистими. Передбачаємо, що свіжий додаток може бути побудовано поверх тієї ж бази даних.

Виберіть базу даних, яка здатна забезпечити обмеження цілісності. Нескорені обмеження, як правило, порушуються з плином часу. Ніхто не помічає. Максимально використовуйте засоби, такі як зовнішні ключі, унікальні обмеження, обмеження перевірки та, можливо, тригери для перевірки. Існує кілька хитрощів, як зловживати індексованими переглядами, щоб застосувати обмеження унікальності між столом.

Тому, можливо, вам потрібно прийняти, що заявка буде переписана через деякий час. Якщо база даних чиста, роботи з міграцією будуть мало. Міграція надзвичайно дорога з точки зору праці та спричинених дефектів.

З точки зору технологій, було б корисно розміщувати більшість додатків на сервері, а не у формі JavaScript для клієнта. Можливо, ви зможете запускати одну і ту ж програму в одному екземплярі ОС надзвичайно довго завдяки віртуалізації . Це не дуже добре, але це гарантія, що програма запрацює 20 років відтепер без будь-яких дорогих витрат на обслуговування та обладнання. Виконуючи це, у вас є принаймні безпечний і дешевий резервний запас для продовження роботи старого, робочого коду.

Також я вважаю, що деякі стеки технологій стабільніші за інші . Я б сказав, що .NET має найкращу можливу історію сумісності в даний час. Microsoft мертво серйозно ставиться до цього. Java та C / C ++ також є стабільними. Python довів, що він дуже нестабільний при порушенні змін Python 3. Насправді JavaScript здається мені досить стабільним, тому що зламати Інтернет - це не варіант для будь-якого постачальника браузера. Ви, мабуть, не повинні покладатися на щось експериментальне чи фанкі. ("Funky" визначається як "Я знаю це, коли бачу").

— usr
джерело

про історію сумісності .net назад - я не думаю, що я бачив додаток java, який би попросив старішу версію Java, як на відміну. Це може змінитися в Java 9 або вище, але ще не бачили цього.

— eis

Це напрочуд сумісно на практиці, а встановлення старішої версії поряд не є проблемою. Також зауважте, що .NET BCL, на мою оцінку, на 10-100x більше, ніж вбудовані класи Java.

— usr

зворотна сумісність означає, що не повинно бути необхідним встановлювати і більш стару версію. Але ми відступимо від початкового питання, це не дуже стосується ОП.

— eis

0

Інші відповіді мають сенс. Однак я вважаю, що коментарі до клієнтської технології закінчують складність. Я працюю розробником останні 16 років. На мій досвід, доки ви не інтуїтивно зрозумієте код свого клієнта, ви повинні бути добре. Тож ніяких "злому" з фреймами / рамками тощо. Використовуйте лише чітко визначені функції у браузерах.

Ви завжди можете використовувати режими сумісності у веб-переглядачах, щоб підтримувати їх роботу.

Щоб довести свою думку, лише кілька місяців тому я виправив помилку тисячоліття у коді javascript для клієнта, який працює у своєму веб-додатку вже 17 років. Досі працює на останніх машинах, останніх базах даних, останніх операційних системах.

Висновок: будьте простими та чистими, і вам слід добре.

— Джонатан ван де Вен
джерело

1

Кадри та рамки кадрів дуже добре визначені в специфікації HTML. Що робить їх непридатними?

— цікаводанні

3

@curiousdannii: Це не стільки використання iframes (кадри більше не підтримуються в HTML5), скільки використання фреймів та iframes для асинхронного завантаження вмісту за допомогою скриптів тощо. Це може працювати чудово зараз, але це завжди підлягати змінам безпеки.

— Джонатан ван де Вен

-2

Кілька аксіом:

Істина виживає. У цьому контексті це були б алгоритми та моделі даних - те, що правдиво представляє "що" і "як" вашого проблемного простору. Хоча, завжди є потенціал для вдосконалення та вдосконалення, або еволюції самої проблеми.
Мови розвиваються. Це справедливо для комп'ютерних мов, як і для природних мов.
Вся технологія вразлива до застарілого віку. Для деяких технологій це може зайняти більше часу, ніж інші

Найбільш стабільні технології та стандарти (найменш уразливі до морального віку), як правило, є тими, які не є власником і є найбільш широко прийнятими. Чим ширше прийняття, тим більша інертність щодо практично будь-якої форми змін. Власні "стандарти" завжди вразливі до стану та примх їх власника та конкурентних сил.

Двадцять років - це дуже довгий час у комп'ютерній індустрії. П’ять років є більш реалістичною ціллю. За п’ять років вся проблема, яку має вирішити ваша програма, може бути повністю переосмислена.

Кілька прикладів для ілюстрації:

C і C ++ існують вже давно. Вони мають реалізацію майже на кожній платформі. C ++ продовжує розвиватися, але "універсальні" функції (доступні на всіх платформах) майже гарантовано ніколи не будуть застарілі.

Flash майже став універсальним стандартом, але він є власним. Корпоративні рішення не підтримувати його на популярних мобільних платформах в основному приречені на це всюди - якщо ви пишете для Інтернету, ви хочете, щоб ваш вміст був доступний на всіх платформах; Ви не хочете пропускати головний ринок мобільних телефонів.

WinTel (Windows / x86), незважаючи на те, що він є власником Microsoft та Intel, розпочав роботу на менш оптимальній платформі (16-бітний внутрішній / 8-бітовий зовнішній 8088 проти сучасного Apple Macintosh 32-бітний внутрішній / 16-бітний зовнішній 68000) та ерозії Apple для споживчого ринку залишається фактичним вибором для бізнес-платформ. За весь цей час (25 років), прихильність до відсталої сумісності одночасно покрутила майбутній розвиток і вселила значну впевненість у тому, що те, що працювало на старій скриньці, все ще працюватиме на новій.

Заключні думки

JavaScript може бути не найкращим вибором для впровадження бізнес-логіки. З міркувань цілісності та безпеки даних бізнес-логіка повинна виконуватися на сервері, тому JavaScript на стороні клієнта повинен обмежуватися поведінкою інтерфейсу користувача. Навіть на сервері JavaScript може бути не найкращим вибором. Хоча для малих проектів працювати з іншими стеками (Java або C #), це не вистачає формальності, яка може допомогти вам писати кращі, більш організовані рішення, коли справи стають складнішими.

— Zenilogix
джерело