Дата выхода на Patreon: 27.01.2022 Видео создано благодаря подписчикам проекта на нашем Patreon. Хотите получать контент на 3 месяца раньше остальных? Присоединяйтесь! / javascriptninja
По поводу вите как надстройка есбилда вроде будет не абсолютно верно, так как там если не ошибаюсь есбилд используется только для компиляции тайпскрипта, киньте камнем если не прав. Пару месяцев назад из-за проблем с парцелом решили рискнуть перейти на есбилд на бета проекте и пока очень довольны, с нюансов что он молодой и много надо самому допиливать в плане плагинов и тд тп, но ничего критического. Для многих огромный минус что автор принципиально не хочет там добавлять HMR и надо жить с browser sync или костылять очень сильно(хотя для многих HOT RELOAD > HMR и я в их числе)
@@JavaScriptNinja был упомянут cypress который ведёт работу над тестированием компонентов, вот я и вспомнил про playwright так как они тоже ведут работу над этим. Если я всё правильно понял конечно
Почему уже который раз слышу про то что хорошо бы тхреды, это же анипатерн в масштабируемых системах, мы должны делать софт минимальным требованиями по ресурсам, а для утилизации девопсы уже будут запускать столько инстансов сколько надо.
Подходы распараллеливания на треды и увеличения кол-ва инстансов решают абсолютно разные проблемы. Первый - чтобы нодовский инстанс не убивал IO под CPU емкой задачей, а второй - чтобы общая нагрузка на систему не перегружала CPU отдельно взятой машины или отдельного инстанса ноды под множеством простых, но частых запросов.
Треды должны быть упакованы в фреймворк так, чтобы не переносить свои проблемы и сложность на прикладного программиста и вы писали код без учета особенностей параллельного и асинхронного программирования, но с их преимуществами
Революции хороши, когда эволюционное развитие исчерпало себя и настало время отбросить весь свой DX и сделать шаг вперед. В чем проблема? В том, что это всегда потрясения как для бизнеса так и для разработчиков и следовательно пользователей. Те если миграция между инструментами крайне сложна, то: часть разработчиков будут с нежеланием изучать новое(вплоть до бойкотирования), кто-то будет нестись впереди планеты всей форсируя использование сырой технологии и тп. Для бизнеса это выльется в расходы для миграции, которую рано или поздно придется совершить и они тоже не особо хотят этого. А пользователи получат задержку в получении нового функционала, так как силы компании отданы на совершения миграции
*Точка зрения определяется точкой сидения* Моя точка зрения радикальным образом отличается от той которую озвучивает Илья. Отличается как в части, касающейся технических факторов, так и в части околовсяческих рассуждений, продиктованных узорами кофейной гущи. Вероятно это связано с тем, что область моих интересов _не лежит_ в плоскости JavaScript фронтенда, но лежит в плоскости архитектуры самого языка JavaScript: интерпретация, компиляция, оптимизация, потребление ресурсов и т.д. *Disclaimer* Я не преследую цели дискредитации (зацепить, обидеть) кого-либо, потому любые признаки токсичности, следует интерпретировать как интеллектуальную недоразвитость автора - то есть меня. Материал не претендует на истину в последней инстанции, и является, прежде всего, информацией к размышлению. *Язык JavaScript - это самый непонятый в мире язык* Я убежден, что все вопросы языка JavaScript, продиктованы одной единственной причиной - чудовищной пропастью между тем, как видят язык люди которые его проектирует и людьми которые этот язык используют. И причины появления этой пропасти не в том, что одни шибко умные, а другие альтернативно одаренные, но в том, что архитектура языка, позволяет программисту получать ожидаемый результат при абсолютно неверном представлении о том, почему произошло именно так, а не иначе. То есть по сути, пользователи языка, имеют в своей голове картину, радикально отличающуюся от той, которую видят его разработчики. Зачастую даже в мелочах. Это очень хорошо будет видно на примере моих ремарок к тезисам, которые озвучил Илья в своем видео. Еще раз подчеркну, не смотря на радикальную разницу в точках зрения, я отдаю должное его мнению. Каждая ремарка будет идти отдельным, дочернем к этому, комментарии.
*00:02:17** ничего, кардинально нового, не используется* Последние три года минимум, в языке JavaScript происходят революционные изменения. И 22 год не будет тому исключением, более того, он может стать годом, когда будут запущены беспрецедентные изменения за всю историю его существования. Наиболее значимыми на мой взгляд является: 1. все что связано с темпом развития WASM, который, фактически, может сформировать совершенно новый рынок услуг. 2. добавление в язык JavaScript статической типизации, что кардинально изменит все существующие инструменты языка. TypeScript в том числе. Потому как, возможно, потребует переработки алгоритмов формирования Vanilla JS кода под новые реалии. В этой связи для проектов, использующих TypeScript, с высокой долей вероятности все пройдет максимально безболезненно. Ниже детали. *WASM* Показательным тому примером является WASM. И если Вы считаете, что место WASM только в плоскости число дробилок, то у меня для вас большие новости: уже сейчас возможностей WASM, более чем достаточно для того чтобы программировать Flash Like сайты. Современный WASM имеет возможность прямого манипулирования canvas *WASM: Ящик Пандоры* Flash Like сайты это что то из 2000, когда был такой Flash, который кроме игрушек и плееров позволял так же и создавать интерактивные свиста-пердящие проекты с оригинальным интерфейсом. Так вот обслуживание такого интерфейса на WASM, с точки зрения потребления ресурсов, может стоит значительно дешевле, чем такой же аналог в рамках привычных HTML CSS JS. Первый минус этого в том, что HTML как инструмент, отражающий текущее состояние интерфейса (контента) перестает существовать как данность, что ставит крест на привычной многим простоте и гибкости работы с любыми сторонними проектами третьими лицами. Другой минус заключается в том, что сейчас, если человек обладает хорошей базой в Vanilla JavaScript - то для него освоение любого из современных фреймворков - всего лишь вопрос времени. Его навыки можно эффективно пере использовать. А вот завтра может быть сформирован рынок, где будут требоваться специалисты погруженные в детали конкретной реализации конкретной библиотеки. И никакие навыки из прошлого не дадут вам возможность форсировать вопрос погружения, по причине того, что каждый такой фреймворк будет обладать не только своей идеологией, но и уникальной формой реализации. И все это не просто сказки, а уже сейчас тестируется Google на проектах от Google Docs до админ панелей. Те же Google Docs, уже более чем пол года переведены с HTML рендера на Canvas Render. То есть отображения документа формируется путем самостоятельной отрисовки его на канвасе. То есть отображение формируется без использования каких либо функций браузера, кроме отображения картинки. То есть фактически - отображение проекта это набор сменяющихся картинок, которые браузер и показывает. Ящик пандоры открыт. Добро пожаловать в 90тые, где каждый писал под себя UI тулкит, фактически выступающий в роли композитора / декоратора / рендера и всего того что делает система и /или браузер с окнами и их элементами. И если Google не остановиться (а он, напротив, педалирует это с огромной силой) то те фреймворки которые сейчас не занимаются формированием подобной кодовой базы, останутся за бортом. Angular кстати такой код уже имеет. *WASM: и средства противодействия* Фактически WASM начинает выполнять роль типичного машинного кода типичного процессора. Анализ подобного кода потребует специальных навыков, которые не формируются в случае использования JS. То есть скоро мы можем столкнуться с новым рынком где будет спрос на инженеров, обладающих навыками такой анализ производить. Специалисты в _Реверс Инжиниринге_ потирают руки. Другим следствием развития WASM является возможность написания кода, который в состоянии обеспечивать минимально-приемлемый уровень противодействия, как анализу его логики (реконструкции алгоритма), так и противодействия вмешательству в его работу. Теперь уже _Кул-хацкеры_ потирают руки.
*JS: Строгая типизация* В язык космическими темпами втаскивается строгая типизация. А это фича, которая по своей революционности превосходит все что было в JS за все время его существования. В настоящий момент, активно ломаются копья на тему того, делать это в рамках use strict или вводить use strict2 или придумывать иной велосипед. Штука в том, что строгая типизация дает возможность создание нового V8, который будет строго детерминирован в части оптимизаций Вашего JS кода. Причем эта задача станет на порядки проще для V8 чем в текущем состоянии. Как следствие, это не только дает возможность получать хорошо оптимизированный код на стадии компиляции, ну и уничтожает гигантское количество издержек, связанных с работой текущих оптимизаторов, которые вынуждены опираться на статистику использования данных, при постоянных проверках все ли впорядке с кодом, и не нужно ли его де-оптимизировать. Как я уже сказал - это революция. Которая потребует от текущих фреймворков серьезной адаптации их кодовой базы. Справедливости ради стоит сказать, что если проект использует TypeScript, то подобный переход может оказаться практически безболезненным. Впрочем как и в случае, если Vanilla JS код писался человеком, который строго следит за Hidden Classes своих данных. Чуть более подробно об этом, я уже написал под видео о State of JS
*Почему солнце всходит и заходит все время в одном месте* Преимущество и ахиллесова пята языка JavaScript заключается в том, что это язык, который дает возможность любому начинающему решать задачи уже в первые полчаса знакомства с языком, но при этом, это очень сложный язык для профессионального использования. При этом развитие инструментов (фреймворков) достигло того уровня, когда начинающий специалист, в кратчайшие сроки, может создавать функционально очень сложные и при этом работающие прототипы. Следствием всего этого, стала ситуация, когда подавляющее большинство пользователей языка, фактически некомпетентны. От Junior до Senior. Первые потому, что и без работы над своей экспертизой их труд принимается в продакшн. Вторые потому, что даже при наличии необходимых навыков, не дают себе труда всерьез погрузиться в язык. С октября 2021 и по январь 2022 года, я принял участие в собеседовании 17 соискателей на позицию Senior JavaScript Developer. Из 17 человек только один, смог пройти этап, где оценивался уровень фундаментальных знаний языка JavaScript. Например: Практически все не понимают, что event loop, microtask и macrotask не имеет никакого отношения к JavaScript а является реализацией агента хост системы выполняющей код. И зависит исключительно от нее, но не от языка. То есть может быть любой при полном сохранении со спецификацией ECMA. Или непонимание того что const это не директива объявления констант, но инструмент управления поведением интерпретатора в окуржении не глубже одной Exacution Env. Не говоря уже о сказках про однопоточности языка, когда на уровне стандарта зафиксировано поведение асинхронности, параллельно работающих тредов, атомик операций, состояний гонки и т.д. Наряду с этим, подавляющее большинство соискателей демонстрировали исключительные знания в смежных областях - от системного администрирования до программирования на языках низкого уровня или глубокого понимания современных тендеций программирования. Другим важным качеством языка, которое в равной степени является его плюсом и минусом, является присутствующая в нем анархия с точки зрения идеологии. Язык не диктует вам как писать код, какую парадигму использовать, но предоставляет вам десятки способов сделать одно и тоже. При этом единственным сигналом о том что лучше, от архитекторов языка, является безобразное - пишите как вам удобно, а мы позаботимся о производительности. Как показал история - архитекторы недооценили воображение пользователей, и переоценили свои навыки в оптимизации всего что должно быть оптимизировано.
*State of JS как индикатор катастрофы* Красноречивым примером, свидетельствующим в пользу сказанного выше, является State of JS. Открываем статистику по критерию features (возможности) и обращаем внимание на графу Other Feature, в которой обозначены два пункта: WebAssembly с 17% тех кто якобы их использует, и, внимание, Progressive Web Apps (PWA) c 64% использования. PWA это не стек технологий. Это манифест, декларация правил. Существование которого, или полное его отсутствие, не отменяет возможности использования всего технологического стека, сейчас приписываемого PWA. А теперь обратите внимание на графу Browser Api, где заявлены те самые API, которые и составляют стек технологий PWA. И сравните цифры. Например, сердцем любого PWA является Service Worker. Без него, даже автоматическую проверку на соответствия требованиям PWA не пройти. Статистика использования SW 50%. Это при использования PWA в 65%. Карйне любопытно узнать, каким образом аудитории в 15% удалось использовать PWA без SW. Другим показательным примером, является статистика используемых источников Blogs & Magazines, в которой нет ни одного профессионального ресурса посвященного архитектуре языка JS. А места занимают источники, предоставляющие в массовом порядке, набор шаманских рецептов для решения той или иной задачи. Третьим примером является статистика JavaScript Pain Points, где заявлены трудности, которые более всего беспокоят разработчиков языка. Где 6 из 8 пунктов, никакого отношения к языку не имеют, но красноречиво подчеркивают уровень экспертизы аудитории. Архитектура кода, Управление состояниям, Отладка - это все области которые строго зависят от квалификации разработчика, а не языка. *Почему так происходит* *Потому что язык не заставляет, не диктует, не навязывает* Но дает возможности сделать так как нравиться. При этом, отсутствует популяризация инструментов, которые, хотя бы на уровне производительности, давали бы объективный ответ, почему эта реализация - лучше, быстрее, экономичнее в отличии от прочей. Наряду с чем получили распространение безграмотные сервисы для минкробенчмарков типа JSPerf и иже с ним, которые создают только лишнюю путаницу, часто являющиеся источником неверного понимания ситуации, но не источником объективной информации. *Static Typing* Ну и вишенкой на торте статистика Features Missing From JavaScript. Где справедливым победителем является Static Typing. Но при этом, назвать проблемы, которые призвана решать статическая типизация, смогли единицы. Большинство же обозначало проблемы, которые разрешаются без статической типизации. Отдельно хочется отметить Immutable Data Structures, где видно как люди пытаются притащить в язык привычные им инструменты из других языков. Или желания Pattern Matching, которое является индикатором как полного непонимания того как JavaScript работает с объектами, так и того, что потребность в Pattern Matching говорит о неправильно выбранной архитектуре приложения.
Несколько ремарок о сказанном в видео, в плоскости написанного мной выше. 00:03:11 *Метархия* Это очень показательный пример того, как отсутствие желания познакомиться с тем что уже сделано до Вас приводит к повторению пути уже проделанного другими людьми. В настоящий момент идеологи монархии справедливо рассудили, что JavaScript это не инструмент дающий в руки парадигму, но инструмент который позволяет такие парадигмы создавать. И засучив руки, упоролись в создание своего метаязыка, который, внезапно, как и любой мета язык, стал повторять путь развития функционального программирования. Я напомню, что в годах 1990 - 2000 эталонными языками для мета-программирования называли Lisp и Haskel - те самые функциональные языки. Впоследствии популярность термина - мета-программировании серьезно упала. Уже сейчас, разработчики метархии, сталкиваются с проблемами, которые решались или уже разрешены в годах между 1960 и 2000: нельзя сделать мета язык, учитывающий специфичность всего на свете. Тем не менее, авторы метархии упорно движутся в направлении, где самой главной проблемой сейчас является создания спецификации монад, и испытывают жуткую нехватку времени для того, чтобы познакомиться с функциональным программированием на уровне чуть больше чем hello world. *Метархией единой* Подобная ситуация характерна для всех популярных фреймворков. Увеличивающаяся сложность архитектуры, неизбежно приводит к пониманию того, что объектно ориентированный подход, в его класс специфичной реализации, не в состоянии обеспечить решение полученных проблем даже в теоретической плоскости. Чему подтверждением является разнообразие подходов, и бурная эволюция инструментов для тестирования кода. Которых в функциональном программировании просто нет и быть не может. Фактически, все движутся к тому чтобы замкнуть круг - и вернуться к точке отсчета: функциональному программированию. Что косвенно, подтверждается расцветом зоопарка JS библиотек, декларирующих функциональный подход. Не говоря уже о том, фактически все парадигмы управлениями состояния приложения повторяют функциональный подход. Кому хочется увидеть к чему все идет, загляните в код $mol, или прости Господи в Elm. Авторам этих продуктов нужно отдать должное. В особенности $mol. Где автор, из за своих экзистенциальных проблем с функциональным программированием, повторил все необходимое через опу объектно ориентированного подхода.
Зубрить не надо, все равно не запомнишь, в начале только практика. Придумай или найди простой проект, сайт, попытайся сделать то же самое. Как делал я: - взял макет, сверстал основу на html и css (можно взять готовый html шаблон) - посмотрел как вообще подключать вью (проще начать со 2 версии - подключить тэгом ) - будет достаточно для начала почитать разделы офф доки по вью (или по видосам на ютуб как удобнее): синтаксис шаблонов, свойства и методы, условная отрисовка, обработка событий - пытаться применить на практике (вывести переменные, повесить обработчик на кнопку и т.д.) - по мере реализации функционала будут возникать вопросы, а как сделать то-то ... ищем в доке или гуглим, применяем, запоминаем. - будут появляться повторяющиеся куски html кода их можно выделять в отдельные компоненты ... смотрим как создавать компоненты, как передавать данные, вызывать события... - как придет понимание базовых вещей, можно уже и на vue 3 создать проект на однофайловых компонентах через vue cli, подключить eslint, разобраться с webpack Сложно только поначалу, потом будет легче
@@vladcid3938 самое интересное то, что я смог создать расширение без знаний английского и без особого погружения в сами расширения, мне это легко дается. А вот дока вью несмотря на то, что она на русском и есть много материала для параллельного изучения - мне вообще не поддается. Я прям уже года полтора два комплексую из-за этого уже
Насчет Jest и как раз той боли, в экосистеме Vite уже наметился явный конкурент: Vitest. Достаточно совместим с Jest, но при этом полностью интегрируется в Vite без дополнительной конфигурации
