В первой части я утверждал, что пришло время подумать, как заменить современную веб-платформу для приложений. Причины — её низкая производительность и в принципе нерешаемые проблемы безопасности.Кое-кто решил, что я пишу слишком в негативном ключе и не обращаю внимания на положительные стороны веба. Так и есть: первая часть была в стиле «Обсудим факт, что мы попали в глубокую яму», а вторая часть — «Как разработать кое-что получше?» Это огромная тема, так что она на самом деле двумя частями не ограничится.
Назовём нашего конкурента вебу NewWeb (э, брендингом можно заняться потом). Для начала нужно понять, почему веб изначально стал успешным. Веб обошёл другие технологии создания приложений с лучшими инструментами для разработки GUI, так что у него явно есть какие-то качества, которые перевешивают недостатки. Если мы не будем соответствовать этим качествам, мы обречены.
Создание GUI в Matisse, редакторе UI с автоматическим выравниванием и ограничителями. Да здравствует (новый стильный) король?
Нужно также сконцентрироваться на дешевизне. У веба многочисленные группы разработчиков. Бoльшая часть их работы дублируется или выбрасывается, кое-что можно использовать повторно. Возможна и новая разработка в небольшом объёме… но по большому счёту любую технологию NewWeb придётся собирать из кусочков существующего программного обеспечения. Беднякам не приходится выбирать.
Вот мой личный список пяти главных свойств веба:
- Развёртывание и изоляция в песочнице
- Простота в освоении пользователями и разработчиками
- Устранение дихотомии документ/приложение
- Продвинутое оформление и брендинг
- Открытый код и бесплатное использование
Это не совсем то, что принято считать главными принципами архитектуры: если опросить разработчиков, то большинство из них, вероятно, назовут сутью архитектуры веба URL, просмотр исходников, кроссплатформенность, HTTP и так далее. Но это всё просто детали реализации. Веб взял верх над Delphi и Visual Basic не потому что JavaScript настолько крут. Есть более глубокие причины.
Перечисленные выше вещи, в принципе, довольно понятны. Я более подробно проанализирую их по ходу статьи. Для победы над вебом недостаточно просто повторить его сильные стороны, мы должны идти дальше и предложить уникальные улучшения, которые веб не способен легко интегрировать. Иначе нет смысла: вместо своего проекта мы будем просто работать над улучшением веба.
В этой статье я предлагаю две вещи: определённые принципы архитектуры, которым, по-моему, должен следовать любой серьёзный конкурент веба, и конкретный пример, собранный из различных open source проектов. Многим читателям не понравится конкретный пример, потому что им по душе другие проекты или языки программирования, в этом нет ничего страшного. Мне не важно. Это просто иллюстрация —? по-настоящему важны принципы. Я называю конкретные кодовые базы только для иллюстрации, что эти мечты не совсем нереалистичны.
Принципы архитектуры
У веба отсутствует вразумительная философия архитектуры, по крайней мере, в отношении приложений. Вот каких необходимых вещей ему не хватает, на мой взгляд:
- Ясное понятие идентификаторов приложений.
- Единое представление данных от бэкенда к фронтенду.
- Бинарные протоколы и API.
- Аутентификация пользователей на уровне платформы.
- Ориентированная на IDE разработка.
- Компоненты, модули и отличная система вёрстки UI ?— точно как в обычной разработке для настольных компьютеров или мобильных устройств.
- Также понадобятся вещи, с которыми хорошо справляется веб: мгновенный запуск стриминговых приложений без инсталляции или необходимости ручного обновления, изоляция этих приложений в песочнице, сложная стилизация UI, сочетание и и приведение в соответствие «документального» и «программного» материала (вроде возможности связать определённые виды приложений), возможность постепенного обучения и архитектура, которая не затрудняет разработчикам создание слишком сложных UI.
Первые четыре пункта, выделенные жирным, связаны с безопасностью, поскольку именно проблемы с безопасностью вынудили меня занять столь радикальную позицию. Возможно, низкую производительность веба можно исправить новым фреймворком JavaScript —? может быть. Но я не думаю, что можно устранить проблемы с безопасностью. В последующих статьях я рассмотрю пункты, которые не выделены жирным.
Идентификаторы приложений и ссылки
Чтобы получить преимущества веба по развёртыванию и изоляции в песочнице, требуется некий браузер для приложений. Неплохо было бы получить возможность ссылаться на отдельные части приложения как на части гипертекстового документа. Это ключевой элемент успеха веба:? страница с поисковыми результатами Amazon похожа на некое приложение, но мы можем ссылаться на него, так что это одновременно и документ.
Но наш браузер приложений не должен физически напоминать веб-браузер. Посмотрите свежим взглядом: UI веб-браузера не идеален.
URL — основная часть дизайна любого браузера, но иногда он вносит путаницу!
Первая проблема в том, что URL'ы проникают повсюду в UI. Адресная строка постоянно содержит случайные биты из памяти браузера, закодированные в таком виде, который сложно понять и людям, и машинам, что ведёт к параду эксплоитов. Если бы десктопное приложение выгружало случайные внутренние переменные в строку заголовка, мы бы посчитали это серьёзным багом, угрожающим репутации фирмы, так почему здесь мы должны это терпеть?
Вторая проблема в том, что машинам тоже сложно воспринимать URL'ы (здесь возможно создание сумасшедших эксплоитов). Даже не учитывая хитрых трюков кодирования вроде этого, в вебе есть различные способы установить идентичность приложения. Браузеру требуется некое понятие идентичности приложения для отделения друг от друга хранилищ кукисов и для отслеживания выданных разрешений. Это «источник» (origin). Со временем концепция источника в вебе эволюционировала, и теперь её в сущности невозможно сформулировать. RFC 6454 пытается сделать это, но в самом документе написано:
Со временем многие технологии сошлись на концепции источника как на удобной единице изоляции. Однако многие из ныне используемых технологий, такие как куки [RFC6265], созданы раньше, чем современная концепция источника в вебе. У этих технологий часто другие единицы изоляции, что ведёт к уязвимостям.
Например, подумайте, что мешает вашему серверу установить куки для домена .com. А что насчёт kamagaya.chiba.jp? (это не веб-сайт, а просто раздел иерархии, как и .com!)
Возможность неожиданно поставить ссылку на часть приложения, которая не получает от этого никакой выгоды и не ожидает этого — один из источников проблемы «опасных ссылок». Сильно URL-ориентированный дизайн подвергает всё ваше приложение опасности инъекции данных со стороны посторонних злоумышленников. Это ограничение дизайна, которое известно тем, что с ним практически невозможно бороться, но оно беспечно поощряется самой архитектурой веба.
Тем не менее, возможность поставить ссылку на середину приложения из документов и наоборот была бы очень приятной, если всё работает как задумано разработчиками. Итак, сформулируем пару требований:
Требование: идентичность приложения (изоляция) должна быть простой и предсказуемой.
Требование: мы должны иметь возможность поставить глубокую ссылку на приложение, но не всегда.
К их чести, архитекторы Android понимали эти требования и предложили решения. Отсюда мы можем начать:
- Идентичность приложения определяет публичный ключ. Все документы, подписанные одним ключом, изолированы в одном домене. Для определения изоляции не используется разбор строк.
- Приложения могут подписаться на получение строго типизированных пакетов данных, которые просят их открыться в какое-то состояние. Android называет эту концепцию «намерениями» (intents). Намерения на самом деле не очень строго типизированы в Android, но могли быть такими. Их можно использовать также для внутренней навигации, но чтобы разрешить ссылки из какого-то другого приложения, намерение должно быть опубликовано в манифесте приложения. По умолчанию приложения не реагируют на ссылки.
- Где найти приложение для скачивания? Доменное имя — достаточно хорошая позиция для начала. Хотя мы можем поддерживать и скачивания по HTTP[S], но мы находим сервер NewWeb по хорошо известному порту и забираем код оттуда. Так что доменное имя становится начальной точкой для получения приложения, но в остальных отношениях не такой важной.
Чтобы различать URL'ы и чужие намерения от наших собственных, назовём чужие линк-пакетами.
Отключение приёма внешних ссылок по умолчанию понизит ссылочную связность NewWeb, но улучшит безопасность. Может быть, это плохой компромисс и он станет фатальным. Но многие ссылки, которые люди могут теоретически создавать в современном вебе, по сути бесполезны или из-за требований аутентификации, или потому что не содержат никакого осмысленного начального состояния (многие SPA). Поэтому приложения минимизируют область атаки. Вредоносная ссылка, которая является стартовой точкой такого большого количества эксплоитов, немедленно становится менее опасной. Это кажется ценным достижением.
Но есть и другие преимущества —? важность доменного имени для веб-приложений делает соблазнительным для провайдеров конфисковать домены, которые не нравятся их руководству. Хотя простые сайты можно перенести на другой домен без особых проблем, более сложные сайты могут дорожить сложившейся репутацией почтовых адресов, токенов OAuth и так далее, для них это более болезненная процедура. Секретные ключи могут быть потеряны или украдены, но то же самое с доменными именами. Если вы потеряли секретный ключ — по крайней мере, это только ваша вина.
Что касается остальных частей браузерного UI, от них, вероятно, можно избавиться. Вкладки могут пригодиться, но кнопка перезагрузки страницы никогда не должна использоваться, а кнопку возврата в предыдущее состояние можно встроить в само приложение, если в ней есть смысл, а-ля iOS.
Как создать браузер приложений? Хотя NewWeb довольно сильно отличается от веба, базовый UI полноэкраннных приложений вполне стандартен, а пользователи захотят переключаться туда и назад. Так почему бы не форкнуть Chromium и не добавить вкладку в новом режиме?
(Правка: некоторые поняли вышесказанное как «использовать Chrome для всего, что здесь перечислено» — это не то, что я имел в виду. Я имел в виду использование его реализации UI со вкладками, чтобы у вас были открыты рядом приложения NewWeb и OldWeb. Но UI с вкладками несложно сделать, и необязательно использовать Chromium, браузер приложений тоже может быть созданным с нуля приложением).
Единое представление данных
Может быть концепция линк-пакетов звучит немного туманно. Что это такое? Для более чёткого определения нам нужны структуры данных.
В вебе существует масса способов сделать это, но все они на основе текста. Напомню тезис из моей прошлой статьи: у текстовых протоколов (не только у JSON) есть фундаментальная уязвимость: это «внутриполосная» сигнализация буфера, то есть чтобы выяснить, где заканчиваются данные, нужно прочитать их все в поиске конкретной последовательности символов. Эти последовательности могут быть законной частью данных, то есть вам нужен механизм экранирования. А потом, поскольку эти протоколы предполагаются как человекочитаемые или хотя бы нердочитаемые, часто возникают странные пограничные случаи с обработкой пробелов или канонизированным Юникодом, что приводит к эксплоитам, вроде атак с разделением заголовка HTTP.
В прежние времена текстовые протоколы помогали веб-разработчикам. Просмотр исходника определённо помог мне столько раз, что я не могу сосчитать. Но теперь средний размер веб-страницы превышает 2 мегабайта, не говоря уже о веб-приложениях. Даже скучные веб-странички со статичным текстом часто содержат массу минифицированных скриптов, в которых без машинной помощи вы не сможете даже начать разбираться. Преимущества текстовых протоколов кажутся меньше, чем в прошлые времена.
Примитивный декомпилятор
Если честно, в последние годы веб медленно отказывается от текстовых протоколов. HTTP/2 бинарный. И разрекламированный “WebAssembly” — это бинарный способ выражения кода, хотя он на самом деле не решает проблем, о которых мы говорили. Но тем не менее.
Требование: сериализация данных должна быть автоматической типизированной, бинарной и неизменной от хранилища данных до фронтеда.
Код для сериализации не только утомительно писать, но это ещё и серьёзный вектор атаки. Хорошая платформа должна взять задачу на себя. Давайте определим в самом примитивном виде синтаксис для выражения структур данных:
enum SortBy {
Featured,
Relevance,
PriceLowToHigh,
PriceHighToLow,
Reviews
}
@PermazenType
class AmazonSearch(
val query: String,
val sortBy: SortBy?
) : LinkPacketВ вебе эквивалентом этого будет URL на сайте amazon.com. Он определяет структуру данных неизменного типа для обозначения запроса на открытие приложения в некоем состоянии.
Эта структура данных помечена как
@PermazenType. Что это значит?Если мы серьёзно относимся к коду с префиксированной длиной, строгой типизацией защитой от инъекций по всему стеку, то придётся что-то сделать с SQL. Язык структурированных запросов — приятный и хорошо понятный способ выразить сложные запросы к разнообразным исключительно мощным движкам БД, поэтому его жалко. Но SQL — это текстовый API. Хотя SQL-инъекции — один из самых простых типов эксплоитов, которые легко понять и исправить, но это также один из самых распространённых багов на веб-сайтах. Ничего удивительного: если использовать SQL на веб-сервере самым очевидным образом, то он будет нормально работать, но незаметно сделает сервер уязвимым для взлома. Параметризованные запросы помогают, но это сбоку привинченное решение, которое не в каждой ситуации можно использовать. Технологический стек создаёт для всех нас хорошо замаскированный медвежий капкан, и наша цель — минимизировать соотношение рисков и функциональности.
У SQL имеются и некоторые другие проблемы. Вы быстро столкнётесь с проблемой объектно-реляционного отображения. Результаты выполнения SQL-запроса нельзя нативно отправить по соединению HTTP или встроить в веб-страницу, так что всегда потребуется некая трансформация в другой формат. SQL скрывает от вас производительность нижележащих запросов. Бэкенд сложно масштабировать. Изменения схемы зачастую требуют заморозки таблицы, так что их невозможно развернуть без неприемлемого даунтайма.
Движки NoSQL ненамного лучше: они обычно исправляют одну или две из этих проблем, но за счёт отбрасывания решений SQL для всего остального. В итоге вы часто застреваете с решением, которое иное, но не обязательно лучшее. В результате крупнейшие компании вроде Google и Bloomberg тратят много времени, пытаясь найти способ масштабировать базы данных SQL (F1, ComDB2).
Permazen — это новый подход к хранению данных, который восхищает меня в данный момент. Цитата с их сайта:
Permazen — совершенно новый подход к стойкому программированию. Вместо того, чтобы начинать разработку со стороны технологии хранения, он начинает со стороны языка программирования, задавая простой вопрос: «Какие проблемы присущи стойкому программированию, независимо от языка программирования или технологии СУБД, и как их можно решить на уровне языка наиболее простым, самым корректным и самым естественным с точки зрения языка способом?»
Permazen — это библиотека Java. Однако её архитектуру и техники можно использовать на любой платформе или языке. Ей нужно сортированное хранилище «ключ-значение» такого типа, какой могут предоставить многие облачные провайдеры (она также может использовать RDBMS в качестве хранилища K/V), но всё остальное делается внутри библиотеки. У неё нет таблиц или SQL. Вместо этого она:
- Использует операторы хостового языка для осуществления объединений и пересечений (соединений).
- Схемы напрямую определяются классами, не требуется устанавливать объектно-реляционное отображение.
- Может производить пошаговую эволюцию схемы «точно в срок», устраняя необходимость в заморозке таблицы для изменения представления данных в хранилище.
- Транзакции установлены однозначно, а копирование данных из транзакции и назад чётко контролируется разработчиком.
- Отслеживание изменений, так что вы можете получать обратные вызовы, когда изменяются лежащие в основе данные, в том числе между процессами (если хранилище K/V это поддерживает, а часто так и есть).
- Есть интерфейс командной строки, позволяющий осуществлять запросы и работать с хранилищем данных (например, инициировать миграцию данных, если вас не устраивает миграция по расписанию), и GUI.
В самом деле, вам просто нужно почитать великолепный доклад или посмотреть слайды (в слайдах используется старое название библиотеки, но это тот же самый софт). Permazen не слишком хорошо известна, но это самый умный и ловкий подход к тесному интегрированию хранилища данных с объектно-ориентированным языком, какой я когда-либо видел.
Одна из интересных особенностей Permazen — то, что вы можете использовать «снимки транзакций» для сериализации и десериализации графа объекта. Этот снимок включает в себя даже индексы, то есть вы можете транслировать данные в локальное хранилище, если памяти мало, и уже над ним выполнять запросы по индексу. Теперь должно стать понятным, как эта библиотека унифицирует хранение данных с поддержкой офлайновой синхронизации. Разрешение конфликтов можно осуществлять транзакционно, поскольку все операции Permazen способны выполняться внутри сериализуемых транзакций (если хотите бесконфликтную работу в стиле Google Docs, которая требует библиотеки операционного преобразования).
Необязательно в NewWeb использовать именно такой подход. Вы можете выбрать что-то немного более традиционное вроде protobuf, но тогда придётся использовать специальный IDL, что одинаково неудобно во всех языках, а также помечать тегами поля. Вы могли бы использовать CBOR или ASN1. В моём текущем проекте Corda мы создали собственный движок для сериализации объектов, построенный на AMQP/1.0. В нём по умолчанию сообщения описывают сами себя, так что для каждого конкретного бинарного пакета вы всегда получаете схему —? и поэтому там доступна функция просмотра исходников, как в XML или JSON. AMQP предпочтителен, потому что это открытый стандарт, а базовая система типов довольно хороша (например, он узнаёт даты и аннотации).
Смысл в том, что рискованно принимать данные из потенциально вредоносных источников, так что в рамках формата желательно получить столько степеней свободы, сколько возможно, и максимальное количество проверок целостности. Все буферы должны быть с префиксами длины, так что пользователи не могут попытаться инъецировать вредоносные данные в поле — такие попытки будут прекращаться на ранней стадии. Данные должны быть тщательно проверены при загрузке, а лучшее место для такой проверки — система типов и конструкторы самих структур данных, тот способ, о которым вы могли уже забыть. Схемы помогают понять, какой должна быть структура, мешая злоумышленникам использовать смешение типов.
Несмотря на абсолютно бинарную природу предложенной схемы, можно произвести одностороннее преобразование в текст для отладки и в образовательных целях. На самом деле Permazen и это умеет.
Простота и поэтапное обучение
У систем типов есть одна проблема — они привносят дополнительную сложность. Разработчикам, которые не сталкивались с типами, они кажутся некоей бессмысленной бюрократией. А без соответствующих инструментов бинарные протоколы могут быть сложнее для изучения и отладки.
Требование: простота в освоении
Уверен, что значительная часть успеха веба объясняется тем, что он по сути не типизирован. Всё здесь — просто строки. Плохо для безопасности, производительности и удобства обслуживания, но очень хорошо для обучения.
Один из способов обращения с такой структурой в мире веба — постепенная типизация в версиях JavaScript. Это хорошая и ценная исследовательская работа, но такие диалекты не нашли широкого применения, и большинство новых языков хотя бы отчасти строго типизированы (Rust, Swift, Go, Kotlin, Ceylon, Idris…).
Ещё одним способом выполнения этого требования может стать умная IDE: если позволить разработчикам сначала работать с нетипизированными структурами (всё что определяется как
Any), среда выполнения может попробовать определить, какими должны быть исходные типы, и транслировать эту информацию обратно в IDE. Затем она может предложить замену на лучшие аннотации типов. Если разработчик сталкивается с ошибками приведения типа во время работы программы, то IDE может предложить снова ослабить ограничение.Конечно, такой подход обеспечивает меньшую безопасность и удобство обслуживания, чем если заставить разработчика самого заранее продумывать типы, но даже относительно слабые эвристически выставленные типы, которые часто приводят к ошибкам во время выполнения, всё равно защищают против большого количества эксплоитов. Среды выполнения вроде JVM и V8 уже собирают информацию о типах такого рода. В Java 9 есть новый API, позволяющий контролировать виртуальную машину на низком уровне (JVMCI), он занимается таким профилированием —? сейчас было бы гораздо проще экспериментировать с такого рода инструментами.
Языки и виртуальные машины
Какой язык должна использовать NewWeb? Конечно, это непростой вопрос: платформа не должна стать вычурной.
За прошедшие годы предпринималось много попыток ввести в веб другие языки, кроме JavaScript, но все они оказались неудачными, не получив консенсуса со стороны разработчиков браузеров (в основном, со стороны Mozilla). На самом деле, в этом отношении веб возвращается в прошлое —? вы могли запускать Java, ActionScript, VBScript и другие языки, но производители браузеров систематически удаляли с платформы все не-JavaScript плагины. Это какой-то позор. Безусловно, можно же было сохранить конкуренцию. Грустный приговор веб-платформе, что WebAssembly — единственная попытка добавить новый язык, и этим языком является C… на котором, я надеюсь, вы не захотите писать веб-приложения! Достаточно нам XSS, чтобы добавлять сверху ещё уязвимости типа двойного освобождения одной и той же памяти.
Всегда проще согласиться с проблемой, чем с решением, но ничего страшного —?пришло время выдвинуть (более) противоречивый тезис. Ядром моего личного дизайна NewWeb стала бы JVM. Это не удивит тех, кто меня знает. Почему JVM?
- HotSpot поддерживает больше различных языков программирования, чем любая другая виртуальная машина, а принцип дешевизны диктует максимально возможное использование кода open source.
Да, это значит, что я хочу оставить возможность использовать JavaScript (на высокой скорости), помимо Ruby, Python, Haskell, и да ?—? C, C++ и Rust тоже останутся в игре. Всё это возможно благодаря двум действительно классным проектам, которые называются Graal и Truffle, о которых я подробно рассказывал. Эти проекты позволяют JVM запускать даже код на неожиданных языках (таких как Rust) в виртуализированной среде, быстро и и интероперабельно. Мне неизвестна никакая другая виртуальная машина, которая органично смешивает вместе так много языков и делает это с такой высокой производительностью. - Песочница OpenJDK годами подвергалась упорным атакам, и разработчики браузеров усвоили ряд болезненных уроков. Последний 0-day эксплоит датируется 2015-м годом, а предыдущий был в 2013-м. Всего два 0-day эксплоита в песочнице за пять лет — неплохо, на мой взгляд, особенно с учётом того, что после каждого из них были усвоены уроки и со временем сделаны фундаментальные улучшения в безопасности. Ни у какой песочницы нет идеальной репутации, так что в реальности всё сводится к личным предпочтениям —? какой уровень безопасности считать достаточным?
- Существует огромное количество высококачественных библиотек, которые складывают ключевые фрагменты головоломки, такие как Permazen и JavaFX.
- Так получилось, что я достаточно хорошо знаю JVM и мне нравится Kotlin, который подходит для бэкенда JVM.
Я понимаю, что многие не согласятся с моим выбором. Без проблем —? те же самые идеи архитектуры можно реализовать на базе Python или V8, или Go, или Haskell, или чего угодно другого, в чём вы плаваете. Лучше выбрать что-нибудь с открытыми спецификациями и наличием конкурирующих реализаций (как у JVM).
Политика Oracle меня не беспокоит, потому что у Java открытые исходники. Среди высококачественных и высокопроизводительных open source рантаймов небольшой выбор. Существующие проекты созданы крупными корпорациями, которые замарали себя спорными решениями в прошлом. На различных этапах своего развития веб находился под влиянием или прямым контролем Microsoft, Google, Mozilla и Apple. Все они совершали поступки, которые я считаю предосудительными: это свойственно крупным компаниям. Вам не захочется вечно соглашаться с их поступками. Oracle вряд ли выиграет конкурс популярности, но преимущество открытого кода в том, что ей и не придётся в нём участвовать.
Конкретно из Google Chrome я бы кое-что позаимствовал. Мой браузер приложений должен поддерживать эквивалент WebGL (т.е. eGL), и проект Chromium ANGLE подходит для этой цели. Браузер приложений должен незаметно автоматически обновляться, как это делает Chrome, а движки автоматических обновлений Google тоже распространяются под свободной лицензией. В конце концов, хотя формат Pack200 сильно сжимает код, не повредило бы использование качественных кодеков вроде Zopfli.
RPC
Бинарных структур данных недостаточно. Нужны ещё и бинарные протоколы. Стандартный способ связать клиента с сервером является RPC.
В настоящее время один из самых крутых британских стартапов — Improbable. Недавно разработчики опубликовали отличный пост в блоге о том, как они перешли с REST+JSON на gRPC+protobuf от браузера к серверу. Improbable описывает результат как «нирвану безопасной типизации». Браузеры справляются с этим не так легко, как с HTTP+XML или JSON, но с использованием нужных библиотек JavaScript вы можете прикрутить сверху нужный стек. Это хорошая мысль. Если вернуться в реальный мир, где мы все пишем веб-приложения, однозначно следует рассмотреть такой вариант.
В разработке протоколов RPC следует использовать имеющийся опыт. Мой идеальный RPC поддерживает:
- Возвращение фьючерсов (обещаний) и ReactiveX Observables, так что вы можете транслировать пуш-события естественным путём.
- Возвращение потоков байтов большого или бесконечного размера (например, для прямых видеотрансляций).
- Контроль потока при передаче трафика с низким/высоким приоритетом.
- Версионирование, эволюция интерфейса, проверка типов.
Опять же, в проекте Corda мы проектируем стек RPC именно с такими свойствами. Мы ещё не выпустили его в виде отдельной библиотеки, но надеемся в будущем сделать это.
HTTP/2 — одна из самых последних и наиболее проработанных частей веба, это достаточно приличный фреймовый транспортный протокол. Но он унаследовал слешком много хлама от HTTP. Только представьте, какие хаки становятся возможными, если отказаться от методов HTTP, которые всё равно никогда не используются. Странный подход HTTP к описанию состояния не нужен. HTTP сам по себе не меняет состояние в процессе исполнения, а вот приложениям нужны сессии с хранением состояния, так что разработчикам приложений приходится добавлять поверх протокола собственную реализацию, используя мешанину легко воруемых кукисов, токенов и так далее. Это ведёт к проблемам вроде атак фиксации сессии.
Лучше более чётко разделить всё по слоям:
- Шифрование, аутентификация и управление сессиями. TLS неплохо справляется. Можно просто использовать его.
- Транспорт и контроль потока. Этим занимается HTTP/2, но протоколы обмена сообщениями вроде AMQP тоже справляются с задачей, и без груза наследия прошлого.
- RPC
Очевидно, стек RPC интегрирован с фреймворком структуры данных, так что все передачи данных типизированы. Разработчикам никогда не понадобится выполнять парсинг вручную. Именование в RPC — это простое сравнение строк. Следовательно, отсутствуют уязвимости с выходом за пределы текущего каталога (path traversal).
Аутентификация пользователей и сессии
NewWeb не будет использовать куки. Для идентификации сессий лучше подходят пары открытого и закрытого ключей. Веб идёт в этом направлении, но чтобы сохранить совместимость с существующими веб-приложениями требуется сложный этап «привязки», на котором токены владельца вроде кукисов соединяются с несущей криптографической сессией, а это привносит дополнительную сложность в важный компонент безопасности —? от этого этапа можно отказаться при полном редизайне. Сессии идентифицируются на стороне сервера только по открытому ключу.
Аутентификация пользователя — одна из самых сложных вещей, которые трудно правильно реализовать в веб-приложении. Я ранее высказал несколько мыслей по этому поводу, так что не буду повторяться. Достаточно сказать, что привязку сессии к почтовому адресу лучше выполнять на стороне базовой платформы, а не постоянно изобретать велосипед на уровне приложений. Сертификата TLS на клиентской стороне вполне достаточно, чтобы реализовать базовую систему единого входа, где поток операций вроде «отправить письмо и подписать сертификат в случае получения» настолько дёшев, что провайдеры бесплатных сертификатов в стиле Let's Encrypt станут вполне реальными.
Этот подход основан на уже существующих технологиях, но при этом серьёзно сократит количество фишинга, взлома баз с паролями, брутфорса и многих других проблем, связанных с безопасностью.
Заключение
Платформа, которая хочет конкурировать с вебом, должна серьёзно озаботиться вопросами безопасности, поскольку это важнейшее обоснование для её создания и конкурентное преимущество. Это главная вещь, которую невозможно легко исправить в вебе. То есть нам нужны: бинарные структуры данных с безопасной типизацией и бинарные API, RPC, криптографические сессии и идентификация пользователей.
В новом вебе также есть изоляция кода в песочнице и стриминг контента, UI с хорошим макетированием, но в то же время хорошо реагирующий и с поддержкой стилей, некий способ смешивать вместе документы и приложения, как это делает веб, и очень продуктивная среда разработки. Ещё нам следует рассмотреть политику нового веба.
Обсудим эти вопросы в следующей статье.
Комментарии (81)
Smokin
02.10.2017 09:52+1Если такое большое недовольство защитой веба, так почему не попытаться улучшить ее, а не заменять веб целиком? Неужели это будет проще?
staticlab
02.10.2017 10:43+10Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим.
Кто был ничем, тот станет всем.
andreymal
02.10.2017 10:46+2Да, проще. В вебе слишком много легаси и обратной совместимости аж с девяностых, когда веб использовался для совершенно других задач.
Конечно, это кажется сложнее, потому что надо разрабатывать с нуля. Но рано или поздно количество всяких архитектурных костылей и прослоек достигает критического, или же изначально заложенные идеи начинают слишком уж мешать, и в итоге почти любой проект рано или поздно переписывается с нуля или почти с нуля. Иногда даже не раз. Netscape > Mozilla, Firefox > Servo (возможно), IE > Edge (не полностью с нуля, но уверяют о очень капитальных переделках), DOS/Windows 9x > Windows NT (в контексте ОС для десктопа), Win32 > UWP (или на чём там нынче под вин10 пишут, сильно не слежу), Mac OS 9 > Mac OS X, Blender 2.4 > Blender 2.5 ну и так далее.
staticlab
02.10.2017 09:59+4Ещё одним способом выполнения этого требования может стать умная IDE: если позволить разработчикам сначала работать с нетипизированными структурами (всё что определяется как Any), среда выполнения может попробовать определить, какими должны быть исходные типы, и транслировать эту информацию обратно в IDE. Затем она может предложить замену на лучшие аннотации типов. Если разработчик сталкивается с ошибками приведения типа во время работы программы, то IDE может предложить снова ослабить ограничение.
Это ж ТайпСкрипт!
Rumlin
02.10.2017 10:08+1По-моему логичнее идти к некой виртуальной машине-браузеру. Случайно создаваемая машина-песочница, которая не имеет возможности взаимодействовать с хостом и не может никак сообщить о нем и его пользователе, и не может нанести вред хосту.
Revertis
02.10.2017 10:26Но XSS останется.
Веб кривой до невозможности, с этим трудно спорить. Но заменить его можно только сообща. Либо имея достаточно ресурсов, как у Фейсбука, например. И цель у них может быть соответствующая —навязатьпредоставить юзерам браузер (на самом деле небраузерный клиент к соцсети), который будет работать по очень хитрому протоколу (например как Скайп в своё время) и не допускать вырезания рекламы.
Вот тогда и не будет всяких XSS и нанесения вреда хосту.
ghosthope
02.10.2017 10:31Сразу возникает вопрос, а что делать с upload/download файлов? Если нет доступа к хосту то и нет доступа к файлам, в таком случае вещи из серии File API теряют смысл, что, в рамках современности, достаточно актуально, много приложение которые есть и будут завязываться на данную функциональность.
chersanya
02.10.2017 10:54+1Да очень легко — при любом запросе к «настоящей» хостовой файловой системе пользователь видит системный запрос «разрешить xxx доступ к yyy?» и всё. В этом плане, если помните, очень удачно было реализовано в мобильных приложениях на J2ME — при обращении к файлам, сети, sms, к другому приложению всегда задавался запрос, который невозможно было обойти. И пользователь сам выбирал, какому приложению он доступ разрешит, которому запретит, а которому будет каждый раз по запросу решать.
ghosthope
02.10.2017 10:55Возможно, только, к сожалению, обычному обывателю такие запросы не очень нужны, он хочется пользоваться и не задумываться, увы, о том что и как внутри. А такие вещи заставляют думать :(((
andreymal
02.10.2017 11:04Отмечу, что в Android 6+ сейчас примерно то же самое, что и в J2ME
chersanya
02.10.2017 16:08Только вот про интернет он не спрашивает, да и про доступ к файлам или обращение/открытие других программ не припомню.
andreymal
02.10.2017 16:12+1Да, поэтому лишь «примерно». Хотя про доступ к файлам у меня некоторые приложения таки спрашивали. Предположу, что текущий беспорядок с правами связан со всяким легаси, и доведение управления доступом до совсем как в J2ME — дело времени
chersanya
02.10.2017 16:45Эх, ещё бы сделали чтобы при отказе приложение не падало и вообще не знало об отказе — а получало пустой результат… Тогда бы было не «как в j2me», а лучше :)
stalkerg
04.10.2017 09:06+1да и про доступ к файлам
спрашивает, если надо что то открыть не в своей локальной песочнице и к примеру на внешней флешки то нужны пермишены.
Тольуо увы у Android сейчас 3 разные системы для открытия файлов не из родной директории. :( Это куча костылей для каждой версии андроида.
dfm
02.10.2017 14:33Вы предлагаете вернуться во времена IE7 опять. Там эта "безопасность" была именно так и реализована. Вместо просмотра страниц тыкаем на постоянно всплывающее окно блокировок.
chersanya
02.10.2017 16:06Вы видимо невнимательно прочитали. Я же пишу, что варианты ответа были не просто «да-нет», а «да-нет-всегда разрешать-всегда запрещать».
vedenin1980
02.10.2017 19:27И 90% пользователей будет всегда нажимать «разрешать все», как сейчас запускает исполняемые файлы из непонятных источников.
chersanya
02.10.2017 19:34Да, это проблема, согласен. Но её вообще никак не понятно, как решать — так что если хоть на оставшиеся 10% улучшится безопасность то уже хорошо.
WinPooh73
02.10.2017 20:57+2После десятого-двадцатого запроса "разрешить ли приложению XXX доступ к YYY" у пользователя выработается условный рефлекс, и он будет нажимать соответствующую кнопку быстрее, чем дочитывать до конца текст вопроса.
chersanya
03.10.2017 08:00+1Вообще не понимаю, откуда такой вывод (для пользователей, кто хоть немного разбирается). Если запрос на постоянно нужный приложению ресурс, типа интернета для браузера, то пользователь просто нажмёт «разрешать всегда». Если вообще лишнее, типа того же интернета для калькулятора или доступа к контактам для файлового менеджера — «запрещать всегда». И затем будут задаваться только запросы, которые пользователь считает что нужно каждый раз решать отдельно. С файлами и интернетом, кстати, можно реализовать в духе «разрешать всегда для директории /home/abc/def/*» и аналогично с сайтами.
Даже если окажется разрешённым больше, чем необходимо, это всё равно лучше, чем сейчас.
batyrmastyr
03.10.2017 14:01для пользователей, кто хоть немного разбирается
Под это определение попадает меньше процента пользователей, это раз. Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.
А ещё случается так, что автор продаёт своё приложение не очень порядочным людям или сам решает срубить зелени (см. AdBlock с его «заплати и твояпорнухареклама станет кошерной»), это три.
Хотя пример iOS с «либо ты думаешь как работать с урезанными правами, либо проваливай из магазина» показывает, что да, требовать можно. Иногда.chersanya
03.10.2017 15:03+1Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.
Когда они «задолбаются», если на большую часть запросов достаточно будет ответить один раз за всё время использования приложения? А оставшиеся разрешения — даже если поставят «разрешать всегда», всё равно будет лучше, чем сейчас.
При этом можно будет выкладывать/распространять/использовать конфиги разрешений для приложений, то есть достаточно взять чей-нибудь адекватный конфиг и будет уже неплохо для начала.
Psijic
03.10.2017 12:58Вы (или в данном случае «простой пользователь») просто не настраивали файрволы.
staticlab
02.10.2017 10:34и не может никак сообщить о нем и его пользователе
даже таймзону не сможет определить?
Rumlin
02.10.2017 14:33Такие вещи виртуальная машина возьмет от хоста при запуске, если разрешение на это будет определено пользователем.
koeshiro
02.10.2017 15:06То есть как сейчас с геолокацией и сервайсами?
Rumlin
02.10.2017 15:59Да, как приустановке приложений на Android.
К сожалению похоже современный веб все больше похож на реальный мир.
Масса публикаций на хабре в последнее время о том как пытаются следить за пользователем… ломятся в окна, в двери, смотрят что ешь, что заказываешь, что смотришь, что пишешь в email…
Отгородиться от веба высоким забором будет всё актуальнее.
Ставить AdBlock, Ghostery, NoScript, RequestPolicy и т.п. вещи — это не уровень обычного пользователя. Для массового пользователя необходима защита из коробки. С объяснением зачем необходимо то или иное разрешение.
koeshiro
02.10.2017 17:02Массового пользователя это не волнует. Кому-то нравится когда ему предлагают вечером заказать пиццу, починить машину… Даже если они этого не искали, а просто говорили об этом с друзьями.
Rumlin
02.10.2017 23:30Пока не волнует т.к. не видит связи. И это до момента когда например и банк и магазин будут отлично знать что пользователь искал и иметь возможность настойчиво предлагать кредит на покупку. А возможностей будет много — адресно на устройствах, которые он видит, на рекламных щитах мимо которых он будет проходить или проезжать, на скамейке в парке где он присядет.
«Если у вас паранойя, это еще не значит, что вас не преследуют». В таком мире будет востребована анонимность.
DaneSoul
02.10.2017 17:18Проблема в том, что «кто платит, тот и заказывает музыку», а в Вебе платит как правило этот самый рекламодатель, заказывающий сбор данных и показы рекламы, а не конечный пользователь, за исключением отдельных платных сервисов по подписке\продаже.
Зачем крупным разработчикам бороться за приватность пользователей, если у них доход с продажи этой самой приватной инфы, хоть и опосредованный?Rumlin
02.10.2017 23:31+1Пользователи будут покупать анонимность.
vedenin1980
03.10.2017 00:06+1И много сейчас пользователей «покупает анонимность»? Хотя бы покупает услуги платных проки/VPN и т.п.? Большинству пользователей пофиг, наоборот реклама показывается более персональная, а 1% те кто не считают себя неуловимыми Джо (то есть нафиг никому не нужными) ставят VPN/Tor'ы и прочее.
Rumlin
03.10.2017 13:28Сейчас еще нет острой необходимости и понимания пользователями реализации своей потребности. Лет через 10 будут другие пользователи, как и способы адресной рекламы.
Ti_Fix
02.10.2017 10:43А как быть в ситуации, когда вам необходимо загрузить файл со своего хоста в приложение?
Rumlin
02.10.2017 14:36Как выше описали либо запрос пользователю либо некий модерируемый накопитель в песочнице, через который возможен обмен с хостом. Хотя логичнее будет просто использовать некий браузер для профессиональных целей.
sheknitrtch
02.10.2017 10:48+7Интересная статья. Но мне кажется, что автор оригинальной статьи сильно углубляется в детали реализации. Он советует какие форматы данных использовать, на каких языках программирования нужно писать. Вряд ли замена JSON на PBF решил проблемы с SQL инъекциями.
Мне кажется, что создавать новый Web нужно со стандартизации виртуальной машины, API браузера, API межпрограммного общения (аналоги OAuth и других протоколов в новой реализации). Нужно понимать, что современный Web не стоит на месте, браузеры внедряют новые возможности (работа со звуком и видео, уведомления на рабочем столе, HTTP/2). При разработке NewWeb нужно заложить расширяемость с учетом обратной совместимости. А вопросы IDE вообще не должны подниматься на этапе формирования идеи/концепции.
Fedcomp
02.10.2017 11:26+23Ого, удивлен что никто еще не дал нормальной критики на статью, потому что автор совсем не разбирается в теме.
Ничего удивительного: если использовать SQL на веб-сервере самым очевидным образом, то он будет нормально работать, но незаметно сделает сервер уязвимым для взлома. Параметризованные запросы помогают, но это сбоку привинченное решение, которое не в каждой ситуации можно использовать.
prepared statements оказались костылем, оооок. Я то думал что это основной способ делать sql запросы, к тому же безопасный.
Но теперь средний размер веб-страницы превышает 2 мегабайта, не говоря уже о веб-приложениях. Даже скучные веб-странички со статичным текстом часто содержат массу минифицированных скриптов, в которых без машинной помощи вы не сможете даже начать разбираться.
В бинарных программах еще сложнее разобраться. Где же плюсы?
Требование: сериализация данных должна быть автоматической типизированной, бинарной и неизменной от хранилища данных до фронтеда.
А что, кто то мешает это сделать уже сейчас?
Вторая проблема в том, что машинам тоже сложно воспринимать URL'ы
Которые для этих же машин и писались, ооок.
Например, подумайте, что мешает вашему серверу установить куки для домена .com. А что насчёт kamagaya.chiba.jp?
Насколько я помню браузер запрещает ставить куки для чужих доменов (могу ошибаться, не проверял).
Просмотр исходника определённо помог мне столько раз, что я не могу сосчитать
Зато предлагаемую автором бинарную хрень вы просто не прочитаете.
Результаты выполнения SQL-запроса нельзя нативно отправить по соединению HTTP или встроить в веб-страницу
Мне кажется автор предлагает добавить еще больше дырок в его реализацию.
Ещё одним способом выполнения этого требования может стать умная IDE: если позволить разработчикам сначала работать с нетипизированными структурами (всё что определяется как Any), среда выполнения может попробовать определить, какими должны быть исходные типы, и транслировать эту информацию обратно в IDE. Затем она может предложить замену на лучшие аннотации типов. Если разработчик сталкивается с ошибками приведения типа во время работы программы, то IDE может предложить снова ослабить ограничение.
Нехватало еще чтобы IDE было обязательным требованием для разработки.
Грустный приговор веб-платформе, что WebAssembly — единственная попытка добавить новый язык, и этим языком является C… на котором, я надеюсь, вы не захотите писать веб-приложения!
Я думаю здесь можно остановиться, ибо некомпетентность автора доходит до предела.
Wasm это все что сможет скомпилироваться в wasm, как минимум все что компилируется в llvm, а это уже не мало.
Достаточно нам XSS, чтобы добавлять сверху ещё уязвимости типа двойного освобождения одной и той же памяти.
Ага, double free в виртуальной машине, очень смешно. Просит добавить новый язык, а когда ему дают платформу на которой можно вообще разные языки использовать — не, не надо говорит.
Да, это значит, что я хочу оставить возможность использовать JavaScript (на высокой скорости), помимо Ruby, Python, Haskell, и да ?—? C, C++ и Rust тоже останутся в игре. Всё это возможно благодаря двум действительно классным проектам, которые называются Graal и Truffle, о которых я подробно рассказывал. Эти проекты позволяют JVM запускать даже код на неожиданных языках (таких как Rust) в виртуализированной среде, быстро и и интероперабельно
А кто мешает их гонять вместе с рантаймом поверх wasm? это по сути тоже самое, но оно уже реализовано!
Песочница OpenJDK годами подвергалась упорным атакам, и разработчики браузеров усвоили ряд болезненных уроков. Последний 0-day эксплоит датируется 2015-м годом, а предыдущий был в 2013-м. Всего два 0-day эксплоита в песочнице за пять лет — неплохо, на мой взгляд, особенно с учётом того,
с учетом того, что java потом из браузеров выкинули, и эксплойты стало писать не так рентабельно.
Бинарных структур данных недостаточно. Нужны ещё и бинарные протоколы
Которые уже есть. Тот же messagepack вполне себе эффективно гоняется по http.
Платформа, которая хочет конкурировать с вебом, должна серьёзно озаботиться вопросами безопасности, поскольку это важнейшее обоснование для её создания и конкурентное преимущество. Это главная вещь, которую невозможно легко исправить в вебе. То есть нам нужны: бинарные структуры данных с безопасной типизацией и бинарные API, RPC, криптографические сессии и идентификация пользователей.
Платформа которая хочет конкурировать с вебом, должна озаботиться вопросами собственной необходимости. Нам нужны: перечисление всего что с безопасностью слабо связано, например бинарные протоколы. И как же они улучшают безопасность? а вот дебажить все это — одно удовольствие.Gregy
02.10.2017 11:57+6Человеку просто хочется обратно в теплые ламповые времена когда тащили Oracle client package для подключения к ораклу из своего приложения, вот там всё было круто, а то наворатили тут понимаешь с вебом, куча слоёв и ничего не понятно.
jehy
02.10.2017 13:41+1Да, как раз хотел написать то же самое. Жесть на жести. Но про SQL и webAssembly круче всего. Уровень некомпетентности зашкаливает разумные пределы.
Loki3000
02.10.2017 12:40+3Приплыли. А то сейчас не существует бинарных протоколов? Да вагон и маленькая тележка! И почему же они до сих пор не захватили веб? Не потому ли, что не решают ни одну из обозначенных проблем?
Графоманство какое-то…
Virviil
02.10.2017 14:43+3Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Эх, статья-статья. Грустно...
Virviil
02.10.2017 14:43Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.
Очевидно, что у автора катастрофически не хватает кругозора, понимания работы определённых вещей, зато нездоровая любовь к каким-то определённым реализациям каких-то конкретных решений, да ещё и в java мире.
Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.
Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....
Эх, статья-статья. Грустно...
lair
02.10.2017 16:14+2насколько я понимаю, фьючерсов нету нигде кроме Java мира
Неправильно вы понимаете.
Virviil
02.10.2017 18:56Я хотел сказать, что почему бы какому-нибудь виджету не подписаться на канал PubSub и не изменять состояние вместе с новыми сообщениями?
Или к примеру использовать fibers, channels, actors и ещё кучу разной технологии, которая не привязана к Java/C#/JS коллбэчистому стилю программирования?
denismaster
02.10.2017 16:29Кстати, в дополнение к новому языку разметки, вполне допустимо оставить например CSS или аналог. Это позволит использовать различные темы в приложениях, системные и кастомные.
Также возможна реализация единой виртуальной машины, встроенной в систему. В байткод этой ВМ будут компилироваться все языки, что также увеличит многообразие. Ну а ОС будут реализовывать стандарт этой ВМ и пытаться сделать более быструю и крутую реализацию)
Эх, розовые мечты…
VovanZ
02.10.2017 15:15Я ещё не дочитал статью, но уже возмущён:
Создание GUI в Matisse, редакторе UI с автоматическим выравниванием и ограничителями. Да здравствует (новый стильный) король?
Автор уже который раз (и в первой статье и в этой) рассуждает так, как будто перетаскивать кнопочки мышкой на формочку — удобнее, чем писать код (html/css/js).
Нет, это не так! По многим причинам:
- В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера. Когда у пользователей есть и компьютеры с мониторами самых разных размеров и разрешений, и планшеты, и телефоны (а у планшетов и телефонов есть ещё горизонтальная и вертикальная ориентация), нам бы хотелось, чтобы интерфейс работал при любом разрешении и размере экрана. Когда мы пишем код руками, мы сразу можем задать поведение (всякие Media Queries и разные обёртки над ними). Когда мы делаем интерфейс в GUI, нам нужно отдельно как-то задавать поведение.
- Тыкать мышкой GUI — просто медленнее, чем писать код.
- Как это потом хранить и версионировать? А как мержить? Это же всё равно хранится во всяких файлах (xml?). То есть, нам всё равно придётся работать с текстовыми файлами. Так давайте сразу работать с текстовыми файлами и затачивать наши инструменты для работы с текстовыми файлами.
bromzh
02.10.2017 15:42+3В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера.
В нормальных GUI для создания GUI это вообще не проблема. Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.
Сейчас можно глянуть на дизайнер UI в Android Studio: там можно сразу посмотреть макет на разных экранах, использовать всю мощь всяких разных LayoutManager-ов, прибиндить разметку к данным, и тд
Тыкать мышкой GUI — просто медленнее, чем писать код.
Далеко не всегда. Иногда удобнее написать код, иногда набросать мышкой элементы на форму, иногда чередовать
Как это потом хранить и версионировать? А как мержить? давайте затачивать наши инструменты для работы с текстовыми файлами
Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).
VovanZ
02.10.2017 18:08+1Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.
Я помню, как во времена Delphi я с этим мучился, и я знаю, насколько просто это сделать сейчас, с помощью HTML и CSS. Особенно, если взять какой-нибудь фреймворк типа бутстрапа, где всё уже сделано.
Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).
Да, я про это и говорю. Если нам нужно что-то смержить, нам всё равно надо будет лезть в код. Следовательно, нужно одновременно понимать, как этот код работает и помнить, куда нужно ткнуть мышкой, чтобы сделать кнопку. То есть, эти GUI не избавляют нас от сложности, они добавляют ещё один уровень сложности.
expeerd
02.10.2017 22:40То есть, эти GUI не избавляют нас от сложности, они добавляют ещё один уровень сложности.
Ну вы не совсем правы, они добавляют возможность решать задачи мышкой, и иногда (сходу не могу придумать ни одного случая) это может оказаться удобнее.
kuraga333
02.10.2017 15:24Начали за здравие, кончили за упокой…
А вообще, ИМХО, чтобы веб-стандарты превратились в хорошие стандарты построения (общих) приложений, им не хватает многоуровневости: должны быть API/стандарты и более низких уровней, чем в W3C Web.
DarthVictor
02.10.2017 18:52+7Эта статья вместе с предыдущей обозначила очень важную проблему современного интернета -обосрать чужое значительно проще, чем сделать хоть что-нибудь своё.
expeerd
02.10.2017 19:36+1Предвкушал фееричность продолжения уже после первых абзацев первой части. Выше есть отличный комментарий, от себя добавлю только одну вещь, которую я не могу развидеть: автор называет деминификатор компилятором, а после этого рассуждает на тему концепции веба будущего, это просто занавес.
vedenin1980
02.10.2017 19:42Как говорится «И ляпай. Но ляпай уверенно. Тогда это называется точкой зрения.» ©
roboter
02.10.2017 21:26+1почему то никто не вспомнил silverlight?
Если бы микрософт не пыталась захватить мир и открыла технологию для всех то может быть взлетело.
Strange_R
03.10.2017 10:06Лет десять назад попалась мне статья о том что Yahoo! пыталась разработать стандарт web, основанный на использовании прямых запросов к серверам баз данных, в которых хранятся данные одновременно об интерфейсе и наполнении. Иными словами, браузер, как клиент, при подключении к ресурсу напрямую обращается к серверу БД и получает из БД структуру страницы (+ поведение) и наполнение.
Этот проект Yahoo тогда забуксовал. Хотя, по-моему, работа web на серверах БД дала бы ряд преимуществ: упрощение, универсализация, масштабирование, скорость. Интернет превратился бы в совокупность взаимосвязанных БД и клиентов к ним. Это не отменяло бы работу традиционного web, но браузеры могли бы работать дополнительно и в таком режиме.
Двадцать минут потратил чтобы найти статью — никак.lair
03.10.2017 11:50А чем это отличается от того, чтобы обращаться к прикладным серверам, которые возвращают "данные об интерфейсе и наполнении"?
Strange_R
03.10.2017 14:42Если Вы имеете ввиду обращение к традиционным web-серверам, то их функционирование сложнее: отдельно шаблоны или генерация шаблонов, отдельно css, отдельно генерация HTML-кода страниц с необходимым функционалом из скриптов, написанных на разных языках(php, asp и т.д.), + подтянутым из прочих подключаемых скриптов (js и тд), отдельно web-серверы, БД отдельно — короче, куча модулей. В то время как теоретически всё это можно заменить серверами баз данных и свести к универсуму.
Насколько я понимаю.lair
03.10.2017 14:44+1В то время как теоретически всё это можно заменить серверами баз данных.
… которые будут выполнять те же самые функции (потому что кто-то же должен их выполнять). В чем отличие-то?
Strange_R
03.10.2017 15:12Внешне для конечного пользователя почти ничего не изменится, кроме, вероятно, повышения скорости. Но упрощается разработка и масштабирование. Или этого мало? Для развития ресурса достаточно работать с одной лишь БД. Браузер будет запрашивать информацию из БД и генерировать страницу, а не получать готовый HTML, сгенерированный на стороне web-сервера.
lair
03.10.2017 15:14+2но упрощается разработка
Почему вдруг? То, что вы раньше писали для прикладного сервера, придется писать для БД.
и масштабирование
А это и вовсе не так, потому что многослойное приложение масштабировать проще — у разных уровней разные требования к масштабированию. БД как раз не очень хорошо масштабируются.
MKMatriX
03.10.2017 12:58TLDR; возможность писать сайт в блокноте — один из его столбов.
Вот только среди веб разработчиков много любителей не особо умных IDE в стиле sublime, notepad++, vim. Плюющихся при любой попытке подсунуть что-то с кучей интерфейсов, которыми проще всего управлять мышкой.
sumanai
03.10.2017 15:26не особо умных IDE в стиле sublime, notepad++, vim
Про sublime ничего не знаю, но когда это редакторы с подсветкой кода и макросами типа notepad++ и vim стали IDE?
ChernovDmitry
03.10.2017 14:00если бы микрософт запилила нормальный магазин приложений в начале 2000-х и интегрировала его в винду, то кому были бы нужны эти веб приложения?
guai
03.10.2017 14:55Поддерживаю автора. Вэб давно ушел не в те дебри. Делали его под текстовую статику, теперь и мультимедиа хотим, и полноценные приложения. И скорости хотим. А оно работает постоянно дебажном режиме.
Типичная ситуация с легаси. Только мирового масштаба.
Ну, подвижки тоже есть. wasm, конеш, странный, но это хотя бы взгляд в нужную сторону. http2 кое-какие беды порешал…
Sql — тоже да. Стандартом так и не стал, у каждого свой диалект. Как задумывался, не используется. Если чо, задумывался он для конечных юзеров, а используется как промежуточное представление. Из ObjectDb его выкинули и стало, по заверениям, в 100 раз быстрее.
Да о чем вообще говорить, если весь вэб стоит на двух самых дебильных языках — на js и на php.
Кстати говоря, вэб изначально таким не планировался, производители браузеров потом его испоганили, тк вместо того, что делает обычная программа — кидается ошибками — начали пытаться и отрисовать то, что не до конца поняли, хоть как-нибудь, и скрипты исполнить хоть как-нибудь.MikailBag
03.10.2017 18:21SQL и PHP относятся к бэкенду, и мешать они могут разве что его разработчикам, но никак ни вебу в целом.
Кстати говоря, вэб изначально таким не планировался, производители браузеров потом его испоганили, тк вместо того, что делает обычная программа — кидается ошибками — начали пытаться и отрисовать то, что не до конца поняли, хоть как-нибудь, и скрипты исполнить хоть как-нибудь.
По-моему лечится вкладкой "Console" в инструментах разработчика
guai
03.10.2017 20:16Когда у вас в последний раз браузер отказывался рендерить страницу из-за незакрытого тэга? Или из-за неподдерживаемой версии яваскрипта.
Они так не делают, они не валят стэктрэйсы, которые можно было бы заслать разработчику/создателю сайта. Есть js — евалим, нет — nojs процессим, нет фреймов — херню какую-нибудь рисуем, нет css — испоганим дизайн, но чего-нибудь нарисуем, даже если кодировка побилась — кракозяблы вывалим. Даже если нужные ресурсы не загрузились — оно чота пытается делать.
По этой причине нет четкого понимания, что является браузером, что нет. Какой лучше, какой хуже. Тестов толком нет. Кто занял большую долю рынка — тот и браузер, остальные пусть подстраиваются. Опера поэтому померла, ИЕ6 стыл притчей во языцех, и вообще общий бардак.
Какие еще проги так себя ведут?justboris
03.10.2017 21:44OpenOffice, который пытается распарсить xls, не всегда успешно. Архиваторы на Windows, которые не всегда понимают архивы сделанные на Mac.
В любом проекте, где одни разработчики пытаются поддержать результат работы других разработчиков, будет место такому раздраю. Проблемы можно попробовать решить при помощи спецификации, но чем сложнее система, тем больше шансов на разночтения.
guai
04.10.2017 12:25Спецификация от w3c — отдельная песня с припевом. Сервер «может» ответить так, а может этак, и браузер «может» на это отреагировать, а может нет, как фишка ляжет.
Если бы железо делалось по таким спекам — у нас бы ничего не работало.
От этого же страдает, например, анонимность в инете. Браузеры можно довольно четко спалить по тому, как они интерпретируют все эти «может» из спецификаций, даже если через user-agent пытаемся передать что-то другое.justboris
04.10.2017 12:59То есть вас не смущает, что множеству разработчиков приходится реверс-инжeнeрить формат XLS, придуманный Майкрософтом, вместо использования какой-нибудь свободной спецификации?
guai
04.10.2017 13:44+1Я не говорю, что надо вэб строить на закрытом стандарте, это, очевидно, не получится. Просто имеющиеся спеки ужасны.
EvilFox
03.10.2017 20:16http2 кое-какие беды порешал…
И добавил новые, посидите на нём с плохой связью (которая может быть и внезапно на стороне хостинг-провайдера). У вас его «конвейер» встанет и вся сессия повесится на несколько минут. Для обычного пользователя поможет только выход из обозревателя. Короче HTTP2 плох если пакеты вдруг теряются. Пока сам не нарвался, относился к этому скептически.
unclechu
03.10.2017 20:35+1Веб взял верх над Delphi и Visual Basic не потому что JavaScript настолько крут. Есть более глубокие причины.
Т.е. вы хотите сказать что жопоскрипт-таки «крут»? Перед расстрелом из реактивного говномёта дадим автору шанс и сделаем вид будто он просто некорректно составил предложение. Ну или на худой конец, что подобная нелепица — погрешности перевода.
paluke
04.10.2017 13:29Ну какое отношение к безопасности имеет текстовый или бинарный протокол? TLS бинарный протокол, но это никак не спасет от ошибок в реализации
MonkAlex
Ну, идея в целом хороша. Кто и зачем это будет делать — совсем другой вопрос.
В плане защиты как минимум, вебом я недоволен целиком. Слишком много векторов атаки, чтобы уверенно сказать, что мы «защищены от самых дешевых атак».