Комментарии 43
Спасибо за статью. Я правильно понял, что вы уже используете hq на проде? Сколько времени у вас занял переезд с предыдущего стека?
Я всего лишь скромный переводчик. Но в данном случае я перевел статью потому, что мы проект пробовали и он нам понравился. Из нашего опыта — переезда не было так как это скорее инструмент для разработки и мы просто начали им пользоваться и стало реально удобнее (это по сути сервер статики так что сложностей в общем-то нет). Это в принципе времени не заняло, решили, что штука интересная и нужно попробовать. Установили и начали пользоваться и она просто сразу заработала, стало удобнее дебажить. Для продакшена там что-то тоже готовится так что следим за обновлениями, но пока мы пользуемся парселем.
За что минусуете? Я старался, переводил (хоть бы кто похвалил качество перевода), да и еще немного разбираюсь в теме и отвечаю на вопросы.
Ребяяят, ребяяят… Тссс… Кажется до них начало доходить…
В современном фронтенде слишком много инструментов! Создам-ка я еще один, в нем уж точно все будет по-нормальному!
Ясно-понятно.
Тут не хватает картинки про стандарты =) Но по моему в данном случае это не совсем справедливо. У нас сейчас только hq и parcel и мы в общем-то ничего не настраиваем (ну немножко парсель). То есть теперь есть возможность сконцентрироваться на бизнес логике и абстрагироваться от сложностей сборки и вообще понимания всего этого зоопарка с бабелем, плагинами и стандартами, все как в старые добрые =)
В этом и дело. Уже есть parcel, create-react-app, next.js, которые тоже работают из коробки без сложных конфигов. Что нового здесь приносит hq?
parcel — бандлит, next — это скорее фреймворк, create-react-app — работает только с реактом. hq работает вообще со всем и не бандлит, что делает разработку и отлов ошибок гораздо комфортнее.
Я это представляю себе так — пусть у нас есть идеальный мир в котором все пишут только по стандарту, все библиотеки имеют формат ЕСМ и браузеры поддерживают все то, что пишут разработчики. hq — это такой себе полифил который этот мир немного приближает. То есть он дает возможность представить, что все так и есть уже сейчас.
Я это представляю себе так — пусть у нас есть идеальный мир в котором все пишут только по стандарту, все библиотеки имеют формат ЕСМ и браузеры поддерживают все то, что пишут разработчики. hq — это такой себе полифил который этот мир немного приближает. То есть он дает возможность представить, что все так и есть уже сейчас.
В Parcel тоже есть dev-server, который делает абсолютно то же самое.
Нет, он делает не то же самое. Он просто раздает вам бандл который делает парсель вот и все, и он не умеет работать с разными фреймворками типа ангулара, так что разница есть. Парсель — это бандлер, а hq — это сервер для разработки. Опыт дебага отличается кардинально.
Смог запустить, потыкал, разобрался.
hq в отличие от других инструментов не занимается бандлингом, а загружает исходники в браузер почти в исходном виде. Все современные браузеры (даже Edge, но не IE) понимают ключевое слово import, поэтому умеют работать с модулями на прямую, с небольшими ограничениями
- bare imports (без относительных путей, например
import 'lodash') в браузерах пока нет, только черновик стандарта. - импорты css,png,svg и других форматов не работают. Планов на имплементацию я тоже не нашел. Закрытая issue на эту тему.
- Cинтаксис JSX не является частью стандарта Javascript и никогда там не будет, поэтому тоже требует процессинга
- Декларации типов от Typescript и Flow тоже не являются валидным JS, их тоже нужно убрать
Именно эти недостающие фичи покрывает hq, не влияя на остальную часть кода. У этого подхода есть плюсы:
- Код в браузере близок к исходникам, нет никакой магии
- Быстрая работа dev-сервера (в теории, на практике всегда надо мерить)
- Потенциальная возможность избавиться от препроцессоров вообще, когда примут стандарт на import-maps.
Есть и минусы:
- Долгая загрузка страницы. Страница с импортами грузится ощутимо дольше, даже с локалхоста.
- Удобство использования этой тулой могло бы быть и лучше. Очень было неочевидно, как с ней вообще начать работать.
Вот какой-то такой обзор я бы хотел прочесть в самой статье. Если там что-то такое и было, то из-за воды про неудобства других инструментов, я этого там увидеть не смог.
В целом, идея хорошая, стоит попробовать.
Для борьбы с минусами пока есть кешь, потом планируется его еще прокачать да и вообще еще дополнительно повысить скорость. В плане неочевидности передам, чтоб хауту было понятнее, пока по предварительным отзывам в среднем все более-менее просто работает с минимальными модификациями.
Спасибо за конструктивный отзыв. Статья обзорная для того чтобы очертить проблему, инструменты которые упомянуты критикуются в контексте разработки, для продакшена они как раз подходят очень даже хорошо, о чем тоже упоминается. Думаю будут и другие статьи где будет больше конкретики.
Спасибо за конструктивный отзыв. Статья обзорная для того чтобы очертить проблему, инструменты которые упомянуты критикуются в контексте разработки, для продакшена они как раз подходят очень даже хорошо, о чем тоже упоминается. Думаю будут и другие статьи где будет больше конкретики.
P.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)что я делаю не так?
не могу сказать, закиньте багу на гитхаб, если есть желание помочь и опишите структуру проекта, разработчики будут вам благодарны.
У нас работало из коробки структура проекта такая:
src/index.html
src/index.js
src/index.css
Пробовал в корень все переместить — тоже работает.
Ну проект новый, думаю поправят детские баги по немногу, нам в целом зашло.
У нас работало из коробки структура проекта такая:
src/index.html
src/index.js
src/index.css
Пробовал в корень все переместить — тоже работает.
Ну проект новый, думаю поправят детские баги по немногу, нам в целом зашло.
Переместил, теперь работает. Получается, сервер смотрит на захардкоженный путь `src` без возможности его поменять. Г — гибкость!
Я понимаю, что молодым проектам нужно помогать разбираться с багами, но после вводной статьи с заявлениями «вы говно, я — д'Артаньян», особого желания помогать не возникает.
Я понимаю, что молодым проектам нужно помогать разбираться с багами, но после вводной статьи с заявлениями «вы говно, я — д'Артаньян», особого желания помогать не возникает.
Не захардкожено, путь ищется в пакедж жсон, срц или корне.
Вы видимо разработчик паре ляжет. Не вижу где вы там увидели такое заявление. Объяснялась разница между проектами и проблемы разработки. Мы парселем пользуемся. Насколько я знаю разработчики проекта тоже. В любом случае никакого негатива не было. Объяснялась разница между подходами. Я лично думаю, что Парасельскими как раз хорошо дополняет тулзу когда речь идёт о продакшене, но честно не хочется выслушивать все ваши оскорбления, я сочувствующий, но скорее переводчик, мне это вообще не нужно.
Есть предположение, что вы переместили index.html из папки src в корень проекта потому hq его и не видит. Попробуйте оставить его в src.
И это действительно не логично и мы скорее делаем так за отсутствием альтернатив или просто потому, что привыкли. Но что если я скажу, что у вас есть выбор?
И сколько вы уже багов из-за различия hq и того, что у вас на тестовой среде словили? Унификация среды разработки и реальных сред происходит не просто так, это довольно выстраданная практика, альтернативы которой практически нет.
Ну для того тестирование в разных браузерах и проводится, это как бы задача совершенно отдельная от задачи разработки. То что вы будете его каждый раз паковать никак вас не спасет от того, что в условном Эдже оно поломается. Так что у нас мухи отдельно, а котлеты отдельно.
То есть у вас разработчик не проводит первичного тестирования и не проверяет, как оно выглядит? Что-то в духе накодил и пусть там дальше тестируют?
Проводит конечно, но на то оно и первичное. То есть если бизнес логика работает и интерфейс не плывет — можно плыть дальше. А после сборки на прод (имеется в виду сборка которая после тестирования пойдет на прод, а не то, что тестируют в проде) — уже тестировщики отлавливают все баги.
Пока проблем связанных с переходом на hq не было, было один раз, что проект работал с hq, но не собирался вообще с парселем. Решилось конфигурацией парселя, но я не могу сказать в чем там была проблема. Как-то он не так понимал зависимости от rxjs что-ли. В целом не могу сказать, что это была проблема hq, скорее либо rxjs либо parcel.
Пока проблем связанных с переходом на hq не было, было один раз, что проект работал с hq, но не собирался вообще с парселем. Решилось конфигурацией парселя, но я не могу сказать в чем там была проблема. Как-то он не так понимал зависимости от rxjs что-ли. В целом не могу сказать, что это была проблема hq, скорее либо rxjs либо parcel.
НЛО прилетело и опубликовало эту надпись здесь
Для разработки, там так и написано =) И еще для быстрых экспериментов, для комфортного дебага, для того, чтобы не думать об этом вот всем, а просто писать бизнес логику.
НЛО прилетело и опубликовало эту надпись здесь
Да, все так, все равно прийдется настраивать систему сборки для прода, просто собирать постоянно не прийдется. Это сильно помогает дебажить.
Ну я бы не сказал, что прям быстрые эксперименты с вот тем вот всем, что выше названо, да и сами посмотрите сколько всего и все разное, а тут один инструмент. Вебпак конфигурировать надо всегда, как минимум инпут/аутпут. Возможность не бандлить иногда многого стоит.
Я ни к чему не призываю, просто делюсь личными впечатлениями, нам зашло.
Ну я бы не сказал, что прям быстрые эксперименты с вот тем вот всем, что выше названо, да и сами посмотрите сколько всего и все разное, а тут один инструмент. Вебпак конфигурировать надо всегда, как минимум инпут/аутпут. Возможность не бандлить иногда многого стоит.
Я ни к чему не призываю, просто делюсь личными впечатлениями, нам зашло.
НЛО прилетело и опубликовало эту надпись здесь
Я имел в виду бандлы. Один здоровый жс даже с сорс мапами это довольно не приятно для дебага. У меня лично глаз начинает дергаться, когда ставишь брейк поинт на строку, а он прыгает куда-то вниз на 5 строк вниз вообще из функции. Ну и теперь прямо в браузере видно что загружается на страницу, не нужна куча плагинов для анализа бандлов.
Веб пак, это все равно конфигурация, но да, это не сложно, но все-таки сложнее чем просто одна команда без параметров в консоли. Тут скорее вопрос восприятия. Раньше мы просто запускали питоновский стандартный статический сервак и начинали что-то делать, теперь — куча сложностей. Для меня hq — это тот самый статический сервак который просто немного умнее стандартного.
Веб пак, это все равно конфигурация, но да, это не сложно, но все-таки сложнее чем просто одна команда без параметров в консоли. Тут скорее вопрос восприятия. Раньше мы просто запускали питоновский стандартный статический сервак и начинали что-то делать, теперь — куча сложностей. Для меня hq — это тот самый статический сервак который просто немного умнее стандартного.
Чет я не совсем понял хейта по поводу бандлов. Какие-то надуманные проблемы с соурсмапами. Тот же вебпак эмулирует файловую структуру проекта через соурсмапы, так что к каждому отдельному модулю будет доступ ( даже к node_modules ) + именно для разработки есть dev-server. Ну и конфигурация: по сути своей один раз настроил и используй во всех проектах. Куча же всяких boilerplate-ов есть.
А тут: для разработки один инструмент, для прода другой. Давайте еще для тестирования придумаем что-нибудь
Ну так а почему нет, разные инструменты заточенные для разных нужд.
С сорсмапами проблема весьма реальна, брекпоинты прыгают, если не повезет и в модуле который делает и собирает другая команда будут проблемы — то в зависимости от их конфигурации можно получить вообще не приятный опыт (особенно с create-react-app) и то, что вы вам браузер отображает структуру проекта дебагу не сильно поможет. Плюс нужно еще разбираться, что у вас в бандл входит и почему он такой здоровый вырос. Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
С сорсмапами проблема весьма реальна, брекпоинты прыгают, если не повезет и в модуле который делает и собирает другая команда будут проблемы — то в зависимости от их конфигурации можно получить вообще не приятный опыт (особенно с create-react-app) и то, что вы вам браузер отображает структуру проекта дебагу не сильно поможет. Плюс нужно еще разбираться, что у вас в бандл входит и почему он такой здоровый вырос. Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Но ведь hq тоже не подойдет для больших проектов
It might help to serve small projects with very little dependencies
Почему? Мы как раз его для большого проекта используем и он дает хороший прирост в скорости разработки. Цитата вырвана из контекста про продашн решение, я бы действительно не пихал его в прод если у проекта много зависимостей, да и в принципе. А вот для разработки — самое оно.
Но вот к примеру у вас огромный проект весит 10 Мб, если в случае с бандлом при малейшем изменении браузер будет грузить все 10 Мб, то hq загрузит только то, что реально поменялось, что гораздо быстрее.
10МБ это конечно дофига, но нa локалхосте они загрузятся довольно быстро.
А если уже используется какой-нибудь фрэймворк, например vuе, созданный через vue-cli, можно ли быстро перейти на hq, или это не тот случай?
А если уже используется какой-нибудь фрэймворк, например vuе, созданный через vue-cli, можно ли быстро перейти на hq, или это не тот случай?
Я не эксперт по вью, но думаю можно просто попробовать запустить hq в корне проекта и в теории должно заработать. При этом для сборки на продакшн у вас все еще останется npm run build
Если что-то не работает — не стесняйтесь, пишите баги на гитхаб, разработчики будут очень благодарны.
Если что-то не работает — не стесняйтесь, пишите баги на гитхаб, разработчики будут очень благодарны.
Я не эксперт по вью, но думаю можно просто попробовать запустить hq в корне проекта и в теории должно заработать.
Например там все компоненты будут лежать в файлах .vue — их просто так браузеру не отдашь (как jsx), надо сначала их «собирать». Похоже что hq такие ситуации не покрывает?
И любопытно, какой фронтэнд фрэймворк вы у себя используете?
В новой версии добавлена поддержка .vue файлов. Пробуйте если интересно и оставляйте фидбек на гитхабе.
Знания устаревают еще не успев закрепиться. Конечно, все это очевидный результат быстрого развития и роста, но это неизбежно добавляет сложности веб разработчикам и увеличивает порог входа в профессию.
Это наглая ложь. Ты в вебе не разбираешься раз такое пишешь. Есть устоявшийся фреймворк который подходит под 100% задач это React, которому 5 лет. Ангуляр и вуе используют единицы, вебпаком и того меньше, веб пак по большому счету и ненужен, он создан для удобства и можно спокойно без него обходится и создавать сайты.
Встречайте hq — специализированный сервер для разработки веб приложений. hq — это статический сервер на стероидах, который понимает все то, что обычному серверу не по зубам. Хотите последнюю фишку из стандарта javascript, но ваш браузер ее еще не поддерживает? — пожалуйста!
Зашел на сайт проекта, а там:
This is development website and it seems like your browser is not supported
Try to install modern web browser and come back.
Столько возгласов, а сайт проекта не отображается в последней версии firefox, в которой даже ES6 модули уже сто лет как можно использовать. Как они умудрились так сделать? Смешно.
Большое спасибо за замечание. Я думаю проблема не в фаерфоксе, в нем все работает, а скорей всего GPU на линукс не хочет что-то рендерить и кидает ошибку. Сайт хостится на гитхабе, а не на hq, так что это тот самый случай когда сапожник без сапог.
Если вам не сложно, могли бы вы сообщение об ошибке из консоли зарепортить на гитхабе или кинуть в личку.
Если вам не сложно, могли бы вы сообщение об ошибке из консоли зарепортить на гитхабе или кинуть в личку.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Сделаем веб снова великим