Начнём с того, что современные веб‑сайты условно можно разделить на три типа: контентные сайты, веб‑приложения и гибрид (как правило, контентный сайт, содержащий в себе элементы полноценного веб‑приложения).
Что характерно для контентных сайтов: они созданы для потребления информации, они должны максимально быстро запускаться, они обязательно должны индексироваться поисковыми системами, и у них как правило тонкий клиент.
Примером контентного сайта можно назвать, например, интернет‑магазин, блоговую платформу, или wiki. Чтобы понять, какие подходы использовать — надо отталкиваться в первую очередь от целей и ожиданий пользователя. Пользователь приходит в поисковик с целью найти важную для него информацию, вбивает запрос, и кликает на нужную ссылку. Что он ожидает увидеть? Он ожидает увидеть интересующий его контент. И чем быстрее, тем лучше. При этом, его не волнует — будет там SPA, будет там красивый JS, или лапша из кода. Это для пользователя не первостепенно. Вторая ожидаемая вещь — хороший дизайн, так как он должен помогать проще усваивать тот контент, который мы хотим показать. В таких случаях — всё задачи лучше решать используя сервер, и максимально отказываясь от JS. Немного JS для того, чтобы слегка оживить интерфейс, легкий фреймворк (как пример Evil Blocks, или что‑нибудь похожее) — чтобы ваш код со временем не превратился в лапшу, и его просто было поддерживать.
Использование SPA для контентных проектов, типа интернет‑магазина может быть привлекательным, так как открывает пути улучшения пользовательского опыта, и разных дизайнерских решений. Но при этом, надо быть готовым, что придется решать проблемы индексации контента, и это уже будет выходить за пределы компетенции фронтенд‑разработчика, и ложиться на плечи системных администраторов (в случае, своей инфраструктуры на базе PhantomJS, например), или на плечи руководства (если мы хотим использовать внешний сервис и платить ему деньги).
Также нельзя не сказать, что скорость загрузки сайта, напрямую влияет на прибыль (что еще более критично для веб‑сайта, нежели для веб‑приложения). Более подробно здесь.
Теперь о веб‑приложениях: они ориентированы на создание и обработку информации, идеально было бы, если бы они работали оффлайн, были бы SPA (чтобы улучшить UX опыт пользователей и в целом ускорить интерфейс), и как правило у таких приложений «тонкий сервер». Например, если посмотреть на Google Docs, не в разрезе всего набора Google Apps, то очевидно, что роль сервера сводится к банальным хранить и выдавать информацию — а львиная доля функционала приходится на клиент.
В условиях переноса бизнес логики на клиент, во многих случаях довольно сложно обойтись легковесным фреймворком. Нет сомнения, что написать приложение можно и без готового каркаса, а в некоторых случаях только так и получится. Но чаще, задача построения SPA приложения состоит на 20% непосредственно из бизнес логики. Все остальное приходится на рутинные, переходящие из проекта в проект, задачи. И в таких случаях, готовый фреймворк помогает сосредоточиться именно на бизнес логике приложения, беря на себя всю рутину.
Что касается гибридных типов приложений. Часто возникает ситуация, когда проект вроде контентный, но где‑то могут встречаться места, в которых требуется сложная логика именно на клиенте. Например, может быть какой‑то интернет‑магазин. Но чтобы продажи были лучше, руководство захотело, чтобы была возможность красиво компоновать страницы товаров. Скорее всего, для решения такой задачи потребуется WYSIWIG-редактор. В таких ситуациях, лучше всего придерживаться разработки веб‑сайта, а для тяжелых на фронт страниц — привлекать тяжелые инструменты (хотя, сейчас уже есть замечательный React, который может помочь обойтись без тяжелых Angular или Ember для одной страницы). Страницы, которые созданы для создания контента, как правило не индексируются, и они не доставят проблем в этом плане. При этом, логика остального сайта будет простой и максимально оптимизированной на предоставление контента. А если у вас появилась задача, сделать весьма хитрый виджет на контентной странице — его можно заключить в <noindex>, чтобы в поисковую выдачу случайно не попало нечто, вроде {{ search.results }}.
Подводя итог вышесказанному: ввиду существования разных типов сайтов, всегда будут требоваться разные подходы и поэтому серебряную пулю найти не получится. Единственное на данный момент идеальное решение — держать руку на пульсе и думать головой, правильно анализируя стоящую задачу, и выбирая правильные решения. Несмотря на то, что сейчас активно создаются проекты, которые призваны решить те или иные задачи — пока до конца не ясно, действительно ли они будут более универсальны, или со временем займут только свою нишу. Среди таких проектов нельзя не отметить шаблонизаторы, которые можно использовать и на клиентской и на серверной стороне (как например, React), и фулстек‑фреймворки (такие как MeteorJS).
Отдельно хотелось бы уделить внимание вопросу о скорости страницы. Для меня этот вопрос неоднозначен.
Если мы говорим о контентном сайте, то для меня крайне важна скорость загрузки страницы. Так как это, в первую очередь время, через которое я получу доступ к интересующему меня контенту. Но как правило, в таких ситуациях, сразу бросаться оптимизировать JS не имеет смысла. Проще, и выгоднее подумать над дизайном и UX. Например, мы хотим загрузить страницу блога, и помимо статьи у нас еще куча комментариев. Мы можем загружать страницу без комментариев, и догружать комментарии после. Таким образом, мы уменьшаем мнимое время загрузки страницы (пользователю на самом деле кажется, что она грузится быстрее, так как он быстрее получает свой контент и сосредатачивает внимание на нем), и не тратим время на судорожное профилирование JS, которое займет столько же или более времени, но может не дать такого же выигрыша по времени.
Если же говорить о веб‑приложении, то здесь конечно, стоит думать под другим углом. Пользователь будет работать с приложением какое‑то количество времени, приложение будет обрабатывать большое количество данных. И в этих условиях, конечно надо подумать, как избежать больших утечек данных, как сделать так, чтобы при большом количестве данных, приложение не начало тормозить (держим в голове, что разрабатывая на Macbook Pro, у пользователя может быть ноутбук пятилетней давности, в котором и одна вкладка браузера может тормозить, а сидеть он будет в IE8). В таких ситуациях, лучше оптимизовать уже код, и думать над UX, чтобы можно было обойти узкие места, которые не получается решить технически.
Таким образом, отвечая на первоначально поставленный вопрос — используя VanillaJS, jQuery лапшу или <вставить название фреймворка>, при должной прямоте рук разработчика, дизайнера и UX-специалиста — можно создать действительно быстрый сайт, от работы с которым, пользователи будут в восторге.
