Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
Для себя я вот что решил. Обязательное разделение сайта на backend и frontend части, где backend представляет собой чисто REST API и является отдельным приложением, а frontend — это просто UI обвязка поверх него. На чем делать frontend при такой архитектуре — дело вкуса, склоняюсь к React. Для backend планируется продолжать использовать .NET, но уже новые его версии.
Затем, постараться минимизировать динамические части сайта. Frontend сайта по сути будет статическим, а всю нужную динамику делать с помошью React на клиентской стороне через REST API к backend'у. Для поисковых систем это не будет вызывать проблем, поскольку будет задействоваться пререндеринг, т. е. там где возможно будет генерироваться чистый HTML, который будет работать даже в браузерах с выключенным Javascript. Плюс почти все поисковики сейчас умеют Javascript.
Почему выбрана именно такая архитектура? Потому что чистый монолит, который у нас есть сейчас, оказался серьезнейшей болью. Сайт был сделан давно на .NET Framework, но попробуйте-ка его сейчас мигрировать на новый .NET. Кода там — под десять тысяч строк за десятилетие набралось и он такой сцепленный, хрупкий, что вообще страшно сейчас всё это трогать. Тестов естественно не было и нет, ведь это просто сайт, там же не может быть много важного кода, правда? Поэтому это технологически устаревшее приложение сейчас только патчится, а время идет и монстр продолжает разрастаться.
Вот сейчас хотелось бы подтянуть UI сайта, но из-за сильной сцепки между UI и бизнес-логикой эта, на первый взгляд безобидная, затея становится архи-сложной. Если же плюнуть на всё и переписать сайт под корень — потеряются существующие наработки и упадут бизнес-процессы. Нехорошо.
Поэтому было принято решение отказаться от монолита чтобы вновь не оказаться в такой же патовой ситуации спустя время. Более того, такой шаг дает некоторую технологическую свободу. Например, не понравится React — можно выкинуть и переписать на чем-нибудь другом когда настанет время.
Хотелось бы услышать ваши идеи и опыт по этой теме.
Здравствуйте, Sharowarsheg, Вы писали:
S>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>Так что моё мнение не следует учитывать.
Вы имеете в виду иерархическую подачу информации? Что-то наподобие https://retype.com/ если брать более современный пример?
Здравствуйте, Aquilaware, Вы писали:
S>>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>>Так что моё мнение не следует учитывать.
A>Вы имеете в виду иерархическую подачу информации? Что-то наподобие https://retype.com/ если брать более современный пример?
Нет, я имею в виду
1. Минимум картинок. Только скриншоты и пару диаграммок где уж совсем надо. Всё остальное текст.
2. Минимум интерактивности. Скролл и всё.
3. Всякое responsive design, которое для мобил, чисто в CSS.
4. JS только в одном месте для подсветки навигации "я сейчас здесь", и всё.
Я сейчас посмотрел в Lynx, нормально смотрится сайт. В смысле, на полном серьёзе нормально работает в текстовом браузере. Странное достижение, но всё же.
у 2CO order page правда не работает. Ну тут уж ничего особо нет смысла делать.
retype.com кстати тоже нормально работает в текстовом браузере, так что да, хороший пример.
A>Хотелось бы услышать ваши идеи и опыт по этой теме.
Путь
2002
чистый пхп
пхп с шаблонами
вордпресс
друпал
да ну его нахер этот пхп
2017
Python Django
Еще ни разу не пожалел
Сайт со всем фаршем, продукты, хелп, статьи, новости, генерация и рассылка ключей, тикеты, в общем полностью закрывает все аспекты.
публикация новых версий продуктов полнсотью автоматизирована, скриптом сбилдило и закинуло на сайт, обновив попутно релиз нотес и т.п.
логика отделена от оформления, потому что философия движка такая.
безболезнено за это время пару раз апдейтил джанго по лтс версиям с 2.0 до 4.0
сейчас планирую небольшой фейс лифтинг сделать, верстку освежить и обновить бутсрап до 5.
в общем слезайте с вашего дотнета, опять же можно сайт не сразу целиком апдейтить а по частям, закрывая те или иные части.
Здравствуйте, Aquilaware, Вы писали:
A>Плюс почти все поисковики сейчас умеют Javascript.
Вы просто верите в это или же есть доказательства сему? Попробуйте найти чисто динамический сайт без пре-рендера и посмотреть что заиндексировал Google.
Все эти новомодные фреймворки создавались для закрытых сред — такие как соц. сети — которые наоборот не очень то хотят, чтобы Гугл доминировал и из индексировал. Или для админок.
A>Для поисковых систем это не будет вызывать проблем, поскольку будет задействоваться пререндеринг
А оно точно будет работать для всех страниц, для пейджинга? Нужно проверять с отключенным JS.
>Кода там — под десять тысяч строк за десятилетие набралось и он такой сцепленный, хрупкий, что вообще страшно сейчас всё это трогать.
Так код же отделен от разметки даже в старом ASP.Net. Проблема видимо в том, что верстальщик вынужден будет видеть серверные контролы, которые не HTML и введут его в ступор. Но погодите — а чем React лучше? Там вообще части HTML разнесены по непонятным для верстальщика файлам и вообще хрен где их искать.
Здравствуйте, Sharowarsheg, Вы писали:
S>Я делаю все свои сайты по образу и подобию вот этого — http://all.net/ S>Так что моё мнение не следует учитывать.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
A>Хотелось бы услышать ваши идеи и опыт по этой теме.
Пререндер я бы выбросил из этого. Коллеги рассказывали, какая это боль. В конце концов это нетипичная работа для сервера: зачем Реакт, если сервер делает то же самое?
Я делаю примерно как вы: у меня бэк на Java, а сайт — отдельная легковесная приложуха на Node.js без БД вообще, тупо HTML'ки склеивает и подставляет данные полученные в JSON от сервера. А вся БД уже на Java-сервере. Никаких React'ов для того, чтобы нарисовать дерево документов не надо, это оверкилл.
У меня массивная dashboard для клиентов, там уже React — он точно также обменивается JSON с Java-бэкендом, ему никакой пререндер не нужен.
Если бы мне нужен был бы простой информационный сайт без всяких админок, чисто показать продукт и кнопку "Купить", я бы взял Drupal 10 и заказал фрилансерам. Но надо следить за обновлениями.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
Мне очень интересна такая тема — насколько реально писать web-скрипты на Lazarus? Т.е. скомпилировать обычный исполняемый файл, который может обрабатывать html запросы. Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Мне очень интересна такая тема — насколько реально писать web-скрипты на Lazarus? Т.е. скомпилировать обычный исполняемый файл, который может обрабатывать html запросы.
Вполне реально. Хошь cgi, хошь расширение для апача.
K> Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
Delphi уже, пять лет как, поддерживает Linux и написать, например, расширение для апача проще простого.
Здравствуйте, rudzuk, Вы писали:
K>> Раньше с Delphi это было неудобно, как я понимаю, потому что Delphi не поддерживает Linux (далеко не все имеют windows-хостинг), а теперь с компиляцией Linux-кода в Lazarus возможно это удачное решение для дельфиста?
R>Delphi уже, пять лет как, поддерживает Linux и написать, например, расширение для апача проще простого.
Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено? Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено?
Borland не имеет отношения к Delphi лет пятнадцать уже.
K> Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
Да. Поддержки гуя из коробки нет. Есть FMX Linux (доступна из GetIt), добавляющая возможность лепить гуй, если очень хочется.
Не вижу смысла использовать на Linux именно Delphi, при наличии FPC и Lazarus.
Здравствуйте, Aquilaware, Вы писали:
A>Коллеги! Более чем уверен что у большинства уже есть рабочие сайты, некоторые из которых даже приносят прибыль. Возник вопрос: если бы вы сейчас рефакторили / переделывали сайт, то какие бы технологии и подходы использовали?
У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
Здравствуйте, Khimik, Вы писали:
K>Просветите пожалуйста, я не очень в курсе. Я думал, что Borland заключили заключение с Microsoft, что Delphi не будет поддерживать Linux. Оно отменено? Я погуглил Delphi Linux, зашёл на сайт Embarcadero и там вроде написано, что писать код под Linux можно, но без визуальных компонентов (VCL или FMX).
Печаль в том, что компилятор под Linux там есть только в редакции Enterprise. В Professional — нет.
Здравствуйте, JustPassingBy, Вы писали:
JPB> Печаль в том, что компилятор под Linux там есть только в редакции Enterprise. В Professional — нет.
Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
Здравствуйте, Shmj, Вы писали:
S>А оно точно будет работать для всех страниц, для пейджинга? Нужно проверять с отключенным JS.
Точно работает, проверено. А для админок где динамика поиск как раз и не нужен.
S>Так код же отделен от разметки даже в старом ASP.Net.
Проблема не столько в самом движке, сколько в стиле написания кода "в одну кучу". В итоге, когда хочется заменить только одну часть проекта, возникает геморой в виде якоря состоящего из всех остальных его частей которые находятся в той же переплетенной куче.
S>а чем React лучше? Там вообще части HTML разнесены по непонятным для верстальщика файлам и вообще хрен где их искать.
Тем, что компоненты самодостаточны и изолированы, т. е. чтобы вставить что-то полезное в страницу не нужно отдельно обрабатывать HTML, отдельно скрипт лепить и отдельно СSS. Вместо этого включается компонент, который всё это автоматически подтягивает на фоне, не вызывая при этом никакой многовекторной боли, какая возникала бы при классическом подходе.
Соответственно появляется возможность переиспользования компонентов в одну строку. Это очень удобно. Компоненты можно выносить в пакеты и переиспользовать в разных проектах. Компоненты можно изолировано улучшать, не боясь при этом случайно посеять хаос в остальных частях страницы.
В ASP.NET так просто этого не сделаешь, поскольку отсутствуют готовые механизмы композиции компонентов. Из коробки есть Layout Pages и Partials и это всё. Когда-то был Web Forms — он в этом плане был получше, но он давно потух.
Здравствуйте, Kerk, Вы писали:
K>У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.
Здравствуйте, sharez, Вы писали:
S>Пререндер я бы выбросил из этого. Коллеги рассказывали, какая это боль. В конце концов это нетипичная работа для сервера: зачем Реакт, если сервер делает то же самое?
Пререндер делается при построении проекта. Сам сервер получается вообще статический. Для этого в качестве основы используются вещи наподобие Gatsby, Next.js.
Поэтому никакие ресурсы ни клиента ни сервера просто так не тратятся. А React используется просто как средство облегчающее программирование методом композии готовых комопонентов.
Здравствуйте, Aquilaware, Вы писали:
K>>У меня сайт на чистом html + блог на вордпрессе. Мне кажется именно в теме шаровары сайты в 99% случаев простейшие. Чего там между drupal и .net выбирать, надо делать максимально по тупому.
A>После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.'
Ну, ключи у меня простой php-скрипт генерирует. Если хочется целую CRM самостоятельно написать, то хозяин-барин конечно. Возможно на каком-то большом уровне это и правда имеет смысл.
Здравствуйте, rudzuk, Вы писали:
R>Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
Низкое качество генерации кода? Компилятор, видимо, не имеет достаточной пользовательской массы, поэтому не особо развивается, видимо. Очень странное решение оставить Professional без него. Только лишний повод переходить на что-то другое.
Здравствуйте, Aquilaware, Вы писали:
A>После определенного уровня такая святая простота становится недостаточной. Например, при таком формате начиная с определенного обьема продаж изготовитель софта будет постоянно в мыле тратитить свое время на генерацию ключей, ведение подписок, активации, обслуживание жизненного цикла пользовательских лицензий. Поэтому рано или поздно это всё ложится на плечи машины, а тут уже как говорится понеслась в плане кода и нарастающей сложности сайта.
Как сайт на вордпрессе мешает автоматической раздаче ключей и чему либо еще? Это все отдельно работает.
Здравствуйте, Aquilaware, Вы писали:
A>Пререндер делается при построении проекта.
Представим, что это React-приложение на главной отображает какую-то статью (берет на лету из БД) и позволяет перейти к следующим.
Если редактор изменит статью в БД, то чтобы поисковики увидели это изменение, мне нужно перекомпилировать и передеплоить проект? Надо ведь заембеддить эту статью в статичные HTML-файлы пререндера. Туда же, кстати, надо заембеддить и все фрагменты-врезки (колонка новостей, новые статьи, свежие комментарии и т. д.).
Здравствуйте, JustPassingBy, Вы писали:
JPB> R>Это да, но там и сам компилятор так себе. Проверял недавно скорость расчета (метод Update) sha256: D11.win64: 55 MiB/s, D11.linux64: 48 MiB/s, FPC 3.2 linux64: 108 MiB/s.
JPB> Низкое качество генерации кода? Компилятор, видимо, не имеет достаточной пользовательской массы, поэтому не особо развивается, видимо.
Это относится не только к Linux-компилятору. Все их LLVM-based компиляторы — а это все кроме компиляторов Windows и 32-битной macOS — генерируют отстойный код. Читал, что по какой-то причине, они не включают оптимизацию в LLVM-бэкенде.
JPB> Очень странное решение оставить Professional без него. Только лишний повод переходить на что-то другое.
Очевидно, сделано для того, чтобы корпоративные клиенты не сидели на дешевых редакциях.
Здравствуйте, Kerk, Вы писали:
K> Ну, ключи у меня простой php-скрипт генерирует. Если хочется целую CRM самостоятельно написать, то хозяин-барин конечно. Возможно на каком-то большом уровне это и правда имеет смысл.
Здравствуйте, sharez, Вы писали:
S>Представим, что это React-приложение на главной отображает какую-то статью (берет на лету из БД) и позволяет перейти к следующим.
S>Если редактор изменит статью в БД, то чтобы поисковики увидели это изменение, мне нужно перекомпилировать и передеплоить проект? Надо ведь заембеддить эту статью в статичные HTML-файлы пререндера. Туда же, кстати, надо заембеддить и все фрагменты-врезки (колонка новостей, новые статьи, свежие комментарии и т. д.).
S>Ну, такое.
Это решенная проблема. Есть концепция под названием Jamstack. Смысл такой: HTML рендерится при построении проекта, после чего он становится статическим. Теперь, когда появляются новые данные (например, статья), есть два варианта: 1) перестроить и передеплоить проект 2) регидрация.
Вариант с построением и деплоем проекта может казаться чем-то сложным, но по факту это делается вызовом одной команды. Благодаря таким сервисам как Netlify и Vercel, деплой сайта из существенной проблемы превращается в очень быстрое и надежное решение.
Теперь 2-й вариант с регидрацией. Его смысл в том, что после загрузки статического содержимого активируется скрипт, который может делать много вещей, но также может и обновлять содержимое из источника данных на стороне клиента. Для клиента это происходит незаметно — сайт как сайт, всё работает и работает хорошо. Примерами таких решений являются Gatsby и Next.js.
Лично я всегда предпочитаю 1-й вариант. Никаких типичных для деплоя трудностей не возникает, т.к. есть абсолютный контроль и полная автоматизация этого процесса и самое главное — нет состояния. Это существенно разнится с классическим подходом, при котором есть приложение, БД и состояние, где любой деплой или чих — это угроза того, что что-то пойдет не так и упадёт.
Здравствуйте, JustPassingBy, Вы писали:
JPB>Как сайт на вордпрессе мешает автоматической раздаче ключей и чему либо еще? Это все отдельно работает.
Никак не мешает, просто одного вордпресса недостаточно чтобы это всё сделать. Можно и на нём конечно, есть даже плагины такие, но оно всё глючное и тормозное.
Использую собственный простенький движок на PHP, из шаблонов только Header и Footer, остальное все чистый HTML.
Пример сайта https://site-analyzer.ru/
Все летает, ничего лишнего, минимум скриптов и прочего мусора, нежели в готовых CMS.
Здравствуйте, Aquilaware, Вы писали:
A>Это решенная проблема. Есть концепция под названием Jamstack. Смысл такой: HTML рендерится при построении проекта, после чего он становится статическим. Теперь, когда появляются новые данные (например, статья), есть два варианта: 1) перестроить и передеплоить проект 2) регидрация.
К сожалению, второй способ не решает проблему предоставления данных поисковику, а именно о нем я говорю.
Первый метод решает, но надо как-то вызывать эту сборку. Тут особенность в том, что редактор и программист — разные роли, и после редактирования контента редактор должен дернуть программиста. Можно, конечно, собирать проект автоматом на сервере, но тогда там надо поднять всё окружение, и быть на 100% уверенным, что в очередной раз билд не завалится (как назло в субботу ночью, когда вы в отпуске) или (ещё хуже) не соберется, но будет в себе содержать ошибку, которую не увидят автотесты.
Если контент меняется довольно часто (не дай бог ещё и UGC), то всё описанное выше усугубляется.
Не то, что бы с этим нельзя было жить, но для сайта шаровары — точно оверкил.
Я думаю, что все эти React + SSR нужны лишь тогда, когда без жирного React-приложения на клиенте вообще не обойтись никак, т. е. не для отрисовки дерева статей, а какая-то админка, которая обязательно должна попадать в поиск Гугла, пусть и с задержкой.
Здравствуйте, Aquilaware, Вы писали:
A>Никак не мешает, просто одного вордпресса недостаточно чтобы это всё сделать. Можно и на нём конечно, есть даже плагины такие, но оно всё глючное и тормозное.
Я не использую плагины, ну кроме мелочей вроде галереи для скриншотов и подобное. Весь нестандартный функционал (генерация ключей, какие-то формы для клиентов чтобы сделать что-то) это все вообще отдельные скрипты, и вордпресс тут никак не участвует.
Отметил такие тенденции: у местной публики компилируемые языки не в почёте, в основном используются скриптовые языки.
Показалось очень интересным решение с Django, т. к. оно представляет собой некий сервер приложений (почти что ОС поверх ОС), в которую "устанавливаются" условные приложения. Чтобы установить приложение, достаточно скопировать соотв. папку с исходным кодом в папку сервера. При этом для всех приложений доступна общая инфраструктура хранения данных, авторизации и еще много чего.
С PHP тоже понятно — положили скрипт, он работает.
Для себя я очень давно зарекся использовать языки без статических проверок в момент компиляции. Причина проста: решения на языках без строгой типизации очень быстро выходят из-под контроля и сопровождать их в итоге становится дорого и тяжело, так как никто не знает где и когда возникнет очередной дефект. Например, банальный рефакторинг кода представляет собой намного более сложную задачу в такой среде. С другой стороны, именно такая лёгкая на подьем скриптовая природа позволяет добиться некоторых интересных результатов, например, как в Django — скопировали папку — появилась функциональность, удалили — исчезла.
Вообщем, не буду идти в скриптовую ловушку, как бы соблазнительна она не выглядела, потому что время накажет. И вообще в ловушку какого-либо одного языка. Устраивает только компонентная модель с условно заменяемыми компонентами со строго определенными интерфейсами независящими от языка, чтобы каждый из этих компонентов со временем можно было бы относительно легко прокачивать на более продвинутые варианты без переписывания всего остального.
Хочу отметить, что я говорю не только о сайте, но и о всех остальных типичных обвязках, таких как помощь, управление лицензиями, подписками, хостинг SaaS и прочее. Понятно, что если вы продаете одну-две сугубо десктопные софтины, то вас такие вопросы скорее всего пока еще не очень трогают. В любом случае, всем спасибо за идеи — этот вопрос на самом деле можно обсуждать вечно. Если кто-то может и хочет что-то добавить, то будет очень интересно почитать.
Здравствуйте, icezone, Вы писали:
I>для небольших сайтов есть своя cms на php, которая из pad генерит базовый набор страниц
Очень интересный подход. Информационное развертывание продукта из описывающих файлов. И никаких кастомных сайтов делать не надо, для нового продукта делаются файлы с его формальным описанием, регистрируются в системе и готово. Тоже хотим со временем к этому прийти.
Жалко что здесь все блюдут анонимность, я бы с удовольствием посмотрел на то как это выглядит у вас.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, icezone, Вы писали:
I>>для небольших сайтов есть своя cms на php, которая из pad генерит базовый набор страниц
A>Очень интересный подход. Информационное развертывание продукта из описывающих файлов. И никаких кастомных сайтов делать не надо, для нового продукта делаются файлы с его формальным описанием, регистрируются в системе и готово. Тоже хотим со временем к этому прийти.
A>Жалко что здесь все блюдут анонимность, я бы с удовольствием посмотрел на то как это выглядит у вас.
ничего особо сложного
есть набор шаблонов на bootstrap, натягиваем тему и дальше скрипт все делает
— стандартный набор из privacy/cookies/terms/contact
— для продукта основная страница/характеристики/скачивание/покупка/changelog
— все это кешируется на диск или в memcached, оттуда напрямую nginx дергает
Здравствуйте, Aquilaware, Вы писали:
A>Для себя я очень давно зарекся использовать языки без статических проверок в момент компиляции.
A>Вообщем, не буду идти в скриптовую ловушку, как бы соблазнительна она не выглядела, потому что время накажет.
Здесь просто: можно зайти в ловушку скриптовых языков, если заниматься этим будешь не сам, а специальные недорогие/бесплатные пых-пых кодеры (сообщество), которые обновляют и поддерживают всё это безобразие. Джумла или ВордПресс, но только, пока сайт простой. Никаких левых модулей, влияющих на структуру сайта ("магазин", "мультиязычность" и т. д.).
Если собственная очень кастомная разработка, то только Java/.NET. Даже в типа-типизированных (но недостаточно) TypeScript бывает, что рефакторинг переменной/поля с именем "data" или "i" может внезапно привести к непредсказуемым последствиям, даже в хорошей IDE типа JetBrains Webstorm. Там ещё есть нюансы с обращениями к полям объекта через точку, либо же как к массиву — как такое вообще зарефакторить?
Я вообще хочу старые скриптовые сайты пройтись краулером, сконвертировать их в тупо HTML-страницы. Всё равно контент давно не обновлялся, а если придется, уже проще опечатку в HTML поменять, чем вспоминать, как песобирать и передеплоивать этот кусок мамонта, не поломав ничего. Потому что если PHP правится прямо на сервере, то это вдвойне ошибка.
Поэтому это технологически устаревшее приложение сейчас только патчится, а время идет и монстр продолжает разрастаться.
