Да, но с flatpak и snap это временная ситуация из-за малого возраста инструментария по сравнению с классическими РЕПами и в новых версиях этим активно занимаются. Даже была статья, кажется, в блоге гнома где они эту проблему подробно разбирали.
Не имеет значение сколько это стоит. Решение о том нужно это или нет принимаете не вы. Ваша задача уведомить руководство о возможных проблемах.
он выполнять свои обязанности не сможет просто физически
Принятие решений не входит в обязанности специалиста.
его ЗП по сути — это бессмысленная трата денег.
Это решать не вам.
По вашей аналогии, так как она слишком далека от истины, а вы на нее так упираете: вы платить зп стоматологу ежемесячно, но отказываетесь давать деньги ему на расходные материалы
Расходные материалы слишком широкое понятие и туда может входить много чего.
p.s. выше вам на все это ответили, читайте внимательно. вы не правы.
Смешивание этих сущностей и есть отсутствие нормальной архитектуры. Бекенд отдает куски html который зависит от js/css. Начинаются танцы с динамическими импортами разных зависимостей на страницах, двойные накладные расходы на чудо проверки: «а что собственно поддерживает фронтенд» и т.д.
В каком месте вы его смешиваете? Все это отделено view слоем и шаблонами.
И не важно фреймворк у вас или нет. Открою для вас секрет — SPA можно сделать и без фреймворка. Да-да, spa на голом js+html если зашла уже речь о таких миниатюрных проектах где фреймворк не нужен.
Да какая разница как все это реализовываете. У вас в любом случае html, css и js. Это то как сейчас работает веб. Вы его не изменили своим SPA, от слова вообще никак. Только все это еще и делаете на машине клиента.
Без проблем. Кол-во человек говорит о размере проекта косвенно. В первом комменте я указал что лишь часть проектов требует увеличения кол-ва девелоперов. Я думаю что мы поняли друг друга и на этом предлагаю закончить ветку.
Я уже сказал, что это скорее всего будет не так. Бэкенд могут писать человек 20, а фронтовая команда, например, человек 5.
Выше речь идет о том когда сайт разрабатывался одним девелопером. Вопрос больших команд, проблему загрузки разных позиций на проекте и их коммуникаций в этом треде я не обсуждал.
И чем вам не нравится пример с банком? Тем, что там бэкендом занимаются сотни?
Со стороны бекенда может быть нереально много логики, а фронт — значительно проще. Пример: банк-клиент (неважно, веб-версия или мобильное приложение).
Тем что фронт на примере банк-клиента может быть небольшим лишь в сравнение с бэкендом. В остальном он будет достаточно величины, чтобы рассматривать фронтенд фреймворки. И опять же обсуждались другие проекты.
И даже в этом случае кол-во знаний для использования фронтенд фреймворка для веб девелопера(в этом случае бэкенд девелопера) увеличивается на порядок. Хотя банк-клиент как пример здесь не очень.
От того что вы смешаете несколько проектов в одну репу/сайт у вас не получится одно приложение, у вас получится мешанина которую поддерживать сможет только фулстек разработчик с бубном который и css/js поправить может и sql запрос к базе.
Вы о чем? Кто что смешает? Открою для вас секрет большинство сайтов и разрабатывается без фронтенд фреймворков. И скажу даже больше кол-во проектов на которых размер js настолько большое что требует для этого отдельный фреймворк — невелико. И не имеет значения насколько это вам не нравится.
И количество специалистов вырастет в два раза только если вы считаете что на проекте должен быть такой вот и швец, и жнец, и на дуде игрец. В остальных случаях у вас просто есть отдельно человек который делает фронт, отдельно человек который делает бек. А если есть swagger или документация то эти люди вообще могут даже не коммуницировать друг с другом.
Вы сами себе противоречите. Чтобы не было и швец и жнец, и появляется еще одна позиция для разработки сайта.
А никто и не заставляет все сразу переписывать. Vue можно вообще подключить как еще одну библиотеку и постепенно переписывать jquery лапшу на него, постепенно избавляясь от легаси.
Пока ничего не доказывает. Вы привели слишком мало и слишком редкие приложения чтобы делать такие громкие заявления.
А то я так могу сказать, что айфон гавно, потому что на нём фортнайт не запускается.
Garage band это вообще приложение apple. Какой смысл его приводить в пример?
Sublime, как по мне, на голову быстрее vscode.
Так разницу и можно увидеть на слабом железе. А не когда у тебя сверх быстрый ссд, i9 и 64 озу.
Да, но с flatpak и snap это временная ситуация из-за малого возраста инструментария по сравнению с классическими РЕПами и в новых версиях этим активно занимаются. Даже была статья, кажется, в блоге гнома где они эту проблему подробно разбирали.
Не люблю когда так делают. Звучит как подъ*б. Это же не обязательно было сделано специально.
Намного лучше как мне кажется сказать об этом как есть и наедине(лично).
Не имеет значение сколько это стоит. Решение о том нужно это или нет принимаете не вы. Ваша задача уведомить руководство о возможных проблемах.
Принятие решений не входит в обязанности специалиста.
Это решать не вам.
Расходные материалы слишком широкое понятие и туда может входить много чего.
p.s. выше вам на все это ответили, читайте внимательно. вы не правы.
Откуда это? :)
Вот так github.com/rails/webpacker
В каком месте вы его смешиваете? Все это отделено view слоем и шаблонами.
Да какая разница как все это реализовываете. У вас в любом случае html, css и js. Это то как сейчас работает веб. Вы его не изменили своим SPA, от слова вообще никак. Только все это еще и делаете на машине клиента.
Тогда, когда его поддержка становится невозможной.
Вы о чем вообще? Перечитайте ветку.
Выше речь идет о том когда сайт разрабатывался одним девелопером. Вопрос больших команд, проблему загрузки разных позиций на проекте и их коммуникаций в этом треде я не обсуждал.
Тем что фронт на примере банк-клиента может быть небольшим лишь в сравнение с бэкендом. В остальном он будет достаточно величины, чтобы рассматривать фронтенд фреймворки. И опять же обсуждались другие проекты.
Вы о чем? Кто что смешает? Открою для вас секрет большинство сайтов и разрабатывается без фронтенд фреймворков. И скажу даже больше кол-во проектов на которых размер js настолько большое что требует для этого отдельный фреймворк — невелико. И не имеет значения насколько это вам не нравится.
Вы сами себе противоречите. Чтобы не было и швец и жнец, и появляется еще одна позиция для разработки сайта.
Можно конвертить их сразу в json из бд. Как указано здесь
И кол-во требуемых специалистов это тоже увеличивает как минимум в два раза, что для любого проекта не есть хорошо.