Выбор js-фреймворка

Зря, вам как минимум при ваших потребностях придется решить 2 самые первые проблемы: 1. роутинг и 2. хранилище

Я честно сказать вообще не представляю как это делать, видимо все решение будет заключатся в том, что при клике куда то будет ajax запрос, который вернет кусок html и его просто вставят в нужный контейнер, и когда роутов станет примерно пара десятков, кода будет примерно пара тыщ строк в которых по большей части будет колбэк хэлл.

Фреймворки решают основную проблему - архитектуру приложения, принципы внедрения зависимостей, компонентный подход и шаблонизацию. Бэк у вас остается просто постоянным централизованным хранилищем данных, который по запросы выплевывает JSON сущности, а весь код на фронте который в том числе покрыт тестами.

При том тот же Vue вполне себе позволяет юзать jQuery плагины без каких то проблем или костылей.

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

На вопрос "Вася, а где у нас приказы в твоей системе ?" легче отослать ссылку на страничку с приказами, чем объяснять куда и как тыкать в аяксовом интерфейсе.

Данный вопрос уже очень давно решен и вполне можно отсылать ссылку на страницу, даже без всяких #! в урле, а как вполне обычную

Я бы советовал Vue, разобраться с ним проще чем с Angular/React, работает он даже быстрее чем оные. И самому понять будет проще.

Сам по себе Vue предполагает компонентную разработку из коробки и имеет пачку крутых функций, чего в JQuery нет.

Аналогично я за vue, vuex ну и не за горами будет nuxtjs если нужно что бы индексировалось ПС, решить можно все что угодно, с невероятной скоростью разработки. Не с каким jquery это сравнивать просто нельзя, это в корне разные вещи для разных задач.

есть схема страницы. какие блоки куда грузятся

и сценарий, что происходит. по большей части храним в data-attributes

собственно прототип для того и делается, чтобы потом решить стоит ли переходить куда-то

будем исходить из потребностей.

сервис будет публичный, так что можно будет пощупать, посмотреть

То, что лучше знает он и вы - на чем порешаете.

Если не будет динамики - то вам вообще фреймворк не нужен в браузере.

А крайне полезен будет ES6 и более свежий, в котором уже запилили основной функционал из jQuery.

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

Для транспиляции рекомендую Rollup + Babel, это будет проще и быстрее работать, чем более старые, но более известные комбинации с Webpack, Gulp, Grunt. А заодно и код вычищаться неиспользуемый будет.

Если веб-морда сайта динамическая - то сейчас активно хвалят, в том числе и за простоту и функциональность Vue.JS.

Если сайт с очень сложным веб-интерфейсом - то уже имеет смысл мощь Angular.

В любом случае, если речь касается современных инструментов - то дело будет не только в фреймворке.

Еще и современная версия JavaScript с транспиляцией или TypeScript или Dart. Без них, на старой версии JavaScript, современные фреймворки не работают или вообще или работают ограничено.

---------- Добавлено 19.10.2018 в 19:40 ----------

Во первых, jQuery не фреймворк. А библиотека.

Во вторых, самый часто употребимый функционал jQuery уже несколько лет как перекочевал в современные версии Javascript (начиная с ES6/ES2015) и для проекта, начинаемого "с нуля" нет никакого смысла в jQuery. Тут jQuery уже сделал свое дело, на нем были отточен тот функционал, что в конечном итоге вошел в сам язык программирования.

Необходимость jQuery на сегодня еще есть:

• Если какие-то уже имеющиеся компоненты будут использоваться, которые требуют jQuery.
• Есть еще необходимость jQuery, если идет речь о поддержке Internet Explorer 8.

---------- Добавлено 19.10.2018 в 19:43 ----------

Ну тут зависит от того, что за планы вы ставите перед собой.

Скажем если рассматриваете как пример Megaplan,

то посмотрите и на опыт Wrike.

Их опыт - это создание полноценнейшего приложения, исполняемого в браузере.

Они выбрали AngularDart - по их мнению для подобного сложного функционала это то, что надо.

---------- Добавлено 19.10.2018 в 19:44 ----------

Это касается только простых проектов.

Для сложных - никакие тонны документации по другому коду вам не помогут.

Когда ваш собственный недокументированный код станет достаточно велик...

---------- Добавлено 19.10.2018 в 19:46 ----------

Для любого сколько нибудь сложного проекта - разработчику придется вникать и вникать в тонны уже написанного.

Это нормально.

Это его типичная работа.

---------- Добавлено 19.10.2018 в 19:53 ----------

Это не совсем так.

Года три живет версия.

Но за три года вы напишите тонну своего кода, из-за которой фреймворк будет с трудом виден. И основные проблему будут уже у кода вашего, а не у кода фреймворка.

Если вы достаточно компетентны, чтобы работать с такими тоннами кода, то и сами должны понимать, что вам придется как-то это все структуировать, причем сразу.

Вы или придумаете свою структуру, по сути, свой фреймворк - или воспользуйтесь готовым.

В любом случае - выбор инструмента это дело самого разработчика. Или старшего разработчика в группе разработчиков.

---------- Добавлено 19.10.2018 в 19:56 ----------

Люблю я такие примеры: "Как у Гитхаба, как у Гугля и т.п."

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

"То, что хорошо Юпитеру, то противопоказано быку."

Шибко древняя латинская поговорка.

---------- Добавлено 19.10.2018 в 19:59 ----------

Что именно "проще и быстрее" - зависит от конкретных навыков конкретного разработчика.

Выбор jQuery в конце 2018 года для нового проекта - довольно странный выбор.

Ибо часто используемый функционал jQuery уже года 3 как въехал в сам язык Javascript (начиная с ES6/ES2015; поддержка старых систем делается автоматически - через трансиляцию).

Но то, что выделена стадия прототипирования и на ее основе будет принято решение - это правильно.

Неправильным будет если будет желание сэкономить и сделать основную версию на основе кода прототипа. Так как прототипирование делают вовсе без расчета упрощения поддержки в будущем, а как бы совсем наоборот - тяп-ляп, лишь бы работало.