Про файлы-пустышки, кода имя указываешь через filename: "js/[name].js". Сам столкнулся с этим.
Можно решить через пакет webpack-extraneous-file-cleanup-plugin. Но он пока с webpack 4 не работает. Но есть pull request, который эту проблему решает.
Или можно, указать массив точек входа:
Например, в шапке в пунктах меню некоторые пункты, которые соответствуют файлам html выделены классом active. И при этом регулярка сильно усложняется.
Я молчу про сборку sass и js файлов.
Почему вы так решили? Исходя из возраста? Что за бред. Еще раз, возраст не значит ни чего.
Рука-лицо. Да причем тут возраст? Я хоть какой-то дурной намек сделал относительно возраста чтоль? Я привел просто список технологий, с которыми вы не работали скорее всего. А для redfs в аналогичной ситуации я привел бы другой список, так как он старше. Всё. Никакого другого смысла это не имело.
Еще раз не нужно судить по возрасту об опыте.
Где я судил об опыте по возрасту? Где? Покажите мне это место в моих сообщениях? Зачем вы придумываете то, чего не было?
Непопулярные и устаревшие — разные вещи. Абсолютно.
Это понятия сильно коррелирующие. А для технологий «много лет тому назад» корреляция становится еще больше.
Выбирать только лишь на основе «потому что популярно», не профессионально.
Инструменты надо выбирать под задачу. Но популярность — это дополнительный критерий. И из двух технологий, которые могут решить задачу, я выберу более популярную, если на это есть время и ресурсы. На поставленную задачу было и то и другое. Разумеется, есть много ситуаций, когда такой подход недопустим. Но я нигде не говорил, что этим нужно руководствоваться постоянно.
из-за одного отвалившегося пакета ложилось все к хренам, и нужно было потратить несколько дней чтобы разобраться что случилось.
Так я же на это отвечал. Есть package-loack.json. Есть бэкапы node_modules. То есть, если нужно, чтобы всё просто работало, то никаких проблем не возникнет.
Используя тот же SSI вы можете просто залить на сервер новый кусок HTML и вставить одну строку в готовый файл, и оно будет работать годами. Зачем усложнять простую задачу? Вот главная претензия.
Да не подходит для поставленной задачи SSI! Сколько об этом можно говорить? Даже redfs это признал. Как мне поможет SSI на Github Pages например? Для того, чтобы больше не было разногласий я добавил уточнение (на мой взгляд оно лишнее) в постановку задачи. А про сборку SASS и js вообще молчу.
нужно выбирать технологии под задачу.
Абсолютно верно! Только вы зачем-то предлагаете технологию ради технологию, которая не решает задачу!
Как итог собрать ничего не получается, и вам приходится тратить несколько дней чтобы добавить вставку HTML блока. Кто это все будет оплачивать?
Нельзя принцип зависимости проекта от других проектов применять во всех случаях. Нельзя! Иначе его можно везде применить. Например, сделали человеку сайт на Wordpress, а через три года Wordpress сильно обновился и функции перестали работать. Написали программу под Windows 10, а через несколько лет в Windows поменялась политика работы с правами доступа и приложение перестало работать. Написали статический сайт на jekyll, а через несколько лет он может перестать работать из-за обновлений. И так далее.
Пожалуйста, очень прошу внимательно читать сообщения. Вот очень прошу. Кому я написал про возраст? Вам? Нет. Я отвечал redfs. На что отвечал? На его комментарий «как человек, который писал NLM для Novell Netware (намек на возраст).» Где redfs в свою очередь зачем-то ответил на мой ответ вам, где я привел список технологий, с которыми вы скорее всего не сталкивались. И этот список (в первую очередь выбор NLM) выбрал на основании уже возраста: технологии стали непопулярными раньше, чем вы могли ими начать заниматься.
Внимательно смотрите кому и на что я отвечаю. И не надо сводить дискуссию к «у кого длиннее писька».
Ну и вы:
Но SSI к этому не относится. Эта технология устарела и никто её не пользуется.
А это предложение было не для вас, а для DexterHD и его пассажей.
как человек, который писал NLM для Novell Netware (намек на возраст).
Опять таки это ответ DexterHD, с которым я почти одного возраста, а не вам.
Если вы не уверены в своем утверждении, не выдавайте свои домыслы за непреложную истину. Человек, узнавший об SSI пару дней назад, мог бы добавить «как мне кажется».
Объясняю. Если популярные поисковики при запросе о технологии выдают статьи 2010-2012 годов, не находится нормальная документация, а stackoverflow также не многословен, то технологию можно считать устаревшей. Это не означает, что она плохая. Но её не используют. И это в отрыве от того: подходит или нет для моей задачи.
Никогда не говорите так на собеседовании. SSI и PHP — это даже разные предметные области.
С точки зрения поставленной задачи буду так говорить. Ибо эти два инструмента можно использовать для склейки html страниц.
Откланиваюсь, читайте книги. а не википедию, всяческих вам удач в дальнейшем.
Вначале сказать, что решение неправильное, плохое, потом прикрыться словами, что в дискуссии не участвуете. Потом все-таки вступить в дискуссию. Потом сказать человеку, что он не прав в терминологии. После ответа вместо контр-доводов сказать «Откланиваюсь, читайте книги. а не википедию». Всё понятно.
Мда… Смотрим. Раздел «Static website» на странице «Website». Читаем далее «Main article: Static web page». То есть это статья, описывающая детально тему «Static website». Переходим на «Static web page». Смотрим как называется русская статья, соответствующая этой: «Статический сайт». Дальше будете спорить?
И описание неосновного толкования по смыслу в статьях «Static website» и «Static web page» очень похоже.
Ее части вставляются сервером `как есть`
Рука-лицо. Вам не кажется, что процесс вставки «как есть» — уже автоматом означает, что HTML страница, которая хранится на сервере, и тот вариант, который передается пользователю — разные? И то, что отправленный вариант был сгенерирован сервером? Нет, не кажется?
Существует огромная масса технологий, которые умерли или устарели. Вы знаете особенности VHTML, конструкции языка COBOL? Про файловый сервер NetWare что-нибудь слышали? Знать их все невозможно и не нужно. Разумеется, определенная база нужна и необходима. Без этого никуда. Но SSI к этому не относится. Эта технология устарела и никто её не пользуется. Она не решает даже часть задачи, которую я озвучил в статье. Но даже, если бы она мне подходила, то никогда бы не остановился на неё выбор. Технология устарела, справочного материала мало, непонятна её поддержка в будущем в серверах и так далее. Если бы у меня стоял выбор какую технологию выбрать, то остановился на старом добром PHP, который пока что не устарел.
Не люблю я эти терминалогические споры. Когда частично отличающиеся определения приводят к таким ситуациям. Хорошо, давайте разбираться. Отвечу тебе и 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 страницы, то сайт можно назвать статическим. Если же страницы могут менять своё содержимое, то сайт можно назвать динамическим. Это статический сайт с точки зрения пользователя.
Поэтому, когда я использую в статье (причем прикладного характера, а не фундаментального) основное определение, а вы пытаетесь предъявить мне ошибки, используя свободное толкование термина, то ваши предъявления необоснованны.
Скорее всего вы оба этот материал не знали. Ничего страшного. Но в будущем, пожалуйста, тщательней изучайте матчасть.
Хм… Тут не смогу не согласиться и наоборот согласится. Например, в том же источнике ниже написано «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).» Что как бы входит в противоречие с цитатой, которую вы привели. Но это уже чисто терминалогический спор: статический сайт определяется со стороны клиента или сервера.
Какое отношение, например, «Совершенный код» относится к «книге, лучше фундаментальной, касающуюся веб разработки в целом, истории вэба, истории развития браузеров и HTML». Или тот же Кнут? А вам сказали именно насчет книг истории развития IT, про которые вы упомянули. А вы в ответ привели список отличных книг, но они про другое.
А историю веба и так далее, как считаю, знаю достаточно. И читать еще какие-то дополнительные книги не хочется.
Добавление uMatrix к uBlock Origin помогло. Спасибо!
Например, https://lenta.ru/ и https://e.mail.ru/messages/inbox/
Adblock Plus — не режет Яндекс директ.
AdBlock — аналогично не справляется.
uBlock Origin — аналогично не справляется.
Проверено только что на Chrome 66.0.3359.117.
Кто-нибудь из блокировщиков рекламы научился блокировать яндекс-директ, который недавно что-то придумал и теперь никак не выпиливается?
Про файлы-пустышки, кода имя указываешь через
filename: "js/[name].js". Сам столкнулся с этим.Можно решить через пакет webpack-extraneous-file-cleanup-plugin. Но он пока с webpack 4 не работает. Но есть pull request, который эту проблему решает.
Или можно, указать массив точек входа:
С несколькими файлами:
Вышеприведенный код создаст app.js, app.css, katex.css, katex.js. И пустышек не будет.
Я молчу про сборку sass и js файлов.
Про скрипты с приставкой
postне знал. Спасибо!Рука-лицо. Да причем тут возраст? Я хоть какой-то дурной намек сделал относительно возраста чтоль? Я привел просто список технологий, с которыми вы не работали скорее всего. А для redfs в аналогичной ситуации я привел бы другой список, так как он старше. Всё. Никакого другого смысла это не имело.
Где я судил об опыте по возрасту? Где? Покажите мне это место в моих сообщениях? Зачем вы придумываете то, чего не было?
Это понятия сильно коррелирующие. А для технологий «много лет тому назад» корреляция становится еще больше.
Инструменты надо выбирать под задачу. Но популярность — это дополнительный критерий. И из двух технологий, которые могут решить задачу, я выберу более популярную, если на это есть время и ресурсы. На поставленную задачу было и то и другое. Разумеется, есть много ситуаций, когда такой подход недопустим. Но я нигде не говорил, что этим нужно руководствоваться постоянно.
Так я же на это отвечал. Есть package-loack.json. Есть бэкапы node_modules. То есть, если нужно, чтобы всё просто работало, то никаких проблем не возникнет.
Да не подходит для поставленной задачи SSI! Сколько об этом можно говорить? Даже redfs это признал. Как мне поможет SSI на Github Pages например? Для того, чтобы больше не было разногласий я добавил уточнение (на мой взгляд оно лишнее) в постановку задачи. А про сборку SASS и js вообще молчу.
Абсолютно верно! Только вы зачем-то предлагаете технологию ради технологию, которая не решает задачу!
Нельзя принцип зависимости проекта от других проектов применять во всех случаях. Нельзя! Иначе его можно везде применить. Например, сделали человеку сайт на Wordpress, а через три года Wordpress сильно обновился и функции перестали работать. Написали программу под Windows 10, а через несколько лет в Windows поменялась политика работы с правами доступа и приложение перестало работать. Написали статический сайт на jekyll, а через несколько лет он может перестать работать из-за обновлений. И так далее.
Внимательно смотрите кому и на что я отвечаю. И не надо сводить дискуссию к «у кого длиннее писька».
А это предложение было не для вас, а для DexterHD и его пассажей.
Опять таки это ответ DexterHD, с которым я почти одного возраста, а не вам.
Объясняю. Если популярные поисковики при запросе о технологии выдают статьи 2010-2012 годов, не находится нормальная документация, а stackoverflow также не многословен, то технологию можно считать устаревшей. Это не означает, что она плохая. Но её не используют. И это в отрыве от того: подходит или нет для моей задачи.
С точки зрения поставленной задачи буду так говорить. Ибо эти два инструмента можно использовать для склейки html страниц.
Вначале сказать, что решение неправильное, плохое, потом прикрыться словами, что в дискуссии не участвуете. Потом все-таки вступить в дискуссию. Потом сказать человеку, что он не прав в терминологии. После ответа вместо контр-доводов сказать «Откланиваюсь, читайте книги. а не википедию». Всё понятно.
Мда… Смотрим. Раздел «Static website» на странице «Website». Читаем далее «Main article: Static web page». То есть это статья, описывающая детально тему «Static website». Переходим на «Static web page». Смотрим как называется русская статья, соответствующая этой: «Статический сайт». Дальше будете спорить?
И описание неосновного толкования по смыслу в статьях «Static website» и «Static web page» очень похоже.
Рука-лицо. Вам не кажется, что процесс вставки «как есть» — уже автоматом означает, что 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 страницы, то сайт можно назвать статическим. Если же страницы могут менять своё содержимое, то сайт можно назвать динамическим. Это статический сайт с точки зрения пользователя.
Поэтому, когда я использую в статье (причем прикладного характера, а не фундаментального) основное определение, а вы пытаетесь предъявить мне ошибки, используя свободное толкование термина, то ваши предъявления необоснованны.
Скорее всего вы оба этот материал не знали. Ничего страшного. Но в будущем, пожалуйста, тщательней изучайте матчасть.
Да, я так считаю. Вы считаете, что каждый человек должен знать никем не используемую технологию? Таких технологий вагон и маленькая тележка.
Из-за того, что в статье опущено описания заливки файлов на хостинг никак не меняет сути.
А про свои косяки с книгами вы решили умолчать… Ладно.
А историю веба и так далее, как считаю, знаю достаточно. И читать еще какие-то дополнительные книги не хочется.