О сайтах, выполненных на фреймворках

Когда-то ранее, лет 20-30 назад, когда сайтостроение только начиналось, никаких фреймворков, конечно, не было. Все вебстраницы, сайты делались вручную. Да и сайтов, собственно говоря, было сравнительно немного. Браузеров тоже было  немного, да еще каждый из них имел определенные особенности. Более того, даже браузер одного и того же разработчика (например, Internet Explorer) мог отличаться, с точки зрения разработчика сайтов, от версии к версии. Ситуация стала меняться, когда интернет вошел в жизнь практически каждого человека, когда он перестал быть уделом узких специалистов. В результате, стали появляться новые браузеры, затем - библиотеки для работы в браузерах (как правило, на языке javascript). А также библиотеки для серверного программного обеспечения. И, наконец, появились так называемые фреймворки.

В последние годы их число заметно увеличилось. Пожалуй, только основных, наиболее известных среди них - несколько десятков. Одними из таковых является, например, Laravel и Vue (React). Эти фреймворки нынче (если брать 2025 год) настолько популярны, что даже в списках вакансий на целевых сайтах, посвященных поиску работы (и работников), в соответствующих целевых нишах, то и дело встречаются вакансии именно на базе этих технологий. Более того, даже можно сказать, что таких вакансий, по всей видимости, подавляющее большинство. В гораздо меньшей степени встречаются вакансии на основе остальных фреймворков, например, какие-нибудь условные OpenCart, MODX и т.д.

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

Стоит ли делать сайт на фреймворке Vue?

Вообще, для того, чтобы принять какое-либо рациональное (логически и практически обоснованное) решение, необходимо, конечно, иметь систему критериев. Исходя из которой уже можно делать вывод. Какими критериями будем руководствоваться? Это, в порядке снижения актуальности, следующие

Возможно, эта система (основных) критериев качества вебсайта кому-то покажется спорной. Однако, при необходимости ее вполне можно обосновать с научной точки зрения. Если принимать во внимание, в первую очередь, потребности пользователя, а уже потом - потребности и возможности разработчика. Отметим, что если игнорировать потребности пользователя, то тогда вполне подойдет просто чистый текст на странице, ну, и ссылки, картинки. И - практически никакого оформления, удобства, интерактивности.

В конце концов, сайты делаются именно для пользователей. А не для того, чтобы ими пользовались только разработчики. Правда, определенная часть нынешних разработчиков придерживается слегка иного мнения. Например, есть множество таких, которые уверены, что люди должны пытаться пользоваться именно тем (***), которое они создали и не рассчитывать на лучшее. Но, это уж, как говорится, нюансы.

Пройдемся по указанным критериям, насколько им соответствует фреймворк Vue.

1. Функциональность как отдельной вебстраницы, так и всего вебсайта в целом: как фактическая, так и потенциальная

Вообще, функциональность - понятие относительное. Есть простые статические, информационные сайты. Которым нужен минимум функциональности, главное, чтобы в интернете отображалась та или иная информация. Правда, сложно назвать такие сайты современными. При необходимости добавления хоть какой-то дополнительной функциональности такой сайт придется существенно дорабатывать.

А есть сложные сайты, например, какой-нибудь Youtube, электронные биржи, социальные сети или игровые ресурсы. Для подобных ресурсов, скорее всего, стандартный фреймворк не подойдет, там оптимальнее будет делать самостоятельную разработку, не будучи связанными ограничениями фремворка. Впрочем... определенные индивиды применяют тот же Vue даже для социальных сетей и не только. А некоторые другие еще и оправдывают такие решения. 

Вообще, наиболее известные фреймворки предназначены для создания "типичного" современного сайта. Т.е. это - текстово-графический, в том числе медиа, контент и типичные элементы интерактивности. Это может быть и условный лендинг-одностраничник, и интернет-магазин, и сравнительно крупный форум. И в целом, для большинства ресурсов этого достаточно. Правда, в результате, по мере разрастания ресурса, возникает одна и та же, общая проблема: снижается скорость доступа к вебстраницам. Существенно повысить которую средствами фреймворка, как правило, невозможно. В подобных случаях решение одно: переход на более мощный сервер. Соответственно, на условиях более высокой оплаты, роста расходов на администрирование.

Если же возникает специфическая задача, то типичный фреймворк может уже и не подойти. 

2. Объем ресурсов, загружающихся с сервера клиенту (например, в браузер)

На этом стоит тоже остановиться отдельно. Когда-то давно, лет 20 назад, если сайт просто работал и что-то там выдавал пользователям для просмотра, было уже хорошо. Тогда в ходу были разные автоматические генераторы html-кода. Которые давали легкую возможность создавать html-код для вебстраниц, но это был "грязный" код. Он практически всегда содержал излишнюю разметку (теги), множество избыточных атрибутов. Все это, конечно, как-то там работало, но создавало существенную нагрузку как на сервер, так и, что важно, на браузеры пользователей. Что, при тогдашней скорости интернета, равной сотню-другую килобайт в секунду, было таким себе "удовольствием".

Потом поисковые системы, в частности, Яндекс и Google (это было в середине 2010-х годов) решили положить этому конец и почистить поисковую выдачу от подобных сайтов. И молодцы, в этом смысле.

В результате, очень скоро разработчики поняли: либо делать вебстраницы быстро, но их мало кто будет смотреть; либо делать качественно. Т.е. - вручную. Со временем, профессионалы обзавелись соответствующими шаблонами и проблема с избыточностью html-разметки, а, значит, и со излишне высоким объемом интернет-трафика, была, в целом, решена.

Потом, со временем, многие интернет-провайдеры стали выдавать более и более высокую скорость трафика. Ряд из них давали даже безлимитный трафик, т.е. неограниченный объем входящего и исходящего трафика на определенной скорости в течение оплаченного периода времени. И вот этот фактор и обусловил, собственно, появление абстрактных высокоуровневых решений для создания вебстраниц, т.е. появление, в том числе, конструкторов сайтов и фреймворков. Что, в какой-то мере, сыграло злую шутку и с пользователями интернет-сайтов, и с самими разработчиками.

Почему? Потому, что такие решения практически всегда обладают существенным недостатком: избыточностью интернет-трафика. Это плохо как для сервера, так и для клиента (пользователя). И если ранее поисковые системы недоброжелательно относились к такому явлению, справедливо заботясь о пользователях, то в 2020-е годы они стали относиться к подобным нюансам гораздо более терпимее. А это, в свою очередью, повлекло за собой все более и более нагроможденные абстрактные решения.

Что обуславливалось и обуславливается, конечно, исключительно волюнтаризмом разработчиков. Точнее, банальной причиной нежелания серьезно изучать языки программирования и при этом - желанием поскорее сделать что-то работающее. И, да, чтобы за это что-то еще и заплатили побольше. Собственно, "мыльный пузырь" высоких заработков в сайтостроении был обусловлен именно этим фактом: халтура, но сделана быстро и работает.

3. Стоимость поддержки

Этот фактор неслучайно стоит на третьем месте. Он важнее, чем стоимость разработки. По той очевидной причине, что изначальное техническое задание на разработку практически НИКОГДА не содержит всей той функциональности, которая потребуется владельцу сайта в будущем. За исключением, конечно, стандартизованных шаблонных решений. Последние стоят, как правило, недорого.

Как бы ни стараться писать полное техническое задание (ТЗ), все равно всего не предусмотришь Кроме того, разработка полноценного, качественного ТЗ - это отдельная статья расходов, сопоставимая со стоимостью разработки всего сайта. Это - задача для таких специалистов, как программный инженер, архитектор, аналитик. 

Поэтому стоимость поддержки (доработки, устранения ошибок) сайта бывает, как правило, гораздо выше, чем стоимость его первоначальной разработки. И именно ее стоит принимать во внимание.

Стоит отметить, что недобросовестные разработчики зачастую умалчивают об этом. Вводя заказчиков в заблуждение "крутыми и современными" технологиями.

Если взять аналогию с автомобилями, но это примерно как покупка бывшего в употреблении автомобиля дорогой, престижной марки. Да, престижно, впечатляюще, функционально и удобно. Но, ровно до тех пор, пока что-нибудь не сломается. После этого - расходы, расходы и еще раз расходы. Ну, или путь на продажу по существенно сниженной стоимости. Или - в металлолом. Как вариант - на постоянную стоянку в качестве музейного экспоната. Практически так же обстоит дело и с сайтом, построенным на технологиях, которые дорого обслуживать.

Разумеется, подобных проблем вполне можно было бы избежать, если (законом) обязать разработчиков выполнять обслуживание и поддержку сайта по соразмерной себестоимости или обязать оплачивать такую поддержку. Скажем, в течение 10-15 лет. Однако, пока что подобного закона, вроде как, нет ни в одной стране мира. А в частном порядке едва ли кто из разработчиков пойдет на это при условии адекватной стоимости разработки. Да и невозможно, наверное, обязать быть столь ответственными всех разработчиков. По крайней мере, сейчас.

Что, как видится, временное явление. Ведь уже давно существует законодательство, обязывающее производителей автомобилей и иной техники оказывать послепродажное обслуживание в течение определенного времени. Думается, что и для разработки сайтов рано или поздно появятся подобные правовые нормы.

Стоимость поддержки целиком и полностью зависит от технологий, примененных при разработке сайта, а также от качества реализации таких технологий. Именно поэтому практически все те компании, кто занимается разработкой, в первую очередь желают иметь понятный и легко обслуживаемый программный код, даже(!) в ущерб его производительности и объему. Однако, тут далеко не все просто.

Можно сделать сайт полностью самописным (вплоть до написания его на языке С/С++). И он, вполне возможно, будет рекордсменом по скорости и экономии интернет-трафика при наличии функциональности, аналогичной другим сайтам. Однако, кто сможет адекватно поддерживать такой сайт? Если судить по настоящему времени, подобных специалистов не столь и много. И стоимость поддержки там будет существенно высокой. Да и стоимость разработки - тоже.

Более того, программные коды на С/С++, в отличие от языков программирования высокого уровня, типа Python или PHP, гораздо более опасны с точки зрения наличия возможных уязвимостей.

А можно сделать сайт в каком-нибудь конструкторе сайтов. И такой сайт даже будет (вот это да!) загружаться в браузер пользователя. Но, это - такое себе, если подразумевать более-менее постоянное использование. Ибо компьютер (или телефон, иное устройство) пользователя будет потреблять существенные ресурсы; будет высоким и интернет-трафик. Если сайт будет мало-мальски функциональным. Да и поддержка, в плане добавления дополнительных функций, может оказаться невозможной. Ни о каком ускорении работы, разумеется, и мечтать не придется.

Как промежуточный вариант, можно сделать сайт на каком-нибудь фреймворке. На том же Laravel или Vue. Скорость разработки будет промежуточной: несколько ниже, чем для самописного сайта, но существенно выше, чем для сайта на конструкторе (или готовой CMS). О вот со стоимостью поддержки может быть, в общем случае, очень по-разному.

Во-первых, вплоть до настоящего времени отсутствуют строгие стандарты для разработки сайтов. Поэтому разработчики, как правило, орудуют, кто во что горазд. Почему? Потому, что хотят сделать по-быстрее (сэкономить), но получить побольше оплаты. Поэтому нередки случаи, когда на сервере присутствуют не один, а даже несколько фреймворков. Плюс к тому, еще и сторонние библиотеки. Это все приводит к неоправданному усложнению архитектуры сайта. И, соответственно, к неоправданному росту усилий и расходов на поддержку сайта.

Даже если сайт сделан "честно", т.е. если там используется лишь один фреймворк, одной из проблем является "грамотная" архитектура сайта. Так как строгих, вменяемых правил для архитектуры (пока) нет, что каждый разработчик, индивидуально или в команде, склонен использовать свою архитектуру, максимум, придерживаясь определенных общих принципов, характерных для того или иного фреймворка. И если в будущем таким сайтом займется другой разработчик, ему будет сложно разобраться, по крайней мере, на начальном этапе. 

Отдельный вопрос - это обновление фреймворков. Например, в широко известном Laravel уязвимости находят каждый год. Соответственно, необходимо каждый раз своевременно обновлять фреймворки.

А вместе со фреймворком придется обновлять, разумеется, и версию языка программирования, на котором он написан. Для Laravel это - РНР. Известно, что новые версии этого языка (PHP 7, 8) имеют определенное отличие и в синтаксисе, и в результатах выполнения тех или иных команд.

Это, в сухом остатке, обуславливает необходимость перехода на новую версию РНР, синхронно с обновлением фреймворка. И если на сайте присутствуют программные коды, выполненные на "чистом" PHP, который уже устарел, то их придется исправлять. Это - отдельная работа, имеющая немалый объем для серьезных и масштабных вебресурсов.

Разработчики сайтов, агитируя заказчиков на использование фреймворков, как правило, НЕ оговаривают с ними этот нюанс. Просто оставляя его за кадром. И если заказчик неопытен, не в курсе дела, то он, через несколько лет использования сайта, КАК ПРАВИЛО, сталкивается с неприятным "открытием". Что придется либо мириться с уязвимостями (т.е. терпеливо и спокойно ожидать, когда же сайт будет взломан), либо доплачивать разработчикам чуть ли не повторную стоимость сайта.

Если же разработчики не будут использовать "чистый" РНР вообще, если они ограничатся только тем синтаксисом, который доступен в самом фреймворке, то это существенно ограничит их возможности и, следовательно, существенно ограничит функционал сайта.

Поэтому, в целом, стоит сказать, что поддержка сайтов, выполненных на фреймворках, это игра в рулетку. Вполне может статься так, что через какое-то время (несколько лет) придется доплачивать разработчикам солидные суммы даже не за добавление нового функционала, а только за то, чтобы сайт хотя бы просто работал, как полагается и не являлся опасным.

От этих нюансов полностью избавлен полностью самописный сайт, без фреймворков, стандартных CMS. Разумеется, при условии, что самописные программные коды выполнены корректно, без уязвимостей. Такой сайт может работать, условно говоря, десятилетиями. Да, быть может, на использовании старых версий языков программирования (например, РНР 5 или даже РНР 4). Да, эти версии работают медленнее, чем более новые. Но, зато - вообще без каких-либо хлопот по необходимости периодических обновлений (если нет уязвимостей, внесенных разработчиками, повторимся). А если уж захочется что-то обновить - так это исключительно по желанию владельца сайта, но не по вынужденной необходимости. Последнее экономит не только средства владельцев сайтов, но и нервы. А также время.

4. Стоимость разработки

Как уже отмечалось ранее, стоимость разработки выше всего, как правило, для самописных сайтах, особенно, если они сделаны на "низкоуровневых" языках, типа С/С++. Бывают, конечно, сайты и на Ассемблере, но это уж совсем редкость.

Что же касается высокоуровневых языков, типа java, Python, C# или РНР, то тут со стоимостью не все так однозначно.

С одной стороны, самописный сайт будет содержать то и только то, что в него вложили его разработчики. Если у заказчика нет необходимости получать сразу много функционала, то стоимость разработки может быть достаточно низкой. А потом, по мере развития сайта, можно уже добавлять функционал так, как захочется. И/или исправлять уже имеющийся. Поэтому стоимость его разработки будет тем выше, чем больше и обширнее его функционал.

С другой стороны, любой, мало-мальски серьезный фреймворк изначально, "в коробке" содержит массу разного функционала, который может быть подключен разработчиками буквально несколькими строчками программного кода. Сразу или со временем. Такое положение дел даже названо "изящным", а самих разработчиков авторы фреймворков именуют как "художников". Что, на наш взгляд, несколько некорректно. 

Однако, нравится это или нет, программный интерфейс фреймворка - это, как правило, ДРУГОЙ ЯЗЫК программирования. Пусть и основанный на каком-либо "чистом" языке, например, том же PHP.

Поэтому разработчик, выполняющий сайт на фреймворке, обязательно должен уметь использовать не только программный интерфейс самого фреймворка, но и интерфейс "чистого" языка, на котором он основан.

Отдельно стоит вопрос на предмет того, какие функции сайта выполнить на "чистом" языке программирования, а какие - на фреймворке. В общем случае, выбор тут не определен. И как поступит тот или иной разработчик (или компания разработчиков) - предсказать практически невозможно. Прописать все в детальном техническом задании - практически нереально.

А это все влияет не только на стоимость, но и на легкость последующей поддержки, доработки, добавления нового функционала.

Краткий разбор типичного современного (на 2025 г.) сайта, выполненного на Vue

В целях наглядности, приведем типичный пример соответствующей вебстраницы. Которая как раз ведет речь об этом фреймворке. Судя по определенным нюансам, можно предположить, что вебстраница выполнена, по крайней мере, не без использования Vue. Посмотрим, что там и как. Стоит ли вообще с этим связываться.

Ни в коем случае речь не идет об аудите и чем-то подобном. Во-первых, потому, что нам это не оплачивали, а, во-вторых, совсем не в этом состоит цель разбора. Наша цель сейчас - лишь обратить внимание на некоторые нюансы, которые просто бросаются в глаза. На нюансы, возникающие при использовании фреймворков, в частности, Vue. Поэтому мы не будем делать никаких выводов о качестве сайта, удобстве, функциональности и т.п. Обратим внимание лишь на ряд технических аспектов. В частности, на большой объем интернет-трафика, возникающего при загрузке вебстраниц того сайта (см. ссылку выше). 

1. Общий объем полезного текстового контента на странице, составляет примерно 7 тысяч символов (примерно 7 кБ). Т.е. это - объем небольшой вебстраницы. Для сравнения, объем этой статьи, которую вы сейчас читаете, составляет около 30 тысяч символов, т.е. примерно 30 кБ (что можно считать средним объемом). 

2. Тогда как объем HTML-кода, передаваемого сервером в интернет-трафике для страницы по ссылке, составляет аж 668 с лишним тысяч символов. Т.е. полезный текстовый контент составляет лишь 1% от общего объема html-кода.

Для сравнения, объем html-кода этой страницы составляет где-то 63 тысячи символов. Т.е. полезного контента у нас 30/63 = 0,48 или 48%. Это в почти в 50 с лишним раз выше, чем на вебстранице по ссылке. Соответственно, страница по ссылке почти в 50 раз менее эффективна в плане расхода интернет-трафика.

М-да... За что что же столь высокий расход интернет-трафика? Чем провинился пользователь, скачивающий ту страницу? Да и он ли провинился? Давайте посмотрим.

3. Открыв исходный код этой той вебстраницы, в разделе <head>...</head> видим страшное вот это:

opacity:0;transform:translate3d(0,-2000px,0)}to{opacity:1;transform:translateZ(0)}}.fadeInDownBig{animation-name:fadeInDownBig}@keyframes fadeInLeft{0%{opacity:0;transform:translate3d(-100%,0,0)}to{opacity:1;transform:translateZ(0)}}.fadeInLeft{animation-name:fadeInLeft}@keyframes fadeInLeftBig{0%{opacity:0;transform:translate3d(-2000px,0,0)}to{opacity:1;transform:translateZ(0)}}.fadeInLeftBig{animation-name:fadeInLeftBig}@keyframes fadeInRight{0%{opacity:0;transform:translate3d(100%,0,0)}to{opacity:1;transform:translateZ(0)}}.fadeInRight{animation-name:fadeInRight}
...
{padding-top:13px!important}body.public .pt-14{padding-top:14px!important}body.public .pt-15{padding-top:15px!important}body.public .pt-16{padding-top:16px!important}body.public .pt-17{padding-top:17px!important}body.public .pt-18{padding-top:18px!important}body.public .pt-19{padding-top:19px!important}body.public .pt-20{padding-top:20px!important}body.public .pt-21{padding-top:21px!important}body.public .pt-22{padding-top:22px!important}body.public .pt-23{padding-top:23px!important}body.public .pt-24{padding-top:24px!important}body.public .pt-25{padding-top:25px!important}body.public .pt-26{padding-top:26px!important}body.public .pt-27{padding-top:27px!important}
...

И все в таком же роде; объем правил для стилей просто непомерно огромен и, что любопытно, практически совершенно не нужен. Даже при том, что текст стилей - сжат, там нет лишних пробелов, переносов строк и т.д. А если не сжимать - так объем стилей увеличится еще больше.

Это - стили (идущие буквально нескончаемым потоком), предназначенные для этой (и только этой) страницы, записанные в теге <style>...</style>. Практически все они - совершенно бесполезны, т.е. лишь просто занимают место: расходуют (и очень существенно) интернет-трафик и ресурсы компьютера пользователя. 

А потом, когда объем требуемых ресурсов еще более возрастет, пользователю предложат... правильно, обновить браузер; а потом - обновить компьютер, чтобы установить более новый браузер. Так может, лучше разработчики сайтов что-то у себя обновят или исправят? Чтобы не вынуждать пользователей на эти разные обновления.

Что тут сказать? Неопытность разработчиков, в нарушение рекомендаций поисковых систем? Или? Не будем делать выводы, читатель может их сделать самостоятельно.

Отметим лишь одно, в этом отношении. Ведь вместо того, чтобы при каждой загрузке вебстраниц с сайта терроризировать браузер пользователя многочисленными (совершенно избыточными, мегаизбыточными) стилями, гораздо эффективнее непосредственно, в html-коде, задать эти стили в атрибуте style. Ведь он для этого как раз и предназначен. Например:

 <p style="padding-top:16px">Наш абзац</p>

Дело-то в том, что браузеру совершенно без разницы, откуда брать этот стиль: то ли из класса (или идентификатора), то ли из атрибута. Да, в последнем случае, как пишут специализированные СМИ, время рендеринга страницы будет несколько выше. Но, это "несколько" - очень несущественно. 

Если такой стиль повторяется более, чем в 3-5 местах html-кода вебстраницы, тогда можно (но необязательно) задать для него соответствующий класс, идентификатор. И - ликвидировать те стили, которые совершенно не нужны. Если не все, то хотя бы 95% из них.

Однако, по всей видимости, разработчики, использующие фреймворк, не будут это делать. И не только исходя из своей веры-убеждений. А, в основном, потому, что - фреймворк. Он накладывает определенные ограничения.

4. Более того. Помимо этих стилей, встроенных в вебстраницу, последняя загружает еще и файлы стилей (имеющей, как известно, расширение scc). Это - файлы с именами типа swiper-vue.5a9197c8.css. Автору статьи удалось насчитать целых 12 подобных вебзапросов.  

А это - почему? Еще раз: потому, что фреймворк. Да-да, Vue. И если вдруг разработчики решили сделать сайт на этом (или аналогичном) фреймворке, им придется не только мириться с массой таких файлов, с массой дополнительных (совершенно избыточных, только мешающих) вебзапросов. Более того, им еще и придется убедить заказчика, т.е. обмануть его, что "так надо". Что это оттого, мол, что "Vue - крутой фреймворк". А вы, мол, заказчик, "не лезьте не в свое дело, ведь вы - не специалист". 

5. Отдельного разговора стоит дублирование полезного контента. Причем - полное дублирование. Это легко видеть, если пролистать огромную совокупность css-стилей, ближе к концу. Вначале контент, его html-код идет, как обычно, как он и должен идти. А вот потом он дублируется в теге <script>...</script>.

Почему? А потому, что - фреймворк Vue. И никуда от этой каторги-нагрузки, вероятно, не деться. Если разработчик вдруг решил использовать "это".

И еще ладно, когда контента на странице - очень мало, всего-то 7 кБ. А что будет, если он составит сотни килобайт?...

Что сказать? Еще годах так в 2015-2020 Яндекс и Google жестко банили сайты за такие проделки. И правильно делали, видимо. Так как пользователь, решивший открыть подобную вебстраницу, "попадал" на очень большой объем трафика.

Но, сейчас времена изменились и за этим уже мало кто следит. Например, на известном сайте РИАНовости наблюдается практически то же самое. И ничего, этот сайт нынче вполне себе в первых позициях поисковых систем - по тематическим запросам.

В итоге, пользователи скачивают кучу абсолютно ненужного, мусорного трафика, оплачивая его (если интернет не безлимитный). Этот трафик многими мегабайтами бесполезно гоняется по сети, создавая нагрузку как на исходные серверы, так и на саму сеть, на DNS узлы и т.д. Потому как дело-то не столько в том конкретном сайте; он взят лишь как типичный пример, "образец". Подобных сайтов, выполненных на "крутых и современных" технологиях нынче - масса. К сожалению.

Почему же так происходит? Ответ: исключительно вследствие нежелания современных разработчиков делать высококачественные сайты. А если точнее, от нежелания нынешних разработчиков задуматься об удобстве пользователей, об экономии их интернет-трафика и ресурсов компьютеров (браузеров).

Часто можно встретить рассуждения, что, якобы, использование фреймворков типа Vue "ускоряет и облегчает процесс разработки". Да, это действительно так. Но, только для не слишком опытных разработчиков. Только для тех, кто не имеет надлежащей квалификации. Иной раз подобные разработчики где-нибудь на интернет-форумах задают совсем уж "детские" вопросы по html или javascript. Ну, а те, кто, помимо фреймворков, использует еще и искусственный интеллект для подобных целей, так называемые вайбкодеры, это уж и вовсе, что называется, за скобками.

А также для тех, кто готов сделать "готовый информационный продукт" быстро и за хорошую оплату. А что там с качеством?... Ну, мол, загружается, работает. И даже (пока) не тормозит. Что, мол, еще нужно.

Но, это - лишь на этапе разработки

А вот когда заказчик, получивший "такое", выполненное на Vue и ему подобных решениях, сталкивается с необходимостью доработок, модернизаций - вот тут стоимость получается уже не просто "хорошей", а очень хорошей. Мягко говоря. Т.е. высокой. Но, это уже потом, через несколько лет. Когда, вроде бы, и бросать сайт жалко, в него, мол, столько средств вложено. И дальнейшая модернизация стоит все дороже и дороже. А еще - периодически возникающая настоятельная необходимость обновлений (чего нет для самописные сайтов, не использующих фреймворки). Когда в результате перестает работать часть функциональности и это необходимо исправлять...

Именно поэтому зачастую от разработчиков, пытающихся сделать доработку на уже выполненном ранее сайте, часто можно услышать предложение - переделать все заново. Почему? Потому, что, еще раз: если использовать Vue и ему подобные решения, ГОРАЗДО ПРОЩЕ сделать еще один сайт с нуля, чем дорабатывать уже имеющийся, если речь идет о мало-мальски серьезной доработке. И дело тут вовсе не в "неправильной архитектуре". Дело даже не столько в "ошибках предыдущих разработчиков", хотя они - нередко встречаются. Дело тут - в самой системе и особенностях, налагаемых фреймворком Vue, в частности.

Когда легко в учении (т.е. в начале), нередко, тяжело в бою (в конце).

Вот даже взять ту страницу (по ссылке). Человеку, который видит ее исходный код с нуля, который ее ранее не выполнял, гораздо проще и быстрее переделать ее заново. Как полагается. Чем вникать и вносить исправления. Тем, кто отважился на сайты, выполненные на Vue и т.п., стоит иметь это в виду. Особенно, если человек (или организация) платит за выполнение таких сайтов свои кровные деньги.

Выскажем, вероятно, не слишком умную вещь. Хотя...

На наш взгляд, изменить сложившуюся ситуацию можно, лишь введя ограничения на пользование интернет-трафиком. Либо - если политика поисковых систем вернется к той, что была лет 10 назад. Это вмиг разгрузит сети, сайты вновь станут экономичными и легкими и при этом - столь же функциональными. Да и серверных мощностей потребуется гораздо меньше.

Может, в самом деле стоит задуматься об экономии интернет-трафика, пусть и таким образом? Хотя, это как бы такое, не слишком-то демократическое, не либеральное решение. Однако, как быть, куда деваться(?), когда немалая часть нынешних разработчиков сайтов массово злоупотребляет этой самой "демократией", т.е. (пока еще) быстрым и часто безлимитным интернет-трафиком. Злоупотребляя, попутно, и ресурсами компьютеров пользователей, вынуждая их браузеры загружать из интернета и обрабатывать огромные, заведомо избыточные объемы данных.

Как вариант, не стоит ли поисковым системах (Яндексу, Google, Bing и прочим) задуматься хотя бы о неких предупреждающих метках? Показывающих, например, объем скачиваемых ресурсов, как это сделано для файлов pdf. Причем, стоит делать это в разрезе {общий объем трафика / полезный объем трафика}. Например, для странице по ссылке эти цифры будут составлять {660 кБ / 7 кБ}. А для страницы, которую вы читаете, соответственно, {63 кБ / 30 кБ}.

Чтобы пользователям не приходилось вдруг, по неосведомленности, скачивать массу ненужного трафика. Возможно, ряд пользователей предпочтет открыть альтернативную, более экономичную вебстраницу (при ее наличии).