Комментарии 27
Если уж писать подобную статью, то нужно как минимум сравнение с другими решениями, учитывая, что есть куда известнее и популярнее.
Если хотите сравнение hq с существующими решениями, то различия такие:
1. Не требует конфигурации
2. Не занимается бандлингом
3. Работает очень быстро
4. Спроектирована специально для комфортной разработки
Это сравнение существующих стандартов с реальным кодом. Какое бы решение вы не использовали — вам прийдется настроить и сделать большинство из упомянутых преобразований.
Если вы говорите А, то не забывайте далее говорить и Б:
«А если вы используете некое zero-configuration решение, то большинство упомянутых преобразований всё равно должны быть (и будут) сделаны, но не вами, а магическим инструментом.»
А потом в особо запущеных случаях ваши попытки как-то это всё донастроить разобьются об идеологию магического инстумента о том, что у него всё «само».
В общем, нестареющая классика: the customers can have their Ford-T in any color, as long as it's black.
Я не думаю, что у вас проекты реальнее, чем у нас и могу сказать, что «подкручивать» как раз в основном не приходится.
Конечно, это зависит от масштаба, уровня, и времени жизни проектов. Что-то типовое и мелкое, что всю жизнь типовым и мелким и останется — может и не придётся подкручивать. Растущее в масштабе — придётся. Нетипичное — придётся.
Вам надо конкретику? Моя личная конкретика на текущий момент — например, такая: разработка модулей, внедряемых в определенное окружение. Необязательно через iframe (отсутствие фреймовости позволяет очень-очень многое сэкономить через общие ресурсы). Могут ли с такими вещами работать zero-configuration песочницы? Абсолютно нет. В большинстве случаев истерика уже случится тогда, когда выяснится, что в проекте нет ни одного .html, да и быть не может (если без iframe). А если даже и не случится — то мне нужен очень определенный список зависимостей (что очень логично, ресурсы-то общие), в то время как у инструментов, даже и не только zero-configuration — порой существуют очень даже особые мнения насчёт зависимостей.
В целом решение проектировалось для разработки проектов, для того, чтоб можно было быстро начать и легко попробовать что-то. Так же оно оказалось полезным в старых проектах с большой кодовой базой и долгим сроком жизни так как позволило улучшить опыт дебага. Скажем, сделали вы, или лучше враги, библиотеку на тайпскрипте и хотите ее попробовать, а тестов нет и документации нет. С hq одной командой можно начинать пробовать, с остальными решениями — нужна сборка и пляски с бубном.
Я верю, что можно выдумать что-то совершенно сложное где hq работать не сможет, но так же верю, что можно и не выдумать, а ограничится решением близким к стандарту. Я так же не буду спорить, что вам hq не подойдет, но не стоит кричать, что у всех проекты стандартные и мелкие, и вот только для такого hq и хорош, это не правда.
У нас прекрасно работает проект на веб компонентах — которые как раз то, что вы описали.
У нас соль не в том, что мы подключаем куски без ифреймов, а в том, что эти куски пишутся разными конторами на разных технологиях. Одни в ангуляре, другие в реакте, третьи в vue, а четвертые вообще фиг пойми в чем. Или вообще не пишутся, а извлекаются из дремучего легаси лохматых годов (кто в энтерпрайзе работал, тот знает, что в ранних нулевых вебразработка не только была, но её иногда еще и до сих пор поддерживать надо, в 2018 году). И это всё надо по-максимуму дружить друг с другом, потому что через ифреймы это вообще будет абсолютно неподъемно по объемам загружаемого кода и ресурсов.
Бандлинг или не бандлинг — это вообще неважно на самом деле. Вебпак можно при желании заставить ничего не бандлить и оставлять всё как есть (правда тогда и вебпак не нужен, но тем не менее). Или бандлить только то, что бандлится хорошо (мелкие ресурсы, картинки, и тэ пэ, например).
Да и вообще я «наезжал» на zero-configuration, всё остальное тут не имеет особого значения. Zero-configuration на мой опыт создаёт гораздо больше проблем, чем решает, и даже когда люди считают, что их это не коснётся — это аналогично пословице про бекапы: есть те, которые делают, а есть те, которые еще пока не делают. Вот и тут, если проект живой и растущий, то неизбежная необходимость переконфигурёжки у кого-то уже наступила, а у кого-то еще пока нет.
Что до hq в продакшене, так это они сами, если чо, пишут:
Is it good for production?
It might help to serve small projects with very little dependencies. But general the answer is no, not yet.
Зависимостями занимается браузер. Средство для разработки, потому ответ на остальные вопросы — нет. Все что вы описали важно и нужно, но hq не для этого. Hq делает процес разработки и отладки комфортнее, для остального есть другие решения.
Зависимостями занимается браузер.
Вы не ответили на вопрос. Что там с циклическими зависимостями?
Hq делает процес разработки и отладки комфортнее, для остального есть другие решения.
И зачем он такой нужен, если для прода всё-равно надо всё перечисленное настраивать отдельно и огребать проблем от того, что для прода и дева код процессится абсолютно по разному?
Нужен для комфортной разработки, без бандлинга оно бывает намного проще и приятней, видно что в проекте лежит, очень просто что-то пробовать и прототипировать, да много для чего. Как минимум не нужно все настраивать для разработки, это все-таки отдельные конфиги. Уже обсуждали разницу прода и дева — вас разработка в хроме не спасет от потенциальных проблем в условном ИЕ, тестированием нужно заниматься отдельно. Процессится оно должно одинаково, просто одно бандлится, другое — нет.
На сколько я знаю, есть планы сделать решение для прода, но пока это все специализированный dev server и решает он именно эту проблему.
В браузере с циклическими зависимостями все в порядке
// a.js
import B from './b.js'
export default class A {
b() {
return new B
}
}
// b.js
import A from './a.js'
export default class B extends A {}
// index1.js
import A from './a.js' // Uncaught ReferenceError: A is not defined
// index2.js
import B from './b.js' // All right
Ну такое себе "всё в порядке". Больше похоже на "счастливой отладки".
без бандлинга оно бывает намного проще и приятней
А что у вас за проблемы с бандлингом? Почему мне он не мешает? Я что-то делаю не так?
видно что в проекте лежит
Где видно? А почему с бандлами не видно?
очень просто что-то пробовать и прототипировать
А, ну если только поиграться и выбросить и никуда не выкладывать, то да, наверно удобно. Хотя, если б ещё и писать бесконечные импорты/экспорты не приходилось — было бы вообще чудесно. А то бывает список импортов чуть ли не больше собственно полезного кода.
Как минимум не нужно все настраивать для разработки, это все-таки отдельные конфиги.
Зачем отдельные? У меня вот они одинаковые. Я профнепригоден?
разработка в хроме не спасет от потенциальных проблем в условном ИЕ
Так я и спрашиваю заведётся ли это счастье в условном ИЕ? Или для ИЕ надо будет настраивать прод сборку?
Процессится оно должно одинаково
Вы предлагаете вручную подбирать конфиги идентичные натуральным hq?
Ну такое себе «всё в порядке». Больше похоже на «счастливой отладки».
Ну так оно ожидаемо валится в таком случае, класс А ведь не определен в момент определения B.
А что у вас за проблемы с бандлингом? Почему мне он не мешает? Я что-то делаю не так?
У меня проблемы с постановкой брекпойнтов, а в особо запущеных случаях и вообще с отладкой в консоли так как имена внутри библиотек могут быть обфусцированы, покрытие кода работает криво, это навскидку.
Где видно? А почему с бандлами не видно?
Ну потому, что с бандлами вам нужен бандл аналайзер или еще что-то в этом роде, а без них у вас структура проекта видна во вкладке нетворк.
А, ну если только поиграться и выбросить и никуда не выкладывать
Можно не выбрасывать, а потом собрать и выложить. Не понимаю в чем тут проблема. Быстрый эксперимент бывает очень ценным оружием. Неужели вы никогда не запускали simpleHTTPServer, вот достойная замена как по мне.
Зачем отдельные? У меня вот они одинаковые. Я профнепригоден?
Это не ко мне вопрос. В вашей ситуации это может быть и подходящий вариант, но многие фреймворки имеют переменные окружения которые дают больше возможностей для отладки, для ускорения сборки на дев версии не нужна обфускация и не нужны все оптимизации как для прода, это может требовать разной конфигурации.
Или для ИЕ надо будет настраивать прод сборку?
Под сборку нужно настраивать в любом случае.
Вы предлагаете вручную подбирать конфиги идентичные натуральным hq?
Нет, я перевожу статью и ничего не предлагаю. В вашем случае я думаю вам этот инструмент не подойдет так как вы не испытываете боли от текущих dev серверов.
Ну так оно ожидаемо валится в таком случае, класс А ведь не определен в момент определения B.
Проблема в том, что в зависимости от точки входа в цикл — он либо будет определён, либо не будет. И если с бандлом хотя бы можно посмотреть что он там насобирал, и увидеть, что порядок не верный, то тут это просто мистика — то работает, то не работает.
У меня проблемы с постановкой брекпойнтов, а в особо запущеных случаях и вообще с отладкой в консоли так как имена внутри библиотек могут быть обфусцированы, покрытие кода работает криво, это навскидку.
Бандлинг-то тут при чём? Описанные вами проблемы — следствие транспиляции языков, которая будет независимо от бандлинга.
а без них у вас структура проекта видна во вкладке нетворк.
Да какая структура? Сотни одновременных запросов, по которым даже не понятно сколько привнесла дополнительного кода подключённая новая библиотека ибо она будет нарезана на сотни файлов. Так что бандл-аналайзер вкладка нетворк никак не заменит. А структура проекта отлично видна на вкладке "sources", независимо от бандлинга.
Можно не выбрасывать, а потом собрать и выложить. Не понимаю в чем тут проблема.
В том, что сначала используется один инструмент, потом другой, когда можно было бы сразу использовать один инструмент.
фреймворки имеют переменные окружения которые дают больше возможностей для отладки
Каких, например?
для ускорения сборки на дев версии не нужна обфускация
Она и на проде не особо нужна как правило. В любом случае, добавить обфускацию отдельным шагом деплоя — не сложно. Зато весь остальной пайплайн останется единым.
не нужны все оптимизации как для прода
Какие ещё оптимизации?
Под сборку нужно настраивать в любом случае.
Некоторые инструменты позволяют этого не делать.
вы не испытываете боли от текущих dev серверов
Поэтому я запилил свой собственный :-D
тут это просто мистика — то работает, то не работает.
Да нет никакой мистики у вас сообщение об ошибке говорит в чем проблема. Точно так же можно посмотреть как выглядит сборка без бандла.
Описанные вами проблемы — следствие транспиляции языков, которая будет независимо от бандлинга.
При пофайловой транспиляции сорсмапы в разы аккуратнее. Если мы говорим про js -> js то вообще проблем не будет, а в случае с бандлом, попробуйте поставить брейкпоинт на выражение, попробуйте подебажить зависимость внутри нод-модулей, это все не так просто как вы описываете.
Да какая структура? Сотни одновременных запросов
Структура запросов, видно кто сделал запрос и зачем. и вы тактично опустили часть про код кавередж.
когда можно было бы сразу использовать один инструмент.
Да это ваша личная проблема и боязнь инструментов, не используйте, кто ж вам мешает то.
Каких, например?
Например реакт
Какие ещё оптимизации?
Оптимизация изображений, генерация сервис воркера, да мало ли что. Если это отдельная часть сборки — так это уже вторая сборка и у вас все равно 2 конфига.
Некоторые инструменты позволяют этого не делать.
Так не делайте, это не для вас инструмент, это мы уже выяснили. У нас прекрасно работает комбинация hq + parcel и нет никаких проблем.
Поэтому я запилил свой собственный :-D
Ну хорошо, что сделали что-то свое. Но я не совсем понимаю смысл всей этой полемики. Вы хотите узнать о преимуществах hq, так это можно сделать просто попробовав. Больше похоже на то, что вы хотите доказать, что инструмент отстой даже не пробовав и переубедить меня им не пользоваться. Я не думаю, что стоит продолжать.
Да нет никакой мистики у вас сообщение об ошибке говорит в чем проблема.
Импорт есть, а класса нет. Никакой мистики, да.
При пофайловой транспиляции сорсмапы в разы аккуратнее.
Что там не аккуратного при склеивании исходников? Давайте сразу пример, а не голословных утверждений про "не поставить брейкпоинт в выражении".
Структура запросов, видно кто сделал запрос и зачем.
Видно лишь первого зависимого. Остальные зависимые сразу получают из кеша. Ну, такое себе "видно структуру".
Например реакт
Реакт — это возможность для отладки?
Оптимизация изображений
При каждой сборке? Зачем? Соптимизировали, закоммитили, всё, лежит, кушать не просит.
генерация сервис воркера
Это что за оптимизация такая? Тем более, которая включится только на проде и чёрт его знает как поведёт себя приложение.
да мало ли что
Мне вот как раз и интересно, что там может быть полезного, не высосанного из пальца.
это не для вас инструмент, это мы уже выяснили
Больше похоже на то, что вы хотите доказать, что инструмент отстой даже не пробовав и переубедить меня им не пользоваться.
Вам стоит поработать над восприятием негативной обратной связи. Если всем так говорить, то ни популярность инструмент не обретёт, ни лучше не станет.
У нас прекрасно работает комбинация hq + parcel и нет никаких проблем.
Какую проблему решает hq, которую не решает parcel?
Вы хотите узнать о преимуществах hq, так это можно сделать просто попробовав.
Вместо того, чтобы наглядно показать эти преимущества (перед кем, кстати?) вы предлагаете читателям поставить себе кую-то тулзу и самим выискивать чем она может быть лучше? Ну, такое себе предложение.
А автоматически устанавливать модули оно умеет?
А должен? Я знаю, что такая фича есть в Parcel и мне она очень не понравилась. Решил попробовать сборщик в новом проекте: Parcel попытался установить новый модуль, используя Yarn (хотя я пользуюсь npm в основном). В package.json был модуль из приватного репозитория. Yarn ругнулся на то, что не может найти такой пакет (потому что про приватный репозиторий не знает) и уронил dev-server целиком. Удалил Parcel, вернулся на Webpack, который такими "умностями" не страдает.
По поводу остальных вопросов не знаю, но делать супер-комбайн из простого сервера не стоит.
Смешанный импорт — не является стандартом
Почему вы так решили? Вот же он в описании на MDN, безо всяких примечаний, а значит — стандарт: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Syntax
Кстати, еще один пример сервера, который превращает старые модули в современные – это unpkg.com. При добавлении в конец url параметра ?module
там включается специальный препроцессинг для обработки bare-импортов.
Вот пример с @angular/core
: https://unpkg.com/@angular/core@7.1.1/fesm2015/core.js?module Обратите внимание на импорты, они перезаписаны. Имплементация лежит вот здесь. Кроме того, unpkg хостит все npm-модули, так что с его помощью можно собрать любую онлайн демку где-нибудь в jsfiddle, просто используя import-синтаксис.
Может, кому-то пригодится.
Это видимо потому, что модули cjs в данном случае.
В погоне за веб стандартами