1. Стоимость поддержки (на php - меньше)
2. Очень условно - безопасность (на php - тоже меньше :)
3. Возможность глобальных изменений в проекте - на php проще
4. И только когда в проекте пользуются миллионы транзакций _ежедневно_, вопросы производительности заставляют искать решение подороже, побыстрее, получше.
не согласен с 3. от ЯП вообще ничего не зависит(брейнфак и тп не в счет), только от того как команда все сделает: хорошая архитектура, чистый код и тд
повидал уже крупные проекты на пхп, в котором на столько здоровенный болт на дальнейшее сопровождение положили, что теперь без боли в груди не возможно смотреть на код, написанный на этом языке
2 тоже спорно, за счет особенностей языка и его широкой распространенности, почти любой школьник может загуглить как хотя бы sql инъекцию сделать, так что пхп в этом плане дорогой язык
от ЯП вообще ничего не зависит(брейнфак и тп не в счет)
Неправда, очень многое зависит. Во-первых, скорость разработки, во-вторых, инфраструктура вокруг языка.
Пока ваша команда будет на Java подымать Spring Boot приложение и писать модельки с атрибутами для JPA команда ларавельщиков или рельсовиков уже сделает готовый сайт и админку.
Другое дело что, возможно, рельсо или пыхоприложение не будет так хорошо масштабироваться и держать нагрузку как грамотное джаваприложение, но пока до этого время дойдет то появятся деньги и на Java разработчиков.
Я пишу коммерческие проекты и на Java и на рельсах и немного на пхп и других языках так что знаю о чем говорю. Для CMS только совсем отбитые граждане выберут java.
ну, ларавел и спринг по скорости примерно одинаковыми при разворачивании будут: что там несколько дней, что там (тоже через это проходили, но понимаю что эти цифры плавающие, чем больше опыта настройки. тем быстрее будет).
Скорость разработки - нууууу, и да, и нет, так как если брать ЕЕ решения, то что в случае со спрингом будет условный год разработки, что с ларавел/симфони/ии (из расчета что над проектом будут работать абсолютно равные специалисты друг другу). Просто каждая из команд будет больше времени тратить на боли их решения: отказоустойчивость, управление потоками и тд.
но да, вам как java разработчику будет виднее, я скромный фронт с опытом работы на пхп и ноде
Нет, ларавел и спринг не равны по разработке абсолютно. Я на java 10 кодю, я знаю о чем говорю. Пока спрингосеньеры будут клепать модельки с геттерами и стеттерами, ларавелодети уже сделают готовую админку и crud api.
управление потоками
Не понимаю о какой отказоустойчивости или потоках вы говорите, ни один вменяемый разработчик не будет использовать потоки, а в пыхе так и вообще как бы нет (или нет в таком простом и готовом для использования виде как в джаве).
отказоустойчивость
Але, вся суть "отказоутойчивости" в i/o. Все всегда упирается в базу данных. Да, java дает на условный cpu больше мощностей, но cpu копейки стоят. А чтобы горизонтально масштабировать приложение и там и там надо думать одинаково. Только пока джавадевелоперы будут чехлиться с модельками, ларавельщики уже будут тестировать гипотезы и грести бабло :)
Угу, вот именно. А точнее - в ее размер (в строках/записях и физический, тоже). Ну и дальше посещаемость ресурса + размер базы = борьба с тормозами в моменты пиковой загрузки - и абсолютно лишними, неиспользуемыми ресурсами во всё остальное время.
Классика жанра - это моментально падающие мини-веб серверы, на которые вдруг дали ссылку в СМИ с миллионной аудиторией.
Комментарий недоступен
1. Стоимость поддержки (на php - меньше)
2. Очень условно - безопасность (на php - тоже меньше :)
3. Возможность глобальных изменений в проекте - на php проще
4. И только когда в проекте пользуются миллионы транзакций _ежедневно_, вопросы производительности заставляют искать решение подороже, побыстрее, получше.
не согласен с 3. от ЯП вообще ничего не зависит(брейнфак и тп не в счет), только от того как команда все сделает: хорошая архитектура, чистый код и тд
повидал уже крупные проекты на пхп, в котором на столько здоровенный болт на дальнейшее сопровождение положили, что теперь без боли в груди не возможно смотреть на код, написанный на этом языке
2 тоже спорно, за счет особенностей языка и его широкой распространенности, почти любой школьник может загуглить как хотя бы sql инъекцию сделать, так что пхп в этом плане дорогой язык
Неправда, очень многое зависит. Во-первых, скорость разработки, во-вторых, инфраструктура вокруг языка.
Пока ваша команда будет на Java подымать Spring Boot приложение и писать модельки с атрибутами для JPA команда ларавельщиков или рельсовиков уже сделает готовый сайт и админку.
Другое дело что, возможно, рельсо или пыхоприложение не будет так хорошо масштабироваться и держать нагрузку как грамотное джаваприложение, но пока до этого время дойдет то появятся деньги и на Java разработчиков.
Я пишу коммерческие проекты и на Java и на рельсах и немного на пхп и других языках так что знаю о чем говорю. Для CMS только совсем отбитые граждане выберут java.
ну, ларавел и спринг по скорости примерно одинаковыми при разворачивании будут: что там несколько дней, что там (тоже через это проходили, но понимаю что эти цифры плавающие, чем больше опыта настройки. тем быстрее будет).
Скорость разработки - нууууу, и да, и нет, так как если брать ЕЕ решения, то что в случае со спрингом будет условный год разработки, что с ларавел/симфони/ии (из расчета что над проектом будут работать абсолютно равные специалисты друг другу). Просто каждая из команд будет больше времени тратить на боли их решения: отказоустойчивость, управление потоками и тд.
но да, вам как java разработчику будет виднее, я скромный фронт с опытом работы на пхп и ноде
Нет, ларавел и спринг не равны по разработке абсолютно. Я на java 10 кодю, я знаю о чем говорю. Пока спрингосеньеры будут клепать модельки с геттерами и стеттерами, ларавелодети уже сделают готовую админку и crud api.
управление потокамиНе понимаю о какой отказоустойчивости или потоках вы говорите, ни один вменяемый разработчик не будет использовать потоки, а в пыхе так и вообще как бы нет (или нет в таком простом и готовом для использования виде как в джаве).
отказоустойчивостьАле, вся суть "отказоутойчивости" в i/o. Все всегда упирается в базу данных. Да, java дает на условный cpu больше мощностей, но cpu копейки стоят. А чтобы горизонтально масштабировать приложение и там и там надо думать одинаково. Только пока джавадевелоперы будут чехлиться с модельками, ларавельщики уже будут тестировать гипотезы и грести бабло :)
Угу, вот именно. А точнее - в ее размер (в строках/записях и физический, тоже). Ну и дальше посещаемость ресурса + размер базы = борьба с тормозами в моменты пиковой загрузки - и абсолютно лишними, неиспользуемыми ресурсами во всё остальное время.
Классика жанра - это моментально падающие мини-веб серверы, на которые вдруг дали ссылку в СМИ с миллионной аудиторией.