по-моему там дело не собственно в пермишенах, судо ведь не помогало само по себе, а в переходе npm на плоскую иерархию пакетов, т.к. ошибка возникает где-то в собственных node_modules пакета-зависимости wct
вообще без sudo тоже может работать, у меня заваливалось из-за ошибки с EACCESS без ключа, я прежде чем докопаться до причины, пробовал и ставить все глобально, затем все очищал обновлял и снова ставил и оттуда этот sudo и остался. Под капотом там Selenium ChromeDriver, в случае невозможности использования глобального npm пакета в его сторону думаю и следует копать. Вообще, люди работающие с нодой должны уже попривыкнуть к тому, что у них и gcc будет что-то собирать, и какое-нибудь другое недоразумение будет самостоятельно выкачивать бинарники за просто так игнорируя все политики%)
не все модули, а только тулчеин используемый для запуска тестов, он все равно много страшного делает типа скачивания браузерных движков и без приведенных параметров не работает, так что тут лучше наверное поморщиться один раз и поставить, т.к. альтернатив для веб компонентов больше не нашлось или не делать этого вовсе и открывать тесты вручную браузером.
бабель можно подключать как-то выборочно можно транспилировать онлайн прямо в браузере с помощью systemjs. И конечно все-таки с ИЕ рано или поздно что-то сделают, сейчас движок уже засунули в edge, и сам механизм браузеров микрософта позволяет в том числе программно переключать этот самый движок задав современный edge, в котором все стандарты реализованы, а теперь там будет еще и хромовский вебкит. Разница в скорости когда отключаешь полифилы очень хорошо заметна даже на глаз. Но вообще я не считаю это прямо краеугольным камнем. Ключевое — браузерное апи сейчас сделано сильно приличнее популярных и не очень фреймворков, у которых кроме преимущетсв полно недостатков. Кроме того, каждый фреймворк это считай изолированный от остальных мирок и разработки очень мало совместимы между собой. А если вы используете нативное апи, вы получаете более универсальный код. Есть фреймворки на основе вебкомпонентов, мне они не очень нравятся, но менее всех XTag, на webcomponents.org полно готовых компонентов и на самом деле в веб компоненты можно заворачивать ui виджетсеты, как старые так и новые. В этом сила и гибкость технологии, вы свои компоненты можете встраивать в чужой в т.ч. вендорный код и наоборот, завернуть в вебкомпоненты хоть jquery ui, не используя теневое дерево правда, хоть ant.design, популярный у ряктовиков. Главное, что это все совместимо с ООП, модулями es6, всякими ленивыми и асинхронными и динамическими загрузками кода, через те же простые .innerHTML и .appendChild
есть выгода в производительности, в поддержке всеми современными браузерами в отсутствии необходимости транспилировать код, в более мощных и доступных динамических возможностях, при этом вы не лишаетесь возможности использовать наследование и другие возможности языка и платформ. Вообще сама по себе склейка/сборка фронта от фреймворков из сотен модулей в условиях http/2 может стать несколько анахроничной и быстрее будет загрузить несколько небольших скриптов с мультиплексированием, чем один огромный или просто статичный бандл, но скорее всего будет некоторое разумное сочетание подходов.
если использовать нечистые функции в рендере код перестанет собираться, а чистые это как раз без ссылок в т.ч. на экземпляр класса.
Насчёт адаптера — не каждая библиотека такое поддержит, мне думается, после перерендера полезут ошибки и утечки.
Реакт вместе с сателлитами очень конкретно определяет решение задач строго определенным способом, например храня все данные в одном глобален. Даже свободная композиция структуры дерева как в мл языках в нем заменена на харкод с прямым связыванием.
рякт не является библиотекой, т.к. не представляет утилитарной ценности кроме структурирования кода приложения, что как раз про фреймворки, кроме того он накладывает ограничения в использовании библиотек взаимодействующих с dom, использующих ООП и прочих нереактизированных
1) вы из мира Java, пришли во фронтенд со своим уставом; 2) большая часть паттернов
я начинал с пхп и питона и много на чем разрабатывал включая js фреймворки, своя особенная специфика была у разработки на js только язык сам по себе был убог, но сейчас в этом нет необходимости и инженерные практики справедливы также и для разработки фронтенда. Хотя я ссылаюсь на них просто что-бы было понятно, что имею ввиду когда вижу в этих велосипедах школячую анскил долбанину, т.е. когда разработчик начинает экономить на буквах или придумывает какое-то «гениальное решение» на хешмапах (обжектах) или заводит обычай раскладывать все по файлам одинаково названным и экспортить с дефолтом
Чем плох тот же StencilJS?
посмотрел и он конечно получше реакта, хотя всеравно заставляет разработчиков инлайнить верстку в джаваскрипт т.е. jsx и непонятно какие задачи он концептуально решает, которые не решены в веб-компонентах, Prop можно самому за несколько часов написать или подключить.
икто в трезвом уме и твердой памяти не будет всерьез сравнивать дикую императивную лапшу на DOM API с лаконичным декларативным
дело в том что альтернативы, т.е. современные фреймворки сделанны дилетантски и противоречат стандартам веб компонентов, браузеров, инженерным практикам. Вот если бы был хороший фреймворк на веб компонентах, тогда это имело бы смысл, а так современное DOM API если довернуть еще хороших решений-библиотек выглядит предпочтительнее сейчас. Насчет тестов вы наверное правы, надо еще сравнить самому с lithtml и svelte%)
где он проявил себя на равных с обычной работой с dom кстати, не вижу проблемы в том, что-бы сравнить 2 решения по производительности, цель разобраться в том нужны ли все эти замороченные решения в фреймворках, которые якобы решают какие-то проблемы
да нет все стандартное, для просто реакта там обновляется setState'ом, а для редакса взят стандартный генератор. Я взял реакт, потому что некоторые упирают на его узкозаточенность под производительность. Сейчас уточнил по заметкам, результаты были такие:
Добавляем 1000 элементов на страницу:
WebComponents: ~ 0.05 s
ReactDOM: ~ 0.5 s
т.е. разница на самом деле в 10 раз
Обновляем 1000 раз:
ReactDOM setState(): ~0.38 s
WebComponents .textContent: ~0.37 s
React + Redux: ~2.30 s — утечка памяти оталась (2k обновлений = 500 mb)
Вы делали дизамическую подгрузку html с сервера чтобы в нее можно было сделать эксплойт?
нет, с сервера подгружается джейсон с данными (на самом деле сейчас етого может и нет, он локально задается), в другом редакторе задается мапинг его на селекторы, в третьем шаблон
да, по разным причинам перерендер окна может быть вызван позднее, я замерил правильно и получил результат в 3-5 раз быстрее вашего, перезамерьте свои фреймворки, мне уже даже любопытно
если использовать нечистые функции в рендере код перестанет собираться, а чистые это как раз без ссылок в т.ч. на экземпляр класса.
Насчёт адаптера — не каждая библиотека такое поддержит, мне думается, после перерендера полезут ошибки и утечки.
Реакт вместе с сателлитами очень конкретно определяет решение задач строго определенным способом, например храня все данные в одном глобален. Даже свободная композиция структуры дерева как в мл языках в нем заменена на харкод с прямым связыванием.
на ангуляр вряд ли, только в валидации форм нельзя дергать её прямо, а вот в Вуе многое пытаются делать как там, но по-своему
рякт не является библиотекой, т.к. не представляет утилитарной ценности кроме структурирования кода приложения, что как раз про фреймворки, кроме того он накладывает ограничения в использовании библиотек взаимодействующих с dom, использующих ООП и прочих нереактизированных
я начинал с пхп и питона и много на чем разрабатывал включая js фреймворки, своя особенная специфика была у разработки на js только язык сам по себе был убог, но сейчас в этом нет необходимости и инженерные практики справедливы также и для разработки фронтенда. Хотя я ссылаюсь на них просто что-бы было понятно, что имею ввиду когда вижу в этих велосипедах школячую анскил долбанину, т.е. когда разработчик начинает экономить на буквах или придумывает какое-то «гениальное решение» на хешмапах (обжектах) или заводит обычай раскладывать все по файлам одинаково названным и экспортить с дефолтом
посмотрел и он конечно получше реакта, хотя всеравно заставляет разработчиков инлайнить верстку в джаваскрипт т.е. jsx и непонятно какие задачи он концептуально решает, которые не решены в веб-компонентах, Prop можно самому за несколько часов написать или подключить.
дело в том что альтернативы, т.е. современные фреймворки сделанны дилетантски и противоречат стандартам веб компонентов, браузеров, инженерным практикам. Вот если бы был хороший фреймворк на веб компонентах, тогда это имело бы смысл, а так современное DOM API если довернуть еще хороших решений-библиотек выглядит предпочтительнее сейчас. Насчет тестов вы наверное правы, надо еще сравнить самому с lithtml и svelte%)
bitbucket.org/techminded/js-benchmarks/src/master/react-state.html
где он проявил себя на равных с обычной работой с dom кстати, не вижу проблемы в том, что-бы сравнить 2 решения по производительности, цель разобраться в том нужны ли все эти замороченные решения в фреймворках, которые якобы решают какие-то проблемы
Добавляем 1000 элементов на страницу:
WebComponents: ~ 0.05 s
ReactDOM: ~ 0.5 s
т.е. разница на самом деле в 10 раз
Обновляем 1000 раз:
ReactDOM setState(): ~0.38 s
WebComponents .textContent: ~0.37 s
React + Redux: ~2.30 s — утечка памяти оталась (2k обновлений = 500 mb)
bitbucket.org/techminded/js-benchmarks
а это был не начальный рендер, а 1000 обновлений, а на начальном вебкомпоненты быстрее раза в 3
нет, с сервера подгружается джейсон с данными (на самом деле сейчас етого может и нет, он локально задается), в другом редакторе задается мапинг его на селекторы, в третьем шаблон
дырка это когда вы не подозреваете о существовании возможности, а когда для этого все и затевали это уже отверстие
зачем? хсс для джейсона в современных браузерах не возможен