Я не эксперт по вью, но думаю можно просто попробовать запустить hq в корне проекта и в теории должно заработать. При этом для сборки на продакшн у вас все еще останется npm run build
Если что-то не работает — не стесняйтесь, пишите баги на гитхаб, разработчики будут очень благодарны.
Для борьбы с минусами пока есть кешь, потом планируется его еще прокачать да и вообще еще дополнительно повысить скорость. В плане неочевидности передам, чтоб хауту было понятнее, пока по предварительным отзывам в среднем все более-менее просто работает с минимальными модификациями.
Спасибо за конструктивный отзыв. Статья обзорная для того чтобы очертить проблему, инструменты которые упомянуты критикуются в контексте разработки, для продакшена они как раз подходят очень даже хорошо, о чем тоже упоминается. Думаю будут и другие статьи где будет больше конкретики.
Не захардкожено, путь ищется в пакедж жсон, срц или корне.
Вы видимо разработчик паре ляжет. Не вижу где вы там увидели такое заявление. Объяснялась разница между проектами и проблемы разработки. Мы парселем пользуемся. Насколько я знаю разработчики проекта тоже. В любом случае никакого негатива не было. Объяснялась разница между подходами. Я лично думаю, что Парасельскими как раз хорошо дополняет тулзу когда речь идёт о продакшене, но честно не хочется выслушивать все ваши оскорбления, я сочувствующий, но скорее переводчик, мне это вообще не нужно.
Но вот к примеру у вас огромный проект весит 10 Мб, если в случае с бандлом при малейшем изменении браузер будет грузить все 10 Мб, то hq загрузит только то, что реально поменялось, что гораздо быстрее.
Почему? Мы как раз его для большого проекта используем и он дает хороший прирост в скорости разработки. Цитата вырвана из контекста про продашн решение, я бы действительно не пихал его в прод если у проекта много зависимостей, да и в принципе. А вот для разработки — самое оно.
Ну так а почему нет, разные инструменты заточенные для разных нужд.
С сорсмапами проблема весьма реальна, брекпоинты прыгают, если не повезет и в модуле который делает и собирает другая команда будут проблемы — то в зависимости от их конфигурации можно получить вообще не приятный опыт (особенно с create-react-app) и то, что вы вам браузер отображает структуру проекта дебагу не сильно поможет. Плюс нужно еще разбираться, что у вас в бандл входит и почему он такой здоровый вырос. Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Я имел в виду бандлы. Один здоровый жс даже с сорс мапами это довольно не приятно для дебага. У меня лично глаз начинает дергаться, когда ставишь брейк поинт на строку, а он прыгает куда-то вниз на 5 строк вниз вообще из функции. Ну и теперь прямо в браузере видно что загружается на страницу, не нужна куча плагинов для анализа бандлов.
Веб пак, это все равно конфигурация, но да, это не сложно, но все-таки сложнее чем просто одна команда без параметров в консоли. Тут скорее вопрос восприятия. Раньше мы просто запускали питоновский стандартный статический сервак и начинали что-то делать, теперь — куча сложностей. Для меня hq — это тот самый статический сервак который просто немного умнее стандартного.
Да, все так, все равно прийдется настраивать систему сборки для прода, просто собирать постоянно не прийдется. Это сильно помогает дебажить.
Ну я бы не сказал, что прям быстрые эксперименты с вот тем вот всем, что выше названо, да и сами посмотрите сколько всего и все разное, а тут один инструмент. Вебпак конфигурировать надо всегда, как минимум инпут/аутпут. Возможность не бандлить иногда многого стоит.
Я ни к чему не призываю, просто делюсь личными впечатлениями, нам зашло.
Проводит конечно, но на то оно и первичное. То есть если бизнес логика работает и интерфейс не плывет — можно плыть дальше. А после сборки на прод (имеется в виду сборка которая после тестирования пойдет на прод, а не то, что тестируют в проде) — уже тестировщики отлавливают все баги.
Пока проблем связанных с переходом на hq не было, было один раз, что проект работал с hq, но не собирался вообще с парселем. Решилось конфигурацией парселя, но я не могу сказать в чем там была проблема. Как-то он не так понимал зависимости от rxjs что-ли. В целом не могу сказать, что это была проблема hq, скорее либо rxjs либо parcel.
Для разработки, там так и написано =) И еще для быстрых экспериментов, для комфортного дебага, для того, чтобы не думать об этом вот всем, а просто писать бизнес логику.
Нет, он делает не то же самое. Он просто раздает вам бандл который делает парсель вот и все, и он не умеет работать с разными фреймворками типа ангулара, так что разница есть. Парсель — это бандлер, а hq — это сервер для разработки. Опыт дебага отличается кардинально.
Ну для того тестирование в разных браузерах и проводится, это как бы задача совершенно отдельная от задачи разработки. То что вы будете его каждый раз паковать никак вас не спасет от того, что в условном Эдже оно поломается. Так что у нас мухи отдельно, а котлеты отдельно.
parcel — бандлит, next — это скорее фреймворк, create-react-app — работает только с реактом. hq работает вообще со всем и не бандлит, что делает разработку и отлов ошибок гораздо комфортнее.
Я это представляю себе так — пусть у нас есть идеальный мир в котором все пишут только по стандарту, все библиотеки имеют формат ЕСМ и браузеры поддерживают все то, что пишут разработчики. hq — это такой себе полифил который этот мир немного приближает. То есть он дает возможность представить, что все так и есть уже сейчас.
Тут не хватает картинки про стандарты =) Но по моему в данном случае это не совсем справедливо. У нас сейчас только hq и parcel и мы в общем-то ничего не настраиваем (ну немножко парсель). То есть теперь есть возможность сконцентрироваться на бизнес логике и абстрагироваться от сложностей сборки и вообще понимания всего этого зоопарка с бабелем, плагинами и стандартами, все как в старые добрые =)
Я всего лишь скромный переводчик. Но в данном случае я перевел статью потому, что мы проект пробовали и он нам понравился. Из нашего опыта — переезда не было так как это скорее инструмент для разработки и мы просто начали им пользоваться и стало реально удобнее (это по сути сервер статики так что сложностей в общем-то нет). Это в принципе времени не заняло, решили, что штука интересная и нужно попробовать. Установили и начали пользоваться и она просто сразу заработала, стало удобнее дебажить. Для продакшена там что-то тоже готовится так что следим за обновлениями, но пока мы пользуемся парселем.
Разница в том, что Object.observe можно было вешать на любой объект (например результат сторонней библиотеки) и при этом слушать события на этом объекте, а Proxy — это обертка которая просто передает вызовы на оригинальный объект. Таким образом если сторонняя библиотека меняет оригинальный объект — Object.observe об этом сообщит, а Proxy сможет сообщить лишь об изменениях над proxy объектом.
Если что-то не работает — не стесняйтесь, пишите баги на гитхаб, разработчики будут очень благодарны.
Спасибо за конструктивный отзыв. Статья обзорная для того чтобы очертить проблему, инструменты которые упомянуты критикуются в контексте разработки, для продакшена они как раз подходят очень даже хорошо, о чем тоже упоминается. Думаю будут и другие статьи где будет больше конкретики.
Не захардкожено, путь ищется в пакедж жсон, срц или корне.
Вы видимо разработчик паре ляжет. Не вижу где вы там увидели такое заявление. Объяснялась разница между проектами и проблемы разработки. Мы парселем пользуемся. Насколько я знаю разработчики проекта тоже. В любом случае никакого негатива не было. Объяснялась разница между подходами. Я лично думаю, что Парасельскими как раз хорошо дополняет тулзу когда речь идёт о продакшене, но честно не хочется выслушивать все ваши оскорбления, я сочувствующий, но скорее переводчик, мне это вообще не нужно.
С сорсмапами проблема весьма реальна, брекпоинты прыгают, если не повезет и в модуле который делает и собирает другая команда будут проблемы — то в зависимости от их конфигурации можно получить вообще не приятный опыт (особенно с create-react-app) и то, что вы вам браузер отображает структуру проекта дебагу не сильно поможет. Плюс нужно еще разбираться, что у вас в бандл входит и почему он такой здоровый вырос. Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Веб пак, это все равно конфигурация, но да, это не сложно, но все-таки сложнее чем просто одна команда без параметров в консоли. Тут скорее вопрос восприятия. Раньше мы просто запускали питоновский стандартный статический сервак и начинали что-то делать, теперь — куча сложностей. Для меня hq — это тот самый статический сервак который просто немного умнее стандартного.
Ну я бы не сказал, что прям быстрые эксперименты с вот тем вот всем, что выше названо, да и сами посмотрите сколько всего и все разное, а тут один инструмент. Вебпак конфигурировать надо всегда, как минимум инпут/аутпут. Возможность не бандлить иногда многого стоит.
Я ни к чему не призываю, просто делюсь личными впечатлениями, нам зашло.
Пока проблем связанных с переходом на hq не было, было один раз, что проект работал с hq, но не собирался вообще с парселем. Решилось конфигурацией парселя, но я не могу сказать в чем там была проблема. Как-то он не так понимал зависимости от rxjs что-ли. В целом не могу сказать, что это была проблема hq, скорее либо rxjs либо parcel.
У нас работало из коробки структура проекта такая:
src/index.html
src/index.js
src/index.css
Пробовал в корень все переместить — тоже работает.
Ну проект новый, думаю поправят детские баги по немногу, нам в целом зашло.
Я это представляю себе так — пусть у нас есть идеальный мир в котором все пишут только по стандарту, все библиотеки имеют формат ЕСМ и браузеры поддерживают все то, что пишут разработчики. hq — это такой себе полифил который этот мир немного приближает. То есть он дает возможность представить, что все так и есть уже сейчас.