Комментарии 227
Это пути могут быть критичными в каких-то задачах и поэтому какой-то определённый framework может оказаться где-то более выгодным.
Где например Angular выгоднее React'a или Vue? Или Vue выгоднее чем React или React выгоднее чем Vue? Только с собственными реальными аргументами и доводами
Ну вот смотрите у нас был Net MVC с Telerik Kendo UI. MVC Нас больше не устраивал по ряду причин и мы стали смотреть альтернативы. У Telerik на тот момент была более менее развитая версия Kendo под Angular и не особо развитые версии под два других.
Кроме того TypeScript по мнению многих в нашей фирме для бэкэндшиков/сишарперов понятнее, логичнее и удобнее чем JavaScript. И на нём большинству у нас удобнее/привычнее работать с интерфейсами и контрактами.
И это две основные причины по которым мы взяли Angular.
Да как сказать… Если так смотреть, то все причины можно назвать субъективными. Кроме того вы же сами просили "собственные реальные аргументы" :)
Ну и кроме того продукты вроде Kendo UI Telerika использует не так уж и мало фирм. А уж TypeScript vs JavaScript так это вообще для гораздо большего количества фирм/разработчиков вполне себе решающий фактор.
Фреймворк/библотека X может это, а используя фреймворк/библиотеку Y это сделать невозможно.
Я понимаю что таких аргументов не будет, потому что их и не существует, они все могут делать все что пожелаешь. Вот и всё, дальше дело вкуса. Я по этому и сказал в этой ветке, что весь web frontend решает абсолютно одинаковые задачи, и я хотел бы увидеть обоснование
… но только немного разными путями.
Это пути могут быть критичными в каких-то задачах и поэтому какой-то определённый framework может оказаться где-то более выгодным.
Вы извините конечно, но по идее то абсолютно всё можно на ассемблере написать. Но это же не значит что использовать или не использовать ассемблер для веба это "дело вкуса".
Вопрос же скорее не в том что возможно или невозможно сделать в принципе. Вопрос в том какой фреймворк в конкретной ситуации оптимальнее и позволяет достичь нужного результата с наименьшими затратами и/или с наибольшей эффективностью.
Во первых да, какой фреймворк больше подходит зависит от компании/разработчика и конкретной ситуации. То есть ультимативного преимущества одного фреймворка над другими лично я не вижу.
А во вторых нет, на мой взгляд это всё таки не "вкусовщина", а вполне себе объективные причины по которым логичнее выбирать тот или иной фреймворк в том или ином случае.
Ещё раз: глобальных и применимых всегда и для всех причин не существует. Но объективные причины для каких-то отдельных ситуаций вполне себе могут быть.
Это как нет какой-то глобальной причины вообще не есть орехи, но люди, у которых аллергия на орехи, вполне себе имеют объективную причину их не есть.
А во вторых нет, на мой взгляд это всё таки не «вкусовщина», а вполне себе объективные причины по которым логичнее выбирать тот или иной фреймворк в том или ином случае.
а вполне себе объективные причины по которым логичнее выбирать тот или иной фреймворк в том или ином случае.
Так где пример который подойдет для всех? Если таковых нет, значит это все вкусовщина и субъективное мнение. А вы говорите есть объективные причины.
Если таковых нет, значит это все вкусовщина и субъективное мнение.
"Обьективная причина" не означат "причина одинаково применимая во всех случаях". Это как в моём примере с орехами: есть объективная причина почему аллергикам не стоит есть орехи. Но эта причина, несмотря на то что она объективная, не применима к людям у которых аллергии на орехи нету.
Субъективная причина не есть орехи это например если кто-то просто не любит вкус орехов
1.Порог вхождения — source code (HTML + JS + CSS) — легче читается новичку чем JSX — меньше времени на обучение, ознакомление с кодом.
2. Читабельность кода. В React часто передают функции через props и определить тип полученных данных иногда можно только по наличию контекста. В React есть такая фича как Stateless Functional Component и в сочетании с Arrow Functions и теми же Arrow Functions которые передаются в props компонента — в итоге на больших проектах (лично я наблюдал такой монструозный код на продакшн для Deutsche Bank) — который сами программисты вручную не могут поддерживать — всё приходится обвешивать тестами — потому что уже невозможно отследить логические связи и зависимости, да и просто вложенные Arrow Functions плохо читаются. А если пропустить эти функции через higher-order component (HOC) — картина становится ещё более запутанной.
3. Интеграция с другими языками — технологиями. Vue использует валидный HTML код для шаблонов и благодаря этому может быть использована с системами генерирующими HTML (JSP, PHP, Google Apps Script...) — AEM CQ5 — с их HTL (язык шаблонов) прекрасно интегрируется с Vue. Хотя большинство онлайн-казино и используют React (+ JSX, + Babel). Длинный код на React неудобно писать на чистом JS + HTML, поэтому если проект не крошечный — всё-равно надо будет осваивать JSX и код пре-компилировать.
4. React: one-way data binding, Vue: two-ways and one-way data binding
5. Наличие дополнительных фреймворков — как и React так и Vue имеют достаточное количество дополнительных инструментов (в этом отношении они равны) — Vuex, Vue Router, Vuetify
6. Vue-разработчики пока дешевле React-девелоперов и их проще и дешевле (пока что) обучить на рабочем месте, прямо на реальном проекте, чем долго искать хорошего специалиста в React/Redux
Фреймворк/библотека X может это, а используя фреймворк/библиотеку Y это сделать невозможно.
$mol умеет в полную ленивость (что не влезает — не рендерим, что не рендерим — не инициализируем, что не инициализируем — то не загружаем, что не загружаем, то даже не собираем), а на Реакте такое сделать невозможно.
Вы внимательно прочитайте о чём я написал. Речь не про динамическую подгрузку кода.
Ну, попробуйте реализовать такое приложение, чтобы оно так же быстро открывалось: http://mol.js.org/app/lamps/#lamp=1
PS. Да вы хитрожопый однако, рендерите то, не все разу а буквально 20 штук которые влазят во view port, сравнение времени рендера не корректное будет, я могу так тоже сделать, просто тупо первые 20 отрендерить и хватит, для ранозначного сравнения
- Чего это вы с Реакта на Свелт перескочили?
- Чего исходники постеснялись выложить? Потому что там лютый не поддерживаемый чудокод с обращениями вида
item[52]? - Где полнотекстовая фильтрация по мере ввода?
- Где гиперссылки для каждого элемента?
- Где подсветка текущего элемента на основе текущей ссылки?
- Ну и, собственно, смотрим как оно всё работает под мобилкой:
$mol_view
Svelte
Когда лампочек станет не 2к, а 5к, ваше приложение вообще 4 секунды будет открываться, а моё практически не замедлится.
А если ещё и добавить требование подсветки найденного — ваше приложение вообще колом встанет.
Ну и вот, кстати, добавил подсветку найденного:
Приложение вообще не замедлилось. Попробуйте повторить, если вдруг будет нечего делать, как мне.
А это ваш мега быстрый $mol
И ещё у этого примера в Svelte размер бандла 2.2kb
Svlete с 20-ю отрендеренымиэлементами как у вас в примере
И как пользователю открыть двадцать первую лампочку?
ещё у этого примера в Svelte размер бандла 2.2kb
Так оно ничего и не умеет.
Вы думаете мне делать нефиг, точную копию вашей фигни делать? Я сделал упрощенный вариант. А лучше чтобы полный список сразу рендерился, без сокращения элементов DOM
Сделайте точно такой же аналог самый простой, просто тупо сравним рендер и размеры бандлов
Вы настолько упростили, что сломали основной пользовательский сценарий — найти лампочку. Ваше приложение стало совершенно бесполезным. С тем же успехом вы можете вообще ничего не рендерить, не загружать, и показать просто феноменальную производительность.
Я вам по секрету скажу: пользователя не очень волнует с какой скоростью вы создаёте дом-узлы, зато его волнует время открытия приложения и удобство работы с ним.
Сравнил с вашей третьей версией:
$mol: 1.5с работа js + 30мс браузера = 1.5 секунды
Svelte: 1.4с работа js + 1.7с браузера = 3 секунды
Скрины я выкладывал выше, ситуация не сильно поменялась.
Ссылка ни сколько не поменялась.
Только в моей версиями DOMContentLoaded за 70ms а в вашей за 140ms. Я специально не отключал кэш для обоих, чтобы не было в измерениях сетевых задержек. Во вкладке Performance: Rendering у вас 11ms, у меня 3ms. Так что ваш мол проигрывает по всем фронтам.
Перечитайте, пожалуйста, и подумайте:
https://habr.com/ru/company/ruvds/blog/470413/#comment_20740078
Не люблю повторяться.
Собственно, напомню исходный тезис:
$mol умеет в полную ленивость (что не влезает — не рендерим, что не рендерим — не инициализируем, что не инициализируем — то не загружаем, что не загружаем, то даже не собираем), а на Реакте такое сделать невозможно.
Вы не смогли реализовать ленивый рендеринг ни на Реакте, ни на Преакте, ни на Свелте. Что и требовалось доказать.
Всё, что вы смогли сделать — бесполезное приложение, которое не выполняет основной пользовательский сценарий. И на поприще бесполезных приложений героически "победили" конкурента. Поздравляю, можете купить себе медаль. А то ваше приложение, которое всё же выполняет пользовательский сценарий оказалось в 2 раза медленее и не масштабируется.
Из всего вышесказанного можно сделать вывод, что вы либо идиот, не способный к элементарным умозаключениям, либо прикидываетесь, рассчитывая, что окружающие поведутся на вашу демагогию. Ни то, ни другое вас не красит.
Всё несколько хитрее, чем вы думаете.
Реализуйте же такое, наконец, раз там всё так элементарно, как вы говорите.
На уровне ядра и стандартных лейаутов, да. Прикладник может вообще об этом не думать.
https://habr.com/ru/post/470337/ — почти 1к комментариев на одной странице. Надо ли говорить, что на мобилке вся эта портянка рендерится целую вечность?
А уж что у вас творится с биндингами это вообще караул (если что печатаю я все четко в обоих примерах, но $mol упорно пытается за меня дописать или удалить символы):
Эта проблема наблюдается из-за дебонса инпута — значение ему устанавливается асинхронно и вы успеваете его изменить. В версии мола на вторых атомах уже используется прогрессивный рендеринг, где надобности в дебонсе больше нет.
Это проблема любого асинхронного рендеринга с биндингом состояния на инпут. Вы, как обычно, не разобравшись в сути вопроса, пытаетесь выставить Svelte в лучшем свете, чем он есть.
Во-вторых, я пишу про весь пример. Если супер-пупер оптимизированный фреймворк юзает в примере супер-пупер специально оптимизированные встроенные компоненты со всевозможными лениво-асинхронными-отложенно-лейаутзависимыми-вставитьсвойбазворд фичами и при этом работает существенно хуже чем тупой рендеринг всего списка в DOM и поиск по нему. До кучи ответный пример написал человек, который со Svelte познакомился ровно для этого примера. То тут ничего не надо представлять в лучшем свете, все итак очевидно.
Не придуривайтесь, из контекста обсуждения и так понятно, что речь про асинхронность с отпусканием ивент-лупа. Микротаски его не отпускают. Добовьте дебонс и реактивное управление состоянием инпута и получите те же проблемы.
Если же вы про теребоньканье скроллбаром, то это не то, чем занимаются пользователи приложения. Это разумная цена за малое время открытия страницы.
Не придуривайтесь, из контекста обсуждения и так понятно, что речь про асинхронность с отпусканием ивент-лупа. Микротаски его не отпускают.
Я не читал весь тред, не так сильно интересуюсь вашими баталиями. Так то микротаски также отпускают ивент-луп после обработки кью, но вы наверное про гарантирование 60фпс. Да этого микротаски не дают. И конечно же в можно придумать надуманных задач, когда они могут держать ивент-луп.
Если же вы про теребоньканье скроллбаром, то это не то, чем занимаются пользователи приложения. Это разумная цена за малое время открытия страницы.
Не теребоньканье, а подчеркнуто не нативный UX скроллбара. Такие скроллбары вообще использоваться нельзя. Ну и я чет на заметил чтобы страница открывалась быстрее и бандл весил меньше.
Микротаски не отпускают ивент-луп. Они исполняются все сразу в конце обработчика события.
Если вам лень следить за обсуждением — чего тогда спешите делать выводы? Функциональность у приложений сильно разная.
Функциональность как-то влияет на адекватность работы списка и поиска?
И там, и там продакшен-реди исходный код?
И там, и там есть фильтрация по любому полю, а не только по названию?
И там, и там пункты меню являются ссылками на лампочки, а не тупо дивами?
И там, и там текущая открытая лампочка подсвечивается в меню?
И там, и там найденные в названии подстроки подсвечиваются?
Ну и простой тест: открываем на мобилке, вводим e27, потом стираем:
https://mazabenchmarks.github.io/svelte-lamps-v3/
По две секунды на любой чих. Привет вам от моего аккумулятора.
https://mol.js.org/app/lamps/
Максимальная зедержка — 1 секунда, и то треть этого времени — парсинг в CSV в массив объектов, а не тупо в неподдерживаемый массив массивов.
Пора бы взрослеть, ребята, и думать не над тем, как бы выиграть у кого-то в споре на Хабре, а о своих пользователях и том, что именно они делают в вашем приложении.
Пора бы взрослеть, ребята, и думать не над тем, как бы выиграть у кого-то в споре на Хабре, а о своих пользователях и том, что именно они делают в вашем приложении.
Ваше решение работает с точки зрения пользователя объективно хуже, чем в свелте (если считать ваше решение вообще рабочим — а оно таковым не является, т.к. ввод зхабагован донельзя).
О чем вы вообще?
Вот тут вывод сразу всего списка + фильтр, когда обновиться git pages
Сделайте ровно тоже самое и сравним, если не слабо конечно.
Размер 2.4kb
Обратите внимание, что в приведённом мной приложении высота строк зависит от содержимого, а в коде приложения нет применения какого-либо специального компонента для виртуализации скроллинга — там просто тупо выводятся данные.
Впрочем, демки виртуального скролла с выводом 10 элементов — это детский сад. Сделайте хотя бы пару сотен видимых элементов.
1) Infinity scroll
2) Pagination
P.S.
лол, тоже мне пагинатор
- Мы уже обсуждали этот вопрос. Infinity Scroll работает лишь для плоских списков. Любая иерархия, как на примере со скриншота, и IS превращается в тыкву, рендеря поддерево целиком.
Пагинация в обмен на решение проблем с производительностью ухудшает UX. Пользователю нужен n+1 элемент, а ему вместо продолжения скроллинга предлагают целиться в кнопку и перескакивать на начало страницы. А особенно весело между страницами дрегендропить.
$mol_paginator отвечает лишь за отображение номера и приёма намерений пользователя. Ограничивать множество возможных значений — не его зона ответственности. Можете глянуть тут как он работает в боевых условиях: https://slides.hyoo.ru
Но, в принципе, да, надо демку приблизить к реальности.
Да, фиксированная высота строк это проблема. В то же время в вашей демке проблема это само поведение кастомного скроллбара, оно забагованное.
Если вы про потребление памяти, то вы не там её смотрите. Актуальное значение на вкладке Memory в девтулзах.
MVC Нас больше не устраивал
очень субъективная причина
развитая версия Kendo под Angular и не особо развитые версии под два других
а вот это кейс с аргументацией
Но довольно специфичный. С таким кейсом не выведешь общее правило — нужны ещё.
очень субъективная причина
Это как раз в данном контексте не причина, это скорее "стартовое условие" :)
С таким кейсом не выведешь общее правило — нужны ещё.
А общего правила на мой взгляд и не будет. Всё зависит от задач и окружающей ситуации. Я вообще думаю что чаще всего решающий фактор это наличие/доступность экспертизы в том или ином виде.
Эта субъективность может потом выйти в сэкономленные человеко-часы на разработку, а может потом и на дальнейшую поддержку. Это уже хороший, но не единственный, повод.
Для кого-то действительно писать код на Angular будет быстрее. Или просто понятнее/проще и его использование будет создавать меньше багов и проблем. Или он проще встраивается в имеющиеся продукты и/или инфраструктуру. Или ещё какие-то другие причины, которые позволят экономить человекочасы и расходы в целом.
Писать код на высокоуровневом фреймворке типа KendoUI будет быстрее, чем на любом низкоуровневом.
Именно поэтому мы 3 года назад запилили высокоуровневый $mol, лишённый этих недостатков.
Ну да, если не надо делать шаг влево / шаг вправо, а когда придется, то начинается, ступор, грабли, костыли на костылях…
Только в том случае, если работают не специалисты. В других случаях как раз на задачах, где надо больше чем "шаг влево/шаг вправо", полноценные фреймворки и дают максимум выхлопа.
Вы angularJS вспомните. Работа над более-менее сложным проектом со временем превращалась в войну с фрейворком) А это еще не высокоуровневый фрейворк.
Причины выбора коречно субъективные, да.
ну Angular использует широкораспространенные подходы из взрослых языков и фреймворковМне любопытно, из каких? Глядя на архитекутуру angularJS, на мой взгляд его писали или java бекендеры или fullstack java разработчики. То, что там подходы бекенда на Java и соответствующих фреймворков, я не сомневаюсь. А вот то, что из каких-то других взято, я сомневаюсь.
А вот то, что из каких-то других взято, я сомневаюсь.
Ну я бы сказал что "подходы из Java" встречаются не только в самом Java и местами в сам Java тоже откуда-то пришли :)
Тогда спрошу по другому. Какие в angular есть подходы, которых нет в Java, но они есть в других взрослых языках и фрейворках?
Мне просто любопытно. Я смотрел немного доки, но не писал на java и angular, только на angularjs.
Как бы это обьяснить… А вот если человек с Java вообще не знаком, но знает скажем C#. И видит что все "подходы", которые есть в Angular точно так же присуствуют и в C#.
Moжет он в таком случае говорить что "подходы Angular взяты из C#"? Или логичнее всё таки сказать что "Angular использует широкораспространенные подходы из взрослых языков и фреймворков"? :)
То картина перевернется на 180 градусов trends.google.com/trends/explore?cat=31&q=Vue.js,React.js,Angular.js
А может, Ember и есть хипстеры, а React/Angular — стабильность с поддержкой крупной компании?
Кто-то скажет, что оно слишком старо, тем не менее это отличное решение. Хотя некоторые мелочи приходится допиливать самому.
Вы указываете, что Vue более стабилен. Опишите в чем проявляются нестабильности React и как их избегать.
Вы пишете, что React более гибкий. Опишите задачу на React можно решать гибко, и почему на Vue — нет.
Оценка технологии исключительно по Google Trends это непрофессионально.
Текст в статье написан поисковым спамером (их сейчас копирайтерами называют) с одной единственной целью — дать в конце рекламу.
vuejs.org/v2/guide/comparison.html
Никаких Google Trends, всё по делу.
P.S. Кстати, оригинал не блещет точностью выражений, а перевод выполнен не совсем близко к тексту. Ниже привожу пример.
Оригинал:
Vue also has worked with a virtual DOM but provides a faster performance in comparison to React. It also ensures a bug-free performance.
Перевод:
В Vue тоже используется виртуальная DOM, но, в сравнении с React, Vue отличается более высокой производительностью и стабильностью.
Начнем с того, что, по идее, в оригинале должно быть не Vue also has worked with a virtual DOM, а что-то вроде Vue also uses/utilizes a virtual DOM (респект переводчику, который не повторил ошибку автора). Еще хотелось бы понять, как a faster performance и a bug-free performance превратились в «более высокой производительностью и стабильностью».
Elm.
Был какой-то проброс с vue на react native, но я лично не доверил бы проект такой конструкции.
React — очень популярен, разработчиков куча. Да, он не очень удобный (по мне так вообще не удобный), зато можно писать достойные мобильные приложения на ReactNative.
Angular — тяжёлая штука, хороша для больших проектов и кровавого интерпрайза.
Vue — то, каким должен был бы стать AngularJS. Леко выучить, легко использовать в популярных сценариях. Минусы в том, что Vue для мобилок ещё не допилили и проще использовать ReactNative. Не так много разработчиков под Vue.
Если говорить про 2020 год и новые проекты то я не вижу альтернативы Svelte.
На нем проще писать, он гораздо компактнее, он быстрее. Если у вас планируется достаточно уникальный проект без множества готовых компонентов то я не вижу альтернативы Svelte.
Пробовал React и Vue, остановился на Vue. Не жалею… Сейчас правда смотрю в сторону Flutter, скоро должны релизнуть для web view.
Лично сам из трёх вариантов я остановился на Vue. Он мне больше всего понравился. Но минус во всех них для меня это JS. Вот не полюбил я его за несколько лет. Особенно потому что так же регулярно пищу на Kotlin и сейчас уже меньше на Java. Котлин, кроме мобильной разработки, очень интересен поддержкой JS, что я могу работать с фронтом на нормальном языке (да не обидятся на меня JS'ники) Ещё очень интересен Flutter, в первую очередь для мобильной разработки и в дальнейшем для десктопных аплекух, ну и потом для веб.
Свой вариант, angular. Но пора прекратить выбирать "лучший framework". Если инструменты решают поставленные задачи, то можно брать любые.
А что мешает писать react и vue приложения на TS?
Свой вариант — Web Components.
Web Components это не то чтобы совсем альтернатива для Аngular/Vue/React. У того же Аngular есть так называемые Elements, которые на самом деле просто возможность генеририовать Web Components из ангуляровских модулей.
А в чём конкретно заключались ваши "попытки"? Ну так для интереса просто. У нас Angular для ie11 вообще без проблем генерирует веб компоненты. Для ie9 мы баловались и вроде тоже работало, но поскольку в прод нам не надо ie9 поддерживать, то мы нормально не тестировали.
P.S.И кстати какого-то особого лишнего кода для веб компонентoв в Angular писать не пришлось. С билдами и деплойментом пришлось немного повозиться это да, а код мы везде один и тот же используем что для single page, что для elements.
То есть вы не web-components голые используете, а angular elements
Именно так. Но на выходе то получаются самые обыкновенные Web Components. которые от "обычных написанных вручную" не особо то и отличаются.
А писать Web Components вручную это конечо тот ещё квест. Особенно если их много и надо ещё легаси браузеры поддерживать. Я бы за такое наверное не взялся :)
Интересно а как вы с веб-компонентами работаете с динамическими списками? Допустим есть список тодошек где можно удалить элемент или вставить новый в любое место в списке. Как вы будете синхронизировать изменения списка тодошек в состоянии с шаблоном? Реакт, ангуляр и вью выполняют так называемый diff списка сравнивая элементы по ключу и перемещая нужные элементы чтобы избежать проблем соответствия компонентов и их дом-элементов. А некоторые фреймворки вроде ivijs или infernojs для сравнения списков вообще реализуют LIS алгоритм который вычисляет минимальное количество перестановок чтобы в итоге уменьшить число dom-операций insertBefore
А где про этот алгоритм почитать?
Про diff списка на основе LIS неплохо описано
в самих исходниках ivi — https://github.com/localvoid/ivi/blob/master/packages/ivi/src/vdom/reconciler.ts#L578. А сам алгоритм LIS неплохо объясняется в этом видео
https://www.youtube.com/watch?v=1RpMc3fv0y4
1) Краткость.
ОДНОЗНАЧНО Vue.
Простой пример: Надо отобразить на экране форму в которой к примеру редактируемых 40 полей
Для React это 40 функций прописанных в коде (Или замудрых выражений в шаблоне )
Для Vue функций 0.
Аргумент убедительный?
И еще синтаксис функций React как бы чрезмерно избыточен. особенно если надо прописать биндинг на вложенное свойство (типа user.docment.Number.
Ну и что выберет адекватный разработчик без опыта в react/vue, глядя на это?
В vue уже есть встроенное решение. В реакте надо самому делать велосипед. В документации и среди best practices от коммьюнити такого нет. Мало в каких командах есть подобное, а если и есть, то по разному реализовано. Также в случае использования сторонних компонентов, к ним это не всегда применимо, либо требует времени еще и к ним это применить.
Ну и это далеко не единственный случай, где в реакте надо самому писать аналог того, что в vue уже есть.
В vue тоже хватает недостатков, но на данный момент он выглядит попривлекательней реакта.
реакт дает тебе очень гибкий инструмент который ты можешь миксовать как угодно и в умелых руках он превращается в шикарную штуку
Вы только полюбуйтесь на эти костыли: https://github.com/mobxjs/mobx-react/blob/master/src/observerClass.js#L69
Там сложность зависит от того насколько сильно изменился массив — K*Log(N) где K это количество перестановок в массиве. Например если в списке из 10к элементов произошла перестановка 3 элементов то LIS будет практически линейным — будет последовательно заполнятся массив из 10к элементов и только в трех случаях будет бинарный поиск до нужного элемента. Зато LIS позволит выполнить всего три insertBefore dom-операции вместо почти полного перестроения всего списка как это делает реакт
А и это вы только считываете изменение значений их еще установить надо.
то есть начитать объект. a потом его сохранить отредактированный и свойства не простые только простыe. а и вложенные ( типа user.documetn.Num).
При работе с React на пустом месте создается гора трудно читаемого кода.
Простой пример: Надо отобразить на экране форму в которой к примеру редактируемых 40 полей
В обоих случаях это будет map по массиву из 40 полей и одна функция.
2) Приведите пример React кода где обрабатывается биндинг объекта со сложной вложенностью типа
user.Name
user.Document.Number
user.Document.Type
И очень желательно что бы функция не была заточена под конкретный объект. На самом деле мне это надо, ибо на работе принято решение использовать React.
Лично я для себя выбрал Vue, так как он легче в изучении, и умещяает огромные возможности в крайне простом API.
Так как это мой первых проект с использованием JS-фреймворков, я не делаю упор на конкретный фреймворк, вместо этого, я стараюсь использовать из него только нужные мне возможности, а остальное делать уже другими методами (знаю, что так делать не хорошо, но этот проект — нечто вроде эксперимента).
Даже по первому взгляду на документацию, мне стало понятно что скорее всего я буду юзать Vue, так как он более гибкий в плане совместимости с другими библиотеками.
1) Гораздо быстрее
2) Гораздо проще
3) Глаза не замыливаются кучей дополнительного кода в виде типов.
4) Ты не скован в выборе вспомогательных инструментов в виду отсутствии у них типизации.
Как обычно на самое важно всем насрать (хорошо что я к этому числу не отношусь), поэтому в какой проект не глянь, аж плакать хочется… АРХИТЕКТУРА, вот что самое важное было всегда и будет всегда. Если у вас хорошая архитектура, вам вообще никакой TS даже близко не нужен. С дерьмовой архитектурой (> 90% проектов) без разницы, есть там типизация или нет. Поддержка таких проектов для людей которые не писали весь этот код, сущий ад в любом случае.
Приводить в примеры монструозные проекты которые содержат тысячи компонентов, сотни тысяч функций не надо, вы в таких не участвуете и не будете участвовать, 99.99% проектам все это не нужно, это лишь напрасный оверхед и потеря времени/денег для бизнеса.
Бла бла бла, а по факту писать с динамической типизацией:
Писать с динамической типизацией действительно местами быстрее и даже проще. Сложнее будет потом кому-то другому(а может и вам самим) когда надо будет через пару лет разбираться почему и как что-то там работает или не работает. И чем больше у вас проект тем сложнее будет разбираться.
Если архитектура плохая и сам подход к написанию когда плохой, то да, но тут и TS никак не спасет.
Да, в такой ситуации не спасёт.
А если архитектура хорошая и все написано очевидно и сверху вниз, то вообще без проблем.
А вот тут не соглашусъ и как минимум мой опыт говорит мне что часто TS с его интерфейсами в такой ситуации гораздо удобнее и создаёт меньше проблем.
А вот тут не соглашусъ и как минимум мой опыт говорит мне что часто TS с его интерфейсами в такой ситуации гораздо удобнее и создаёт меньше проблем.
Я так же не согласен, вообще без разницы есть TS или нету в случае хорошо написанного кода. Только если он есть, глаз замыливается дополнительным кодом и описанием типов. А раз вы его выделяете, значит вы все таки никогда не видели хорошо написанный код, в котором все понятно что происходит любому человеку, который первый раз видит проект, он просто смотрит что делает та или иная функция ему все понятно, он просто идет сверху вниз, без надобности заглядывать попутно в сотни файлов, потому что написано грамотно, по простому.
он просто смотрит что делает та или иная функция ему все понятно, он просто идет сверху вниз, без надобности заглядывать попутно в сотни файлов, потому что написано грамотно, по простому.
Я посмотрю как вы "грамотно по простому" напишите код если у вас скажем ваш DTO для коммуникации идёт по какому-нибудь индустриальному стандарту и имеет пару сотен(а то и тысяч) аттрибутов.
Я подозреваю что вы просто похоже до сих пор не сталкивались с бизнес-процессами и задачами где "сотня файлов" это не "ошибка архитектуры", а обоснованная необходимость.
Покажет же этот идеальный код, который никогда не потребует рефакторинга.
Бла бла бла, а по факту писать с динамической типизацией:
1) Гораздо быстрее
2) Гораздо проще
По факт в любом проекте на одну строку кода написанного кода приходится 6-12 строк переписанного. Переписывать статически типизированный код проще.
3) Глаза не замыливаются кучей дополнительного кода в виде типов
Когда вам нужно выяснить что происходит в проекте, этот дополнительный код становится основным.
Приводить в примеры монструозные проекты которые содержат тысячи компонентов, сотни тысяч функций не надо, вы в таких не участвуете и не будете участвовать
Из 4-х проектов, которые я писал последние 6 лет только в одном счет компонентов шел на десятки. В остальных — на сотни.
Это всё очень хорошо когда вы сами в одиночку пишите фронт и бэк. Или если вам дают время подправить ваш фронт после изменения в бэке.
А вот если у вас фронт и бэк паралелльно пишут две разные команды, то вам нужен какой-то интерфейс, которого должны придерживаться обе стороны.
И его конечно можно написать на бумажке, но гораздо удобнее сразу использовать языки, которые позволяют использовать интерфейсы. А в оптимальном случае имеют какую-то возможность дефинировать интерфейс один раз одновременно для фронтенда и бэкэнда.
Но есть ли суммарная выгода по потраченному времени с TS?
О каком потраченном времени вы говорите? При нормально настроненном IDE и тулинге в целом, TS даже местами позволяет экономить время.
Например если у вас интерфейсы уже дефинированы в бэкэнде, то для фронта можно их спокойно автоматически генерировать. И даже стабы классов имплементирующих эти интерфейсы можно генерировать. И стабы классов для работы с этими интерфейсами можно генерировать.
В принципе даже простые формочки для обработки этих классов(например crud'ы) можно целиком генерировать из интерфейса. И уже с нужными контролями, с примитивной валидацией и с нужным порядком/расположением.
Архитектура должна задаваться фреймворком. Теми самыми фреймами которые будут удерживать архитектуру в заданных параметрах.А программисты тогда чем заниматься должны? Изучить фреймворк и бездумно следовать решениям его авторов? Итак немного людей, способных построить более менее гибкую и удобную архитектуру. А если за программистов фреймворки будут решать, тогда вообще такие люди переведутся.
А программисты тогда чем заниматься должны?
Ну например они могут первым делом выбирать наиболее подходящие под какую-то задачу фреймворки. А потом уже развивать архитектуру в имеющихся рамках.
В любом случае на мой взгляд это более логичный подход чем когда делается наоборот и какой-то "любимый" фреймворк пытаются прогнуть под не подходящую для него архитектуру или даже задачу.
Ну если совсем грубо, то ассемблер тоже можно подо всё прогнуть. Но это же не причина везде использовать ассемблер?
Гибкость она ведь тоже не за просто так даётся и не всегда является "ультимативным плюсом".
Иногда и какой-нибудь .Net MVC логичнее использовать. От ситуации зависит.
Так как его прогнуть под pull семантику? Это очень удобная штука.
Странная логика. Если за каменщика проект здания будет решать куда класть кирпичи, тогда архитекторы вообще переведутся?
Проект каждого здания делает архитектор, а не какой-нибудь ГОСТ, например. Если будут делать по одним и тем же проектам зданий, то откуда взяться архитекторам.
Так и в программирование архитектура должна задаваться не фреймворком, а архитектором. Да, в каких-то рамках фремворка. Но это не значит, что не стоит выходить за эти рамки, не значит, что надо следовать всему, что диктует фреймворк.
Да на любом уровне абстракции можно придумать тот же самый пример: Если за архитектора санитарные нормы будут решать сколько кубометров воздуха должно приходиться на человека, тогда разработчики этих норм вообще переведутся?
Жизнь такая, что кто-то способен сделать хорошую архитектуру, а кто-то нет. Кому-то это интересно, а кому-то нет. Кто-то любит разрабатывать инструменты, а кто-то ими пользоваться. И это нормально, что первые создают фреймворки, а вторые ими пользуются. Каждый делает то, что получается у него лучше всего.
Жизнь такая, что кто-то способен сделать хорошую архитектуру, а кто-то нет. Кому-то это интересно, а кому-то нет. Кто-то любит разрабатывать инструменты, а кто-то ими пользоваться. И это нормально, что первые создают фреймворки, а вторые ими пользуются. Каждый делает то, что получается у него лучше всего.К этому у меня претензий почти нет.
Мне эта фраза не понравилось:
Архитектура должна задаваться фреймворком.Ощущение такое, что хотелось сказать: «зачем нам в команде архитектор или зачем нам заниматься проектированием, если есть фреймворк.» Может быть она только мне такой показалась.
Ну, толковый архитектор — птица редкая. Поэтому да, лучше без самодеятельности. А если такая птица есть, то она либо сама выбирает фреймворк под задуманную архитектуру, либо делает свой. Но результат для остальных всё-равно тот же — надо делать в соответствии с гайдлайнами фреймворка.
И чем меньше фреймворк оставляет возможностей для индивидуальных извращений отдельно взятого программиста работающего над коллективным проектом тем лучше.
Типичная логика(оправдание) для тех, кто думать не хочет(может и не умеет).
Я конечно понимаю что основная масса разрабов > 95%, это очень низкий сорт, который реально даже не способен построить архитектуру для приложения, но это не значит что остальные 5% такие. Это 95% на то и 95% потому что им даже думать никто возможности не дает, говорят просто вот тебе это и это, делай так и всё.
Проблема как раз ровно в этом. Что каждый думает своей головой. Но по разному. И чем меньше фреймворк оставляет возможностей для индивидуальных извращений отдельно взятого программиста работающего над коллективным проектом тем лучше.Ну а какие есть варианты?
Либо постоянная борьба с фреймворком, чтобы сделать костылями то, что в нем не продумано. И то тут каждый по своему будет делать.
Либо договариваться с командой и делать code review, чтобы придерживаться более-менее общего стиля.
То же самое можно отнести к языкам программирования. Чем менее гибкий язык, тем он лучше получается?
А вообще, может приведете несколько популярных не гибких фреймворков?
Ангуляр, Вью, Реакт — все они не позволяют менять шаблонизатор.
А о чём же?
Ну вот разработчик хочет писать шаблоны в ином синтаксисе — как ему это сделать?
Да и отсутствие в фреймворке каких-либо фич, еще не повод называть его не гибким. Везде чего-то кому-то не хватает. Всем не угодишь. Минус фреймворку, если действительно востребованной фичи нет, а если она практически никому не нужна, то даже хорошо, что разработчики не потратили на нее время.
Продолжать дискуссию про шаблонизаторы больше не буду. Мне эта тема не интересна.
ЗЫ. Я бы выбрал ванилу, так как с веб компонентами и шэдоу домом всё можно сделать самому.
Как-то нелогично совсем получается, что нативный движок медленней рантаймовского JS…
Даже Google для своих технических демонстраций на Chrome Dev Summit использует React.
В общем React потенциально более интересен.
codesandbox.io/s/kind-colden-7bviy
и я имею в виду именно выкрутасы с функциями, а не реализацию конкретно этой зашитой разметки.
пс: я понимаю, что искусственный пример жестковат для понимания, приношу извинения за бобо глазкам.
Что лучше выбрать в 2020 году — React или Vue?