Во-первых стоит наверное что-то показать пользователю, мол сорян, ошибка на сервере, попробуй позже.
А во-вторых стоит консоль лог спрятать под условие `if (isDevelopment) {}`. Хотя вебпак всё-равно удалит их для прода при правильной настройке.
Спасибо за ответ. Но не слишком ли много они ставят на бабел? По большому счёту уже сейчас можно начинать отправлять es6 модули. Тогда некоторые вопросы всё ещё актуальны.
На самом деле я не пытаюсь разразить жаркую дискуссию, и даже тот факт, что моя компания инвестирует в вебпак тут не при чём :) Просто мыслю вслух могу ли я в своём проекте перейти на парсель. Ответ: пока нет. Слишком много надо будет кастомного допиливать пока. Обязательно буду следить за развитием проекта.
В целом для простых проектов я думаю, что парсель — долгожданный продукт. Я правда ещё не пробовал, но если бы я захотел сейчас переходить на парсель с вебпака, то сразу возникает несколько вопросов:
1. Работаю с vue компонентами, парсель пока не поддерживает. Впрочем должно быть скоро имплементировано (https://github.com/parcel-bundler/parcel/issues/5). Но вопрос больше глобальный, как работать с фреймворком «х», если он требует дополнительного парсинга? И если начать поддерживать все фреймворки, то останется ли он таким быстрым? Или же нужно будет опять-таки конфигурировать?
2. Я не увидел из доументации, что там с хэшами для js и css файлов? Добавляет ли он их автоматически. Зачастую бывает необходимо выгрузить хэши в json, чтобы потом бэкенд мог из использовать.
3. Можно ли использовать алиасы и дополнительные плюшки, как то `webpack.DefinePlugin`.
4. Уверен, что для определённых юзкейсов размер сборки будет не оптимальным. Как дебажить и оптимизировать (a-la `webpack-bundle-analyzer`)?
Я не замерял, поскольку пробовал разные подходы в разные временные промежутки, когда и не думал о статье. Сейчас жалко времени возобновлять тесты, чтобы получить данные с весьма сомнительным применением. Проблема я думаю была не с xhyve, как видно из этого тикета.
> Это особенность докера вообще
По этому пункту вы правы.
> что речь идет о volumes
Да, речь идёт о mounted volumes, упоминалось в статье.
> то я могу (с трудом, но могу)
В данной статье речь идёт только о среде разработки. На боевых машинах я думаю никому не придёт в голову использовать динги.
Я уверен, что приведённое решение поставленных задач — не единственное и не идеальное. Но оно достаточно простое, подтвердило свою работоспособность и оказалось весьма быстрым, а значит имеет место на существование.
По поводу одной виртуальной машины — я считаю, что существует такой юзкейс, когда это может стать недостатком. То, что это проблема — я не писал. В любом случае — это особенность, которая в «плюсы» точно не попадает.
Про «ужасно медленный». Никогда не слышал, чтобы замеряли производительность среды разработки. Мой фактор таков: если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно (при том, что на вагранте, который использовали до этого, происходит за 3).
Ну и про порт. Именно на уровне прокси это и решено. Надстройка главным образом добавляет NFS. В комплекте идёт прокси — зачем же изобретать свой велосипед, когда тут всё готово и динамически подстраивается под настройки контейнеров (это я про конфигурацию nginx внутри прокси контейнера).
Подобные комментарии позволяют задуматься немного глубже об обсуждаемых инструментах. Ради этого мы и читаем/пишем комментарии, не так ли? А комментарий мой относится больше не к самому фреймворку. Он больше филосовский.
Теперь по пунктам.
1. Я бы не назвал серверный рендеринг — новым уровнем абстракции. Это достаточно непростая задача, которая даст разработчику много новых скилов.
2. Можно и так. Не вижу тут особых проблем. Но скрывать конфиг в зависимостях — для меня это всё же странно.
3. Согласен. А теперь представьте у вас новый баг. Где проблема — во Вью, в Наксте или быть может в Лодэше?
4. А вот тут не согласен. Оставим фотошоп в стороне и поговорим про зависимости. Если зависимости не увеличивают сорс код, это вовсе не означает, что их не нужно контролировать. Все помнят историю про left-pad?
Вопрос: только у меня ощущение, что с ростом зависимостей я становлюсь более уязвим и теряю контроль над проектом? Понятно, что многих зависимостей не избежать, но в целом я считаю, что нужно держаться курса по их уменьшению.
Для каждой отдельной задачи нужно выбирать наиболее подходящий инструмент. Накст — это однозначно отличное решение для определённого типа задач.
Вопрос, на который я пытаюсь для себя ответить — хорошо ли это для общего образования/становления новых разработчиков? С одной стороны — конечно. Это вдохновляет и подталкивает на новые открытия. А с другой стороны не вырастит ли это более, хм, скажем «ленивых» разработчиков, и таким образом не ухудшит ли это общий уровень среди разработчиков в целом? Разумеется никто не заставляет использовать фреймворк, без изучения основ программирования, но именно так и происходит во многих случаях, которые я вижу в последнее время.
В скором времени я планирую пересечься с Эваном Ю на конференции и задать ему этот вопрос. Понятно, что можно и написать, но раз уж выпадает возможность пообщаться лично, то почему бы и нет.
Решил я попробовать этот Накст, тем более сам Эван Ю его очень советует. Установив его и начав разбираться, я понял, что мне нужно изучить ещё один уровень абстракции. Да в нём даже исходный вебпак конфиг зарыт в зависимостях. И тут я подумал — а куда мы вообще двигаемся? Теперь не зная и не понимая самого языка можно написать приложение, но стоит копнуть чуть глубже и что? В итоге начинаешь изучать как написан инструмент (а ещё хуже «бороться с ним»), вместо того, чтобы решать реальные задачи.
Я когда-то давно ставил под вопрос использование самих фреймворков. Теперь же, когда они достигли хорошей производительности и удобных интерфейсов, этот вопрос отпал. Но использовать двойную абстракцию с тонной зависимостей — спасибо, не надо. Дальше видимо надо будет рисовать в фотошопе, а тебе раз и приложение готовое. Но где-то я уже это видел…
А во-вторых стоит консоль лог спрятать под условие `if (isDevelopment) {}`. Хотя вебпак всё-равно удалит их для прода при правильной настройке.
На самом деле я не пытаюсь разразить жаркую дискуссию, и даже тот факт, что моя компания инвестирует в вебпак тут не при чём :) Просто мыслю вслух могу ли я в своём проекте перейти на парсель. Ответ: пока нет. Слишком много надо будет кастомного допиливать пока. Обязательно буду следить за развитием проекта.
1. Работаю с vue компонентами, парсель пока не поддерживает. Впрочем должно быть скоро имплементировано (https://github.com/parcel-bundler/parcel/issues/5). Но вопрос больше глобальный, как работать с фреймворком «х», если он требует дополнительного парсинга? И если начать поддерживать все фреймворки, то останется ли он таким быстрым? Или же нужно будет опять-таки конфигурировать?
2. Я не увидел из доументации, что там с хэшами для js и css файлов? Добавляет ли он их автоматически. Зачастую бывает необходимо выгрузить хэши в json, чтобы потом бэкенд мог из использовать.
3. Можно ли использовать алиасы и дополнительные плюшки, как то `webpack.DefinePlugin`.
4. Уверен, что для определённых юзкейсов размер сборки будет не оптимальным. Как дебажить и оптимизировать (a-la `webpack-bundle-analyzer`)?
По этому пункту вы правы.
> что речь идет о volumes
Да, речь идёт о mounted volumes, упоминалось в статье.
> то я могу (с трудом, но могу)
В данной статье речь идёт только о среде разработки. На боевых машинах я думаю никому не придёт в голову использовать динги.
Я уверен, что приведённое решение поставленных задач — не единственное и не идеальное. Но оно достаточно простое, подтвердило свою работоспособность и оказалось весьма быстрым, а значит имеет место на существование.
Про «ужасно медленный». Никогда не слышал, чтобы замеряли производительность среды разработки. Мой фактор таков: если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно (при том, что на вагранте, который использовали до этого, происходит за 3).
Ну и про порт. Именно на уровне прокси это и решено. Надстройка главным образом добавляет NFS. В комплекте идёт прокси — зачем же изобретать свой велосипед, когда тут всё готово и динамически подстраивается под настройки контейнеров (это я про конфигурацию nginx внутри прокси контейнера).
Теперь по пунктам.
1. Я бы не назвал серверный рендеринг — новым уровнем абстракции. Это достаточно непростая задача, которая даст разработчику много новых скилов.
2. Можно и так. Не вижу тут особых проблем. Но скрывать конфиг в зависимостях — для меня это всё же странно.
3. Согласен. А теперь представьте у вас новый баг. Где проблема — во Вью, в Наксте или быть может в Лодэше?
4. А вот тут не согласен. Оставим фотошоп в стороне и поговорим про зависимости. Если зависимости не увеличивают сорс код, это вовсе не означает, что их не нужно контролировать. Все помнят историю про left-pad?
Вопрос: только у меня ощущение, что с ростом зависимостей я становлюсь более уязвим и теряю контроль над проектом? Понятно, что многих зависимостей не избежать, но в целом я считаю, что нужно держаться курса по их уменьшению.
Для каждой отдельной задачи нужно выбирать наиболее подходящий инструмент. Накст — это однозначно отличное решение для определённого типа задач.
Вопрос, на который я пытаюсь для себя ответить — хорошо ли это для общего образования/становления новых разработчиков? С одной стороны — конечно. Это вдохновляет и подталкивает на новые открытия. А с другой стороны не вырастит ли это более, хм, скажем «ленивых» разработчиков, и таким образом не ухудшит ли это общий уровень среди разработчиков в целом? Разумеется никто не заставляет использовать фреймворк, без изучения основ программирования, но именно так и происходит во многих случаях, которые я вижу в последнее время.
Я когда-то давно ставил под вопрос использование самих фреймворков. Теперь же, когда они достигли хорошей производительности и удобных интерфейсов, этот вопрос отпал. Но использовать двойную абстракцию с тонной зависимостей — спасибо, не надо. Дальше видимо надо будет рисовать в фотошопе, а тебе раз и приложение готовое. Но где-то я уже это видел…
rm -rf nuxtjs-test