ИМ
На симфе с апи платформой только осторожно её надо уметь готовить
Size: a a a
2020 June 22
ИМ
А так все щелчком пальцев делается, с доктриной вообще проблем не будет, эластик стоит самому реализовывать если надо
M
А с RN не так было несколько лет назад? Да и сейчас?
Просто выбирая кроссплатформенное решение нужно быть всегда готовым к тому, что придется писать что-то платформозависимое, если это решение вообще такое позволяет:)
AS
Всем привет! Если вам хочется попрокрастинировать этим солнечным утром по московскому времени - вот какую тему хочу вбросить.
На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:
- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)
И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).
На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.
На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.
Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).
Какие ещё идеи, или поспорьте со мной, может быть?
На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:
- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)
И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).
На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.
На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.
Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).
Какие ещё идеи, или поспорьте со мной, может быть?
> мало людей, мало новых проектов, много легаси)
А если сейчас людей в команде хватает, важны ли первые 2 пункта? Ну и про легаси непонятно
А если сейчас людей в команде хватает, важны ли первые 2 пункта? Ну и про легаси непонятно
SS
На симфе с апи платформой только осторожно её надо уметь готовить
так это же про любую технологию :)
СА
А с RN не так было несколько лет назад? Да и сейчас?
Не погружался в это глубоко, но по крайней мере сейчас такого ада там не наблюдается, по ощущениям. Впрочем, это не вполне релевантно, обсуждение больше про бэкенд)
СА
Kotlin/Spring уже по определению Java-наследие, Kotlin/Ktor ещё может быть нет (и то только в теории)
Spring очень под REST заточен, насчёт Ktor нет уверенности, хотя в этом направлении не очень его трогал, только один очень реактивный сервис на вебсокетах.
СА
Kotlin/Spring уже по определению Java-наследие, Kotlin/Ktor ещё может быть нет (и то только в теории)
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
ΠΣ
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
Вашей строчки на Java
ΠΣ
Но под капотом там всё та же Java
ΠΣ
Это не хорошо/плохо, просто это тот же Java стек, просто другой язык
СА
Вашей строчки на Java
Это я готов терпеть, пока оно не вылезает из под капота) И даже какие-то Java-библиотеки подключать.
ΠΣ
Это я готов терпеть, пока оно не вылезает из под капота) И даже какие-то Java-библиотеки подключать.
Абстракция протечет
СА
Это не хорошо/плохо, просто это тот же Java стек, просто другой язык
Это JVM-стек, я бы сказал.
ΠΣ
Это JVM-стек, я бы сказал.
Да, можно так
ΠΣ
И у вас на WebFlux? С корутинами?
СА
Абстракция протечет
Абстракции всегда протекают( Но Kotlin, как я понимаю, и задумывался с возможностью миграции с Java и параллельной работы двух кодбаз.
Да, на WebFlux с корутинами.
Да, на WebFlux с корутинами.
ΠΣ
Абстракции всегда протекают( Но Kotlin, как я понимаю, и задумывался с возможностью миграции с Java и параллельной работы двух кодбаз.
Да, на WebFlux с корутинами.
Да, на WebFlux с корутинами.
MPP и Native сильно позже появились, изначально JVM/JS
Y
У нас есть уже минимум два сервиса на Spring, где нет ни одной строки на Java)
У меня куча сервисов только с main и без кода
E
Всем привет! Если вам хочется попрокрастинировать этим солнечным утром по московскому времени - вот какую тему хочу вбросить.
На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:
- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)
И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).
На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.
На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.
Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).
Какие ещё идеи, или поспорьте со мной, может быть?
На вопрос "какой язык/фреймворк выбрать для монолитного REST API бэкенда нового проекта", который мне задают регулярно, я сам всегда отвечаю - те, где у тебя/твоей команды уже есть максимум компетенций. А недавно так получилось, что я этот вопрос задал себе. И поняв, что владею в достаточной степени несколькими стеками, и овладеваю новыми тоже достаточно быстро и эффективно - на верхние позиции выходят критерии типа:
- зрелость и беспроблемность (вероятность словить какие-то неразрешимые глюки или ограничения в языке/фреймворке, см. Flutter)
- доступность и стоимость инженеров (гоферов пылесосят с рынка)
- перспективы в ближайшие 5 лет (точно не Perl)
- экосистема библиотек/пакетов (leftpad)
- аффилированность с FAANG и другим крупняком (Go всегда будет языком для Google, а потом для остальных, Rust явно сильно затачивается под Mozilla Foundation)
И как-то получилось, что на первом месте незаметно оказались PHP и Symfony (либо Slim для менее развесистых проектов).
На второе аккуратно ставлю Kotlin/Spring с мыслью, что нехватку нативных библиотек всегда можно восполнить Java-наследием, и опасением конкурировать за инженеров с мобильной разработкой.
На третье - Python/Django, но уже с мыслью о конкуренции с рынком ML/data analysis.
Не готов рассматривать Java (рынок рабочей силы в основном состоит из инженеров кровавого энтерпрайза, которые плохо приспосабливаются к режиму стартапа), Go (людей мало и они дорогие, язык не заточен под REST-парадигму и большие монолиты), Typescript (там наведённый ад от экосистемы фронтенда), Ruby (мало людей, мало новых проектов, много легаси), .NET (сильная привязка к экосистеме Windows).
Какие ещё идеи, или поспорьте со мной, может быть?
Slim скорее всего потом вырастет обратно в симфони
Я думал сейчас для новых проектов берут лару
Я думал сейчас для новых проектов берут лару