Современный веб — это сложная динамическая система, которая постоянно находится в движении. Как было замечено во многих статьях, становится очень сложно уследить за всеми изменениями так как новые инструменты и фреймворки появляются чуть ли не каждый день. Знания устаревают еще не успев закрепиться. Конечно, все это очевидный результат быстрого развития и роста, но это неизбежно добавляет сложности веб разработчикам и увеличивает порог входа в профессию.
Доходит до абсурда, чтобы создать простую форму ввода пользовательских данных приходится конфигурировать сначала babel, потом webpack, а затем еще и разбираться с настройками специфичными для выбранного фреймворка… А это пожалуй слишком много новых слов для новичка в команде, которому поручили эту простую на вид задачку. Нет, скорее всего проект уже будет настроен и сконфигурирован и новичка конечно же не бросят одного на произвол судьбы вкратце рассказав ему что по чем. Но стоит признать, что это действительно стало слишком сложно и мы похоже тратим значительную часть времени на все эти системы сборки и борьбу с конфигурацией.
Но давайте попробуем вспомнить — разве так было всегда? Разве о таком будущем мечтали создатели паутины? Нет, черт возьми, и еще раз нет! Ведь какой-никакой, часто неказистый, наполненный трюками и фокусами но веб был другим — простым и понятным! Вот мы добавили скрипт, вот стиль, а тут наша разметка страницы. Так что же пошло не так, неужели все стало на самом деле так плохо? Ведь javascript да и весь веб только рос и улучшался, язык становился сильнее и выразительнее, появилась модульность, стало очевидным преимущество различных архитектурных шаблонов и все же — где та былая простота? Неужели мы потеряли ее навсегда?
(Великолепный человек-паук)
Ответ на самом деле достаточно прост и прямолинеен. Веб действительно вырос и стал сложнее, теперь не редкость встретить мультимедийное приложение полностью написанное под веб технологии или 3д игру в браузере, что было немыслимо еще 10 лет назад. Но главная проблема в том, что мы часто хотим от веба того, что он еще не готов нам дать — новейшие технологии и стандарты, экспериментальные архитектурные шаблоны, все только самое новое и современное и конечно это должно работать везде и у всех, и побыстрее пожалуйста. И тут на сцене появляется дикая банда во главе с webpack и начинает править бал. И вот вы уже обвешаны сложными конфигурациями и ваш проект собирается полторы минуты и весит полсотни мегабайт. Finito la comedia. Начинается борьба с конфигурацией в попытке выжать еще немного производительности и сократить размер. И о какой разработке и воплощении идей тогда может вообще идти речь, если львиную долю времени мы проводим за настройками сборочной линии. Признавайтесь, кто у вас в команде эксперт по webpack?
Мы не то чтобы привыкли к этому, но скорее смирились, что это нормально, ну а и как иначе? Мы обвешались типами и фреймворками, корпоративность, безопасность — даже не придерешься. Но куда же девалась эта легкость и простота эксперимента, для которой был задуман этот слабо типизированный динамичный язык? А все, нет ее, пропала под горами бандлов и энтерпрайза. Но неужели совсем ничего нельзя сделать?
Тут стоит остановиться и задуматься, а что мы вообще делаем и зачем? Ведь если мы используем webpack, rollup, parcel (нужное подчеркнуть) и создаем все эти нечитаемые бандлы которые потом невозможно дебажить даже с source maps, то ведь это точно кому-нибудь нужно, ведь так? Да, все так, для быстрого и эффективного продакшена от бандлов никуда не денешься и даже новомодный HTTP2 не сделал задачу сильно проще. Потому и пакуют разработчики сидя в офисе долгими осенними вечерами, засиживаясь подольше на работе и сжигая сотни тысяч киловатт энергии, пакуют отделами, пакуют компаниями, пакуют всем миром передавая смену с движением солнца. Так уж повелось, и таков закон. Dura lex, sed lex. Так что поистине шекспировский вопрос бандлить или не бандлить — погибает даже не успев сорваться с уст юного Гамлета открывшего visual studio, чтобы сваять очередной шедевр.
(Все в порядке)
Но постойте, вы же сказали, что это все необходимо для продакшена, а что насчет разработки? Почему нельзя комфортно разрабатывать как в старые добрые времена просто запустив сервер и потом уже упаковывать все перед самой отправкой на продакшн? И почему мы вообще пользуемся одними и теми же инструментами для продакшена и разработки? Почему бы не использовать решение заточенное специально для разработки, ведь то что мы делаем выглядит как-то не особо логично.
И это действительно не логично и мы скорее делаем так за отсутствием альтернатив или просто потому, что привыкли. Но что если я скажу, что у вас есть выбор?
Встречайте hq — специализированный сервер для разработки веб приложений. hq — это статический сервер на стероидах, который понимает все то, что обычному серверу не по зубам. Хотите последнюю фишку из стандарта javascript, но ваш браузер ее еще не поддерживает? — пожалуйста! Ваша библиотека использует commonjs формат — нет проблем! Долой разномастные инструменты заточенные для работы с каждым конкретным фреймворком, hq поддерживает их всех, прямо из коробки. hq настолько крут, что не требует никакой конфигурации, он просто работает и делает свое дело. Нет parcel все не так как у тебя, hq НА САМОМ ДЕЛЕ не требует никакой конфигурации, ее просто нет, так что деваться некуда. Установите его единожды
npm install -g @hqjs/hqи затем запускайте одной командой в корне проекта, чтобы начать экспериментировать немедленно
hqНу скажете вы, примерно то же предлагала нам и старая банда, ну может чуть побольше конфигурации, чуть менее просто, но все примерно очень похоже, так зачем нам этот новый Чак Норрис в мире дев серверов? И тут я отвечу вам новым девизом дома Грейджой — “Мы не бандлим!”. Да, на самом деле, мы не бандлим!
(Дом Грейджой. Мы не
Привет, я занимаюсь веб разработкой с 13-ти лет и я начал бандлить когда мне было 19. Меня на это подсадил мой друг, когда я зашел к нему в гараж где он бандлил дни и ночи на пролет. Я спросил, что это ты делаешь? И он сказал, что это новая штука, это теперь очень модно и круто и я обязательно должен попробовать. Сначала я просто клеил файлы, а потом попробовал небольшой бандл с closure compiler и потом уже не смог остановиться. gulp, browserify, а потом и webpack… Мои бандлы становились все тяжелее. Я не знал как остановиться, я попал в круговорот который не давал мне выйти. Каждый раз когда я попадал на новый проект там уже кто-то бандлил и отказаться было просто невозможно. Не бандлить стало не престижно! Люди из профессии и даже близкие друзья отказывались от общения и не перезванивали мне, когда узнавали, что я хочу перестать. Так что деваться было некуда. Но теперь я чист! Я больше не бандлю во время разработки! Со мной перестали бандлить и мои друзья и знакомые, это теперь не принято у нас в компании. И знаете что? Я никогда не чувствовал себя так хорошо! Мир наконец-то заиграл новыми красками и начало находиться время и на работу и на семью.
Серьезно, отсутствие бандлов сильно упрощает жизнь. Вспомните невыносимые ситуации, когда невозможно поставить break point не то что на выражение, а даже на нужную строку! Или эти имена переменных сгенерированных webpack __webpack__@#%^$!!! При их прочтении не мудрено и сатану вызвать, а писать их в консоль и врагу не пожелаешь, а что самое противное они скрыты за нормальными, человеческими именами, так что их еще поди угадай. В общем отладка частенько превращается в ад, даже с полноценными source maps. Сколько раз в день вы материте код находящийся внутри node_modules? Сколько проклятий сыпятся на голову несчастным разработчикам React и Angular потому, что невозможно понять сообщение об ошибке и где эта ошибка возникает? После того как мы перешли на hq, мы забыли все это как страшный сон. Времени стало реально больше, теперь не приходится ломать голову почему оно не собирается или просто молча не работает и откуда у нас в билде взялась еще вот эта библиотека на десять мегабайт, теперь прекрасно видно откуда! Страданий стало меньше, работа стала проще и получается делать ее в удовольствие.
(Этот человек — Варг или меняющий кожу, он может проникать в сознание животных. Сейчас он парит вместе с орлом, высматривая врага)
Самое приятное, что hq не кажется чем-то новым и сложным, такое ощущение, что он был с нами всегда, настолько все просто и привычно. hq — это статический сервер который просто понимает тебя. Старт нового проекта становится невероятно быстрым, одна команда в консоли и можно начать экспериментировать. Фреймворки, библиотеки, форматы, архитектурные подходы — все это больше не создает барьеров, с hq все просто работает как в старые добрые времена, быстро, просто и логично! Плюс ко всему hq опенсорс проект так что всегда можно что-то улучшить или добавить поддержку какого-нибудь нового формата.
Признаться честно, мы нашли и недостатки. Раньше, когда сборка с webpack занимала несколько минут это было чудесным оправданием чтобы заглянуть на кухню за чашечкой ароматного кофе, теперь же все работает настолько быстро, что времени для этого просто нет. Хотя, нужно ли вообще искать оправдание для хорошего кофе?
Как же это все работает? Тут может сложиться впечатление, что hq это здоровенный монстр сотканный доктором Франкенштейном из множества разнородных и несвязных частей приправленый толикой черной магии. Но на самом деле все достаточно стройно и единообразно. hq раздает каждый файл индивидуально по запросу, так же как, как это делает обычный статический сервер. Это дает нам всего лишь ограниченную возможность избавиться от неиспользуемого кода, без полноценного tree shaking, но зато экономит много времени которое тратилось на анализ зависимостей. Все трансформации происходят мгновенно и на лету. Более того, трансформируется лишь необходимый минимум. Если вы используете современный браузер и придерживаетесь веб стандартов, то ваш код вряд ли будет изменен вообще. В то время когда вы можете уповать на стандарты, нет никакой гарантии, что библиотеки к которым вы так привыкли будут делать то же самое. Большинство из них наверняка будут поставляться в формате commonjs, что не позволяет им работать в браузере как есть. hq заботится и об этом преобразуя commonjs модули в формат ESM, обрабатывает не стандартные, но довольно распространенные импорты (такие как css или json) и деструктуризирует импортируемые объекты, когда это нужно. hq работает в связке с веб браузером, используя его систему кэширования, чтобы ускорить доставку асетов и передавать лишь файлы которые были изменены. Он автоматически перезагрузит страницу когда вы измените свой код, так что вы мгновенно сможете оценить результат изменений. hq может работать с множеством фреймворков, но не зависит от их кода. Вместо этого hq производит серию AST трансформаций с помощью плагинов для babel, которые были специально созданы для hq, чтоб он смог понять и преобразить разнообразие технологий и подходов используемых в разработке к единому стандарту поддерживаемому браузером.
Таким образом не смотря на все сложности и вызовы предъявляемые современным вебом, разработка проектов может оставаться простой и интуитивно понятной, так же как это было на заре веб технологий. Попробуйте hq сейчас, чтобы улучшить опыт разработки в старом проекте, или используйте его, чтобы создать новый захватывающий проект!
npm install -g @hqjs/hq Комментарии (38)
justboris
06.11.2018 11:03В современном фронтенде слишком много инструментов! Создам-ка я еще один, в нем уж точно все будет по-нормальному!
Ясно-понятно.
Large Автор
06.11.2018 11:07Тут не хватает картинки про стандарты =) Но по моему в данном случае это не совсем справедливо. У нас сейчас только hq и parcel и мы в общем-то ничего не настраиваем (ну немножко парсель). То есть теперь есть возможность сконцентрироваться на бизнес логике и абстрагироваться от сложностей сборки и вообще понимания всего этого зоопарка с бабелем, плагинами и стандартами, все как в старые добрые =)
justboris
06.11.2018 11:29В этом и дело. Уже есть parcel, create-react-app, next.js, которые тоже работают из коробки без сложных конфигов. Что нового здесь приносит hq?
Large Автор
06.11.2018 11:37parcel — бандлит, next — это скорее фреймворк, create-react-app — работает только с реактом. hq работает вообще со всем и не бандлит, что делает разработку и отлов ошибок гораздо комфортнее.
Я это представляю себе так — пусть у нас есть идеальный мир в котором все пишут только по стандарту, все библиотеки имеют формат ЕСМ и браузеры поддерживают все то, что пишут разработчики. hq — это такой себе полифил который этот мир немного приближает. То есть он дает возможность представить, что все так и есть уже сейчас.justboris
06.11.2018 11:42В Parcel тоже есть dev-server, который делает абсолютно то же самое.
Large Автор
06.11.2018 11:47Нет, он делает не то же самое. Он просто раздает вам бандл который делает парсель вот и все, и он не умеет работать с разными фреймворками типа ангулара, так что разница есть. Парсель — это бандлер, а hq — это сервер для разработки. Опыт дебага отличается кардинально.
justboris
07.11.2018 00:36+1Смог запустить, потыкал, разобрался.
hq в отличие от других инструментов не занимается бандлингом, а загружает исходники в браузер почти в исходном виде. Все современные браузеры (даже Edge, но не IE) понимают ключевое слово
import, поэтому умеют работать с модулями на прямую, с небольшими ограничениями
- bare imports (без относительных путей, например
import 'lodash') в браузерах пока нет, только черновик стандарта. - импорты css,png,svg и других форматов не работают. Планов на имплементацию я тоже не нашел. Закрытая issue на эту тему.
- Cинтаксис JSX не является частью стандарта Javascript и никогда там не будет, поэтому тоже требует процессинга
- Декларации типов от Typescript и Flow тоже не являются валидным JS, их тоже нужно убрать
Именно эти недостающие фичи покрывает hq, не влияя на остальную часть кода. У этого подхода есть плюсы:
- Код в браузере близок к исходникам, нет никакой магии
- Быстрая работа dev-сервера (в теории, на практике всегда надо мерить)
- Потенциальная возможность избавиться от препроцессоров вообще, когда примут стандарт на import-maps.
Есть и минусы:
- Долгая загрузка страницы. Страница с импортами грузится ощутимо дольше, даже с локалхоста.
- Удобство использования этой тулой могло бы быть и лучше. Очень было неочевидно, как с ней вообще начать работать.
Вот какой-то такой обзор я бы хотел прочесть в самой статье. Если там что-то такое и было, то из-за воды про неудобства других инструментов, я этого там увидеть не смог.
В целом, идея хорошая, стоит попробовать.
Large Автор
07.11.2018 01:36Для борьбы с минусами пока есть кешь, потом планируется его еще прокачать да и вообще еще дополнительно повысить скорость. В плане неочевидности передам, чтоб хауту было понятнее, пока по предварительным отзывам в среднем все более-менее просто работает с минимальными модификациями.
Спасибо за конструктивный отзыв. Статья обзорная для того чтобы очертить проблему, инструменты которые упомянуты критикуются в контексте разработки, для продакшена они как раз подходят очень даже хорошо, о чем тоже упоминается. Думаю будут и другие статьи где будет больше конкретики.
- bare imports (без относительных путей, например
justboris
06.11.2018 11:36P.S. решил попробовать hq, установил его вместо react-scripts, положил index.html в корень проекта, а в браузере вижу такое
File / not found NotFoundError: File / not found at Object.throw (/Users/just-boris/coding/sbs-demo/node_modules/koa/lib/context.js:96:11) at resolvePath (file:///Users/just-boris/coding/sbs-demo/node_modules/@hqjs/hq/middlewares/resolve-path.mjs:67:18)
что я делаю не так?
Large Автор
06.11.2018 11:41не могу сказать, закиньте багу на гитхаб, если есть желание помочь и опишите структуру проекта, разработчики будут вам благодарны.
У нас работало из коробки структура проекта такая:
src/index.html
src/index.js
src/index.css
Пробовал в корень все переместить — тоже работает.
Ну проект новый, думаю поправят детские баги по немногу, нам в целом зашло.justboris
06.11.2018 23:47Переместил, теперь работает. Получается, сервер смотрит на захардкоженный путь `src` без возможности его поменять. Г — гибкость!
Я понимаю, что молодым проектам нужно помогать разбираться с багами, но после вводной статьи с заявлениями «вы говно, я — д'Артаньян», особого желания помогать не возникает.Large Автор
06.11.2018 23:59Не захардкожено, путь ищется в пакедж жсон, срц или корне.
Вы видимо разработчик паре ляжет. Не вижу где вы там увидели такое заявление. Объяснялась разница между проектами и проблемы разработки. Мы парселем пользуемся. Насколько я знаю разработчики проекта тоже. В любом случае никакого негатива не было. Объяснялась разница между подходами. Я лично думаю, что Парасельскими как раз хорошо дополняет тулзу когда речь идёт о продакшене, но честно не хочется выслушивать все ваши оскорбления, я сочувствующий, но скорее переводчик, мне это вообще не нужно.
Large Автор
06.11.2018 13:59Есть предположение, что вы переместили index.html из папки src в корень проекта потому hq его и не видит. Попробуйте оставить его в src.
SirEdvin
06.11.2018 11:22И это действительно не логично и мы скорее делаем так за отсутствием альтернатив или просто потому, что привыкли. Но что если я скажу, что у вас есть выбор?
И сколько вы уже багов из-за различия hq и того, что у вас на тестовой среде словили? Унификация среды разработки и реальных сред происходит не просто так, это довольно выстраданная практика, альтернативы которой практически нет.
Large Автор
06.11.2018 11:43+1Ну для того тестирование в разных браузерах и проводится, это как бы задача совершенно отдельная от задачи разработки. То что вы будете его каждый раз паковать никак вас не спасет от того, что в условном Эдже оно поломается. Так что у нас мухи отдельно, а котлеты отдельно.
SirEdvin
06.11.2018 12:05То есть у вас разработчик не проводит первичного тестирования и не проверяет, как оно выглядит? Что-то в духе накодил и пусть там дальше тестируют?
Large Автор
06.11.2018 12:11Проводит конечно, но на то оно и первичное. То есть если бизнес логика работает и интерфейс не плывет — можно плыть дальше. А после сборки на прод (имеется в виду сборка которая после тестирования пойдет на прод, а не то, что тестируют в проде) — уже тестировщики отлавливают все баги.
Пока проблем связанных с переходом на hq не было, было один раз, что проект работал с hq, но не собирался вообще с парселем. Решилось конфигурацией парселя, но я не могу сказать в чем там была проблема. Как-то он не так понимал зависимости от rxjs что-ли. В целом не могу сказать, что это была проблема hq, скорее либо rxjs либо parcel.
staticlab
06.11.2018 11:53Is it good for production?
It might help to serve small projects with very little dependencies. But general the answer is no, not yet. However, it is really good for development. The production solution is currently a WIP and it is going to reduce all the pain that modern web application building and deployment usually demands.Ну и зачем оно нужно? :)
Large Автор
06.11.2018 11:56Для разработки, там так и написано =) И еще для быстрых экспериментов, для комфортного дебага, для того, чтобы не думать об этом вот всем, а просто писать бизнес логику.
staticlab
06.11.2018 12:11А потом я захочу задеплоить на прод, и мне придётся всё равно настраивать систему сборки?
Для быстрых экспериментов есть, как уже упомянули, parcel, create-react-app, next.js, create-vue-app. Для ангуляра же вообще всё из коробки идёт. В особо простых случаях есть ванильный webpack, который даже конфигурировать не надо, хоть там ничего сложного и нет. Зато в любой момент можно выкатить наработки на прод.
Large Автор
06.11.2018 12:16Да, все так, все равно прийдется настраивать систему сборки для прода, просто собирать постоянно не прийдется. Это сильно помогает дебажить.
Ну я бы не сказал, что прям быстрые эксперименты с вот тем вот всем, что выше названо, да и сами посмотрите сколько всего и все разное, а тут один инструмент. Вебпак конфигурировать надо всегда, как минимум инпут/аутпут. Возможность не бандлить иногда многого стоит.
Я ни к чему не призываю, просто делюсь личными впечатлениями, нам зашло.staticlab
06.11.2018 12:21просто собирать постоянно не прийдется
Там же хот-релоадинг, быстрая пересборка в фоне.
Вебпак конфигурировать надо всегда, как минимум инпут/аутпут
В командной строке просто задать. Естественно, в package.json.
Large Автор
06.11.2018 12:26Я имел в виду бандлы. Один здоровый жс даже с сорс мапами это довольно не приятно для дебага. У меня лично глаз начинает дергаться, когда ставишь брейк поинт на строку, а он прыгает куда-то вниз на 5 строк вниз вообще из функции. Ну и теперь прямо в браузере видно что загружается на страницу, не нужна куча плагинов для анализа бандлов.
Веб пак, это все равно конфигурация, но да, это не сложно, но все-таки сложнее чем просто одна команда без параметров в консоли. Тут скорее вопрос восприятия. Раньше мы просто запускали питоновский стандартный статический сервак и начинали что-то делать, теперь — куча сложностей. Для меня hq — это тот самый статический сервак который просто немного умнее стандартного.
ThisMan
06.11.2018 12:38Чет я не совсем понял хейта по поводу бандлов. Какие-то надуманные проблемы с соурсмапами. Тот же вебпак эмулирует файловую структуру проекта через соурсмапы, так что к каждому отдельному модулю будет доступ ( даже к
node_modules) + именно для разработки естьdev-server. Ну и конфигурация: по сути своей один раз настроил и используй во всех проектах. Куча же всякихboilerplate-овесть.
А тут: для разработки один инструмент, для прода другой. Давайте еще для тестирования придумаем что-нибудь
Large Автор
06.11.2018 12:45Ну так а почему нет, разные инструменты заточенные для разных нужд.
С сорсмапами проблема весьма реальна, брекпоинты прыгают, если не повезет и в модуле который делает и собирает другая команда будут проблемы — то в зависимости от их конфигурации можно получить вообще не приятный опыт (особенно с create-react-app) и то, что вы вам браузер отображает структуру проекта дебагу не сильно поможет. Плюс нужно еще разбираться, что у вас в бандл входит и почему он такой здоровый вырос. Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.ThisMan
06.11.2018 13:07Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Но ведь
hqтоже не подойдет для больших проектов
It might help to serve small projects with very little dependencies
Large Автор
06.11.2018 13:09-2Почему? Мы как раз его для большого проекта используем и он дает хороший прирост в скорости разработки. Цитата вырвана из контекста про продашн решение, я бы действительно не пихал его в прод если у проекта много зависимостей, да и в принципе. А вот для разработки — самое оно.
Large Автор
06.11.2018 14:53Но вот к примеру у вас огромный проект весит 10 Мб, если в случае с бандлом при малейшем изменении браузер будет грузить все 10 Мб, то hq загрузит только то, что реально поменялось, что гораздо быстрее.
YemSalat
07.11.2018 01:2910МБ это конечно дофига, но нa локалхосте они загрузятся довольно быстро.
А если уже используется какой-нибудь фрэймворк, например vuе, созданный через vue-cli, можно ли быстро перейти на hq, или это не тот случай?Large Автор
07.11.2018 01:43Я не эксперт по вью, но думаю можно просто попробовать запустить hq в корне проекта и в теории должно заработать. При этом для сборки на продакшн у вас все еще останется npm run build
Если что-то не работает — не стесняйтесь, пишите баги на гитхаб, разработчики будут очень благодарны.YemSalat
07.11.2018 12:16Я не эксперт по вью, но думаю можно просто попробовать запустить hq в корне проекта и в теории должно заработать.
Например там все компоненты будут лежать в файлах .vue — их просто так браузеру не отдашь (как jsx), надо сначала их «собирать». Похоже что hq такие ситуации не покрывает?
И любопытно, какой фронтэнд фрэймворк вы у себя используете?Large Автор
07.11.2018 12:51Я всячески борюсь за стандарты и веб компоненты, но пока в основном у нас реакт.
JSX поддерживается, а вот vue пока нет (какая-то версия фреймворка работала с hq, но там еще vue файлов не было), хороший пункт в списке того, что нужно добавить. Спасибо, за замечание.
Zet_Roy
06.11.2018 15:29Знания устаревают еще не успев закрепиться. Конечно, все это очевидный результат быстрого развития и роста, но это неизбежно добавляет сложности веб разработчикам и увеличивает порог входа в профессию.
Это наглая ложь. Ты в вебе не разбираешься раз такое пишешь. Есть устоявшийся фреймворк который подходит под 100% задач это React, которому 5 лет. Ангуляр и вуе используют единицы, вебпаком и того меньше, веб пак по большому счету и ненужен, он создан для удобства и можно спокойно без него обходится и создавать сайты.
valsaven
Спасибо за статью. Я правильно понял, что вы уже используете hq на проде? Сколько времени у вас занял переезд с предыдущего стека?
Large Автор
Я всего лишь скромный переводчик. Но в данном случае я перевел статью потому, что мы проект пробовали и он нам понравился. Из нашего опыта — переезда не было так как это скорее инструмент для разработки и мы просто начали им пользоваться и стало реально удобнее (это по сути сервер статики так что сложностей в общем-то нет). Это в принципе времени не заняло, решили, что штука интересная и нужно попробовать. Установили и начали пользоваться и она просто сразу заработала, стало удобнее дебажить. Для продакшена там что-то тоже готовится так что следим за обновлениями, но пока мы пользуемся парселем.
Large Автор
За что минусуете? Я старался, переводил (хоть бы кто похвалил качество перевода), да и еще немного разбираюсь в теме и отвечаю на вопросы.