Комментарии 27
А если серьёзно то мне хочется плакать от того как развивается современный веб.
можете раскрыть свои переживания?
Я, конечно, не Aquahawk, но просто разработчик, который большую часть времени занимается бэкендом и системными штуками.
Иногда для разных pet project возникает необходимость сделать веб-интерфейс к чему-то.
И вот я, будучи не совсем глупым человеком, лезу в гугл и ищу в сторону modern web development.
Что нахожу:
- Туториалы для новичков "как запустить create-react-app", "установить npm/node/tsc/yeoman/leftpad/etc", в которых говорится "сделайте npm install X", пишется hello world в шаблоне, всё.
- Чем Vue/Angular лучше React, почему jQuery отжил своё, а на backbone правильные пацаны не должны писать.
- Как прикрутить модную библиотеку для REST/реактивного программирования/и т.д. к React/Angular/Vue.
Как только начинаешь производить системный подход, углубляться дальше "npm install/run", читать доки к webpack, tsc, бабелам всяким, понимаешь, что разобраться, КАК всё это работает возможно только за целую вечность.
И в сухом остатке выходит, что современный веб — это либо "просто запустить, но магия под капотом", либо "ничего непонятно, и когда будет понятно — не известно".
Это всё, безусловно, ИМХО, и чисто впечатление от человека, который занимается разработкой веб-интерфейсов достаточно ситуативно.
TL;DR Инструментарий для разработчика не должен становиться проблемой на долгие часы изучения.
В других языках не так что ли? Все эти компиляторы, SDK конфигурируются одной кнопкой, что даже ребенок может справиться с этим?
Предугадать абсолютно все желания пользователей нельзя, поэтому простые проекты да, делают без огромных конфигов, но это не значит, что должны быть только "простые" проекты. Проекты бывают разные, в том числе и сложные, которые в любом случае требуют доп настроек
Что касательно всяких там вебпаков и бабелей. Эти инструменты слишком универсальны, чтобы быть простыми. Проектов много, они разные, у всех разные потребности. Да и без них пока никак. Браузеры только сейчас научились import, а есть ещё большой процент старых и мобильных браузеров, которые до сей поры про let и const не знают.
Если говорить о разнообразии, то это же здорово! Вспомнить только про npm и yarn. Пока второй не появился, первый не особо стремился оптимизировать скорость загрузки пакетов. Конкуренция это всегда хорошо.
Я недавно попробовал заюзать родной нодовский import (.mjs) и столкнулся с тем что он сделан несовместимым с остальным миром. То есть из .mjs модуля можно импортировать только другой .mjs модуль.
То есть теперь альтернатива — или пропускать весь код для нода через бабел — или начать целенаправленно и поседовательно юзать .mjs.
Если к этому добавить что есть запрос (а в webpack он уже реализован) на динамический import (на нем и основан собственно code splitting) то ситуация с импортами выглядит немного запутанно.
И вот я, будучи не совсем глупым человеком, лезу в гугл и ищу в сторону modern web development.
В этот момент вам нужно понять, что вам нужно. Если вы хотите изучить гибкие мощные современные инструменты, то они по определению будут сложные, с наскока за полчаса их не освоить.
Но если вам нужно написать немного кода для браузера, не обязательно лезть в "modern web development". Можно по старинке руками подключить скрипты на страницу. Появление Webpack никак этого не отменяет.
1. При первом обращение к любой (не только к /) странице приложения React грузился весь необходимый для прорисовки страницы код в макимум двух файлах
2. При переходе на другие страницы догружался недостающий код.
Из коробки пока что у меня получется больше файлов при первой загрузке. Возможно что я еще не нашел тот вариант который сделает это для меня без конфигурирования.
Возможно есть в npm зависимость от deprecated babel?
Пошли на поводу у parceljs. Личное имхо, подход при котором напрочь забивают на обратную совместимость (напишите пожалуйста все плагины еще раз для 4 версии) разочаровывает.
Одна из полезных и сравнительно новых фич webpack — code splitting, перенесена в новой версии из плагинов в основную конфигурацию.
В оригинальной документации по Webpack куда вы даете ссылку, как был этот плагин так и остался. Недавно собирал достаточно большое приложение и так же использовал его с 4-ой версией. Ума не приложу где вы тут проблему нашли. В документации же все написано, что и как делать…
Уважаемый автор:
1) Ни чего не поменялось и ни чего ни куда не переехало. Все осталось как раньше.
2) В новый webpack заехал плагин который поставляется из коробки и этот плагин называется SplitChunksPlugin.
3) Появился он в ответ на некоторые проблемы которые были у CommonChunksPlugin.
4) Если вы хотите его использовать, подозреваю у вас есть какие то проблемы со старым плагином. Если же их нет и вы чего то не понимаете, не создавайте их себе, берите то что есть и решайте задачу.
5) Если все же хочется его использовать, разберитесь как работает CommonChunksPlugin и как работает SplitChunksPlugin. Самое важное здесь то, что они работают по разному. Если вам реально нужен этот плагин, даже за неимением документации всегда можно прочесть код. Понять как он работает не составит большого труда если вы читали документацию по webpack и понимаете концепции в нем заложены:
github.com/webpack/webpack/blob/master/lib/optimize/SplitChunksPlugin.js
В первом случае используется новы динамический импорт во втором — статический require
Webpack 4 и code splitting