Если для своего внутреннего проекта, где будет 1-2 разработчика и есть уверенность, что они всегда будут, почему бы нет. Если это Б2Б система с планами по развитию или потенциально для продажи, скорее нет. Ну и брать стоит если есть экспертиза или охото чего-то нового, в остальных случаях не уверен, что оно будет полезным и результативным
Как фреймворк для новичка, который только освоил JS, скорее, не рекомендовал бы. Весьма нишевая технология. Зависит от цели, чего нужно добиться в результате
Спасибо за информацию по инструменту!
В данный обзор данный квазар уже точно не попадет, но попробую сделать тест-драйв и в дальнейшем упомянуть в смежных статьях, если такие будут
На рынке кадров эта профессиональная деформация уже во всю гуляет, к сожалению. Я не против Typescript, ни в коем случае, и в результирующей таблице он в плюсах, а не в минусах и считаю, что все приложения больше to-do листа должны его использовать во избежании дальнейших проблем с рефакторингом, расширением кодовой базы и прочих. Но по моему опыту многие говорят на интервью: «Да, я использую тайпскрипт уже год», но по факту это означает проставить примитивные типы и не более, ну может пару модификаторов методам еще, а это уже звоночек, а нужен ли такой человек, если за год использования инструмента он не поинтересовался даже документацией и не опробовал ее на своем проекте?
Кастаельно обывателей, да, это джуны, стажеры, но все же изначально стоит им фокусироваться на основах языка, а не на его надстройке/расширении. Всем информация дается по разному, у кого вообще был опыт в языках со строгой типизацией, тут все просто и хорошо, а кому-то и базовые методы массивов даются с трудом. Те, кто толком не освоил JS, могут нырнуть в TS и окончательно потеряться, это мое мнение. Да и многие компании/проекты/команды до сих пор в 2020 году не мигрировали свои базы с JS на TS.
Вопрос качества специалистов очень актуален и всегда будет актуален. У многих кандидатов нет знаний TS, главное понять вообще, что человек соображает, а дальше как вы и сказали — неделька-другая и у нас есть разработчик, который может TS, тем более для обучения имеются разные инструменты в компаниях, тренинги, экзамены. Но это наиболее эффективно именно в среде, где TS активно применяется и есть кому подсказать, слепое чтение документации врядли поможет ввиду того, что эти знания не будут закреплены на практике, а pet projects нычне, как понимаю, не в моде и многие считают их тратой времени, с чем я конечно же не согласен.
Вашу точку зрения я понимаю, согласен с ней и я бы хотел, чтобы все так и было, но нынешний рынок кадров диктует иные подходы и предоставляет иной материал, поэтому приходится проявлять гибкость и где-то понижать планку.
Я с удовольствием и распростертыми объятиями встретил бы junior dev с багажом знаний из базовых алгоритмов, статической типизации TS, хорошим нативным JS, возможно знанием фреймворка типа Angular/React/Vue, но зачастую эти люди ожидают позиции middle и более того, они их с 70% вероятностью получат, где-то. И это я говорю про российский рынок, если говорить про европейский, а там я тоже провожу интервью, то ситуация еще хуже, возможно пандемия на это все накладывает свой отпечаток.
Фраза вырвана из контекста, причем, умышленно удалена фраза «для обывателя».
Но вернемся к теме. Проводя по 40-50 собеседований в год, на вопросы по TS (так как пишем мы только на нем) слышу: «глубоко не разбирался во всяких дженериках», «не помню, что такое юнион», а встретить человека знающего про тайпгарды — скорее исключение, поэтому да, рынок ИТ весьма перегрет и да, это реалии.
Это же прекрасно накладывается и на начинающих разработчиков, для кого и написана данная статья, поэтому на данный текст стоит смотреть через призму разработчика, который начинает свой путь.
А в чем не устраивает поддержка от команды React? на мой взгляд ребята наоборот делают очень крутую обратную совместимость между минорными и даже мажорными версиями.
Что касатся сложностей при саппорте, расширении и тестировании. Я как понимаю речь то идет не про слой представления, чем и является React, а в принципе про приложения написанные на React и связанной экосистеме? Если так, то сама экосистема очень богатая, не нужно упираться в дефолтный React-Redux, есть куча альтернатив:
— React-MobX
— React-Effector
— React-Reatom
— И для самых консерваторов React-EventEmmiter
Просто из этого списка можно выбрать наиболее удобное для себя решение по критериям масштабирования, кол-ву бойлерплейта, простоте тестирования.
Как человек, который использует React с 2014 года и писал только жнтерпрайз на нем, скажу, что нет с этим никаких проблем. Но Angular действительно имеем богатую экосистему и поставляется в виде batteries included решения, поэтому очень популярен в ентерпрайз проектах.
По работе со $scope было много специфики, насколько уже сейчас помню. Некоторые из них, такие как коллизии имен переменных при использовании нескольких контроллеров в одном шаблоне, уходили при использовании controllerAs синтаксиса, да и в контроллерах можно было уходить от $scope к this. Помимо $scope, очень не нравился подход написания директив и их области видимости, но не стал заносить все это в недостатки, чтобы не уходить в глубокую специфику инструмента.
Спасибо маркетингу Facebook, React в любом случае показал новые подходы к написанию кода, может и не самые лучшие и в других инструментах они были удобнее, да и есть. Тем не менее на момент выхода интересный концепт реактивного программирования + хороший маркетинг IT гиганта сделали свое дело, а дальше это снежный ком все сложнее останавливать.
По сложности тестирования именно React компонентов скажу, что уже как года 3 перестал их тестировать именно unit-тестами с jest-снапшотами, более эффективно получается писать компонентные тесты с использованием скриншотов.
Касательно тонн кода, отсутствия внятной архитектуры и другого, это я и попытался занести в недостатки (но с другой стороный может быть и +, смотря как на это смотреть). Это действительно не работа React и он не покрывает слой бизнес логики и не старается, и когда мы берем данный инструмент, оказывается, там много чего не хватает из коробки и мы пускаемся в увлекательное путешествие в гугл =)
Но если бы не холивары по эффективности, отличиям и прочим особенностям инструментов, то возможно двигатель прогресса бы затормозился. Но в любом случае, согласен с вами)
Это немного за рамками этой статьи, но UI фреймворки типа Webix, Bootstrap, Foundation, Material UI, Antd и прочие решают именно проблему готовых компонентов и быстрой сборки представления.
Альтернативы описал выше, но опять же, часто каждый из UI фреймворков, ровно как и интсрументов описанных в статье имеет свои особенности, в число таких Webx отличает наличие неплохих pivot таблиц, мы даже их использовали на одном из проектов.
Как правило альтернативу выбирают по принципу, покрывает ли UI фреймворк ваши компоненты которые используются в проекте, сложность интеграции и другие особенности, как вес бандла (tree-shaking), сложность API, использование конкретного препроцессора внутри, возможность расширения.
Все зависит от того, какую задачу на данный момент решает у вас Webix, а так очень часто на современныз проектах встречаю больше и больше Material UI.
Тут есть несколько поинтов.
1) У Vue есть встроенный store pattern, который позволяет управлять стором, при этом Vue не преследует концепцию единого глобального стора, поэтому сторы могут быть атомарными, Vuex — концепт единого стора, аля Redux, созданый для того чтобы понизить уровень сложности миграции комьюнити c React/Redux на Vue/Vuex, да и в принципе данный концепт хорошо себя показал, как многие считают, отсюда и появление инструмента.
2) Практически тоже самое у Svelte, так как наследовали свои лучшие практики они (Svelte + Vue) у одного прородителя, насколько помню, Reactive.js
3) react-router не относится напрямую к монорепе react, даже к неймспейсу. Исторически react context api был статическим, сейчас его называют legacy context api, новый context api не поменял концепт react, поэтому не произошло переименования библиотеки во фреймворк. Vue + vue-router поставлялись как правило вместе и входили в один неймспейс vuejs на github, которые давали вместе полноценный фреймворк, Vuex — не в счет, он появился позже.
По поводу того, что написано на офф странице фреймворка/библиотеки, это зависит от позиционирования, кому-то выгодно поставить все из коробки и целятся они на одну аудиторию, другие позиционируют себя как библиотеки и фокусируются на другую. Отсюда и позиционирование React как либы и фокус на рендеринге и Vue/Svelte, где можно собрать по описаному гайду приложение и оправить его в условный продакшен.
На самом деле, как не назови все эти инструменты, решают они одни и теже задачи и взаимозаменяемы ввиду развития фронтенда.
Понимаю, что тут смутило. В определении фреймворка подразумевалось, что он отвечает за архитектуру и структуру не только слоя представления, как правило слой представления нуждается в меньшей «архитектурности», а больше за архитектуру бизнес слоя и приложения в целом, включая слой сервисов и прочего. Реакт диктует же именно как писать компоненты, но как их компоновать, как структурировать, это дело падает на плечи пользователя инструмента.
Ну и плюс React сам говорит: «я библиотека» — «A JavaScript library for building user interfaces».
Рассматривать отдельные подсистемы как фреймворки — перебор, как минимум для данной статьи, что может смутить начинающих разработчиков. В остальном конечно react можно считать чем-то большим, чем библиотеку, для кого-то это действительно фреймворк, если помимо отображения использовать Context API для управления данными
Все верно, но это не отменяет наличие бойлерплейта в Redux из коробки. Но тулкит — это еще одна библиотека поверх redux (как раз в конце дана ссылка на getting started в секции redux, где говорится о тулките), без которой сейчас действительно нет смысла писать redux приложения, если нет какой-то своей инфраструктуры или оберток.
Если для своего внутреннего проекта, где будет 1-2 разработчика и есть уверенность, что они всегда будут, почему бы нет. Если это Б2Б система с планами по развитию или потенциально для продажи, скорее нет. Ну и брать стоит если есть экспертиза или охото чего-то нового, в остальных случаях не уверен, что оно будет полезным и результативным
Как фреймворк для новичка, который только освоил JS, скорее, не рекомендовал бы. Весьма нишевая технология. Зависит от цели, чего нужно добиться в результате
В данный обзор данный квазар уже точно не попадет, но попробую сделать тест-драйв и в дальнейшем упомянуть в смежных статьях, если такие будут
Кастаельно обывателей, да, это джуны, стажеры, но все же изначально стоит им фокусироваться на основах языка, а не на его надстройке/расширении. Всем информация дается по разному, у кого вообще был опыт в языках со строгой типизацией, тут все просто и хорошо, а кому-то и базовые методы массивов даются с трудом. Те, кто толком не освоил JS, могут нырнуть в TS и окончательно потеряться, это мое мнение. Да и многие компании/проекты/команды до сих пор в 2020 году не мигрировали свои базы с JS на TS.
Вопрос качества специалистов очень актуален и всегда будет актуален. У многих кандидатов нет знаний TS, главное понять вообще, что человек соображает, а дальше как вы и сказали — неделька-другая и у нас есть разработчик, который может TS, тем более для обучения имеются разные инструменты в компаниях, тренинги, экзамены. Но это наиболее эффективно именно в среде, где TS активно применяется и есть кому подсказать, слепое чтение документации врядли поможет ввиду того, что эти знания не будут закреплены на практике, а pet projects нычне, как понимаю, не в моде и многие считают их тратой времени, с чем я конечно же не согласен.
Вашу точку зрения я понимаю, согласен с ней и я бы хотел, чтобы все так и было, но нынешний рынок кадров диктует иные подходы и предоставляет иной материал, поэтому приходится проявлять гибкость и где-то понижать планку.
Я с удовольствием и распростертыми объятиями встретил бы junior dev с багажом знаний из базовых алгоритмов, статической типизации TS, хорошим нативным JS, возможно знанием фреймворка типа Angular/React/Vue, но зачастую эти люди ожидают позиции middle и более того, они их с 70% вероятностью получат, где-то. И это я говорю про российский рынок, если говорить про европейский, а там я тоже провожу интервью, то ситуация еще хуже, возможно пандемия на это все накладывает свой отпечаток.
Но вернемся к теме. Проводя по 40-50 собеседований в год, на вопросы по TS (так как пишем мы только на нем) слышу: «глубоко не разбирался во всяких дженериках», «не помню, что такое юнион», а встретить человека знающего про тайпгарды — скорее исключение, поэтому да, рынок ИТ весьма перегрет и да, это реалии.
Это же прекрасно накладывается и на начинающих разработчиков, для кого и написана данная статья, поэтому на данный текст стоит смотреть через призму разработчика, который начинает свой путь.
Что касатся сложностей при саппорте, расширении и тестировании. Я как понимаю речь то идет не про слой представления, чем и является React, а в принципе про приложения написанные на React и связанной экосистеме? Если так, то сама экосистема очень богатая, не нужно упираться в дефолтный React-Redux, есть куча альтернатив:
— React-MobX
— React-Effector
— React-Reatom
— И для самых консерваторов React-EventEmmiter
Просто из этого списка можно выбрать наиболее удобное для себя решение по критериям масштабирования, кол-ву бойлерплейта, простоте тестирования.
Как человек, который использует React с 2014 года и писал только жнтерпрайз на нем, скажу, что нет с этим никаких проблем. Но Angular действительно имеем богатую экосистему и поставляется в виде batteries included решения, поэтому очень популярен в ентерпрайз проектах.
По сложности тестирования именно React компонентов скажу, что уже как года 3 перестал их тестировать именно unit-тестами с jest-снапшотами, более эффективно получается писать компонентные тесты с использованием скриншотов.
Касательно тонн кода, отсутствия внятной архитектуры и другого, это я и попытался занести в недостатки (но с другой стороный может быть и +, смотря как на это смотреть). Это действительно не работа React и он не покрывает слой бизнес логики и не старается, и когда мы берем данный инструмент, оказывается, там много чего не хватает из коробки и мы пускаемся в увлекательное путешествие в гугл =)
Альтернативы описал выше, но опять же, часто каждый из UI фреймворков, ровно как и интсрументов описанных в статье имеет свои особенности, в число таких Webx отличает наличие неплохих pivot таблиц, мы даже их использовали на одном из проектов.
Как правило альтернативу выбирают по принципу, покрывает ли UI фреймворк ваши компоненты которые используются в проекте, сложность интеграции и другие особенности, как вес бандла (tree-shaking), сложность API, использование конкретного препроцессора внутри, возможность расширения.
Все зависит от того, какую задачу на данный момент решает у вас Webix, а так очень часто на современныз проектах встречаю больше и больше Material UI.
1) У Vue есть встроенный store pattern, который позволяет управлять стором, при этом Vue не преследует концепцию единого глобального стора, поэтому сторы могут быть атомарными, Vuex — концепт единого стора, аля Redux, созданый для того чтобы понизить уровень сложности миграции комьюнити c React/Redux на Vue/Vuex, да и в принципе данный концепт хорошо себя показал, как многие считают, отсюда и появление инструмента.
2) Практически тоже самое у Svelte, так как наследовали свои лучшие практики они (Svelte + Vue) у одного прородителя, насколько помню, Reactive.js
3) react-router не относится напрямую к монорепе react, даже к неймспейсу. Исторически react context api был статическим, сейчас его называют legacy context api, новый context api не поменял концепт react, поэтому не произошло переименования библиотеки во фреймворк. Vue + vue-router поставлялись как правило вместе и входили в один неймспейс vuejs на github, которые давали вместе полноценный фреймворк, Vuex — не в счет, он появился позже.
По поводу того, что написано на офф странице фреймворка/библиотеки, это зависит от позиционирования, кому-то выгодно поставить все из коробки и целятся они на одну аудиторию, другие позиционируют себя как библиотеки и фокусируются на другую. Отсюда и позиционирование React как либы и фокус на рендеринге и Vue/Svelte, где можно собрать по описаному гайду приложение и оправить его в условный продакшен.
На самом деле, как не назови все эти инструменты, решают они одни и теже задачи и взаимозаменяемы ввиду развития фронтенда.
Ну и плюс React сам говорит: «я библиотека» — «A JavaScript library for building user interfaces».
Рассматривать отдельные подсистемы как фреймворки — перебор, как минимум для данной статьи, что может смутить начинающих разработчиков. В остальном конечно react можно считать чем-то большим, чем библиотеку, для кого-то это действительно фреймворк, если помимо отображения использовать Context API для управления данными