Комментарии 88
Спасибо, как раз на днях занимался подобным вопросом. Ранее читал, что сборка webpack-ом стилей, html и т.п. медленнее чем галпом. Вы не пробовали сравнить быстродействие? У меня есть отдельно настроенная сборка галп+вебпак с шаблонизатором jade. Так там при большом количестве jade миксинов пересборка длится ощутимое время. Если же webpack 4 покажет лучшее быстродействие — стоит на него в таком случае переезжать.
gulp быстрее, однако webpack это несколько иной инструмент. Webpack собирает бандлы с учётом зависимостей и умеет tree-snaking. То есть если типичный сценарий с gulp собираем все стили в одном файлы, скрипты в другом. С вебпаком, если у вас есть некий компонент, которому требуют скрипты и стили, а также имеет зависимости, то вы все стили и зависимости подключаете непосредственно в скрипте этого компонента. Поэтому если вдруг вам компонент больше не нужен будет, и вы перестанете его использовать, он у вас перестанет попадать в бандл.
А использовались ли какие-нибудь фичи нового webpack? А то по названию как будто упор на 4 версию идёт. А с виду тот же третий.
из новых фич: сборка с использованием флага --mode
Как уже отметили, режимы
--mode development и --mode production. Также отсутствие необходимости указывать паку dist в путях в файле webpack.config.js. А также отсутствие некоторых плагинов (это скорее антифича). Например, jshint пока прикрутить нельзя, так как jshint-loader не работает с новым Webpack.eplaksin, Harrix, спасибо.
Тут недавно статья была про новый вебпак, и как там все здорово будет. А по сути изменения получаются скорее косметические. Я то думал что будет какой-то режим сборки из коробки, без возни с конфигами, но его нет. И в результате, по моим личным ощущениям, получается, что использовать webpack что 3-ий, что 4-ый, для сбора статического сайта это все таки небольшой оверхед.
Тут недавно статья была про новый вебпак, и как там все здорово будет. А по сути изменения получаются скорее косметические. Я то думал что будет какой-то режим сборки из коробки, без возни с конфигами, но его нет. И в результате, по моим личным ощущениям, получается, что использовать webpack что 3-ий, что 4-ый, для сбора статического сайта это все таки небольшой оверхед.
Режим для сборки из коробки там есть. Но как показывает практика, всегда будут появляться свои хотелки, которые потребуют написание своих конфигов.
Разумеется, для полноценного статического сайта куда лучше подойдет специализированный инструмент, как тот же Jekyll. Но и там те же css и js надо будет кем-то собирать. И тогда появляется связка Jekyll + webpack или Jekyll + gulp. Вот и решил для простых вариантов обойтись одним инструментом.
Разумеется, для полноценного статического сайта куда лучше подойдет специализированный инструмент, как тот же Jekyll. Но и там те же css и js надо будет кем-то собирать. И тогда появляется связка Jekyll + webpack или Jekyll + gulp. Вот и решил для простых вариантов обойтись одним инструментом.
`new CleanWebpackPlugin(['dist', 'build']),`
зачем build здесь, ведь эта папка не фигурирует нигде. Потом, столько мусора, в bundle.js есть пути до scss. Зачем…
зачем build здесь, ведь эта папка не фигурирует нигде. Потом, столько мусора, в bundle.js есть пути до scss. Зачем…
Но что печалит. Если при сборке js файла при подключении js файла Bootstrap библиотеки Webpack знает, где находятся нужные файлы, то при подключении стилей нужно указывать путь к папке в node_modules.
Можно писать так:
@import "~bootstrap/scss/bootstrap";по крайней мере node_modules не надо писать. Путь внутри пакета конечно придётся писать, т. к. в package.json пакета нет ключа "main" для стилей.
После прочтения ряда статей (например, этой) решил перейти на современный подход с использованием Node.js при написании простых сайтов с подхода «динозавров».
Это сарказм?? Перед вами бизнес (вы сами) поставил простейшую задачу:
Сайт представляет собой простой набор HTML-страниц со своим CSS стилями и файлом JavaScript
Ваш репозиторий с установленными зависимостями весит 177 MB..
Война и Мир в HTML будет весить не более 20 Мб. 2300 зависимостей!
Вот дерево зависимостей которые вы для этого подтянули, оно не умещается в комментарий:
gist.github.com/DexterHD/9ed32eedf9412e7c1fdfaf6a1c458fae
И это все чтобы создать набор из HTML страниц с несколькими CSS и JS??? Серьезно Современный подход??
Скомпилированные js, css весят 155 KB и 118 KB соответственно.
Некомпилированные js, scss, шаблоны — несколько килобайт.
Все остальное — использованные библиотеки, плюс «компиляторы» и тп. Считать их размер в размер репозитория некорректно.
К примеру, в .Net вы тоже считаете вес всего фреймворка, .Net компиляторов — это же тоже зависимости? Затем зависимости следующего уровня — API операционной системы, в общем операционную систему, компилятор в машинные команды, ещё кучи библиотек.
Некомпилированные js, scss, шаблоны — несколько килобайт.
Все остальное — использованные библиотеки, плюс «компиляторы» и тп. Считать их размер в размер репозитория некорректно.
К примеру, в .Net вы тоже считаете вес всего фреймворка, .Net компиляторов — это же тоже зависимости? Затем зависимости следующего уровня — API операционной системы, в общем операционную систему, компилятор в машинные команды, ещё кучи библиотек.
В реальности собирается чуть посложнее сайт, но да. Современный подход, к сожалению или к счастью, выглядит так. От количества файлов в node_modules у самого глаза на лоб лезут. А пока собирал проект по кусочкам — обматерил всех и вся. Но, представьте, что папки node_modules нет. И она заменена на обычное приложение, которое весит все те же 177 Мб и выполняет тоже самое. В этом случае такой жесткой критики не будет.
А по правде говоря меня очень даже устраивала определенное время Koala для решения задачи сборки CSS из SASS и минификации js файлов. Но потом появились хотелки, которые она уже не могла решать (та же шаблонизация HTML). Вот и появился повод разобраться в «современном подходе». Но я уверен, что в ближайшие годы многое изменится.
А по правде говоря меня очень даже устраивала определенное время Koala для решения задачи сборки CSS из SASS и минификации js файлов. Но потом появились хотелки, которые она уже не могла решать (та же шаблонизация HTML). Вот и появился повод разобраться в «современном подходе». Но я уверен, что в ближайшие годы многое изменится.
Современный подход, к сожалению или к счастью, выглядит такВы ошибаетесь. Подход сам по себе не может быть «современным» или «олдовым». Любой подход определяется выбором правильного инструмента для реализации. Вы выбрали современный инструмент, но это вовсе не значит, что этот инструмент обеспечил правильный подход и правильное/оптимальное решение вашей задачи.
Подход сам по себе не может быть «современным» или «олдовым».
Вы выбрали современный инструмент
Вы сами себе противоречите. Есть современные и есть олдовые подходы. А то, что современный подход является оптимальным решением — я этого нигде не говорил. Например, серьезный статический сайт, на подобии Jekyll не написать (хотя для таких задач я предпочту динамический сайт, но это тема другого холивара). А сам webpack мне очень многим не нравится. И я уверен, что на смену ему придет что-то другое.
Вы сами себе противоречите… А то, что современный подход является оптимальным решением — я этого нигде не говорил.Вроде нет противоречия. Поясню. Я исхожу от задачи, озвученной вами в статье. Задача решена, но плохо, хоть и современными методами.
Если бы ваша постановка задачи выглядела как-то так:
Задача (цель): Изучить современные технологии (webpack)
Способ решения: Собрать простой статический сайт с помощью webpack 4.
то можно было бы сказать, что задача решена хорошо.
Почему решение задачи плохое? И какое решение, на ваш взгляд, хорошее?
Почему решение задачи плохое?Как вы сами признали, оно не является оптимальным. Почти по всем параметрам — время на разработку, пара тысяч зависимостей (в курсе истории о том, что было, когда одна из зависимостей сломалась и пропала из репо?), дальнейшее сопровождение и т.д. и т.п. Иными словами — вы простейшую, можно сказать — тестовую задачу решали, создавая себе максимальные сложности.
Однако опять отмечу, что если вы все-таки решали другую задачу (самообучение), то задача решена хорошо.
К сожалению, сейчас повсеместная беда с постановкой задачи, как таковой. Люди путают цели со средствами их достижения.
И какое решение, на ваш взгляд, хорошее?
Понимаете, как штука… Думаю, что это риторический вопрос с вашей стороны, потому что во первых, в комментах уже писали как минимум о нескольких, во вторых, стараюсь не участвовать в религиозных спорах.
Ну как пример, вы пишите о подключаемых хедере и футере, что код шапки прописывать вручную в тысячах файлов — это ад…
Могу сказать, что технология SSI известна больше 20 лет, но наверняка нарвусь на обвинение в «подходе динозавра».
Мда… Ожидал нормальная аргументацию.
Вы часто говорите странные вещи. То говорите, что я ошибаюсь в том, что существуют современные и олдовые подходы, то потом сами говорите про современные инструменты и подходы динозавров. То теперь сравниваете плохое решение и не оптимальное. Это не одно и тоже!
По вашему любое решение с высоким порогом вхождения — это плохое решение?
Есть такой файл. Называется package-lock.json, который хранит подробную информацию о всех пакетах с конкретными номерами версий. Так что я всегда, пока существует npm, смогу получить свой набор пакетов конкретных версий. Но даже если что-то пропадет, то мне достаточно заархивировать папочку node_modules и вообще беспокоиться не о чем.
А если произойдет какой-то капец в пакетах с многомиллионными загрузками, то проблема будет решена очень быстро.
И вот опять. «Цель — конечный результат, на который преднамеренно направлен процесс». В постановке не описаны конкретные инструменты, но они там могли быть на законных основаниях.
Не надо сливаться. Мне нужен инструмент, который собирал бы HTML страницы, CSS собирал из SASS, Javascript собирал в один файл (желательно с поддержкой модулей), все это минифицировал, находил ошибки, шаблонизаторы HTML поддерживали условия (например, в шапке в меню можно было бы к пунктам меню ставить параметр active в зависимости от имени html страницы), желательно имелся быстрый способ обновления всех библиотек до последних версий и сборка на лету в статический(!) вариант, который мог бы работать локально. Предложите вариант.
Вроде бы насчитал три варианта, которые предлагали на замену. Один с сервером (не подходит под задачу создания статического сайта), один просто с блокнотом (так как я раньше так и делал, то вижу чем это плохо), один с использованием другого пакета из npm (этот вариант может быть даже очень хорошим), который обладает всеми теми же недостатками, которые вы приписали к моему варианту: высокий порог вхождения, зависимости и др.
Server Side Includes — зачем вы предлагаете инструмент динамического сайта для статического сайта? Вы это серьезно? Нужна будет динамика — я возьму php или другой язык, куда лучше подходящий, чем SSI. Прочитайте название статьи. Требуется инструмент создания статического(!) сайта!
Как вы сами признали, оно не является оптимальным.
Вы часто говорите странные вещи. То говорите, что я ошибаюсь в том, что существуют современные и олдовые подходы, то потом сами говорите про современные инструменты и подходы динозавров. То теперь сравниваете плохое решение и не оптимальное. Это не одно и тоже!
время на разработку
По вашему любое решение с высоким порогом вхождения — это плохое решение?
пара тысяч зависимостей (в курсе истории о том, что было, когда одна из зависимостей сломалась и пропала из репо?), дальнейшее сопровождение
Есть такой файл. Называется package-lock.json, который хранит подробную информацию о всех пакетах с конкретными номерами версий. Так что я всегда, пока существует npm, смогу получить свой набор пакетов конкретных версий. Но даже если что-то пропадет, то мне достаточно заархивировать папочку node_modules и вообще беспокоиться не о чем.
А если произойдет какой-то капец в пакетах с многомиллионными загрузками, то проблема будет решена очень быстро.
К сожалению, сейчас повсеместная беда с постановкой задачи, как таковой. Люди путают цели со средствами их достижения.
И вот опять. «Цель — конечный результат, на который преднамеренно направлен процесс». В постановке не описаны конкретные инструменты, но они там могли быть на законных основаниях.
в комментах уже писали как минимум о нескольких, во вторых, стараюсь не участвовать в религиозных спорах.
Не надо сливаться. Мне нужен инструмент, который собирал бы HTML страницы, CSS собирал из SASS, Javascript собирал в один файл (желательно с поддержкой модулей), все это минифицировал, находил ошибки, шаблонизаторы HTML поддерживали условия (например, в шапке в меню можно было бы к пунктам меню ставить параметр active в зависимости от имени html страницы), желательно имелся быстрый способ обновления всех библиотек до последних версий и сборка на лету в статический(!) вариант, который мог бы работать локально. Предложите вариант.
Вроде бы насчитал три варианта, которые предлагали на замену. Один с сервером (не подходит под задачу создания статического сайта), один просто с блокнотом (так как я раньше так и делал, то вижу чем это плохо), один с использованием другого пакета из npm (этот вариант может быть даже очень хорошим), который обладает всеми теми же недостатками, которые вы приписали к моему варианту: высокий порог вхождения, зависимости и др.
Могу сказать, что технология SSI известна больше 20 лет
Server Side Includes — зачем вы предлагаете инструмент динамического сайта для статического сайта? Вы это серьезно? Нужна будет динамика — я возьму php или другой язык, куда лучше подходящий, чем SSI. Прочитайте название статьи. Требуется инструмент создания статического(!) сайта!
Server Side Includes — зачем вы предлагаете инструмент динамического сайта для статического сайта? Вы это серьезно? Нужна будет динамикаДальнейшие обсуждения не имеют смысла. Динамического? Нет, серьезно? Т.е. вы на самом деле считаете. что статику нельзя подключать через SSI? Знаете, прежде чем следовать моде, неплохо бы с основами разобраться.
неплохо бы с основами разобраться.
Это какие-то старые основы. Пока я нахожу статьи 2011 или 2012 года, где рассказывается как SSI использовать на Apache. И статей как-то маловато. Тогда подскажите, пожалуйста, мне недалекому, который основ не знает, как с помощью SSI сгенерировать статические html файлы.
подскажите, пожалуйста, мне недалекому, который основ не знает, как с помощью SSI сгенерировать статические html файлыSSI не генерирует статические html файлы, а позволяет делать вставки в статические html файлы. Например, создаете статические header.html и footer.html. Потом можете создавать сколько угодно статических html файлов примерно следующего содержания:
<!--#include file="header.html" --> <p>Моя статическая страница</p> <!--#include file="footer.html" -->
SSI не генерирует статические html файлы
Если он не генерирует статические html страницы, то зачем мне он нужен? Правильно ли я понимаю, что есть сервер, который динамически подгружает include в html страницы по запросу пользователя? Так я про это и говорил, когда сказал «зачем вы предлагаете инструмент динамического сайта», а вы мне обвинили, что я основы не знаю. Сайт получается динамический!!! Ему нужен сервер для генерирования HTML страниц! Или я что-то не понимаю, и всё-таки можно его попросить сгенерировать как-то конкретные статические конечные html файлы.
Мне нужен инструмент статического(!) сайта! Чтобы я на выходе получил набор html файлов, которые я могу закинуть на тот же GitHub Pages или вообще открыть локально на компьютере. SSI для этого не подходит! Статический сайт! Не динамический!
В динамическом сайте HTML страницы генерируются по запросу пользователя на лету из исходников. И не важно являются ли исходники статическими файлами или нет!
В статическом сайте HTML страницы генерируются заранее, и на хостинге хранятся уже сгенерированные HTML страницы!
Чтобы я на выходе получил набор html файлов, которые я могу… открыть локально на компьютереЕсли без сервера, то (навскидку) я бы написал однострочник на bash минут за несколько. Это вообще не проблема — сгенерировать такие файлы.
То есть вы назвали решение плохим, не вникнув даже в постановку задачи, и перепутали динамический сайт со статическим. Понятно.
Это будет точно однострочник? Напишите. И это будет именно настоящий однострочник, а не липовый, когда строчка длинная-предлинная? У меня код, который это делает в проекте, занимает чуть больше десяти строк. Но это уже несерьезно.
И да, даже если вы напишите скрипт на bash, то что изменится? Да, написать программу, которая заменяет содержимое некоторых строчек на содержимое других файлов во всех файлах папки — это легко везде. Только не понимаю, почему это делает мой вариант плохим.
Плюс к этому потом я предложу усложнить задачу: в меню шапки пункты меню, которые соответствуют названию файлов, должны иметь класс acitive. Или еще что-то. В моем решении в lodash шаблоне можно использовать любой js код.
Но даже, если вы покажите вариант (чего наверно не будет), когда bash осуществляет сборку html файлов, то это ничего не поменяет. Так как остаются задачи работы с SASS и js файлами. Сборка, минификация и др. Это как вы предлагаете сделать? Использовать другие инструменты? И завести целый зоопарк технологий? Или что-то другое?
я бы написал однострочник на bash минут за несколько
Это будет точно однострочник? Напишите. И это будет именно настоящий однострочник, а не липовый, когда строчка длинная-предлинная? У меня код, который это делает в проекте, занимает чуть больше десяти строк. Но это уже несерьезно.
И да, даже если вы напишите скрипт на bash, то что изменится? Да, написать программу, которая заменяет содержимое некоторых строчек на содержимое других файлов во всех файлах папки — это легко везде. Только не понимаю, почему это делает мой вариант плохим.
Плюс к этому потом я предложу усложнить задачу: в меню шапки пункты меню, которые соответствуют названию файлов, должны иметь класс acitive. Или еще что-то. В моем решении в lodash шаблоне можно использовать любой js код.
Но даже, если вы покажите вариант (чего наверно не будет), когда bash осуществляет сборку html файлов, то это ничего не поменяет. Так как остаются задачи работы с SASS и js файлами. Сборка, минификация и др. Это как вы предлагаете сделать? Использовать другие инструменты? И завести целый зоопарк технологий? Или что-то другое?
Плюс к этому потом я предложу усложнить задачу:) Ну а потом, после потом… Нет уж, давайте я не буду тратить свое и ваше время, а просто соглашусь, что был неправ, и ваше решение совсем неплохое. если учитывать все нюансы.
Вот есть вариант, если что: https://github.com/kidwm/node-ssi
В принципе, идея SSI норм, но видимо есть какие-то подводные камни, раз эта идея не стала популярной.
Возможно виной тому отсутствие эскейпа html и уязвимость к XSS. Может быть, просто не хватало возможностей (не увидел поддержки циклов).
Еще так и не нашел единого описания стандарта. Сложилось впечатление, что каждый веб-сервер (Apache, Jigsaw и т.п.)
поддерживает свой несовместимый набор команд
Купите лучше какую-нибудь книгу, лучше фундаментальную, касающуюся веб разработки в целом, истории вэба, истории развития браузеров и HTML.
Зачем?
Потому что изучение фундаментальных трудов это отличная инвестиция в будущее, если конечно вы хотите стать профессионалом в области разработки ПО. Конечно можно изучать все исключительно по статьям и Ютубам, но вряд ли это поможет сделать карьеру или найти работу на которой можно будет решать сложные и интересные задачи.
Литература, представляющая сугубо исторический интерес, поможет сделать карьеру с ещё меньшей вероятностью.
Хотя, конечно, чтиво занимательное.
Хотя, конечно, чтиво занимательное.
Труды Танненбаума, «Архитектура компьютеров», «Операционные Системы», «Компьютерные Сети», это сугубо исторический интерес? Или может быть «Код» Петцольда представляет сугубо исторический интерес? А может быть Деннис Ритчи «Язык Си» ни кому не нужная историческая книжка? «Чистый код», «Программист прагматик», «Совершенный код», «Архитектура корпоративных приложений», или вот… Кнут «Искусство программирования», которая была написана пол века назад. Это все сугубо исторические книги? Я на 100% уверен что люди которые не читали хотя бы половину из перечисленного, понятия не имеют как писать программы, более того, в голове у них как правило каша и я регулярно с этим сталкиваюсь когда приходится нанимать людей на работу.
Любая фундаментальная литература не имеет срока давности и дает глубокие знания и понимание всего того что программист использует.
А читать книги по языкам программирования или не дай бог по Библиотекам, типа «Изучаем jQuery» или программируем на «React» — пустая трата времени.
Любая фундаментальная литература не имеет срока давности и дает глубокие знания и понимание всего того что программист использует.
А читать книги по языкам программирования или не дай бог по Библиотекам, типа «Изучаем jQuery» или программируем на «React» — пустая трата времени.
Какое отношение, например, «Совершенный код» относится к «книге, лучше фундаментальной, касающуюся веб разработки в целом, истории вэба, истории развития браузеров и HTML». Или тот же Кнут? А вам сказали именно насчет книг истории развития IT, про которые вы упомянули. А вы в ответ привели список отличных книг, но они про другое.
А историю веба и так далее, как считаю, знаю достаточно. И читать еще какие-то дополнительные книги не хочется.
А историю веба и так далее, как считаю, знаю достаточно. И читать еще какие-то дополнительные книги не хочется.
Это какие-то старые основы. Пока я нахожу статьи 2011 или 2012 года, где рассказывается как SSI использовать на Apache. И статей как-то маловато. Тогда подскажите, пожалуйста, мне недалекому, который основ не знает, как с помощью SSI сгенерировать статические html файлы.
Достаточно хорошо чтобы писать такое? Ну ок. У вас кстати в постановке задачи первым стоит слово «Сайт», изучите чем «сайт» отличается от набора html страниц.
Достаточно хорошо чтобы писать такое?
Да, я так считаю. Вы считаете, что каждый человек должен знать никем не используемую технологию? Таких технологий вагон и маленькая тележка.
У вас кстати в постановке задачи первым стоит слово «Сайт», изучите чем «сайт» отличается от набора html страниц.
Из-за того, что в статье опущено описания заливки файлов на хостинг никак не меняет сути.
А про свои косяки с книгами вы решили умолчать… Ладно.
Да, я так считаю. Вы считаете, что каждый человек должен знать никем не используемую технологию? Таких технологий вагон и маленькая тележка.
Я считаю что web-разработчик должен хорошо знать фундамент на котором стоит Web. А web стоит на целой пачке технологий некоторый из которых наложены одна на другую или являются развитием более старых вещей. И чтобы оптимально и правильно решать задачи нужно хотя бы иметь общее представление о всех них. Книги отсылающие к истории веба как нельзя лучше подходят для того чтобы вообще понять почему современный вэб такой какой он есть и где какие технологии стоит использовать, а где они избыточны или не нужны.
Существует огромная масса технологий, которые умерли или устарели. Вы знаете особенности VHTML, конструкции языка COBOL? Про файловый сервер NetWare что-нибудь слышали? Знать их все невозможно и не нужно. Разумеется, определенная база нужна и необходима. Без этого никуда. Но SSI к этому не относится. Эта технология устарела и никто её не пользуется. Она не решает даже часть задачи, которую я озвучил в статье. Но даже, если бы она мне подходила, то никогда бы не остановился на неё выбор. Технология устарела, справочного материала мало, непонятна её поддержка в будущем в серверах и так далее. Если бы у меня стоял выбор какую технологию выбрать, то остановился на старом добром PHP, который пока что не устарел.
Ох, участвовать в дискуссии, заранее зная, чем она закончится..., но было любопытно скорее с точки зрения психологии.
Вот я пишу:
(С грустью) Опять угадал.
Но все-же хочу дать вам несколько советов
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Вот я пишу:
стараюсь не участвовать в религиозных спорах… Могу сказать, что технология SSI известна больше 20 лет, но наверняка нарвусь на обвинение в «подходе динозавра».Ну и вы:
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.
(С грустью) Опять угадал.
Но все-же хочу дать вам несколько советов
Про файловый сервер NetWare что-нибудь слышали?как человек, который писал NLM для Novell Netware (намек на возраст).
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.Если вы не уверены в своем утверждении, не выдавайте свои домыслы за непреложную истину. Человек, узнавший об SSI пару дней назад, мог бы добавить «как мне кажется».
Если бы у меня стоял выбор какую технологию выбрать, то остановился на старом добром PHP, который пока что не устарел.Никогда не говорите так на собеседовании. SSI и PHP — это даже разные предметные области.
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Ну и вы:
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.
А это предложение было не для вас, а для DexterHD и его пассажей.
как человек, который писал NLM для Novell Netware (намек на возраст).
Опять таки это ответ DexterHD, с которым я почти одного возраста, а не вам.
Если вы не уверены в своем утверждении, не выдавайте свои домыслы за непреложную истину. Человек, узнавший об SSI пару дней назад, мог бы добавить «как мне кажется».
Объясняю. Если популярные поисковики при запросе о технологии выдают статьи 2010-2012 годов, не находится нормальная документация, а stackoverflow также не многословен, то технологию можно считать устаревшей. Это не означает, что она плохая. Но её не используют. И это в отрыве от того: подходит или нет для моей задачи.
Никогда не говорите так на собеседовании. SSI и PHP — это даже разные предметные области.
С точки зрения поставленной задачи буду так говорить. Ибо эти два инструмента можно использовать для склейки html страниц.
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Вначале сказать, что решение неправильное, плохое, потом прикрыться словами, что в дискуссии не участвуете. Потом все-таки вступить в дискуссию. Потом сказать человеку, что он не прав в терминологии. После ответа вместо контр-доводов сказать «Откланиваюсь, читайте книги. а не википедию». Всё понятно.
Если популярные поисковики при запросе о технологии выдают статьи 2010-2012 годов, не находится нормальная документация, а stackoverflow также не многословен, то технологию можно считать устаревшейЗабыли добавить — «как мне кажется». Ибо я могу предложить другую трактовку. Технология настолько проста и хорошо документирована что у Apache, что у nginx — что там и обсуждать то нечего.
Вначале сказать, что решение неправильное, плохое, потом прикрыться словами, что в дискуссии не участвуете. Потом все-таки вступить в дискуссию. Потом сказать человеку, что он не прав в терминологии. После ответа вместо контр-доводов сказать «Откланиваюсь, читайте книги. а не википедию». Всё понятно.Забыли еще несколько пунктов. Честно пытаться разобраться в вашей терминологической путанице и пытаться понять, какую же задачу вы решали, а после того, как это все-таки мне удалось, често признаться, что был неправ и ваше решение неплохое, с учетом всех нюансов.
Поэтому еще совет. Читайте собеседника внимательно.
Опять таки это ответ DexterHD, с которым я почти одного возраста, а не вам.
А возраст о чем то говорит кроме возраста? На мой взгляд ни о чем. Если это намек на опыт, то считайте сами, «Hello World» я написал в 2000г. А в 2004 получил первые деньги за разработку сайта под заказ (Как сейчас помню, это был «варезный» портал интегрированный с phpBB 2.0 с единой аутентификацией/авторизацией через форум и плотной интеграцией с ним). Куда уж мне до «статических HTML сайтов» в 2018 году.
Пожалуйста, очень прошу внимательно читать сообщения. Вот очень прошу. Кому я написал про возраст? Вам? Нет. Я отвечал redfs. На что отвечал? На его комментарий «как человек, который писал NLM для Novell Netware (намек на возраст).» Где redfs в свою очередь зачем-то ответил на мой ответ вам, где я привел список технологий, с которыми вы скорее всего не сталкивались. И этот список (в первую очередь выбор NLM) выбрал на основании уже возраста: технологии стали непопулярными раньше, чем вы могли ими начать заниматься.
Внимательно смотрите кому и на что я отвечаю. И не надо сводить дискуссию к «у кого длиннее писька».
Внимательно смотрите кому и на что я отвечаю. И не надо сводить дискуссию к «у кого длиннее писька».
технологии стали непопулярными раньше, чем вы могли ими начать заниматься.
Непопулярные и устаревшие — разные вещи. Абсолютно. Выбирать только лишь на основе «потому что популярно», не профессионально.
где я привел список технологий, с которыми вы скорее всего не сталкивались.
Почему вы так решили? Исходя из возраста? Что за бред. Еще раз, возраст не значит ни чего.
И не надо сводить дискуссию к «у кого длиннее писька».
При чем тут это? Еще раз не нужно судить по возрасту об опыте.
Отмотайте вообще в начало. Самая первая моя претензия была в 3000 зависимостях для решения простейшей задачи.
Не знаю как вы а я лично сталкивался с тем что при очередном `npm install` из-за одного отвалившегося пакета ложилось все к хренам, и нужно было потратить несколько дней чтобы разобраться что случилось.
И я представляю чем ваш подход может кончится для заказчика потому что у меня был такой жизненный опыт. Вы же не хотите к нему прислушаться просто потому что мы равного возраста. Отлично.
Просто это бывает так: Вы сделали статический сайт и все хорошо, он проработал 3 года, через 3 года к вам обратились для того чтобы вставить пару HTML блоков. Вы пулите репку, делаете npm i, а за 3 года половина зависимостей тех версий что есть в lock файле уже безбожно устарели и выпилились.
Как итог собрать ничего не получается, и вам приходится тратить несколько дней чтобы добавить вставку HTML блока. Кто это все будет оплачивать? Заказчик? Задачу которая делается за 5 мин он будет ждать 2 дня?
Используя тот же SSI вы можете просто залить на сервер новый кусок HTML и вставить одну строку в готовый файл, и оно будет работать годами. Зачем усложнять простую задачу? Вот главная претензия.
Все остальное вытекает отсуда. Знание и изучение фундамента тоже. Не нужно делать простые вещи сложными, не нужно гнаться за популярными технологиями, нужно выбирать технологии под задачу.
Устаревшей является технология которая давно выпилена из индустрии и осталась только в книжках и статьях. SSI поддерживается всеми современными web серверами, многие сайты до сих пор используют ее а это значит что технология жива.
Почему вы так решили? Исходя из возраста? Что за бред. Еще раз, возраст не значит ни чего.
Рука-лицо. Да причем тут возраст? Я хоть какой-то дурной намек сделал относительно возраста чтоль? Я привел просто список технологий, с которыми вы не работали скорее всего. А для redfs в аналогичной ситуации я привел бы другой список, так как он старше. Всё. Никакого другого смысла это не имело.
Еще раз не нужно судить по возрасту об опыте.
Где я судил об опыте по возрасту? Где? Покажите мне это место в моих сообщениях? Зачем вы придумываете то, чего не было?
Непопулярные и устаревшие — разные вещи. Абсолютно.
Это понятия сильно коррелирующие. А для технологий «много лет тому назад» корреляция становится еще больше.
Выбирать только лишь на основе «потому что популярно», не профессионально.
Инструменты надо выбирать под задачу. Но популярность — это дополнительный критерий. И из двух технологий, которые могут решить задачу, я выберу более популярную, если на это есть время и ресурсы. На поставленную задачу было и то и другое. Разумеется, есть много ситуаций, когда такой подход недопустим. Но я нигде не говорил, что этим нужно руководствоваться постоянно.
из-за одного отвалившегося пакета ложилось все к хренам, и нужно было потратить несколько дней чтобы разобраться что случилось.
Так я же на это отвечал. Есть package-loack.json. Есть бэкапы node_modules. То есть, если нужно, чтобы всё просто работало, то никаких проблем не возникнет.
Используя тот же SSI вы можете просто залить на сервер новый кусок HTML и вставить одну строку в готовый файл, и оно будет работать годами. Зачем усложнять простую задачу? Вот главная претензия.
Да не подходит для поставленной задачи SSI! Сколько об этом можно говорить? Даже redfs это признал. Как мне поможет SSI на Github Pages например? Для того, чтобы больше не было разногласий я добавил уточнение (на мой взгляд оно лишнее) в постановку задачи. А про сборку SASS и js вообще молчу.
нужно выбирать технологии под задачу.
Абсолютно верно! Только вы зачем-то предлагаете технологию ради технологию, которая не решает задачу!
Как итог собрать ничего не получается, и вам приходится тратить несколько дней чтобы добавить вставку HTML блока. Кто это все будет оплачивать?
Нельзя принцип зависимости проекта от других проектов применять во всех случаях. Нельзя! Иначе его можно везде применить. Например, сделали человеку сайт на Wordpress, а через три года Wordpress сильно обновился и функции перестали работать. Написали программу под Windows 10, а через несколько лет в Windows поменялась политика работы с правами доступа и приложение перестало работать. Написали статический сайт на jekyll, а через несколько лет он может перестать работать из-за обновлений. И так далее.
Ну или можно сменить постановку задачи и статью на: «Генерируем набор HTML страниц с помощью WebPack 4», тогда все вопросы и споры отпадут сами собой.
Вот кстати неплохая цитатка про SSI, источник указывать не буду, вы и сами знаете:
Вот кстати неплохая цитатка про SSI, источник указывать не буду, вы и сами знаете:
Static websites may still use server side includes (SSI) as an editing convenience, such as sharing a common menu bar across many pages. As the site's behaviour to the reader is still static, this is not considered a dynamic site.
Хм… Тут не смогу не согласиться и наоборот согласится. Например, в том же источнике ниже написано «Server-side dynamic pages are generated „on the fly“ by computer code that produces the HTML (CSS are responsible for appearance and thus, are static files).» Что как бы входит в противоречие с цитатой, которую вы привели. Но это уже чисто терминалогический спор: статический сайт определяется со стороны клиента или сервера.
Там 2 раздела. Первый называется Static website, второй Dynamic website. Я привел текст из первого раздела, вы приводите со второго. Нет ни каких противоречий. Просто прочитайте эти разделы и все станет на свои места.
Вы утверждали что SSI сделает сайт динамическим, хотя это не так. И именно для этого я посоветовал ознакомится с фундаментальной литературой.
Вы путаетесь в терминологии в данном конкретном случае, а терминология крайне важная вещь в нашей отрасли.
К слову я тоже не семи пядей во лбу, поэтому частенько поднимаю теорию и вам того же советую.
Вы утверждали что SSI сделает сайт динамическим, хотя это не так. И именно для этого я посоветовал ознакомится с фундаментальной литературой.
Вы путаетесь в терминологии в данном конкретном случае, а терминология крайне важная вещь в нашей отрасли.
К слову я тоже не семи пядей во лбу, поэтому частенько поднимаю теорию и вам того же советую.
Но это уже чисто терминалогический спор: статический сайт определяется со стороны клиента или сервераКоллега, поясните, пожалуйста, вашу мысль — «статический сайт со стороны клиента»?
Вам действительно надо привести в порядок терминологию, хотя бы для того, чтобы ваши читатели вас правильно понимали.
Не люблю я эти терминалогические споры. Когда частично отличающиеся определения приводят к таким ситуациям. Хорошо, давайте разбираться. Отвечу тебе и DexterHD вместе.
В статье Website википедии в разделе про динамический сайт приводится одно из главных его свойств: «Server-side dynamic pages are generated „on the fly“ by computer code that produces the HTML». То есть HTML страницы генерируются по запросу пользователя из каких-либо исходников. В разделе про статический сайт данный вид сайта определяется как «A static website is one that has web pages stored on the server in the format that is sent to a client web browser.» То есть, что хранится на сервере, то и отдается пользователю. На данный момент всё согласуется с тем, как я использовал понятия динамического и статического сайт.
Однако, вы нашли следующий момент «Static websites may still use server side includes (SSI) as an editing convenience, such as sharing a common menu bar across many pages. As the site's behaviour to the reader is still static, this is not considered a dynamic site.» По данному моменту получается, что, если для ПОЛЬЗОВАТЕЛЯ, сайт всегда выдает одно и то же, то такой сайт тоже называется статическим. Отсюда получается, что, если, например, у нас будет php скрипт, который собирает html страницу из нескольких исходников (аналогично SSI) и ничего более не делает, то для ПОЛЬЗОВАТЕЛЯ данный сайт будет статическим.
Отсюда получается вдруг, что статический сайт может собираться на лету из исходников, а также статический сайт может быть написан на том же PHP. На лицо очевидное противоречие. Давайте разбираться далее.
Переходим на основную страницу, посвященной статическим сайтам Static web page. И тут статический сайт определяется как «A static web page (sometimes called a flat page/stationary page) is a web page that is delivered to the user exactly as stored, in contrast to dynamic web pages which are generated by a web application.» То есть здесь опять же главным отличием от динамических сайтов определяется отдача файлов «как они есть» в отличии от генерирования их из исходников.
Однако ниже написано «However, loose interpretations of the term could include web pages stored in a database, and could even include pages formatted using a template and served through an application server, as long as the page served is unchanging and presented essentially as stored.» То есть можно рассматривать сайт статическим, если для ПОЛЬЗОВАТЕЛЯ неизменен. Обратите внимание на словосочетание «loose interpretations» — свободное толкование в переводе.
То есть есть толкование понятия статического сайта, которое НЕ ЯВЛЯЕТСЯ основным, где под статический сайт попадают динамически генерируемые страницы, но которые для пользователя неизменны.
Итого. С точки основного определения статического сайта, данный вид сайтов определяется через процесс происходящий с момент прихода запроса на сервер и отдачи ответа пользователю: если HTML файлы генерируются из исходников, то сайт динамический, если HTML страницы отдаются как хранились, то сайт статический. Для вашего понимания я это назвал статический сайт с точки зрения сервера. Есть НЕОСНОВНОЕ, свободное толкование, где статический сайт определяется с точки зрения пользователя: если пользователь получает неизменные HTML страницы при одном и том же адресе HTML страницы, то сайт можно назвать статическим. Если же страницы могут менять своё содержимое, то сайт можно назвать динамическим. Это статический сайт с точки зрения пользователя.
Поэтому, когда я использую в статье (причем прикладного характера, а не фундаментального) основное определение, а вы пытаетесь предъявить мне ошибки, используя свободное толкование термина, то ваши предъявления необоснованны.
Скорее всего вы оба этот материал не знали. Ничего страшного. Но в будущем, пожалуйста, тщательней изучайте матчасть.
В статье Website википедии в разделе про динамический сайт приводится одно из главных его свойств: «Server-side dynamic pages are generated „on the fly“ by computer code that produces the HTML». То есть HTML страницы генерируются по запросу пользователя из каких-либо исходников. В разделе про статический сайт данный вид сайта определяется как «A static website is one that has web pages stored on the server in the format that is sent to a client web browser.» То есть, что хранится на сервере, то и отдается пользователю. На данный момент всё согласуется с тем, как я использовал понятия динамического и статического сайт.
Однако, вы нашли следующий момент «Static websites may still use server side includes (SSI) as an editing convenience, such as sharing a common menu bar across many pages. As the site's behaviour to the reader is still static, this is not considered a dynamic site.» По данному моменту получается, что, если для ПОЛЬЗОВАТЕЛЯ, сайт всегда выдает одно и то же, то такой сайт тоже называется статическим. Отсюда получается, что, если, например, у нас будет php скрипт, который собирает html страницу из нескольких исходников (аналогично SSI) и ничего более не делает, то для ПОЛЬЗОВАТЕЛЯ данный сайт будет статическим.
Отсюда получается вдруг, что статический сайт может собираться на лету из исходников, а также статический сайт может быть написан на том же PHP. На лицо очевидное противоречие. Давайте разбираться далее.
Переходим на основную страницу, посвященной статическим сайтам Static web page. И тут статический сайт определяется как «A static web page (sometimes called a flat page/stationary page) is a web page that is delivered to the user exactly as stored, in contrast to dynamic web pages which are generated by a web application.» То есть здесь опять же главным отличием от динамических сайтов определяется отдача файлов «как они есть» в отличии от генерирования их из исходников.
Однако ниже написано «However, loose interpretations of the term could include web pages stored in a database, and could even include pages formatted using a template and served through an application server, as long as the page served is unchanging and presented essentially as stored.» То есть можно рассматривать сайт статическим, если для ПОЛЬЗОВАТЕЛЯ неизменен. Обратите внимание на словосочетание «loose interpretations» — свободное толкование в переводе.
То есть есть толкование понятия статического сайта, которое НЕ ЯВЛЯЕТСЯ основным, где под статический сайт попадают динамически генерируемые страницы, но которые для пользователя неизменны.
Итого. С точки основного определения статического сайта, данный вид сайтов определяется через процесс происходящий с момент прихода запроса на сервер и отдачи ответа пользователю: если HTML файлы генерируются из исходников, то сайт динамический, если HTML страницы отдаются как хранились, то сайт статический. Для вашего понимания я это назвал статический сайт с точки зрения сервера. Есть НЕОСНОВНОЕ, свободное толкование, где статический сайт определяется с точки зрения пользователя: если пользователь получает неизменные HTML страницы при одном и том же адресе HTML страницы, то сайт можно назвать статическим. Если же страницы могут менять своё содержимое, то сайт можно назвать динамическим. Это статический сайт с точки зрения пользователя.
Поэтому, когда я использую в статье (причем прикладного характера, а не фундаментального) основное определение, а вы пытаетесь предъявить мне ошибки, используя свободное толкование термина, то ваши предъявления необоснованны.
Скорее всего вы оба этот материал не знали. Ничего страшного. Но в будущем, пожалуйста, тщательней изучайте матчасть.
Вы спутали два определения, web page и website. Вы ссылаетесь на статью про веб-страницу и называете веб-страницу сайтом. Это все равно что я системный блок или монитор буду называть компьютером, ну знаете раньше так делали. Веб-страница это веб-страница, сайт это сайт! И да веб-страница использующая SSI является HTML страницей она ни во что не преобразовывается и не меняется во времени. Ее части вставляются сервером `как есть`. И да, на последок, вы прочитайте весь абзац про Static Web Site, там вполне четкие критерии описано, когда и как сайт считается статическим, вплоть до того с помощью чего статические сайт создаются, а то что вы тут скомпилировали исключительно ваша интерпретация. В общем успехов вам… :)
Вы спутали два определения, web page и website
Мда… Смотрим. Раздел «Static website» на странице «Website». Читаем далее «Main article: Static web page». То есть это статья, описывающая детально тему «Static website». Переходим на «Static web page». Смотрим как называется русская статья, соответствующая этой: «Статический сайт». Дальше будете спорить?
И описание неосновного толкования по смыслу в статьях «Static website» и «Static web page» очень похоже.
Ее части вставляются сервером `как есть`
Рука-лицо. Вам не кажется, что процесс вставки «как есть» — уже автоматом означает, что HTML страница, которая хранится на сервере, и тот вариант, который передается пользователю — разные? И то, что отправленный вариант был сгенерирован сервером? Нет, не кажется?
А если я покажу, например, эту ссылку https://www.techopedia.com/definition/5399/static-web-page, то наверно скажите, что её составляли идиоты.
Боже, в какое дно превратили Интернет любители NodeJS. Это не сайты, а уродцы какие-то. Тоже самое можно сделать в десять раз проще если выкинуть весь этот ужас.
Это не сайты, а уродцы какие-то.
Уродство с точки зрения сборки или с точки зрения получившегося результата? Если второе, то что там уродского? Обычныt Bootstrap страницы.
Тоже самое можно сделать в десять раз проще если выкинуть весь этот ужас.
Специально в статье приведена постановка задачи. Скажите как её можно решить в десять раз проще. Честно, буду очень признателен.
С точки зрения процесса. Нафиг NodeJS нужен для сайтов я так и не понял.
Типичный мой проект:
1. Сгенерированные статические роутеры через vibed c шаблонизатором pug/diet
2. Динамические части на vuejs подгружаемые через http-vue
3. css по вкусу, которую можно прям в компонентах vue разместить.
В итоге проект весит сотни килобайт (исходники). Переносится с компа на комп копи-пастом. Никаких мучительных конфигураций веб-пака и развертывания NodeJS.
Типичный мой проект:
1. Сгенерированные статические роутеры через vibed c шаблонизатором pug/diet
2. Динамические части на vuejs подгружаемые через http-vue
3. css по вкусу, которую можно прям в компонентах vue разместить.
В итоге проект весит сотни килобайт (исходники). Переносится с компа на комп копи-пастом. Никаких мучительных конфигураций веб-пака и развертывания NodeJS.
Смутно представляю эти технологии, так что задам несколько вопросов.
Правильно ли я понимаю, что это получается скорее web приложение, чем обычные web страницы, где html код можно посмотреть просто в html файлах?
Как я понимаю, вначале были прописаны эти исходники, настроены и всё такое. А чем тогда от предложенного способа отличается? Мне нужно будет в другом проекте написать только
Где-нибудь можно посмотреть на пример такого проекта? Возможно от webpack перейду к vue.js.
Правильно ли я понимаю, что это получается скорее web приложение, чем обычные web страницы, где html код можно посмотреть просто в html файлах?
Как я понимаю, вначале были прописаны эти исходники, настроены и всё такое. А чем тогда от предложенного способа отличается? Мне нужно будет в другом проекте написать только
npm i и вся настроенная система появится опять.Где-нибудь можно посмотреть на пример такого проекта? Возможно от webpack перейду к vue.js.
Нет получаются очень удобные html-страницы. Которые генерятся на сервере т.е. их видит поисковик. Всякие модные интерактивные компоненты можно оформлять именно как веб-компоненты и подгружать в нужные места.
Тоесть проблем с индексацией не будет. Страницы все открываются пулей.
pug шаблон позволяет описать каркас сайта один раз и потом просто цеплять к нему нужные блоки.
Пример кину в личку.
Тоесть проблем с индексацией не будет. Страницы все открываются пулей.
pug шаблон позволяет описать каркас сайта один раз и потом просто цеплять к нему нужные блоки.
Пример кину в личку.
vibed — это вы имеете в виду vibe-d, веб-сервер на D?
Да, именно
Так это же веб-сервер, его запускать где-то надо.
Статья про принципиально другой подход. Статический сайт собирается из исходников скриптом и получается несколько html-файлов. Эти файлы загружаются на любое файлохранилище (surge, netlify или Github pages). Затем прикручиваете кастомный домен, и сайт готов. Поддерживать запущенный сервер не надо вообще.
В чем проблема сделать сайт на стандартных html,css,js(+vue) и залить на github pages?
Зачем мне nodejs, webpack?
Зачем мне nodejs, webpack?
Если для вас достаточно html,css,js(+vue), то вам не нужен node.js и webpack. Я сам многие годы обходился без всего этого. Но node.js с webpack позволяет следить за версиями библиотек, подгружать обновления, собирать html страницы по шаблону, поднимать локальный сервер, который автоматически перестраивает страницы и обновляет в браузере, собирать css из sass, минимизировать js и так далее. То есть node.js + webpack позволяет автоматизировать много рутинных вещей. Но да, без этого можно обойтись.
P.S. Есть люди, которые vue используют без node.js?
P.S. Есть люди, которые vue используют без node.js?
можете описать почему именно он? чем не угодил любой другой вебсервер?
Открыть любой текстовый редактор и решить. В 10 раз проще и главное быстрее. Постановка задачи на самом деле, это первое предложение, а второе предложение:
Это создание надуманной проблемы которую потом всю остальную часть статьи приходится решать.
Необходимо написать проект, который бы собирал наш сайт из исходников:
Это создание надуманной проблемы которую потом всю остальную часть статьи приходится решать.
Открыть любой текстовый редактор и решить.
Ввиду того, что раньше так и делал, то могу оценить насколько эти два варианта. Во-первых, без SCSS работу с CSS я сейчас вообще не представляю. Повышает удобство работы во много раз. Можно найти программы, которые позволяют работать с SASS без node.js (например, Koala), но внутри них также стоят настроенные бандлеры. Во-вторых, работа с js с модулями и компоновкой в один файл также сильно повышает удобство работы (но не так сильно). В-третьих, шаблонизаторы с возможностью написания условий, циклов — так это вообще красота. А вручную прописывать один и тот же код шапки, например, в сотнях html файлах — это ад.
НЛО прилетело и опубликовало эту надпись здесь
И если добавить стили библиотеки в наш style.scss, то file-loader будет искать картинки библиотеки lightgallery в моей папке src/img, а не там, где они находятся. И побороть я это не смог.
Если я правильно понял суть проблемы, то она решается с помощью resolve-url-loader
Как раз в процессе переноса сборки с gulp'а на webppack — так что Ваша статья в руку, есть то, с чем я еще не разобрался.
И если добавить стили библиотеки в наш style.scss, то file-loader будет искать картинки библиотеки lightgallery в моей папке src/img, а не там, где они находятся. И побороть я это не смог.
Опция exclude не поможет, примерно как здесь указано — https://stackoverflow.com/questions/44211666/how-to-exclude-bootstrap-files-when-css-modules-is-enabled ?
Обратите внимание на то, что в точках входа entryмы добавили новый входной файл style.scss
Кстати, если в output указать не конкретное имя, а чанки, напр.,
filename: "js/[name].js",то в папке dist/js появится style.js… пустой) (ну, не совсем пустой — там будет вебпаковаская обертка, но по сути, ничего не делающая, поскольку стили извлечены extract плагином)
Поэтому для итоговой сборки рекомендую использовать не команду *npm run build, а команду npm run build-and-beautify.
В npm можно указывать команды с префиксами "pre" и "post", которые запустяться, соотвественно, до и после основной команды, т.е. вот это:
"scripts": {
"build-and-beautify": "webpack --mode production && html dist/*.html --indent-size 2",
"beautify": "html dist/*.html --indent-size 2"
},можно записать так:
"scripts": {
"build": "webpack --mode production && html dist/*.html --indent-size 2",
"postbuild": "html dist/*.html --indent-size 2"
},команда postbuild запуститься автоматически после выполнения build
Еще очень рекомендую эту книгу о вебпак — SurviveJS — Webpack
И курс Ильи Кантора (хоть и 2015 г., но все равно полезный в плане понимация настройки Webpack) — Скринкаст по Webpack
поправка к "build-and-beautify":
"scripts": {
"beautify": "html dist/*.html --indent-size 2",
"build": "webpack --mode production",
"postbuild": "npm run beautify"
},exclude к сожалению не поможет, но поможет пакет resolve-url-loader, как отметили выше.
Про скрипты с приставкой
Про скрипты с приставкой
post не знал. Спасибо!Про файлы-пустышки, кода имя указываешь через filename: "js/[name].js". Сам столкнулся с этим.
Можно решить через пакет webpack-extraneous-file-cleanup-plugin. Но он пока с webpack 4 не работает. Но есть pull request, который эту проблему решает.
Или можно, указать массив точек входа:
entry: {
'app': [
'./src/js/index.js',
'./src/scss/style.scss'
]
},С несколькими файлами:
entry: {
'app': [
'./src/js/index.js',
'./src/scss/style.scss'
],
'../katex/katex': [
'./src/js/katex.js',
'./src/scss/katex.scss'
]
},Вышеприведенный код создаст app.js, app.css, katex.css, katex.js. И пустышек не будет.
* промах
Мда, простые статичные сайты уже не те.
В чем преимущества такого подхода вместо того чтобы просто выложить файлы на сервер?
В чем преимущества такого подхода вместо того чтобы просто выложить файлы на сервер?
Интересно, можно ли использовать JSX в отрыве от реакта. Как шаблонизатор. В итоге, сочетая с описанной в статье конфигурацией, в итоге можно посадить дизайнера-верстальщика делать макет, а потом скопировать верстку в реальный проект (естесственно с некоторыми правками — другим разбиением на компоненты, с заточками под условное отображение и т.п.).
JSX is an XML-like syntax extension to ECMAScript without any defined semantics.
This specification does not attempt to comply with any XML or HTML specification. JSX is designed as an ECMAScript feature and the similarity to XML is only for familiarity.
This specification does not attempt to comply with any XML or HTML specification. JSX is designed as an ECMAScript feature and the similarity to XML is only for familiarity.
НЛО прилетело и опубликовало эту надпись здесь
Кажется в разделе про html ошибка, должно быть
вместо
const CopyWebpackPlugin = require('copy-webpack-plugin')
вместо
const HtmlWebpackPlugin = require('html-webpack-plugin')
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой статический сайт на Webpack 4