Pull to refresh

Comments 70

появится возможность анимировать переходы между страницами MPA, что ранее было возможно

Было возможно еще аж в IE 4 :)

Не менее элегантный трюк — взять веб-сервер Redbean и внедрить внутрь бинарника свои статические файлы

Тоже очень старая идея - такое еще с конца девяностых было в Allegro RomPager. Правда, и страданий это принесло немало.

аннулируют главные преимущества использования одностраничных приложений (SPA) вместо нормальных многостраничных сайтов (MPA):

Т.е., по-вашему, SPA - это не нормально?

SPA это нормально для своей области (огромные медийные или корпоративные порталы), для обычных сайтов обычных компаний это скорее попытка забивать гвозди микроскопом.

Если нормальность определять количеством, то да, SPA это не нормально. SPA нишевая штука. Если нет какого-то сложного интерфейса пользователя на странице, то многостраничные сайты удобнее.

Да, с моей точки зрения, SPA — это ненормально, потому что ломают привычный инструментарий работы с сайтом, а именно возможность для пользователя открыть столько окон, сколько ему нужно. Например, Gmail: как я могу открыть несколько писем, каждое в своём окне? А никак, SPA этого не позволяет. Можно только создать несколько инстансов этого SPA. Или Google Maps: как я могу открыть информацию о нескольких объектах одновременно, чтобы сравнить их?

В итоге пользователь начинает работать с SPA так, как если бы это был MPA, но при этом страдает от тяжеловесности SPA.

А никак, SPA этого не позволяет.

SPA это позволяет. Точней не запрещает никак. Вопрос в реализации. У меня весьма сложная интерпрайз система в виде SPA-приложения и роутинг обрабатывает такие моменты, схожие с открытием нового письма в новой вкладке/окне или нажатие средней кнопкой мышки на вкладки. Открывается просто новое окно и в нем можно работать полноценно. При этом не загружается все приложение целиком (около 11% кода). Вопрос конечно в синхронизации между вкладками встает остро, но т.к. это локалка - можно спамить кучей xhr.

Конечно открыть в новой вкладке кнопку "сохранить" не выйдет, однако открыть пару окон и вкладок с разными "рабочими пространствами"- можно.

Но за это конечно платишь оооочень дорого, и я тут даже не про деньги. Время разработки растет в десятки раз.

Например, Gmail: как я могу открыть несколько писем, каждое в своём окне? А никак, SPA этого не позволяет.

Хм,

позволяет

Ну или просто Command + Click, думаю Alt в другой системе тоже сработает.

Спасибо, не знал. Я привык открывать ссылки в новых окнах через Middle Click, а этот функционал не работает в Gmail. Через меню открывает в новом окне, а не вкладке. К слову, папки (там, где входящие, отправленные) по среднему клику открываются в новом окне, а через Ctrl — наоборот, нет.

Папки это ссылки, а письма это переход в другую часть SPA. Если включена строка состояния, то видны таргеты при наведении на папки.

Возможность переопределять стандартное контекстное меню браузера вообще зло само по себе.

В Gmail можно использовать html версию, тогда никаких проблем с этим. Постоянно её использую, очень удобно, грузится шустро, можно открывать кучу вкладок и ничего не будет тормозить, сжирать память гигабайтами и т.д.

SPA - это прекрасный инструмент в правильных руках. Он позволяет создавать отличные веб-приложения, основная задача которых - быстро работать с данными. Статистика, дашборды, редакторы, корпоративные инструменты - море всего требует реактивности, одной странички для работы и отсутствия перезагрузок.

SPA - это ужасающе и отвратительно, когда неумелые выкормыши экспресс-курсов вида "фронтенд-профессионал" пытаются пихать его везде. Обычные сайты-визитки, статичные лендинги, небольшие интернет-магазины - зачем там этот ужас, когда хватает простейшей статики? Зачем мне гигантское приложение на сайте, где меня интересует ценник на холодильник? К тому же, приложение дико глючное, стоит использовать любимый Сафари. Раньше на компе держали Internet Explorer, чтобы просмотреть сайты с ActiveX, а сейчас приходится держать лишний Firefox для просмотра SPA шедевров этих выдающихся личностей.

Сайт в исполняемом файле

Очень старая идея, наверное ей уже лет 30, я помню как такие сайты писали на Perl, потом на C++, потом Java сервлеты и Java аплеты. Там свои проблемы, получается мешанина html и обычного кода и со временем это становится болью.

Примечательно, что всё те же этапы развития повторяет сфера IoT. Прошивка - это такой же бинарник с интегрированными кусками HTML-кода в виде констант.

Если железо позволяет - внутри появляется файловая система с html файлами.

Никто не мешает при сборке приложения преобразовать исходники в формате html в любую структуру данных, хоть образ squahsfs, хоть дерево/словарь/массив строк. Вся файловая система, с кластерами/правами/контрольными суммами/кешированием - не всегда нужна.

PHP же - скрипт и шаблонизатор вместе.

И нигде на странице статьи нет упоминания названия этой технологии CGI.

Сразу вспоминается Навальный. Как можно было написать статью про CGI и ни разу не употребить её названия?

Потому что в статье речь не про CGI. CGI - это когда у нас есть веб-сервер, который на каждый запрос дёргает какой-то бинарник/интерпретатор чтобы сгенерить страницу. А здесь же идёт речь про случай, когда код, генерирующий страницы, вкомпилен непосредственно в бинарник самого веб-сервера, то есть составляет с ним единое целое (см. про вышеупомянутый RomPager, например).

Ну да. В той же Java/Kotlin можно и Spring Boot и Quarkus и Ktor на выходе будет один файл.

У меня статический сайт на Nicepage, там css файл 1 Мег. Я пытался чистить но все время что-то ломается. Как бы это сделать автоматически? Мне их этого css нужно процентов 5...

Скачай расширение для лисы css usage или что то подобное. Походи по сайту и оно накопит только используемые свойства.

Посмотрите в сторону PurgeCSS .

Если есть динамический контент (получаемый из БД, например), то необходимо будет добавить его стили в исключения.

Chrome внедрил кэширование «назад-вперёд» (back-forward caching) — теперь эта оптимизация реализована во всех основных браузерах, так что навигация вперёд-назад между страницами MPA стала практически мгновенной.

То есть, в хроме наконец реализовали то, что ещё 10 лет назад умела Opera 12?

Opera, насколько я помню, кэшировала только сами элементы страницы и содержимое форм. В наше время так действовать не получится - сегодня сайты (особенно вышеупомянутые SPA) обскриптованы по самое не хочу, и если просто закэшировать состояние DOM-дерева, многие сайты после загрузки из кэша сломаются нафиг - нужно сохранять полностью ещё и состояние скриптов, выполняемых на странице. Opera такое не умела, а вот в новом Хроме, по заверениям разработчиков, оно действительно работает.

Не любитель старой Оперы, но только что проверил — похоже, что состояние скриптов сохраняется.

А как конкретно проверили? Оно действительно восстанавливает js heap целиком, все таймеры, не успевшие сработать коллбэки, и все остальное из tasks queue?

Когда в свое время, засидевшись, слезал с "классической" Оперы, помню, что уже тогда некоторые сайты начали ломаться при загрузке из кэша...

Ну как минимум таймеры и значения переменных восстанавливаются, проверил на radar.veg.by. Без восстановления состояния там бы таймер с обратным отсчётом сбрасывался бы до ближайших 30 секунд, как при перезагрузке страницы. Что-то более тяжёлое из современного вы там вряд ли заведёте уже. Возможно, в каких-то случаях оно работало плохо или с ошибками, я не знаю. Оперой как основным браузером никогда не пользовался, только тестировал в ней свои сайты. Иногда сталкивался с неприятными багами в неожиданных местах при этом. Возможно, вы тоже сталкивались с какими-то ошибками в реализации.

Не знаю, что и как конкретно она сохраняла, но при использовании кнопки «Назад» ни один сайт никогда не ломался (а пользовался я ей довольно часто, да и сайты были типа google.ru — то есть, объём скриптов там уже тогда был приличный).

Интересно для хобби-проекта, но я лично бы не стал доверять таким решениям.

Если хочется раздавать только статику с одного публичного сервера - то nginx "и никаких гвоздей"!

Бинарник слушающий сокет? А забыли ли мы атаки с переполнением буфера, инжекцией параметров или просто какой-нибудь printf()?

Как только создаешь публичный сервер с открытыми портами - в течение нескольких часов набегает толпа китайских ботов-сканеров и шлют всякую ересь в надежде использовать какой-то эксплоит.

nginx надежен и протестирован миллионами. Не пускает куда не надо, умеет TLS, пишет логи и прекрасно справляется с тысячами HR, внезапно захотевших открыть вашу страничку с резюме в одно и то же время.

А забыли ли мы атаки с переполнением буфера, инжекцией параметров или просто какой-нибудь printf()?

Если использовать нормальные безопасные языки, то этого не будет.

«Безопасность» языка помогает защититься только от определённого класса проблем, но против банальных недосмотров они бессильны. Пример — если в веб-сервере не проверять выход выше корневой папки, то любой Петя прочитает с диска всё, до чего дотянутся его ../../
Ну или можно добавить интересные функции, из-за которых вообще бахнет так, что мало не покажется, привет Log4j.
Пример — если в веб-сервере не проверять выход выше корневой папки, то любой Петя прочитает с диска всё, до чего дотянутся его ../../

Вопрос в том, где вы это будете проверять. Если вы пишете код на C (или на go), то это надо проверять в каждой точке чтения файлов. Если вы пишете на более выразительных языках, то это достаточно проверить ровно в одном месте.


Ну или можно добавить интересные функции, из-за которых вообще бахнет так, что мало не покажется, привет Log4j.

Опять же, если язык достаточно выразительный, то нельзя.

Вопрос в том, где вы это будете проверять.

Я не хочу этого проверять. Вот вообще.

Не то, чтобы все эти проверки были чем-то плохим, просто я относительно слабо разбираюсь в вопросах безопасности. Так что, если условный nginx закрывает over9000 "стандартных" сценариев, пусть и ценой докер-образа в 60 МБ -- я возьму nginx.

А если весь сайт — это бинарь, умеющий отдавать зашитые константы файлы (как предложено), то там и нет никаких ../../ откуда можно какие-то файлы читать, вообще ничего нет, кроме одинокого запущенного бинаря с одной фунцией route(address) -> str :)

Полезность такого сайта стремится к 0 ;)

А откуда вы знаете, что условный nginx это закрывает, и его конфиг не позволяет читать файлы откуда-то ещё? Я этого не знаю, например.

Вопрос резонный. Принципы работы с безопасностью (для самых маленьких):

  1. Полной защиты не дает ничто (смотрим в сторону ZeroDay уязвимости, социальной инженерии, бекдоры от спецслужб). Вывод: наша задача (как людей не особо знакомых с безопасностью) -- закрыть наиболее ходовые сценарии, с минимальными затратами.

  2. В случае малого\среднего сайта безопасник - максимум один. А посылать всякую ересь в порты сервиса будет толпа китайских ботов-сканеров. Велика вероятность, что один из толпы заюзает таки эксплоит, с которым наш безопасник не знаком.
    Вывод: кастомные платформы рискованней поддерживаемой платформы с богатой историей.

Как выбирать сервер/framework для интернет-магазина/платформу для блога/etc:

  1. Спросить друга безопасника. Друг не только посоветует что-то, но еще и расскажет (а то и проверит) самые критичные дыры.

  2. Если друга безопасника нет - гуглим самое популярное решение. Пентест закладываем исходя из бюджета (в 90% случаев - не закладываем).

  3. Гуглим "10 popular vulnerabilities for your-platform-name", закрываем уязвимости из списка.

  4. Ставим напоминалку на через год: "обновить nginx/magento/wordpress/etc, продлить напоминалку".

  5. Расслабляемся.

  6. Идем настраивать бекапы.

  7. Расслабляемся

Друзья, безопасники, закрываем 10 уязвимостей… Не, извините, мне проще в этом своём хаскеле типами проверить, что я нигде не вылезаю за ../../.

И что unicode правильно парсится.

Пример — если в веб-сервере не проверять выход выше корневой папки, то любой Петя прочитает с диска всё, до чего дотянутся его ../../
Совсем не обязательно мапить веб-запрос напрямую в файловую систему, особенно при использовании своего собственного веб-сервера. Html можно генерировать на лету, а не загружать его каждый раз с диска — в этом и смысл.

Так-то можно ещё меньше зависимостей оставить, без docker'а, Go и sh-скриптов. Просто модулем к nginx запросы обрабатывать, мне приходилось такое реализовывать. НО это максимально нишевое решение с миллионом способов отстрелить себе ногу, и непонятно, зачем могут понадобиться такие костыли основной массе разработчиков.

Затем использовал докеровский инструмент scratch для минификации образа. Эта программа оставляет внутри только ядро и скрипт для загрузки всего необходимого, после запуска скачивает и устанавливает Alpine (130 МБ), берёт снаружи файлы веб-сайта — и начинает работать:

Ну неправда же, в докер образе нет ядра. Ну scratch это не какая-то отдельная программа, а способ сборки докер образа. Очень похоже на кривой перевод

И сама идея: скачивать при каждом запуске по 130 МБ ради того, чтобы уменьшить образ на 7 МБ?


Как-то не очень. И плохо сходится с идеей статьи о «минимуме зависимостей» и «только то, что нужно»

Эти 130 мегов нужны, чтобы скомпилировать веб-сервер из исходников со статической линковкой. Дальше вы на выходе получаете образ минимального размера, с которым можете делать что угодно.

Долговечность стека текущих зависимостей 20–30 лет?
А как решается проблема с https? Отказаться от него — браузеры начнут говорить сайт небезопасный (уже начинают), поддерживать — так лет через десять появится TLS1.7 а в TLS1.3 найдут чтонибудь ну очень ужасное и браузеры начнут ругатся на него. Даже если не найдут — как сертификат то обновлять? Каждый раз на старте бинарника (у нас один бинарник же — только в память сохранять) дергать Let's Encrypt на предмет сертификата? а что если протокол общения с Let's Encrypt сменится? Или Let's Encrypt в конкретной стране забанят (или он забанит страну)?
Или вешать nginx перед сервером? А нафига?


Если у нас сайт это набор статических страниц без js — уже чем хостить — то найдется.

У знакомого статичный сайт лежит на амазоне - недавно показывал в какие копейки хост обходится в год.

Oracle две виртуалки дает бесплатно. IO не очень, но крутит и Симфони, и Спринг бут с небольшими базами.

В России уже не даёт, а кому дал тех банит

Наслышан. А Амазон не банит?

Амазон и гугл пока работают, только с оплатой проблемы, как и везде

Обещали забанить, кстати, но тьфу-тьфу, виртуалка продолжает работать уже три месяца после того, как пришло письмо «мы вас отключили».

Небольшой статичный наверное можно на GtHub Pages совсем бесплатно положить.
А насчет сайта-бинарника — еще никто не вспомнил про архитектуру. Конечно, сейчас «дефолтная» amd64 почти везде, но я бы не закладывался на то, что это сохранится через 30 лет. Вполне может arm ее потеснить, он энергоэффективнее — значит arm хостинг постепенно станет дешевле.
Хотя сайт все равно как-то обновлять надо, скорее всего пересобирая из исходников при этом.

... можно запускать из под qemu-user :) Кстати, интересное извращение получится, можно попробовать заняться как-нибудь на выходных...

В Go кстати есть встроенные средства для embed.

import _ "embed"

//go:embed hello.txt
var s string
print(s)

У меня есть статичный сайт без JS, который я писал на Markdown с последующей конвертацией в HTML с помощью Python-Markdown.

Вообще, нужно было сделать справочник по своему миру для компании в Dungeons & Dragons. Какие-то существующие вики-решения по типу Fandom показались слишком сложными в управлении. Неплохим вариантом были Notion и Telegraph, но в первом было слишком много лишних функций и чужой брендинг, а во втором, наоборот, функций было слишком мало. К тому же руки чесались сделать что-то самому.

В итоге родился небольшой проект, работающий примерно так: я пишу Markdown с несколькими самописными модулями (навигация по страницам, относительные ссылки, шаблоны для статблоков), прогоняю его через конвертер и заливаю на Github Pages. Также на случай, если захочется хостить самому (на практиже же просто смотреть результат в процессе написания), есть простенький Bash скрипт для питоновского http.server, который ещё и обновления в MD исходниках смотрит и HTML страницы пересобирает.

На выходе получается что-то эдакое: https://kizhifox.github.io/dnd-shard-wiki/

P.s.: Спасибо за абзац про WebP, возможно ещё пикчи в него перегоню, а то об этом как-то сам забыл :)

Hugo? Не слышал о нём, пока не погуглил. Ну да я и не веб разработчик :)

А так да, получилось что-то похожее, только с меньшим функционалом. Но скорее было интересно самому что-то простое написать, поэтому готовые фреймворки даже не смотрел.

ну не знаю. Вот глиняные таблички были норм — ты их мог хотя бы пощупать. А что с этими байтами делать? только лишние слои абстракции

Вся нужная информация - в генах. А таблички всего несколько тысяч лет пока протянули.

В своё время вот пытались делать сайты на IntraWeb -там тоже всё делает бинарник. Не взлетело.

По сути, автор сделал аналог GitOps, только для статического сайта. Правда, я не очень понял претензию к чужим сервисам - что автору мешает хостить статику со своего же сервера, ну и билдить при деплое (если не нравится гитхаб, можно хоть на сервер пушить, а можно и по ftp заливать, коли совсем дело плохо).

На поиграться интересно, но это же 100% велосипед.

Так я не понял, теперь што js и react не нужОн чтоли? Што за жизнь, учишь сначала mvc-шный фреймворк с родным шаблонизатором и узнаешь, что такое давно не модно и все хотят отдельный фронт в виде SPA. Потом учишь фронт и вот оказывается, что SPA то и не нормально вовсе и снова взад к многостраничной статике.....вот это поворот! Нет, в чем то тут должен быть подвох!

Only those users with full accounts are able to leave comments. Log in, please.