Comments 33
Так и запишем.
Плюсы: используем динамично развивающиеся технологии, поэтому в моменте только самое передовое.
Минусы: используем динамично развивающиеся технологии, поэтому через год после релиза проекта вы не найдёте тех, кто будет поддерживать это старьё, а разработчик, естественно, не будет мигрировать проекты с учётом обновлений элементов стека.
Странная статья.... не вяжется с заголовком. Просто взяли и перечислили на каком стеке работаете. С кратким описанием фреймворков и библиотек. Суть вопроса "На каком стеке разработать проект, чтобы не похоронить его после релиза" - не раскрыта вообще.... Хоть на чем можно разработать и похоронить даже до релиза... на это стек значительно не влияет. Больше влияет общая архитектура, выстраивание бизнес процессов и прочее.
Ни разу не указано - почему использовать лучше этот а не тот фреймворк/библотеку....
CEO в компании Pyrobyte
следите за нами: В телеграм-канале
Статью дальше можно не читать. По сути перечислили все то, что используете. Если действительно используете и это просто не реклама.
Как на каком? На таком чтобы резюме сияло и рекрутеры толкались и пачки денег сували.
По личному опыту: стек нужен такой, чтобы сначала быстро выкатить MVP, затем быстро проверять гипотезы. Ибо рынок платит не за стек. Рынку всё-равно, что у тебя за стек. Рынок платит за продукт. Даже если он на FORTRAN'е
Стек тоже важен. Потому что если гипотезы стартапа оправдаются, скорее всего, понадобятся разработчики для развития и поддержки этого продукта/проекта. А для этого очень важен правильный стек. Если в нем будут плохо поддерживаемые технологии, продукт далеко не уедет. Другой вопрос в том, что не все об этом задумываются на старте, потому что волнует другое.
Вы запилИте MVP, проверьте основные гипотезы, продайте продукт. А уже потом думайте про стек, чистый код и бла-бла-бла...
Пока вы будете подбирать стек, пока будете искать исполнителей и деньги на старте под этот стек, пока будете создавать "идеальное приложение", кто то сделает пункт №1, а вы еще даже до проверки гипотез не дойдете... И что? Стек, деньги, время, ресурсы в топку?
Другой вопрос в том, что не все об этом задумываются на старте, потому что волнует другое.
Скорее так: кто на старте об этом задумывается, у того стартап и не взлетает.
На каком стеке разработать проект, чтобы не похоронить его после релиза?
На том, который лучше всего знает команда
Ваш К.О.
TypeScript — языком программирования, в котором исправлены недостатки JavaScript
TypeScript это просто линтер+бабель с своими расширениями а не язык программирования и что он исправил недостатки JavaScript это прям спорно.
TypeScript (TS)
Это старший брат JavaScript, хоть и появился позже. Разработчики добавили в JS дополнительные возможности, такие как статическая типизация, классы и модули, чтобы создавать более надежные и поддерживаемые программы.
Простите но все кроме статической типизации (хотя по факту она только в compile time существует) уже есть и в обычном JavaScript.
Судя по выбору MySQL только из-за удобства, а не по принципу что лучше подойдет (иногда даже в пределах одного проекта) у вас стек действительно очень влияет, команда при любых нестандартных ситуациях ничего не сделает.
Продукт на нем разрабатывается быстрее, чем, например, на Symfony (второй по популярности PHP-фреймворк). Все потому, что в процессе разработчики могут обходиться без сложного кода.
А можете пояснить пожалуйста, что сложного в Symfony, без чего можно обходиться и простого в Laravel?
В Laravel все из коробки. В Symfony нужно знать, как минимум, о существовании скелетонов с пресетами бандлов. Если в процессе разработки на Symfony нужно докинуть какой-нибудь бандл, то добро пожаловать в yaml конфиг. В Laravel конфигурирование более очевидное.
В Symfony по умолчанию запрещен доступ к сервис контейнеру. Фреймворк прямо говорит, что дергать сервисы в любом месте приложения — плохо. В то время как у Laravel противоположная концепция — «фасады» доступны всегда и везде.
В Symfony многое работает на рефлексии (аннотации, атрибуты) — разработчик должен понимать, что это такое, дабы не воспринимать происходящее как магию. У Symfony жизненный цикл построен на событиях, в то время как весь Laravel — это цепочка мидлварей.
Элоквент — active record. Доктрина — data mapping. То есть, в Laravel модель содержит в себе все, что угодно для построения запросов в БД. В Symfony из коробки есть слой репо, концептуально это сложнее.
То есть Laravel в какой-то степени более прямолинейный и менее требовательный к архитектуре. И коммьюнити у него больше. Преимуществ у Symfony не меньше, чем в Laravel, но чтобы ими пользоваться, разработчик должен точно знать, что ему нужно и где это найти.
В Symfony по умолчанию запрещен доступ к сервис контейнеру. Фреймворк прямо говорит, что дергать сервисы в любом месте приложения — плохо. В то время как у Laravel противоположная концепция — «фасады» доступны всегда и везде.
Элоквент — active record. Доктрина — data mapping. То есть, в Laravel модель содержит в себе все, что угодно для построения запросов в БД. В Symfony из коробки есть слой репо, концептуально это сложнее.
То есть, Laravel позволяет наделать глупостей (а команда, для которой концепции Symfony сложны, наверняка их наделает), которые усложнят его поддержку, что более вероятно приведёт к его похоронам? Выглядит как преимущества Symfony.
Стек разработки, с точки зрения "не похоронить" после релиза, зависит от того, есть ли у вас лояльные и мотивированные разработчики (идеальный вариант один из фаундеров технарь на этом стеке). Если не уходить в крайности, то все, что есть на рынке разработки более или менее соответствуют требованиям и не важно java, .net, php или ещё что.
"во Flutter есть набор инструментов, которые помогают в разработке приложений, а вот у RN с этим сложнее. Но зато у него меньше порог вхождения, чем у Flutter, а это значит что? Что на проект будет легче найти разработчика. "
Во-во, под разработчиком понимается какой-то подсобник, а не программист. Потому что программисту пофиг на чем писать, а на Flutter можно приложение написать за месяц,с нуля, заодно и выучив его, если понимаешь, базовые принципы программирования и архитектуру приложения.
Вообще каждый раз же меняются фреймворки. Недавно читатал свежую статью на Кеду https://kedu.ru/press-center/articles/samye-populyarnye-freymvorki-php/ - там описаны совершенно другие актуальные фреймворки, может вам пригодится
На каком стеке разработать проект, чтобы не похоронить его после релиза?