А никто и не говорит, что Реакт это фреймворк. И в этом и его преимущество и недостаток в зависимости от взгляда и подхода. Я, например, выбрал для своей аппликации фрейворк для данных и состояния наиболее подходящий для её требований. Если же UI компоненты и бизнес логика засунуты в неделимый фреймворк, то заменить что-то становится сложнее.
А у меня на тот момент не было настолько большого опыта с Реактом. Я тогда писал на Ангулар 1. А с реактом работал чуть больше года до этого в течении нескольких месяцев.
Реакт сам по себе очень прост и гибок. И увеличение проекта никак на это не влияет. В этом плане он ничем от других библиотек компонентов не отличается, он даже проще. А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.
Я не более чем год назад с нуля организовал проект на Реакт с выбором инфраструктуры и дополнительных библиотек компонентов и инструментов, организацией билда, е2е и юнит тестов, короче всего. При этом для проверки системы походу писал уже отдизайненые экраны. В общей сложности за менее чем 3 месяца написал 4 экрана, не считая модальных диалогов и всяких главных баров и менюшек. Все без е2е тестов, но с симуляцией серверных данных. Далее обучил одного джуна и двух синьёров, не работавших ранее с Реактом. Это заняло неделю. И в течении полутора-двух месяцев мы набросали ещё полтора десятка экранов, а также полный набор е2е тестов для всех экранов. Экраны представляли собой как сложные формы, так и более комплексные приблуды. Одной из задач, например, было внедрение редактора кода от Вижуал студио — монако.
Не очень понимаю, каким тормозом нужно быть, чтобы за два месяца не написать 3 экрана, разве, что там каждый экран это докторская диссертация.
Это понятно. Просто есть стандартный набор паттернов, пришедший из Функционального Программирования, который покрывает практически любые варианты. То есть практически льбой цикл можно превратить в последовательность вызовов этих паттернов. Это будет не всегда самое, быстрое, но почти всегда самое читабельное решение (после небольшой практики — вначале и сам страдал)
Когда-то мне объяснили, что в HTML приняты двойные кавычки, и, чтоб писать шаблоны внутри JS удобно использовать одинарные. Действительно было удобно с Ангуларом. В Реакте все равно, но уже привык.
Тем кто интересуется, советую обратить внимание на маленькую библиотеку Slim.js (http://slimjs.com). Это более тонкая чем Полимер и быстрая обертка над Веб Компонентами, ориентированная на Javascript
Я бы даже сказал, что это чем-то напоминает загрузку и сохранения файлов в текстовых редакторах, где сам файл представляет некий стандартный формат, а в редакторе виден удобный для работы текст.
С моей точки зрения идеальным вариантом, исключающим большинство холиваров, был бы такой подход: при загрузке в редактор — персональное автоформатирование, а при сохранении/коммите — стандартизированное форматирование. В обоих случаях должно происходить полное переформатирование без учета текущего формата. Исключением могут быть специально обозначенные блоки, которые никогда не переформатируются, только вручную. Тогда каждый будет работать с удобным и привычным ему лично форматом, а стандартизированный формат позволит более корректно проводить мерджи и позволит избежать различных проблем, присущих, например, JS. Причем персонализированный формат должен быть максимально настраиваимым, а стандартизированный наоборот не должен иметь натроек совсем.
Не понял, что нового в статье. Так писали 7-8 лет назад (а может и раньше), чтобы не заморачиваться с наследованием и чтобы симулировать private. Особенно такой стиль любят выходцы из С#/С++. На сегодня, с приходом классов, этот стиль уходит. Возможно в одном из следующих релизов можно будет декларировать в качестве члена класса что нибудь типа стрелочных функций с привязкой this
В чем-то вы правы, в мире браузеров исторически сложившийся бардак и несовместимость. В основном это вина нежестких стандартов w3c/ecma, откуда проистекает несовместимость в разных движках и конечно любимой Майкрософт, которая хочет как лучше, а получается как всегда. Кроме этого бурное развитие всего во фронт-энде дополняет кошмар.
НО.
Если разобраться по сути, то окружение Джавы, С# и JS не так уж принципиально отличаются. В Java и С# существует Виртуальная машина, её ассемблер/intermediate language (e.g. MSIL) и JIT компиляция. В JS тоже самое. Браузер с его V8 или другим движком это собственно та же виртуалка, её ассемблер/IL это и есть тот самый JS, а проблема совместимости версий существует из-за необходимости поддержки старых браузеров (привет Майкрософту). И транспиляторы компилируют код из разных языков в JS так же как компиляторы из Java/Scala/C#/VB в код их виртуалок. А далее за дело берется JIT, который существует во всех них. И то, что код VM не читабелен, а код JS да, принципиального рояля не играет.
Тоже можно сказать и про инструменты сборки проектов. У Java есть Maven/Gradle, у C# — MSBuild у JS много всего на выбор. Часть умирает, часть выживает.
И так практически по всем пунктам. Со временем поутихнет развитие и останутся проверенные временем решения. Уйдут в небытие старые несовместимые браузеры, ужесточатся стандарты, надают по шее Майкрософту. На смену (или в дополнение) интерпретируемому JS придет нормальный IL, например webasm. Напишут компиляторы с разных языков и будет всем счастье. Устаканятся фреймворки. Может кто и до реализации WPF дойдёт (Я его реально люблю). Возможно и с CSS layout что нибудь нормальное сделают (хотя в это мне намного меньше верится, чем в победу разума над JS)
Чисто для инфы, я работал на клиенте, когда серверов (в нынешнем понимании) ещё не существовало, работал на сервере и сейчас пишу на всяческом фронт-энде. Просто в большинстве знаю эту кухню и весь кошмар не по-наслышке. И, если честно, не смотря на все его недостатки, мне нравится JS.
Про Javascript практически каждый недостаток заканчивается тем, что в «ES6 уже исправлено». Только сегодня практически все пишут на ES6, а кто не пишет — очень рекомендую, или сразу на Typescript
Если эти фреймворки сложны и система построения проекта зашкаливает, то попробуйте Google Polymer — это надстройка над новой системой в HTML — Web Components. Это всего лишь библиотека, позволяющая строить компоненты легко и прозрачно. У меня заняло несколько минут понять простоту системы, пару часов для написания простейшего проекта и неделю для достаточно сложного проекта и разбора истемы в деталях. Просто открыть документацию и прочиитать её (она относительно короткая) будет достаточно для написания систем практически любой сложности. Не требуется знаний новейших скриптов, поскольку используется уровень функции и объекта, а не класса. Система загрузки зависимостей встроена в HTML. Существует аппликация Vulkanizer, позволяющая упаковать весь проект в один файл
В Java есть два типа исключений:
— декларируемые, которые нужно декларировать по всей иерархии вызовов
— RuntimeException, которые появились из-за диких проблем с первыми. Они работают так же, как исключения в С#
Абсолютно согласен. Самый прозрачный фреймворк, полностью разделяющий обязанности HTML, CSS & JS. Мне только показалось, что в 0.8 версии они убили всю простоту и человекоориентированность. Надеюсь, что ошибаюсь.
Реакт сам по себе очень прост и гибок. И увеличение проекта никак на это не влияет. В этом плане он ничем от других библиотек компонентов не отличается, он даже проще. А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.
Не очень понимаю, каким тормозом нужно быть, чтобы за два месяца не написать 3 экрана, разве, что там каждый экран это докторская диссертация.
<humor>Освящать что бы то ни было — это прерогатива церкви. </humor>
НО.
Если разобраться по сути, то окружение Джавы, С# и JS не так уж принципиально отличаются. В Java и С# существует Виртуальная машина, её ассемблер/intermediate language (e.g. MSIL) и JIT компиляция. В JS тоже самое. Браузер с его V8 или другим движком это собственно та же виртуалка, её ассемблер/IL это и есть тот самый JS, а проблема совместимости версий существует из-за необходимости поддержки старых браузеров (привет Майкрософту). И транспиляторы компилируют код из разных языков в JS так же как компиляторы из Java/Scala/C#/VB в код их виртуалок. А далее за дело берется JIT, который существует во всех них. И то, что код VM не читабелен, а код JS да, принципиального рояля не играет.
Тоже можно сказать и про инструменты сборки проектов. У Java есть Maven/Gradle, у C# — MSBuild у JS много всего на выбор. Часть умирает, часть выживает.
И так практически по всем пунктам. Со временем поутихнет развитие и останутся проверенные временем решения. Уйдут в небытие старые несовместимые браузеры, ужесточатся стандарты, надают по шее Майкрософту. На смену (или в дополнение) интерпретируемому JS придет нормальный IL, например webasm. Напишут компиляторы с разных языков и будет всем счастье. Устаканятся фреймворки. Может кто и до реализации WPF дойдёт (Я его реально люблю). Возможно и с CSS layout что нибудь нормальное сделают (хотя в это мне намного меньше верится, чем в победу разума над JS)
Чисто для инфы, я работал на клиенте, когда серверов (в нынешнем понимании) ещё не существовало, работал на сервере и сейчас пишу на всяческом фронт-энде. Просто в большинстве знаю эту кухню и весь кошмар не по-наслышке. И, если честно, не смотря на все его недостатки, мне нравится JS.
— декларируемые, которые нужно декларировать по всей иерархии вызовов
— RuntimeException, которые появились из-за диких проблем с первыми. Они работают так же, как исключения в С#