Comments 72
аннулируют главные преимущества использования одностраничных приложений (SPA) вместо нормальных многостраничных сайтов (MPA):
Т.е., по-вашему, 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 — наоборот, нет.
Возможность переопределять стандартное контекстное меню браузера вообще зло само по себе.
В Gmail можно использовать html версию, тогда никаких проблем с этим. Постоянно её использую, очень удобно, грузится шустро, можно открывать кучу вкладок и ничего не будет тормозить, сжирать память гигабайтами и т.д.
SPA - это прекрасный инструмент в правильных руках. Он позволяет создавать отличные веб-приложения, основная задача которых - быстро работать с данными. Статистика, дашборды, редакторы, корпоративные инструменты - море всего требует реактивности, одной странички для работы и отсутствия перезагрузок.
SPA - это ужасающе и отвратительно, когда неумелые выкормыши экспресс-курсов вида "фронтенд-профессионал" пытаются пихать его везде. Обычные сайты-визитки, статичные лендинги, небольшие интернет-магазины - зачем там этот ужас, когда хватает простейшей статики? Зачем мне гигантское приложение на сайте, где меня интересует ценник на холодильник? К тому же, приложение дико глючное, стоит использовать любимый Сафари. Раньше на компе держали Internet Explorer, чтобы просмотреть сайты с ActiveX, а сейчас приходится держать лишний Firefox для просмотра SPA шедевров этих выдающихся личностей.
Сайт в исполняемом файле
Очень старая идея, наверное ей уже лет 30, я помню как такие сайты писали на Perl, потом на C++, потом Java сервлеты и Java аплеты. Там свои проблемы, получается мешанина html и обычного кода и со временем это становится болью.
Примечательно, что всё те же этапы развития повторяет сфера IoT. Прошивка - это такой же бинарник с интегрированными кусками HTML-кода в виде констант.
PHP же - скрипт и шаблонизатор вместе.
И нигде на странице статьи нет упоминания названия этой технологии CGI.
Сразу вспоминается Навальный. Как можно было написать статью про CGI и ни разу не употребить её названия?
Ну да. В той же Java/Kotlin можно и Spring Boot и Quarkus и Ktor на выходе будет один файл.
У меня статический сайт на Nicepage, там css файл 1 Мег. Я пытался чистить но все время что-то ломается. Как бы это сделать автоматически? Мне их этого css нужно процентов 5...
Скачай расширение для лисы css usage или что то подобное. Походи по сайту и оно накопит только используемые свойства.
в хроме есть такая функция
https://umaar.com/dev-tips/121-css-coverage/
Посмотрите в сторону PurgeCSS .
Если есть динамический контент (получаемый из БД, например), то необходимо будет добавить его стили в исключения.
SourceHut - хороший образец минимализма.
Когда-то сохранил себе в копилку идей понравившийся сайт https://oknaludyam.ru :)
https://web.archive.org/web/20180506234654/http://oknaludyam.ru/ хорош, а теперь дизайн слегка подпортили в угоду повышению конверсии или как оно там называется.
лучшее, что я когда-либо видел
Chrome внедрил кэширование «назад-вперёд» (back-forward caching) — теперь эта оптимизация реализована во всех основных браузерах, так что навигация вперёд-назад между страницами MPA стала практически мгновенной.
То есть, в хроме наконец реализовали то, что ещё 10 лет назад умела Opera 12?
Не знаю, что и как конкретно она сохраняла, но при использовании кнопки «Назад» ни один сайт никогда не ломался (а пользовался я ей довольно часто, да и сайты были типа google.ru — то есть, объём скриптов там уже тогда был приличный).
Интересно для хобби-проекта, но я лично бы не стал доверять таким решениям.
Если хочется раздавать только статику с одного публичного сервера - то nginx "и никаких гвоздей"!
Бинарник слушающий сокет? А забыли ли мы атаки с переполнением буфера, инжекцией параметров или просто какой-нибудь printf()?
Как только создаешь публичный сервер с открытыми портами - в течение нескольких часов набегает толпа китайских ботов-сканеров и шлют всякую ересь в надежде использовать какой-то эксплоит.
nginx надежен и протестирован миллионами. Не пускает куда не надо, умеет TLS, пишет логи и прекрасно справляется с тысячами HR, внезапно захотевших открыть вашу страничку с резюме в одно и то же время.
Ну или можно добавить интересные функции, из-за которых вообще бахнет так, что мало не покажется, привет Log4j.
Вопрос в том, где вы это будете проверять.
Я не хочу этого проверять. Вот вообще.
Не то, чтобы все эти проверки были чем-то плохим, просто я относительно слабо разбираюсь в вопросах безопасности. Так что, если условный nginx закрывает over9000 "стандартных" сценариев, пусть и ценой докер-образа в 60 МБ -- я возьму nginx.
Вопрос резонный. Принципы работы с безопасностью (для самых маленьких):
Полной защиты не дает ничто (смотрим в сторону ZeroDay уязвимости, социальной инженерии, бекдоры от спецслужб). Вывод: наша задача (как людей не особо знакомых с безопасностью) -- закрыть наиболее ходовые сценарии, с минимальными затратами.
В случае малого\среднего сайта безопасник - максимум один. А посылать всякую ересь в порты сервиса будет толпа китайских ботов-сканеров. Велика вероятность, что один из толпы заюзает таки эксплоит, с которым наш безопасник не знаком.
Вывод: кастомные платформы рискованней поддерживаемой платформы с богатой историей.
Как выбирать сервер/framework для интернет-магазина/платформу для блога/etc:
Спросить друга безопасника. Друг не только посоветует что-то, но еще и расскажет (а то и проверит) самые критичные дыры.
Если друга безопасника нет - гуглим самое популярное решение. Пентест закладываем исходя из бюджета (в 90% случаев - не закладываем).
Гуглим "10 popular vulnerabilities for your-platform-name", закрываем уязвимости из списка.
Ставим напоминалку на через год: "обновить nginx/magento/wordpress/etc, продлить напоминалку".
Расслабляемся.Идем настраивать бекапы.
Расслабляемся
Пример — если в веб-сервере не проверять выход выше корневой папки, то любой Петя прочитает с диска всё, до чего дотянутся его ../../Совсем не обязательно мапить веб-запрос напрямую в файловую систему, особенно при использовании своего собственного веб-сервера. Html можно генерировать на лету, а не загружать его каждый раз с диска — в этом и смысл.
Так-то можно ещё меньше зависимостей оставить, без docker'а, Go и sh-скриптов. Просто модулем к nginx запросы обрабатывать, мне приходилось такое реализовывать. НО это максимально нишевое решение с миллионом способов отстрелить себе ногу, и непонятно, зачем могут понадобиться такие костыли основной массе разработчиков.
Затем использовал докеровский инструмент scratch для минификации образа. Эта программа оставляет внутри только ядро и скрипт для загрузки всего необходимого, после запуска скачивает и устанавливает Alpine (130 МБ), берёт снаружи файлы веб-сайта — и начинает работать:
Ну неправда же, в докер образе нет ядра. Ну scratch это не какая-то отдельная программа, а способ сборки докер образа. Очень похоже на кривой перевод
Долговечность стека текущих зависимостей 20–30 лет?
А как решается проблема с https? Отказаться от него — браузеры начнут говорить сайт небезопасный (уже начинают), поддерживать — так лет через десять появится TLS1.7 а в TLS1.3 найдут чтонибудь ну очень ужасное и браузеры начнут ругатся на него. Даже если не найдут — как сертификат то обновлять? Каждый раз на старте бинарника (у нас один бинарник же — только в память сохранять) дергать Let's Encrypt на предмет сертификата? а что если протокол общения с Let's Encrypt сменится? Или Let's Encrypt в конкретной стране забанят (или он забанит страну)?
Или вешать nginx перед сервером? А нафига?
Если у нас сайт это набор статических страниц без js — уже чем хостить — то найдется.
У знакомого статичный сайт лежит на амазоне - недавно показывал в какие копейки хост обходится в год.
Oracle две виртуалки дает бесплатно. IO не очень, но крутит и Симфони, и Спринг бут с небольшими базами.
А насчет сайта-бинарника — еще никто не вспомнил про архитектуру. Конечно, сейчас «дефолтная» amd64 почти везде, но я бы не закладывался на то, что это сохранится через 30 лет. Вполне может arm ее потеснить, он энергоэффективнее — значит arm хостинг постепенно станет дешевле.
Хотя сайт все равно как-то обновлять надо, скорее всего пересобирая из исходников при этом.
В 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, возможно ещё пикчи в него перегоню, а то об этом как-то сам забыл :)
В своё время вот пытались делать сайты на IntraWeb -там тоже всё делает бинарник. Не взлетело.
По сути, автор сделал аналог GitOps, только для статического сайта. Правда, я не очень понял претензию к чужим сервисам - что автору мешает хостить статику со своего же сервера, ну и билдить при деплое (если не нравится гитхаб, можно хоть на сервер пушить, а можно и по ftp заливать, коли совсем дело плохо).
На поиграться интересно, но это же 100% велосипед.
Так я не понял, теперь што js и react не нужОн чтоли? Што за жизнь, учишь сначала mvc-шный фреймворк с родным шаблонизатором и узнаешь, что такое давно не модно и все хотят отдельный фронт в виде SPA. Потом учишь фронт и вот оказывается, что SPA то и не нормально вовсе и снова взад к многостраничной статике.....вот это поворот! Нет, в чем то тут должен быть подвох!
Возрождение простых сайтов. Статика, 0kB JS, ничего лишнего