Современный веб — это сложная динамическая система, которая постоянно находится в движении. Как было замечено во многих статьях (ссылки) становится очень сложно уследить за всеми изменениями так как новые инструменты и фреймворки появляются чуть ли не каждый день. Знания устаревают еще не успев закрепиться. Конечно, все это очевидный результат быстрого развития и роста, но это неизбежно добавляет сложности веб разработчикам и увеличивает порог входа в профессию.

Доходит до абсурда, чтобы создать простую форму ввода пользовательских данных приходится конфигурировать сначала 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