Я уже немного далек от веба, так как последние годы работаю с флаттером, но все же мне непонятна концепция. Какой смысл писать фронт и бек на одном языке, учитывая что в большинстве приложений бекенд работает с базой данных а фронтенд ответственен за отрисовку интерфейсов и взаимодействие с пользователем. Бизнес логика фронта и бека так или иначе сильно разнится. Если только для каких то нишевых задач/проектов, так как по сути скорость разработки будет примерно такой же, как если бы вы тоже самое бы написали на разных языках. Связка graphql + любой js фреймворк по моему будет эффективнее в большинстве задач, так как вы получаете и бек и фронт на одном языке, при этом бек вообще практически не пишете.
Это только вершина айсберга. Еще месяца через 4 вы возможно поймете как устроен жизненый цикл виджетов, узнаете что на самом деле представляет из себя контекст и может даже погрузитесь в то как связаны между собой виджеты, элементы и рендеробжекты. Поиграетесь с инхерит виджетами, стримами и изолятами. А через год другой будете ломать голову над тем какие архитектуры использовать в том или ином проекте и может даже напишите свой кастомный роутер на навигаторе 2.0). Ну по крайней мере у меня так..
Graphql имеет смысл использовать, если у вас nocode бекенд, отсутствует бекендер, или вы хотите его разгрузить. Например он будет заниматься интеграциями а вы пилить crud-ы. В таком случае вы существенно ускорите разработку. Ещё одним неоспоримым преимуществом является типизация, которую не всегда вам может обеспечить условный бекендер питонщик. Нынешние graphql платформы вроде hasura и apollo могут также предложить неплохую производительность по сравнению с бекенд api. Если же ваш проект это только crud-ы и у вас есть свободный бекендер то вы можете наоборот потерять в скорости так как вся работа по получению и обработки данных переносится на ваши плечи(как фронтендера)
Ерунда. Фреймворк собирает html и скрипты одной или несколькими командами. Этим занимается сборщик пакетов, в котором в том числе настраивается минификация и прочие плюшки для оптимизации. Тоесть на релизе у тебя уже готовый html со всеми скриптами который размещается на веб сервере. Разница в том что это одностраничное приложение. И все грузится как правило сразу. Поэтому начальная загрузка может быть медленнее конечно но учитывая оптимизации разница не такая уж заметная. Так как точка входа по сути одна то ресурсы веб сервера себя чувствуют лучше при таком раскладе. Меньше одновременных подключений на сервер, меньше расход ресурсов так как каждая страница это отдельное соеденение. И переключение между экранами конечно в одностраничных придожениях намного быстрее так как нету взимодействия с сервером при этом.
Большая часть статьи конечно относится к платформам. Но это актуально для флаттера так как это кроссплатформа и можно ориентироваться на статью как мануал, вместо того чтобы читать доки по каждой платформе отдельно. А в конце статьи чисто флаттерский пакет описан для поддержки диплинков. Так что да, статья актуальна именно для флаттера
Пробовал routemaster и немного поковырялся с go_router. AutoRoute мне не понравился тем что там кодогенерация. Routemaster более менее удобный, но там есть моменты которые не разруливаются без костылей и как мне кажется автор подзабил на поддержку. Из перспективных мне кажется go_router, так как поддерживается командой флаттера но там не было полноценных решений для вложенных роутеров внутри табов и снаружи. Возможно это уже допилили.
Отличная статья, все разжеванно. Побольше бы таких для флаттера. Как пожелание автору для дальнейших статей было бы интересны ваши подходы к навигации. С диплинками и вложенными роутерами для кроссплтаформы( тобишь веба и мобилок), если есть опыт конечно. Все решения какие пробовал я для своих проектов либо работают с костылями(если использовать готовые пакеты), либо отнимают много времени (если писать что то кастомное на navigator 2.0)
Ну вам просто не повезло работать в корпоративной среде. Проекты наверняка enterprise с кучей legacy? Я такого стараюсь избегать. Я в основном берусь за средние проекты на год-другой разработки почти все с нуля
Я помню 10 лет назад скачал бесплатно с торентов курс по php от преподов с бауманки, не помню как назывался. И еще несколько по mysql, js. Мне этого хватило чтобы потом говногодить на джумле, писать всякие плагины для нее и даже малость зарабатывать. Спустя 10 лет я уже флаттер разработчик с опытом веб и бекенд разработки на 5 языках программирования, правда этот опыт уже уставший. Впору открывать курс как стать разработчиком бесплатно)
Ну мне кажется не велика наука. Если речь идет о фронтенд разработке то уже все более менее удобные элементы для интерфейсов придуманы. Есть нюансы в плане юзабилити но тут мне кажется больше для дизайнеров актуально
Речь идёт о понимании клиента или продукта не пойму? Как по мне так сложнее всего соблюсти баланс между гибкостью и сложностью архитектуры проекта. И вот тут разработчики чаще всего и упарываются либо в оверинжиниринг либо в лютую императивщину которую невозможно поддерживать.
Интересно, сколько времени у джуниора займет разработка при соблюдении всех этих пунктов. Да и вообще стоит ли проект полностью доверять новичку, особенно что касается архитектуры? По моему опыту главная беда новичков это оверинжиниринг
Энтерпрайз это ад адовый. Незнаю я как то нашел свою нишу на средних и небольших проектах и норм себя чувствую тут. Помнится было что то такое когда в штатах работал в стартапе. Типо фреймворк для мобильной разработки был написан индусами свой под разные платформы и надо было в нем копаться модули под него писать. Это еще до react native было вернее писать они его начали когда оный еще не вышел. На самом деле копание в кишках занятие не сильно творческое, я вот восхищаюсь иногда алгоритмами придуманные математиками которые использовал в своих проектах. Вот это реально свет, столпы. Как например Дийкстра полвека назад придумал то что сейчас используется для навигации когда еще компутеров не было. Вообщем мой посыл в том что знание - это свет а 1с и прочее legacy это тьма и тут уже каждый для себя выбирает с чем ему работать)
routemaster вроде подходящее решение. Как нибудь попробую. Надеюсь что багов не будет) Самые проблемные места обычно это навигация вперед назад между табами.
Использовал globalKeys для создания двухуровневой навигации в приложении. Имеются табы в каждой из который свой набор роутов.При этом некоторые виджеты(роуты) могут отображаться в нескольких табах. Мне интересно кто как выкручивался, возможно уже есть решения для nested routes во флаттере? Все таки довольно распостраненный кейс.
Ну я не говорю что базы вообще никакой не нужно, я думаю что и то и другое нужно в равной степени. Просто тут даже название статьи такое, что мол фреймворки учить не нужно. Да и все повально одно и то же повторяют, типа js core важнее. А там вообще нет по сути нет ничего такого что за пару недельм или собесов не выучить
Заканчивается всё возмущенными репликами в профильных чатах: «Я им показываю собственную соцсеть, которую сделал в одиночку за два месяца, а они меня просят рассказать про Event loop. Им разработчики нужны или теоретики?!?!»
А теперь другая ситуацию. Приходит джун натаскавшийся на однотипных собесах, заучивший все теоретические основы (а их и не так уж и много по большому счету), в компанию которая разрабатывает собственную соцсеть. Да еще и на позицию мидла, да еще и без знания фреймворка. Ничего что он там наговнокодит и всю архитектуру поломает? Или будете с ним часами бодаться на код ревью и баги за ним фиксить? Ну да, зато он знает про event loop...
Уже много лет работаю с фреймворками и вот абсолютно все равно мне что сработает раньше промис или таймаут. Если надо будет всегда можно уточнить. 5 минут это займет. А вот если ui или асинхронная логика вся построена на таймаутах то это уже извините шляпа. Такие вещи как Imediate functions и прототипы вообще я считаю рудименты языка. Все фреймворки построены на модулях и синтаксис уже давно есть адекватный для наследования. Однако так как это важная часть js core то на собесах вас будут 80% времени будут об спрашивать и задавать задачки. Пока наизусть не выучите.
Только что это даст если вы идете на позицию react разработчика к примеру? И уж если вы думаете что выучить фреймворк легко, то как насчет всего сопутствующего? Либы, state management выбрать. Правильную архитектуру подобрать для проекта, раскидать бизнес и ui логику правильно чтобы не писать лапшу в компонентах, чтобы приложение было гибким и хорошо расширяемым, код понятным и читаемым? Для этого знаний js core боюсь будет недостаточным.
Я уже немного далек от веба, так как последние годы работаю с флаттером, но все же мне непонятна концепция. Какой смысл писать фронт и бек на одном языке, учитывая что в большинстве приложений бекенд работает с базой данных а фронтенд ответственен за отрисовку интерфейсов и взаимодействие с пользователем. Бизнес логика фронта и бека так или иначе сильно разнится. Если только для каких то нишевых задач/проектов, так как по сути скорость разработки будет примерно такой же, как если бы вы тоже самое бы написали на разных языках. Связка graphql + любой js фреймворк по моему будет эффективнее в большинстве задач, так как вы получаете и бек и фронт на одном языке, при этом бек вообще практически не пишете.
Это только вершина айсберга. Еще месяца через 4 вы возможно поймете как устроен жизненый цикл виджетов, узнаете что на самом деле представляет из себя контекст и может даже погрузитесь в то как связаны между собой виджеты, элементы и рендеробжекты. Поиграетесь с инхерит виджетами, стримами и изолятами. А через год другой будете ломать голову над тем какие архитектуры использовать в том или ином проекте и может даже напишите свой кастомный роутер на навигаторе 2.0). Ну по крайней мере у меня так..
Graphql имеет смысл использовать, если у вас nocode бекенд, отсутствует бекендер, или вы хотите его разгрузить. Например он будет заниматься интеграциями а вы пилить crud-ы. В таком случае вы существенно ускорите разработку. Ещё одним неоспоримым преимуществом является типизация, которую не всегда вам может обеспечить условный бекендер питонщик. Нынешние graphql платформы вроде hasura и apollo могут также предложить неплохую производительность по сравнению с бекенд api. Если же ваш проект это только crud-ы и у вас есть свободный бекендер то вы можете наоборот потерять в скорости так как вся работа по получению и обработки данных переносится на ваши плечи(как фронтендера)
Ерунда. Фреймворк собирает html и скрипты одной или несколькими командами. Этим занимается сборщик пакетов, в котором в том числе настраивается минификация и прочие плюшки для оптимизации. Тоесть на релизе у тебя уже готовый html со всеми скриптами который размещается на веб сервере. Разница в том что это одностраничное приложение. И все грузится как правило сразу. Поэтому начальная загрузка может быть медленнее конечно но учитывая оптимизации разница не такая уж заметная. Так как точка входа по сути одна то ресурсы веб сервера себя чувствуют лучше при таком раскладе. Меньше одновременных подключений на сервер, меньше расход ресурсов так как каждая страница это отдельное соеденение. И переключение между экранами конечно в одностраничных придожениях намного быстрее так как нету взимодействия с сервером при этом.
А так ли нужен SEO сейчас? Есть миллион других способов раскрутки сайтов, приложений
Большая часть статьи конечно относится к платформам. Но это актуально для флаттера так как это кроссплатформа и можно ориентироваться на статью как мануал, вместо того чтобы читать доки по каждой платформе отдельно. А в конце статьи чисто флаттерский пакет описан для поддержки диплинков. Так что да, статья актуальна именно для флаттера
Пробовал routemaster и немного поковырялся с go_router. AutoRoute мне не понравился тем что там кодогенерация. Routemaster более менее удобный, но там есть моменты которые не разруливаются без костылей и как мне кажется автор подзабил на поддержку. Из перспективных мне кажется go_router, так как поддерживается командой флаттера но там не было полноценных решений для вложенных роутеров внутри табов и снаружи. Возможно это уже допилили.
Отличная статья, все разжеванно. Побольше бы таких для флаттера. Как пожелание автору для дальнейших статей было бы интересны ваши подходы к навигации. С диплинками и вложенными роутерами для кроссплтаформы( тобишь веба и мобилок), если есть опыт конечно. Все решения какие пробовал я для своих проектов либо работают с костылями(если использовать готовые пакеты), либо отнимают много времени (если писать что то кастомное на navigator 2.0)
Ну вам просто не повезло работать в корпоративной среде. Проекты наверняка enterprise с кучей legacy? Я такого стараюсь избегать. Я в основном берусь за средние проекты на год-другой разработки почти все с нуля
Я помню 10 лет назад скачал бесплатно с торентов курс по php от преподов с бауманки, не помню как назывался. И еще несколько по mysql, js. Мне этого хватило чтобы потом говногодить на джумле, писать всякие плагины для нее и даже малость зарабатывать. Спустя 10 лет я уже флаттер разработчик с опытом веб и бекенд разработки на 5 языках программирования, правда этот опыт уже уставший. Впору открывать курс как стать разработчиком бесплатно)
Фронтенд это не только веб.
Ну мне кажется не велика наука. Если речь идет о фронтенд разработке то уже все более менее удобные элементы для интерфейсов придуманы. Есть нюансы в плане юзабилити но тут мне кажется больше для дизайнеров актуально
Речь идёт о понимании клиента или продукта не пойму? Как по мне так сложнее всего соблюсти баланс между гибкостью и сложностью архитектуры проекта. И вот тут разработчики чаще всего и упарываются либо в оверинжиниринг либо в лютую императивщину которую невозможно поддерживать.
Интересно, сколько времени у джуниора займет разработка при соблюдении всех этих пунктов. Да и вообще стоит ли проект полностью доверять новичку, особенно что касается архитектуры? По моему опыту главная беда новичков это оверинжиниринг
Энтерпрайз это ад адовый. Незнаю я как то нашел свою нишу на средних и небольших проектах и норм себя чувствую тут. Помнится было что то такое когда в штатах работал в стартапе. Типо фреймворк для мобильной разработки был написан индусами свой под разные платформы и надо было в нем копаться модули под него писать. Это еще до react native было вернее писать они его начали когда оный еще не вышел. На самом деле копание в кишках занятие не сильно творческое, я вот восхищаюсь иногда алгоритмами придуманные математиками которые использовал в своих проектах. Вот это реально свет, столпы. Как например Дийкстра полвека назад придумал то что сейчас используется для навигации когда еще компутеров не было. Вообщем мой посыл в том что знание - это свет а 1с и прочее legacy это тьма и тут уже каждый для себя выбирает с чем ему работать)
Ну я примерно так и делал. Вдохновлялся этой статьей https://codewithandrea.com/articles/multiple-navigators-bottom-navigation-bar/
routemaster вроде подходящее решение. Как нибудь попробую. Надеюсь что багов не будет) Самые проблемные места обычно это навигация вперед назад между табами.
Использовал globalKeys для создания двухуровневой навигации в приложении. Имеются табы в каждой из который свой набор роутов.При этом некоторые виджеты(роуты) могут отображаться в нескольких табах. Мне интересно кто как выкручивался, возможно уже есть решения для nested routes во флаттере? Все таки довольно распостраненный кейс.
Ну я не говорю что базы вообще никакой не нужно, я думаю что и то и другое нужно в равной степени. Просто тут даже название статьи такое, что мол фреймворки учить не нужно. Да и все повально одно и то же повторяют, типа js core важнее. А там вообще нет по сути нет ничего такого что за пару недельм или собесов не выучить
А теперь другая ситуацию. Приходит джун натаскавшийся на однотипных собесах, заучивший все теоретические основы (а их и не так уж и много по большому счету), в компанию которая разрабатывает собственную соцсеть. Да еще и на позицию мидла, да еще и без знания фреймворка. Ничего что он там наговнокодит и всю архитектуру поломает? Или будете с ним часами бодаться на код ревью и баги за ним фиксить? Ну да, зато он знает про event loop...
Уже много лет работаю с фреймворками и вот абсолютно все равно мне что сработает раньше промис или таймаут. Если надо будет всегда можно уточнить. 5 минут это займет. А вот если ui или асинхронная логика вся построена на таймаутах то это уже извините шляпа. Такие вещи как Imediate functions и прототипы вообще я считаю рудименты языка. Все фреймворки построены на модулях и синтаксис уже давно есть адекватный для наследования. Однако так как это важная часть js core то на собесах вас будут 80% времени будут об спрашивать и задавать задачки. Пока наизусть не выучите.
Только что это даст если вы идете на позицию react разработчика к примеру? И уж если вы думаете что выучить фреймворк легко, то как насчет всего сопутствующего? Либы, state management выбрать. Правильную архитектуру подобрать для проекта, раскидать бизнес и ui логику правильно чтобы не писать лапшу в компонентах, чтобы приложение было гибким и хорошо расширяемым, код понятным и читаемым? Для этого знаний js core боюсь будет недостаточным.