Как стать автором
Обновить

Комментарии 69

> VanillaJS имеет смысл, только если ты можешь позволить себе потратить вечность на разработку проекта.

Ну или же ты используешь SvelteJS ;-)

Не уверен, что дропнуть саппорт ie11 — хорошая идея (хотя и очень хочется)

Людей с плохим зрением в разы больше чем пользователей IE. Забейте наконец на него и позаботьтесь о людях.
У нас в конторе порядка 3% заказчиков заходили через IE, однако мы приняли решение не тратить время на адаптацию нового сайта для старых браузеров т.к. лучше реально что-то более полезное сделать. Сразу скажу, что 3% с нашими оборотами это около 150-200 тыс руб прибыли ежемесячно. В итоге силы решили потратить на всевозможные оптимизации и ускорения сайта.
Ну да, забить можно. Просто это закрывает дорогу приложениям на Vue в корпоративный сектор. Для сайтов это не критично, а если ты делаешь веб-приложения то ой.

Корпоративный сектор бывает разный.


Доводилось мне делать одну штуку для крупной финансовой компании. Там по стандарту у всех сотрудников стоял последний Google Chrome. Поэтому мы использовали web-components, es6-фичи и т.д.


Множества "корпоративный сектор" и "компании сидящие на IE" хоть и пересекаются, но не тождественны.

Зависит от этого самого сектора и кто конкретно будет пользоваться. Я вот пилю продукт для энтерпрайза (медиа-агенства и аналитики из больших корпораций). У нас вообще требований как таковых нет, вся разработка идет только в хроме, фаерфокс открываем раз в несколько месяцев, на Edge всем вообще пофиг (а про ИЕ даже никто и никогда не спрашивал).
Ну так то да, можно найти проект, где не надо ие. Но если работаешь в b2b секторе, то там не все так просто. У меня есть статистика по продукту, где за год из 200 млн. сессий 40 млн. юзерами 46% из них используют ие, а именно 11-го 90%, а остальные 4-5%.

Это если еще гос. клиентов нет. Мы вот только год назад с трудом дропнули поддержку 9-го. Боль и унижение — объективная реальность.

Сразу скажу, что 3% с нашими оборотами это около 150-200 тыс руб прибыли ежемесячно. В итоге силы решили потратить на всевозможные оптимизации и ускорения сайта.


А решение-то принимал бизнес-руководитель или разработчики?

Это для сильно будущих версий. В актуальных билдах работа так же продолжится.
Сейчас Vue не поддерживает все, что ниже IE 9. Когда-то такое время наступит и для 11 ослика.

VanillaJS имеет смысл, только если ты можешь позволить себе потратить вечность на разработку проекта.

Бо́льшей чепухи уже давно не сышал. Фреймверк абсолютно не гарантирует положительный результат.

НЛО прилетело и опубликовало эту надпись здесь

С какой стороны посмотреть. Все зависит от задачи, во многих ситуациях фреймверк является избыточным, что не только не ускоряет разработку, а всячески мешает. Поэтому я и высказался о том, что фраза бредовая.

Я бы сформулировал иначе. Не «во многих случаях избыточен», а «в некоторых случаях избыточен». Чаще всего, фреймворки как раз значительно ускоряют разработку. А при условии наличия прямых рук — даже не чаще всего, а почти всегда.

… значительно ускоряют разработку на ранних этапах. В некоторых проектах фреймверк — это бомба замедленного действия. Фреймверки меняются, код остается.

НЛО прилетело и опубликовало эту надпись здесь

Есть вариант написания "фреймверка" под проект или серию проектов с прицелом на определенную предметную область. Бомба — это когда фреймверк утратил популярность и найти разработчика под проект становиться дорого, а баги фреймверка годами остаются не пофикшенными.

Вот только самописные фреймворки оказываются в состоянии «найти разработчика под проект становиться дорого, а баги фреймверка годами остаются не пофикшенными» намного быстрее…

Собственный "фреймверк" (если он конечно проектировался и был реализован соответствующим образом, без перегибов) обладает меньшим количеством не используемого кода, контроль команды над кодом и понимание "фреймверка" выше, что позволяет более эффективно обучать молодых специалистов. Я о проектах которые всегда находятся в стадии неприрывной разработки, а не о проектах с фриланса.

Это только до тех пор пока команда не разбежится. А она разбежится обязательно, потому что нельзя всю жизнь делать один и тот же проект.

После этого для следующего поколения программистов это будет уже не «собственный фреймворк», а «чужое легаси без документации».

Конечно команду нужно обновлять и это прямая задача руководства. Если руководство хочет всю жизнь ехать на одних и тех же, то проекту конечно конец.
Это равноценно и для проектов на общедоступных фреймверках. Приходится видеть проекты которые остали в обновлении фреймверка, потому что в какой то момент завязались на недокументированный API либо когда разработчики депрекейтнули часть API, что согласитесь не редкость...

Тем не менее, когда на проект приходит новый разработчик — для него освоить чужой велосипед не проще чем устаревший фреймворк.

Вот только у устаревших фреймворков есть актуальная документация — а у чужих велосипедов таковой обычно не наблюдается.

… а так же есть старые баги.


Просто мы рассматриваем два разных подхода которые имеют место быть. Типовые проекты, типовые задачи, типовые решения в виде фреймверков. Но шаг в лево, шаг в право сделать не просто.


Хороший пример (если мы о бэкэнде) зависимость от определенных реализаций БД, чем часто грешат фреймверки. Подходит для мелких проектов и совершенно не подходит для крупных, где может быть несколько баз данных с различными подходами к работе с данными.


Если ближе к конкретике во фронтэнде, есть Bootstrap который уродуют настолько, что документация теряет актуальность, а разработчики путаются в странном поведении фреймверка.


Далее обычно на проекте баги фреймверка патчатся, что делает документацию опять таки не актуальной. И получается, что в документации одна реальность, а требования к проекту создали новую реальность в которой документация уже не актуальна.


При наличии решения под проект ("фреймверка" — называйте как хотите) есть возможность сделать API отражающий требования к проекту, а если руководство не будет тупить — то и актуальную документацию.

Старые баги есть в обоих случаях, как в старом фреймворке — так и в чужом велосипеде.
НЛО прилетело и опубликовало эту надпись здесь
В вашем самописном фреймворке без документации будет ещё больше багов, чем в том, который попользовали 1000+ разработчиков в разных окружениях.

И вообще — в чём проблема исправить баги в неподдерживаемом более фреймворке? Это ничуть не сложнее, чем исправить их в самописном, а даже легче, если есть документация. Особенно когда оригинальная команда, создавшая «кастомный фреймворк» давно разбежалась. Если проект настолько большой и серьёзный — то на исправление багов выделяется отдельная команда, в обоих случаях.

Я много раз за карьеру видел, как проектируются и пишутся эти «самописки» (поработал в том числе в компаниях на 200000+ человек, с сильным IT департаментом и кучей внутренних IT-решений). Получается это хорошо (на самом деле крайне редко) только в том случае, если у вашей команды работа — писать фреймворки и опыт их написания лет 100 суммарно. А бизнесу обычно надо решать бизнес-задачи, а не проектировать кастомные фреймворки, которые денег не приносят и так же будут погребены под костылями, как и «народные», будут сильно забагованы и никто не будет знать, как оно точно работает.

Да, бывают очень узкие задачи, где кастом — самое то. Но это, по опыту, крайне редко проекты на 5+ лет жизни. Кстати, наблюдение: иногда можно испытать иллюзию, что своё лучше готового по причине того, что «своим» толком никто и не пользуется и складывается ощущение, что оно работает хорошо.

Вы привели в пример Bootstrap, где со временем накостылено так, что оно уже не работает как bootstrap. С кастомным будет ровно то же — задачи будут сыпаться в изобилии, делать их надо будет быстро и рано или поздно руководство будет принимать административные решения забить на концептуальную чистоту и сделать БЫСТРО, потому что деньги.

Ваши аргументы за «кастом» актуальны только в мире, где заказчик точно знает чего хочет, может это изложить, и больше никогда и ни за что не будет требования менять. В мире, которого в обозримом поле зрения нет. Атомные станции и самолёты делают доли процента всего IT мира.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

На мой взгляд в сравнении фреймвоков и самописных решений упущен очень важный момент — количество кода и зависимостей и при при прочих равных когда баги есть и в устаревших фреймворках и в самописных решениях второй вариант лучше потому что там просто меньше кода. Для наглядности — возьмем популярные шаблоны для создания приложений. При создании нового пустого проекта с популярным нынче create-react-app устанавливается 969 зависимостей, а с vue-cli устанавливается 1434 зависмости. 1434, карл!!! Мне кажется, имея 1434 пакетов, придется чуть ли не каждый день изучать ченджлоги потому что обновился пакет и исправил какие-то баги или добавил какие-то фичи. А что насчет безопасности? Сколько вы потратите времени на аудит, учитывая что каждый из этих пакетов может либо содержать увязвимости, либо быть скомпрометированным и достаточно добавить post-install-скрипт в один из этих 1434 зависимостей чтобы при выполнении команды "npm i" этот скрипт получит полный доступ к компьютеру с возможностями начиная от воровства токенов закачивая шифровальщиками или всякими вирусами. И при всем этом я что-то ни в одном проекте не видел чтобы зависимости коммитили в гит (чтобы избежать подмены исходников на npm, компрометации, или вообще взлома серверов по ссылках в lock-файлах) А какой процент фич от этих тысячи пакетов реально будет использоваться? Учитывая что каждый пакет имеет тенденцию добавлять все новые фичи на все возможные случаи, то чем больше комбинаций из этих пакетов — тем больше будет дублирования этих фич и попытка для большого бизнес-проекта, которому нужны гибкие и специализированные решения и быстрое развитие, выбрать какой-то жирный фреймворк как минимум столкнется с конфликтами, ограничениями и костылями. А теперь если сравнить с самописными решениями? Реакт (до 16 версии имел 20-25к теперь 18к строк) можно написать на 200 строчек кода, получив diff виртуального дома + компоненты. Имея js-парсер можно на 100 строчках реализовать сборку в бандл и webpack вместе с 431 зависимостями будет не нужен. В итоге, если сравнивать по количеству багов, то для того чтобы исправить какой-то баг — что проще — разобраться в устаревшем фреймворке на 20к строчек (собранный вдобавок из кучи других зависимостей) или в маленьком файле на 200 строчек? Я уверен что самописные решения (хотя правильно это было бы назвать "специализированный инструмент заточенный под нужды бизнеса") всегда будут гибче и проще как в поддержке так и развитии

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Но нужно помнить, что "госты" во фронтэнде (достаточно длительное время) не были в стабильном состоянии. Если вы превели аналогию с болтами, то я не про это. Я про архитектуру, а вы про низкоуровневые компоненты. Первый мой комментарий был о том, что разработчик Vue незаконно навязывает идею, что Vanilla JS — это плохо, а я говорю о том, что хорошая архитектура может быть построена на чем угодно (пускай голый HTML и обвязка правильно спроектированного JS API вокруг этого всего). Просто разработик пытается выгородить свой инструмент за счет приуменьшения значимости чего то еще. Это выглядит не очень. Некоторые вещи можно делать в разы быстрей (факт!) вместо конфигурации сборки фреймверка, изучения того что по факту не понадобится, причем это не будет чем то с чем не знакомы другие разработчики, просто это будет скучно.

Простой пример: вам нужно несколько форм и список чего то на фронтэнде. Голый HTML, CSS и form over HTTP (возможно JS) прекрасно справятся с задачей быстро сделать MVP, только не нужно спорить что это сложнее, чем притащить Vue. А в некоторых случаях есть большие успешные проекты использующие подобную модель и не чувствующие большого дискомфорта. Я за рациональность и за "не тащить все что попало", если это действительно не требуется. Разработчик Vue откровенно лукавит. Не всегда есть задачи в которых не обойтись без Vue, обычным Vanilla JS.

НЛО прилетело и опубликовало эту надпись здесь
Мне как раз приходится поддерживать (чужой) самописный фреймверк и я знаю что это такое.
1. Полное отсутствие документации.
2. Крайне бедный функцонал и отсутствие гибкости (запилить нову фичу фактически нужно лезть в ядро фреймерка).
3. Куча неотловленных багов.
4. Дикая тормознутость (начальная загрузка страницы на слабых девайсах до 20 сек. хотя на десктопах пару секунд).
5. Отсутствие обновлений — ну естественно все же уже наигрались в мега-разработчиков и свалили и вследствие этого использование библиотек и версий языков 5-летней давности.
6. Самый дикий. Черезмерно честолюбивые разработчики на фоне доверявших им менеджеров раположили фрейм в своих приватных репах вседствии чего по невнимательности ли, по злому умыслу ли некоторые репы удаллились вследствии чего приходилось искать их чуть ли не копии на каких-то списанных компьютерах.

Но конечно любоая разработка настоящего и полезного фрема как например Vue или React начинается со «своего фремверка». Тут наверное важнен правильный менеджмент и оценка возможностей. Т.к. если группа из 3 разработчиков начинает гнуть линию в сторону своего фреймверка скорее всего они не понимают во что ввязываются. Т.к. тут важно три момента что любой фрейм это не просто гениальный код это как минимум
— тысячи человеко-часов работы
— тестирование, документация
— поддержка версий продукта, обновления в связи с выходом новых версий связанных продуктов.
НЛО прилетело и опубликовало эту надпись здесь
Согласен если говорить о хороших фреймерках. Я же говорю о плохих фреймерках, которых (чужих) только у меня на поддержке в настоящее время четыре. Всен они как один 1. Не документированы 2. Отстали лет на пять 3. Находятся в репозитариях к которым в лучшем случае просто нет доступа на редактирование а в худшем случае вообще нет никакого доступа (то есть проект невозможно развернуть). Я не думаю что это исключитеьная ситуация. Мне даже не так волнует, что при этом страдает поукпатель или ваделец бизнеса (хотя мы же работаем для клиента и на владельца). Мне просто тосклливо вспоминать тот период когда мне пришлось разбираться со всем этим хотя можно было бы более проивзодительно затратить это время на работу с нормальным фреймверком который бы мне обеспечил опыт работы с нормальными технологиями (тем же Vue)

А цмирают порой даже хорошие идеи из-за разных обстоятельств. Например не смог автор собрать вокруг себя сообщество. Или же была неверная маректинговая политика. Из последних крупных таких фейлов — прекращении разработки RethinkDB — и это уже после выхода в подакшн (есть еще надежда что это проект получит развтите как open sorce — хотя весьма слабая надежда).
НЛО прилетело и опубликовало эту надпись здесь
чистейшая апория от jMas, продолжать комментировать и читать ветку бессмысленно.
Может кто подскажет по поводу ie11. Это относится к 2.х или же к планам 3.0?
Поддержку IE могут убрать как 2.x, так и в 3.x

В оригинале
We do have some plans for 3.0 but nothing concrete yet. The closest thing is 2.x-next which is a feature-compatible branch of 2.x with the internal reactivity system replaced using ES2015 Proxies. This will improve both performance and get rid of some caveats in the current implementation. It will drop support for IE11 and below but will allow us to leverage all the latest ES2015 features for a more efficient codebase.
оу, а можно где-то этот оригинал почитать?
Тут (это другая сессия вопросов) говорится, что поддержку уберут в 3.0, но вторую версию продолжат параллельно поддерживать.
Вот английская версия
спасибо!
O: Хотя React это позволяет, я не думаю, что это хорошая идея.

Странное мнение. Как по мне это самый большой недостаток vuejs и вместе с тем нарушение компонентного подхода. Есть компоненты которые могут принимать данные через пропсы. Никто же нас не ограничивает в том сколько раз мы эти данные отобразили в компоненте, так почему теперь, когда вы решили передать компоненту несколько div-элементов в качестве пропса-слота, мы жестко ограничены в том что больше одного раза отобразить его в компоненте мы не можем? Вот в реакте сделали настоящий компонентный подход — передав элементы через пропсы (либо вложенные либо через отдельный пропс) <Component someContent={<div>...</div>}/> — компонент может сколько угодно раз отрендерить то что ему передали а не один раз как во vuejs.

Тут разница в том, что в React передается VDOM-описание компонента, а не сам компонент — его-то и можно вот так клонировать.

Во vue.js же компоненту передаются не VDOM-описания, а инстансы дочерних нод. Их клонировать невозможно.
НЛО прилетело и опубликовало эту надпись здесь
Покажите как будет выглядеть клонирование экземпляра компонента, который уже начал выполнение асинхронного запроса.
НЛО прилетело и опубликовало эту надпись здесь
там не передаются инстансы — посмотрите в дебагере — слот заменяется на объекты VNode который является обычным объектом описывающий верстку — точно так же как в реакте. Другое дело что vuejs прикрепляет к этим объектам ссылки на инстансы компонентов, но это уже недостаток реализации самого vuejs
НЛО прилетело и опубликовало эту надпись здесь
cvvv sd brnnnnnvrfgv fbbhhhwjb vfvfn vvvvv hj
Народ, извините, полуторагодовалый «хакер» в лице моей дочурки решил высказат своё мнение за те 30 секунд, пока я ходил чай наливать :)
Строчка в резюме: "… в 1.5 года отправила первый коммент на хабр" )
НЛО прилетело и опубликовало эту надпись здесь
напомнило цитату с башорга
ребенок подошел к ноутбуку, и постучал ладонями по клаве в руби конференции
когда я подошел, в том коде уже разобрались и нашли ошибки
В: Будет ли возможно использовать компилятор однофайловых компонентов без модульных бандлеров?
O: Да, у нас есть компилятор SFC (Однофайловых компонентов), мы надеемся что его можно будет использовать для создания внешних или внутрибраузерных компиляторов.

Уже сейчас можно подключать .vue компоненты напрямую в браузере, что может упростить разработку, но в прод такое конечно пускать не рекомендуется. https://github.com/FranckFreiburger/http-vue-loader

Наконец таки Proxy, страсть как бесит невозможность полноценно использовать мапы и сеты

>O: Прогрессивная адаптивность: ты можешь использовать его как замену jQuery или создавать приложения любой сложности, используя CLI, роутер и Vuex.

Вот это именно та приина, почему я перешёл с AngularJS на Vue.js. React и Angular невыносимо тяжело использовать в легаси-проектах. AngularJS можно просто подключить и потихоньку переписывать jquery-виджеты и добавлять новые, с Vue.JS можно поступать так же.
Во-первых, большое спасибо за переданный вопрос.
Во-вторых, так как здесь собралось много разбирающихся в Vue людей, хочу спросить(не холивара окаянного ради): какие для вас преимущества предоставляет Vue по сравнению с React? Для меня это два основных пункта:
  1. Инфраструктура с рекомендуемыми командой разрабокти компонентами: vue-router, Vuex, vue-meta, и т.п. Под React есть множество хорошо проработанных роутеров, библиотек для управления состоянием, и выбирать нужные кирпичики для постройки приложения приходится дольше. Да-да, я жалуюсь на обилие возможностей :)
  2. Наличие SSR фреймворка без значимых проблем в архитектуре. Nuxt великолепен, очень прост в работе, в нем не встретишь всяких `dangerouslySetInnerHTML` для подключения стилей, он понимает TS и JSX, есть поддержка инфраструкутры Vue(Vuex, vue-meta, vue-i18n), очень хорошо проработано генерирование статики.

Дальше плюсы React:
  1. Проще найти работу/работников
  2. React Native. Киллер-фича, как по мне. Он не создает впечетление полусырого продукта, есть внятная документация, есть активное англоговорящее сообщество. Для человека, у которого знания китайского языка(你好, weex) ограничаются матерными фразами из Firefly, это очень важно :)
  3. Поддержка Facebook. Эти ребята легко генерируют штуки вроде Draft.js, Yoga, Relay, и т.п. Они там вообще спят?
Не совсем понял Ваш вопрос. Nuxt ведь это же Next реализованный на vue. И в стандартной экосистеме react весьма развит — react- router, redux с некоторых пор.
Тот, да не тот. Действительно, изначально Nuxt появился как «симметричный ответ», однако вскоре обогнал Next по возможностям, добавив генерирование статики, плагины, поддержку vue-meta и vue-router, систему шаблонов.
Некоторые из этих возможностей повторили уже в zeit, при чем те же плагины появились только в 5 версии. Но при этом в Next остается несколько архитектурных проблем, к примеру, моя «любимая» — это полная перерисовка с потерей состояния родительских компонентов при навигации на стороне клиента.
Как писал ранее, это все не ради холиваров, я стараюсь собрать побольше информации об особенностях обоих проектов, так что спасибо за замечание.
Современное состояние react такое что нему уже не нужен next тк с выходом react routee 4 и последних версий webpack для code splitting все можно реализовать на чистом react. В подтверждение этого тезиса я написал несколько сообщений на этом сайте и сделал тестовый проект в рамках проекта reakworld см github.com/gothinkster/realworld/issues/186 примечательно что весь код этого проекта основан на компиляции официальных доков react и webpack
Спасибо за пример, хорошая демонстрация прогресса развития React. Штука в том что и Next и Nuxt, и альтернативы вроде after.js(который очень похож на приведенный пример) представляют из себя такой же каркас приложения + конфигурация Webpack. Одна команда в CLI — и мы готовы работать с прототипом, все настроено, плюс есть всякие плюшки вроде модулей и плагинов, и уже решены многие проблемы вроде подключения TypeScript или flow, конфигурации метаданных, или генерирования статики в кластере.
В итоге, решая все эти проблемы на самодельном SSR-фреймворке мы придем к клону того же Next. Впрочем, Jared Palmer(создатель after.js) так и сделал, из-за наличия фундаментальных проблем в архитекутре Next.
Кстати про ssr или если точнее про uni ersal/isomorphic приложения. С учётом возможнстпй но react router и динамического import() от webpack реализовал universal приложение можно при помощи исключительно базового стандартного набора react который уже описан с примерами в документации reacf
«Вдогонку» vue — это просто глоток свежего воздуха. Восхитительный проект. Я, когда решил посмотреть что там в мире фронтенда, потратил около 2 месяцев в попытках просто выбрать чем стоит заняться, angular или react. Посмотрел кучу видеокурсов на плюралсайте, прочитал море статей и так и не выбрал. В одной статье доказывают что лучше ангулар, в другой совершенно аргументированно говорится что рулит реакт. Устал выбирать. Смотрю код — и там понятно и там понятно. А куда идти — неясно. Душу воротит от jsx, и не хочется монструозности ангулара. И все это с огромным количеством (безусловно нужного и понятного) бойлерплейта.

И тут, случайно, на глаза попался хвалебный отзыв по вью. Потом еще один. Потом еще 10. Посмотрел и просто как будто в летнюю жару подали стакан холоднгой воды. Или зимой с морозца, да к печке… Стал углубляться, написал пару проектиков и в полном восторге. Все работает как ожидается, мусора писать надо гораздо меньше, изучение основ заняло один день…

Простите за комментарии восторга от вью. Стараюсь всюду оставлять свое мнение о вью, чтобы он, не дай бог, не помер. Спасибо за него. Простите за некоторый оффтоп. Просто хотел поблагодарить.
НЛО прилетело и опубликовало эту надпись здесь

Спасибо автору за сий труд. Для меня лично, многое стало понятнее, после ответа на этот вопрос:


В: Тони Хор (Tony Hoare) назвал null ошибкой на миллиард долларов. Какое было самое неудачное техническое решение в твоей карьере?
O: Было бы неплохо использовать TypeScript изначально, еще когда я начал переписывать код для Vue 2.x.

Может Vue.js 3.0 уже будет на TypeScript при примеру Angular?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории