Интересный подход, но он уменьшает читабельность. Если каждый компонент будет добавлять префикс сабкомпонентам, то html структура получится менее понятной. Но вы правы, это наверное пока единственное решение (я добавлял префиксы на уровне компилятора). Есть обсуждаемая проблема с локальным регистром имен на уровне компоненты, посмотрим, что из этого выйдет.
Можно посоревноваться со Svelte, думаю плбедить не получится (даже если Svelte компилировать не в веб компоненты). С веб компонентами до сих пор не решено большое количество проблем основная из которых — глобальное пространство имен компонентов (это сильно мешает при создании и поддержке библиотеки компонентов и их композиции)
То, что программист не может типизировать свой код означает, что программист написал плохо.
Разница в «не может типизировать свой код» и «не может типизировать свой код средствами TypeScript» огромна. Последний не поддерживает статические методы в классах, нормальное наследование и полноценные дженерики. Любая функциональная библиотека будет недотипизирована и проблема тут как раз в отсутствии полноценной системы типов в TypeScript
Я вам ничего не предлагаю и не хочу спорить, вы даете фидбек не попробовав, я hq использую но поддержкой не занимаюсь. Так что это едва ли обратная связь. Вы делаете безапиляционные заявления, которые я бы назвал спорными, а многие из ни вообще чушь. Тон ваших заявлений мне не нравится потому обсуждать что-либо не вижу смысла. Вы не пользователь, проходите мимо, зачем поливать все помоями? Вам интересно — разбирайтесь сами, меня общение с вами лично утомляет.
тут это просто мистика — то работает, то не работает.
Да нет никакой мистики у вас сообщение об ошибке говорит в чем проблема. Точно так же можно посмотреть как выглядит сборка без бандла.
Описанные вами проблемы — следствие транспиляции языков, которая будет независимо от бандлинга.
При пофайловой транспиляции сорсмапы в разы аккуратнее. Если мы говорим про js -> js то вообще проблем не будет, а в случае с бандлом, попробуйте поставить брейкпоинт на выражение, попробуйте подебажить зависимость внутри нод-модулей, это все не так просто как вы описываете.
Да какая структура? Сотни одновременных запросов
Структура запросов, видно кто сделал запрос и зачем. и вы тактично опустили часть про код кавередж.
когда можно было бы сразу использовать один инструмент.
Да это ваша личная проблема и боязнь инструментов, не используйте, кто ж вам мешает то.
Каких, например?
Например реакт
Какие ещё оптимизации?
Оптимизация изображений, генерация сервис воркера, да мало ли что. Если это отдельная часть сборки — так это уже вторая сборка и у вас все равно 2 конфига.
Некоторые инструменты позволяют этого не делать.
Так не делайте, это не для вас инструмент, это мы уже выяснили. У нас прекрасно работает комбинация hq + parcel и нет никаких проблем.
Поэтому я запилил свой собственный :-D
Ну хорошо, что сделали что-то свое. Но я не совсем понимаю смысл всей этой полемики. Вы хотите узнать о преимуществах hq, так это можно сделать просто попробовав. Больше похоже на то, что вы хотите доказать, что инструмент отстой даже не пробовав и переубедить меня им не пользоваться. Я не думаю, что стоит продолжать.
Ну такое себе «всё в порядке». Больше похоже на «счастливой отладки».
Ну так оно ожидаемо валится в таком случае, класс А ведь не определен в момент определения B.
А что у вас за проблемы с бандлингом? Почему мне он не мешает? Я что-то делаю не так?
У меня проблемы с постановкой брекпойнтов, а в особо запущеных случаях и вообще с отладкой в консоли так как имена внутри библиотек могут быть обфусцированы, покрытие кода работает криво, это навскидку.
Где видно? А почему с бандлами не видно?
Ну потому, что с бандлами вам нужен бандл аналайзер или еще что-то в этом роде, а без них у вас структура проекта видна во вкладке нетворк.
А, ну если только поиграться и выбросить и никуда не выкладывать
Можно не выбрасывать, а потом собрать и выложить. Не понимаю в чем тут проблема. Быстрый эксперимент бывает очень ценным оружием. Неужели вы никогда не запускали simpleHTTPServer, вот достойная замена как по мне.
Зачем отдельные? У меня вот они одинаковые. Я профнепригоден?
Это не ко мне вопрос. В вашей ситуации это может быть и подходящий вариант, но многие фреймворки имеют переменные окружения которые дают больше возможностей для отладки, для ускорения сборки на дев версии не нужна обфускация и не нужны все оптимизации как для прода, это может требовать разной конфигурации.
Или для ИЕ надо будет настраивать прод сборку?
Под сборку нужно настраивать в любом случае.
Вы предлагаете вручную подбирать конфиги идентичные натуральным hq?
Нет, я перевожу статью и ничего не предлагаю. В вашем случае я думаю вам этот инструмент не подойдет так как вы не испытываете боли от текущих dev серверов.
В браузере с циклическими зависимостями все в порядке, они разрешаются согласно спецификации (условно импорты кешируются), hq разрешением зависимостей не занимается.
Нужен для комфортной разработки, без бандлинга оно бывает намного проще и приятней, видно что в проекте лежит, очень просто что-то пробовать и прототипировать, да много для чего. Как минимум не нужно все настраивать для разработки, это все-таки отдельные конфиги. Уже обсуждали разницу прода и дева — вас разработка в хроме не спасет от потенциальных проблем в условном ИЕ, тестированием нужно заниматься отдельно. Процессится оно должно одинаково, просто одно бандлится, другое — нет.
На сколько я знаю, есть планы сделать решение для прода, но пока это все специализированный dev server и решает он именно эту проблему.
Интересный проект, по сравнению с hq он занимается только преобразованием модулей и не помогает преобразовывать другие различия. С модулями к сожалению справляется не всегда пример unpkg.com/react@16.6.3/index.js?module
Это видимо потому, что модули cjs в данном случае.
Зависимостями занимается браузер. Средство для разработки, потому ответ на остальные вопросы — нет. Все что вы описали важно и нужно, но hq не для этого. Hq делает процес разработки и отладки комфортнее, для остального есть другие решения.
От масштаба и сложности и времени не зависит. Зависит от конкретного случая. У нас прекрасно работает проект на веб компонентах — которые как раз то, что вы описали. Суть в том, что не зависимо от того, что вы делаете, вы грузите это в браузер. Браузер понимает стандарты и с ними работает. hq умеет прозрачно преобразовывать разнообразие стилей к стандарту и делает это пофайлово, а зависимостями рулит сам браузер. В целом все, что делается при бандлинге можно делать и без бандлинга. Я могу представить ситуацию когда решение настолько далеко от веб стандарта, что пофайловая сборка вам не подойдет, но сложно сказать наилучшее ли это решение и нет ли альтернативы, где зависимостями может управлять сам браузер (у нас это так и происходит).
В целом решение проектировалось для разработки проектов, для того, чтоб можно было быстро начать и легко попробовать что-то. Так же оно оказалось полезным в старых проектах с большой кодовой базой и долгим сроком жизни так как позволило улучшить опыт дебага. Скажем, сделали вы, или лучше враги, библиотеку на тайпскрипте и хотите ее попробовать, а тестов нет и документации нет. С hq одной командой можно начинать пробовать, с остальными решениями — нужна сборка и пляски с бубном.
Я верю, что можно выдумать что-то совершенно сложное где hq работать не сможет, но так же верю, что можно и не выдумать, а ограничится решением близким к стандарту. Я так же не буду спорить, что вам hq не подойдет, но не стоит кричать, что у всех проекты стандартные и мелкие, и вот только для такого hq и хорош, это не правда.
Ну это тоже без конкретики очень сложно обсуждать. Я не думаю, что у вас проекты реальнее, чем у нас и могу сказать, что «подкручивать» как раз в основном не приходится. Если пишите стандарт, то и преобразований у вас не будет. Инструмент работает как полифил и сглаживает разницу между стандартом и привычкой (которая либо изменится либо войдет в стандарт). Все как раз прозрачно и очевидно, я не думаю, что вы можете оценить инструмент даже не попробовав. Подкрутка это добавление плагинов в привычный .babelrc, в этом нет ничего не очевидного или сложного, и это в большинстве наших реальных проектов не нужно.
Без конкретики это сложно обсуждать. Инструмент не преобразовывает вещи которые имеют неоднозначную трактовку, такие случаи возможно донастроить с помощью привычного всем .babelrc (пример — импорт svg как реакт компонента), но в подавляющем большинстве случаев нужен лишь перечисленный список который необходимо рутинно настраивать практически на каждом проекте. И тут как видите нет никакой магии, все достаточно просто.
Это не описание свойств конкретного решения. Статья о том какие преобразования нужно выполнить в исходном коде, чтоб он запустился в браузере. Это сравнение существующих стандартов с реальным кодом. Какое бы решение вы не использовали — вам прийдется настроить и сделать большинство из упомянутых преобразований. Понятно, что все новое воспринимается подозрительно, вы можете игнорировать предложенное решение и просто смотреть часть про стандарты (это большая часть статьи).
Если хотите сравнение hq с существующими решениями, то различия такие:
1. Не требует конфигурации
2. Не занимается бандлингом
3. Работает очень быстро
4. Спроектирована специально для комфортной разработки
Спасибо большое! Да, возможно аддон. Передам, чтоб поправили заглушку для старых браузеров или вообще скомпилировали, там заглушка пока очень примитивная на любую ошибку.
Большое спасибо за замечание. Я думаю проблема не в фаерфоксе, в нем все работает, а скорей всего GPU на линукс не хочет что-то рендерить и кидает ошибку. Сайт хостится на гитхабе, а не на hq, так что это тот самый случай когда сапожник без сапог.
Если вам не сложно, могли бы вы сообщение об ошибке из консоли зарепортить на гитхабе или кинуть в личку.
Я всячески борюсь за стандарты и веб компоненты, но пока в основном у нас реакт.
JSX поддерживается, а вот vue пока нет (какая-то версия фреймворка работала с hq, но там еще vue файлов не было), хороший пункт в списке того, что нужно добавить. Спасибо, за замечание.
Разница в «не может типизировать свой код» и «не может типизировать свой код средствами TypeScript» огромна. Последний не поддерживает статические методы в классах, нормальное наследование и полноценные дженерики. Любая функциональная библиотека будет недотипизирована и проблема тут как раз в отсутствии полноценной системы типов в TypeScript
Да нет никакой мистики у вас сообщение об ошибке говорит в чем проблема. Точно так же можно посмотреть как выглядит сборка без бандла.
При пофайловой транспиляции сорсмапы в разы аккуратнее. Если мы говорим про js -> js то вообще проблем не будет, а в случае с бандлом, попробуйте поставить брейкпоинт на выражение, попробуйте подебажить зависимость внутри нод-модулей, это все не так просто как вы описываете.
Структура запросов, видно кто сделал запрос и зачем. и вы тактично опустили часть про код кавередж.
Да это ваша личная проблема и боязнь инструментов, не используйте, кто ж вам мешает то.
Например реакт
Оптимизация изображений, генерация сервис воркера, да мало ли что. Если это отдельная часть сборки — так это уже вторая сборка и у вас все равно 2 конфига.
Так не делайте, это не для вас инструмент, это мы уже выяснили. У нас прекрасно работает комбинация hq + parcel и нет никаких проблем.
Ну хорошо, что сделали что-то свое. Но я не совсем понимаю смысл всей этой полемики. Вы хотите узнать о преимуществах hq, так это можно сделать просто попробовав. Больше похоже на то, что вы хотите доказать, что инструмент отстой даже не пробовав и переубедить меня им не пользоваться. Я не думаю, что стоит продолжать.
Ну так оно ожидаемо валится в таком случае, класс А ведь не определен в момент определения B.
У меня проблемы с постановкой брекпойнтов, а в особо запущеных случаях и вообще с отладкой в консоли так как имена внутри библиотек могут быть обфусцированы, покрытие кода работает криво, это навскидку.
Ну потому, что с бандлами вам нужен бандл аналайзер или еще что-то в этом роде, а без них у вас структура проекта видна во вкладке нетворк.
Можно не выбрасывать, а потом собрать и выложить. Не понимаю в чем тут проблема. Быстрый эксперимент бывает очень ценным оружием. Неужели вы никогда не запускали simpleHTTPServer, вот достойная замена как по мне.
Это не ко мне вопрос. В вашей ситуации это может быть и подходящий вариант, но многие фреймворки имеют переменные окружения которые дают больше возможностей для отладки, для ускорения сборки на дев версии не нужна обфускация и не нужны все оптимизации как для прода, это может требовать разной конфигурации.
Под сборку нужно настраивать в любом случае.
Нет, я перевожу статью и ничего не предлагаю. В вашем случае я думаю вам этот инструмент не подойдет так как вы не испытываете боли от текущих dev серверов.
Нужен для комфортной разработки, без бандлинга оно бывает намного проще и приятней, видно что в проекте лежит, очень просто что-то пробовать и прототипировать, да много для чего. Как минимум не нужно все настраивать для разработки, это все-таки отдельные конфиги. Уже обсуждали разницу прода и дева — вас разработка в хроме не спасет от потенциальных проблем в условном ИЕ, тестированием нужно заниматься отдельно. Процессится оно должно одинаково, просто одно бандлится, другое — нет.
На сколько я знаю, есть планы сделать решение для прода, но пока это все специализированный dev server и решает он именно эту проблему.
Это видимо потому, что модули cjs в данном случае.
Зависимостями занимается браузер. Средство для разработки, потому ответ на остальные вопросы — нет. Все что вы описали важно и нужно, но hq не для этого. Hq делает процес разработки и отладки комфортнее, для остального есть другие решения.
В целом решение проектировалось для разработки проектов, для того, чтоб можно было быстро начать и легко попробовать что-то. Так же оно оказалось полезным в старых проектах с большой кодовой базой и долгим сроком жизни так как позволило улучшить опыт дебага. Скажем, сделали вы, или лучше враги, библиотеку на тайпскрипте и хотите ее попробовать, а тестов нет и документации нет. С hq одной командой можно начинать пробовать, с остальными решениями — нужна сборка и пляски с бубном.
Я верю, что можно выдумать что-то совершенно сложное где hq работать не сможет, но так же верю, что можно и не выдумать, а ограничится решением близким к стандарту. Я так же не буду спорить, что вам hq не подойдет, но не стоит кричать, что у всех проекты стандартные и мелкие, и вот только для такого hq и хорош, это не правда.
Если хотите сравнение hq с существующими решениями, то различия такие:
1. Не требует конфигурации
2. Не занимается бандлингом
3. Работает очень быстро
4. Спроектирована специально для комфортной разработки
Если вам не сложно, могли бы вы сообщение об ошибке из консоли зарепортить на гитхабе или кинуть в личку.
JSX поддерживается, а вот vue пока нет (какая-то версия фреймворка работала с hq, но там еще vue файлов не было), хороший пункт в списке того, что нужно добавить. Спасибо, за замечание.