Comments 411
Автор как всегда предлагает убить то, в чём не разбирается. Достаточно было дочитать про Flux. Flux/redux имеют весьма посредственное отношение к скорости рендеринга. Это методология организации кода. REST api, разрабатывается всегда с предположением, что клиент скомпроментирован. Для жизнено важных приложений используется дмз и другие способы отсечь удаленное управление, что небесполезно и для защиты десктопных прилад. Зато так приятно ощутить, а то и возглавить панику)
Мне скажем не жалко памяти моего компьютера… как бы сколько надо столько и купим =), я понимаю _почему_ так получается, но мне кажется что-то с «данностью» не так если десктопный Slack под win10 прямо сейчас жрет у меня 523Mb памяти… представляя из себя окно, показывающее одновременно 20-30 текстовых сообщений и при этом с невозможностью посмотреть историю если нет сети, при этом считаясь почти эталоном корпоративного общения…
Проблема даже не столько в вебе, как мне кажется… он ведь по сути дал просто некий инструментарий… проблема в том, что под флагами маркетинга и завоевания всего и вся, этот инструментарий начали использовать для совершенно непригодных вещей…
Вот опять же, глубокое IMHO, банк-клиент ВТБ24 — обычный для «физиков»… 10 лет назад он был легким, быстрым, работал почти на любых каналах… имел нормальные человеческие функции поиска платежа по описанию, по типу, по строчкам в получателе итд… на тот момент это объективно был лучший банк клиент для физ лиц… да и для юриков тоже был не плох… за 10 лет после 4-5 реинкарнаций, первую кстати начала студия Лебедева… он превратился в чуть шевелящегося уродца с невнятным, абсолютно неочевидным интерфейсом, весом в полтонны… зато обзавелся кучей модных свистелко-перделок…
Имелось в вид, что если вы контроллируете длинну "буферов" (длинну данных, или длинну запроса), никто не может добавить к запросу посторонний код.
Тем не менее, проблема SQL injection "успешно" возникла в Web, как и buffer overflow в C/C++ за 20 лет до этого. Вот автор и говорит о том, что Web повторяет путь десктопного софта, включая схожие грабли.
Так что хотя SQL injection и победили параметризацией, тесктовый протокол с текстовыми же маркерами начала и конца данных далек от того, чтобы считаться полность безопасным.
Так SQL и не является частью Web (deprecated WebSQL не в счет).
Автор говорит именно о Web и его протоколах, которые до недавних пор были исключительно тесктовыми, да и сейчас ключевые протоколы остаются таковыми.
Так что он предлагает (во второй чати статьи) заменить текстовые протоколы на бинарные.
Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).
Уязвимость возникла из-за комбинации пагубной практики программистов строить свои SQL запросы конкатенацией с сырыми данными, полученными из браузера, и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. И если первое можно победить, заставив программистов использовать параметры в SQL, то второе никуда не делось, и еще будет источником новых уязвимостей.
Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.
Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.
Наивно полагать...
А я и не полагаю наивно ;-)
Автор предлагает не просто бинарный протокол, а еще и типизированный, что автоматически делает невозможным в принципе любые вставки в нетекстовые данные, потому что они фиксированной динны (а в HTTP можно сделать вставки в любые данные, не только текстовые, но и числа, даты и т.д.)
С текстом посложнее, но тоже решаемо. Например, в ряде случаев от текста можно вообще отказаться -> проблема решена полностьб — см. выше. Можно работать с текстом фиксированной длинны. И т.д.
К тому же, основная цель NewWeb (как автор это называет) не в устранении всех возможных уязвимостей на 100% (сам автор считает это невозможным), а в минимизации возможных ошибок, что приведет к уменьшению числа дыр.
Всё это должно делаться стандартными средствами протокола, чтобы не плодить ошибок от кастомных решений.
Бинарность протокола делает ненужным всякие ухищрения с экранированием/эскейпингом, а также существенно облегчает парсинг (особенно если данные типизированы). Это ведет к уменьшению числа потенциальных ошибок и новых дыр.
а вот текстовый протокол вполне себе может что-нибудь заэкранировать. Но на стороне сервера значение будет деэкранировано. И на этом этапе уязвимости не будет.
Вот как раз на это автор указывает как на еще один недостаток современного Web: разные экранирования/эскейпинги и постоянные парсинги текста, причем с обеих сторон. Во-первых, никаким экранированием и эскейпингом вы не сделаете текстовый запрос из Web приложения безопасными с точки зрения injection (разве что вы будете его подписывать, но там уже свои проблемы). Во-вторых, все эти манипуляции являются потенциальным источником ошибок и новых дыр.
Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.
Как я уже говорил, SQL injection — просто частный случай. Проблема в самом текстовом протоколе без всяких средств контроля данных.
Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.
Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим). Если вы этого не понимаете, то… это вы не понимаете суть SQL Injection ;-)
Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.
сериализация/десериализация всё равно будут нужны.
Конечно. Это должна быть стандартная часть протокола, и будет делаться через стандартный API.
Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).
SQL Injection это всегда отсутствие валидации входных данных
Да, вы можете валидировать текстовые данные, добавиви в ваш стек еще одно место потенциальных ошибок и дыр. Именно так и делается в современном Web, и именно это критикует автор.
А можно перейти на другой протокол, который в ряде случаев вообще не допускает SQL injection "by design".
добавиви в ваш стек еще одно место потенциальных ошибок и дыр
Без ошибок только тот код, которого нет. Переход на другой протокол, это просто перенос валидации на уровень протокола, а не приложения. Но да же и тут без валидации на уровне приложения никак.
Но ведь можно попробовать хотя бы уменьшить количество потенциальных дыр. В этом и состоит предложение автора статьи.
Даже в текущем стеке Web постоянно появляются новые технологии, и никто особо не переживает по поводу небыстрого избавления от багов :-)
У среднестатистического пользователя Web-приложения есть только браузер в качестве клиента, который вы не можете контроллировать. Как вы будете доставлять все это (Java, Thrift etc.) к нему в браузер? Особенно если он не хочет ваших плагинов.
Вот автор и "предлагает" сделать новый Web (NewWeb) с улучшенным дизайном для улучшения безопасности и производительности. Чтобы клиенты (e.g. браузеры) "из коробки" поддерживали новые протоколы.
JSON — тоже текстовый. Вставка во время транспорта делается также легко, как и в URL простого HTTP GET.
Да, вы можете использовать JSON валидацию — так же как программисты, допустившие SQL injection, могли бы использовать SQL с параметрами. А можете и не использовать, что является дырой.
Автор предлагает NewWeb, в котором накоторые дыры будут закрыты "by design", независимо от того, что вы используете (или не используете) на своем backend'е.
А вот что насчёт подмены строки как в моём примере?
Использовать параметризированный SQL :-)
Еще раз повторю: проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. Это будет источником новых уязвимостей.
Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).
С чего это вдруг? Он происходит после передачи данных, при обработке в приложении.
Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе.
С чего это вдруг? Какая разница, передали мы значение $client в виде "OR 1=1\n" или в виде "0x06OR 1=1"?
и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом
Почему вы решили, что в двоичном протоколе подменить данные сложнее?
Это с чего бы? SQL-инъекции возможны в любом приложении, которое принимает данные от пользователя и подставляет их в запрос. Не важно, десктоп это или веб.
Flux, последнему модному веб-фреймворку от Facebook
В вебе минули геологические эпохи с тех пор, как Flux был последним и модным (не то чтобы пришедшее на замену шибко лучше, но все-таки).
На C++ невозможно написать безопасный код, а виноват, конечно, веб, ну да.
Веб, со всеми его недостатками, с REST-ом, Flux-ом и прочим грузом, по факту оказался самой удобной системой доставки контента и приложений (что, впрочем, трудно разделить, потому что современный контент требует интерактива (привет, комменты на хабре), а приложения работают с контентом (well, duh)).
Как только появится что-то кардинально лучшее, мы все немедленно на него перейдем: разработчики, если они не застряли в ностальгии, как им любовно и прельстиво кодилось в 90-ые под Win3.x, любят вскакивать на hype-train как никто другой. Боюсь, только, что оно будет организовано на примерно тех же принципах: гипертекст и скриптовый язык.
Не «что-то», а «что-то + экосистема». Именно поэтому надеяться на то, что оно само появится… Не стоит?
Я прошел путь от Rails до собственной lightweight библиотеки по типу React, и тут понял… Что HTML и пр. тут просто не нужен… Бери себе C++/Python/Ruby/etc. + xWidgets, замути такую библиотеку и… Ну разве что, еще нужны всякие API для доступа к сенсорам (если нужно). Но экосистемы-то нет, потому, что нет моды, потому, что нет…
А мода на комбайны под названием «браузеры» (заметьте, еще и несколько!) — плохая. Даже с учетом налаженного процесса стандартизации… Это я спустя десяти лет web programming говорю, спустя годы восхищений… Сейчас я понимаю, что даже идея комбайна JVM — возможно, лучше…
Иллюстрация? Восхищения по поводу WebAssembly: взяли ОС, создали браузер со своей «ОС», сделали «стандартный» высокоуровневый ЯП, а WebAssembly — инновация, которой нам не хватало! Ассемблер внутри всего этого.
Но, наверное, во всех других бизнес-моделях была бы куча стандартов (например, API доступа к сенсорам), ну и тоже бы ничего путного не вышло…
Боль.
Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти
А сейчас этого мало даже дня нативного десктопного мессенджера, да и для мобильного тоже. Так что вы правы, html — зло. Хотя, при чем здесь html?
И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
А с ней там плохо по другим причинам.
Ну, если так подходить, то вообще все проблемы безопасности можно считать везде одинаковыми. Тем не менее, некоторых проблем, характерных для экосистемы веб, в Flash никогда не было.
Ну самое очевидное — то что там изначально аналог shadow dom, т.е. один компонент не может что-то сломать в родительском приложении или его стилях. Или в другом компоненте. Т.е. только публичный API, и ничего больше. Такой вещи, как глобальный window, как document.write — вообще никогда не было за ненадобностью. Там нет загрузки скриптов, как таковой — есть загрузка swc, но это совсем другая история.
Чистая правда. Я сейчас после длительного перерыва смотрю на веб-фреймворки, и вижу, что да, shadow dom и кастомные элементы все-таки сделают революцию рано или поздно — но все это уже было в Flash/Flex, причем много лет назад.
Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу, а для UI использовался бы нормальный язык разметки, в идеале поддающийся автоматизации (чтобы дизайнеры могли «рисовать» его в редакторе, не заморачиваясь с версткой).
Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу
WebAssembly+WebSocket+WebGL? А все остальное вопрос фреймворков.
на платформу вообще без стандартной библиотеки
С чего это вы взяли? Можно хоть существующие фреймворки на других языках прикрутить
Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?
Потому что клиенты платят деньги и хотят все запускать из браузера.
Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.
Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
Вот только она не унифицирована :)
Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.
Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNI
Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNI
Какая-то ерунда, вы про такой язык как Groovy не слышали, который в JVM позволяет писать функциональные скрипты без ООП с динамической типизацией?
>> Строгая типизация — даже в Java можно использовать переменные Object и явное приведение типов везде, вот вам динамическая типизация. На JVM платформе достаточно языков с динамической типизацией.
>> Необходимость обработки исключений — в чем необходимость? В новом JVM языке не используйте проверяемые исключения, оборачивайте все возможные вызовы старых Java методов в непроверяемые исключения на этапе компиляции и не будет такой необходимости.
>> Принудительное ООП — за неиспользование ООП в JVM вас арестовывает Java полиция? Никто не мешает вам даже в Java написать весь код приложения в методе main одного входного класса и использовать только статические функции и переменные без всякого ООП.
В JVM легко может существовать функциональный или процедурный язык без всякого ООП, байт-коду все равно как выполняется в ООП или не ООП.
>> Управление памятью и системным треем доступно только через платформозависимый JNI
Есть много способов низкоуровеневой работы в JVM, вплоть до подключения C/C++/машинных кодов и вручную обращения к api ОС. JNI это лишь один из них.
>> Необходимость установки среды исполнения — а вот тут не понял, что это значит? Необходимость наличия на устройстве JRE в принципе? Но странно если платформа могла работать без платформы. Или вы предлагаете в каждому приложение тащить весь JRE (сотни мегабайт) с собой? Есть возможности компилировать Java байт сразу в машинные коды и тащить все с собой, но ими мало кто пользуется.
В общем, странные у вас представления о Java платформе.
Создавать разметку?
Да, создавать разметку. Специально для поисковиков.
Вообще, её даже создавать не надо, такая разметка уже есть, и она как раз изобретена поисковиками для поисковиков — schema.org. Просто берём её готовую и не паримся.
Она прибита к HTML.
Нет, microdata в HTML — это лишь один из вариантов представления schema.org, там же есть и, например, JSON-LD (который к тому же рекомендуется для использования гуглом), не связанный с HTML вообще никак; ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.
А вообще нахрена индексировать приложения, лол?
5 лет назад никто не жаловался на JS
Я жаловался :D
C#/java программисты переживают за душевные страдания веб разработчиков
Вот вообще плевать на них. Мне не плевать на то, что новый скайп-фор-линукс нормально завести на интел-атоме вообще нереально по причине лютых тормозов и зашкаливающего потребления оперативы. Зато разработчикам скайпа удобно, блджад! Конечно говнокодить удобно, кто ж спорит, только вот на выходе говно и получается.
Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
Обёртки над обёртками над обёртками над тормозящими HTML-CSS-JS, а в итоге чятики, по своим возможностям едва превосходящие IRC из 1989-го, еле шевелятся на моём относительно новеньком ноуте из 2014-го (да, это камень в Slack).
если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.
Я хочу разрабатывать не-веб приложения. И я, допустим, даже могу их разрабатывать и разработаю. Но это всего лишь я. Всё ещё осаётся две проблемы:
1) Все начинают делать веб-приложения без десктоп-альтернатив — взять хотя бы те же Slack и Skype. Как пользователь я вынужден использовать их тупо по причине отсутствия альтернатив (замену на какой-нибудь XMPP пока опустим, представим производственную необходимость).
2) Продвигать веб-приложения проще и выгоднее, потому что они не требуют установки и браузер уже есть у всех (а для желающих иконку в трее клепается Electron-версия на коленке). Никто не заинтересован в создании нормальных десктоп-приложений, и см. п. 1.
Нужна платформа, которая не содержала бы ничего лишнего (условный один-единственный canvas плюс API для доступа к системе, как я уже ранее упоминал), имела бы эффективно интерпретируемый байткод без костылей (в том же V8 уже работает чуть ли не ИИ, пытаясь скомпилировать наиболее эффективные версии js-функций, хотя всё можно легко порешать тупо статической типизацией) и как следствие не тормозила бы. Варианты, как могла бы выглядеть такая платформа, уже неоднократно предлагались здесь в комментариях, да и в более старых хабрапостах с нытьём про веб.
Мне нужна такая платформа в первую очередь как пользователю, чтоб скайп на линуксе не тормозил.
Кстати насчёт тормозов, есть WebGL-версия UT99 (почти целиком урезанная, чтоб поменьше весила, к сожалению), было бы очень интересно вычислить её минимальные системные требования и сравнить с требованиями оригинального UT99. А потом вспомнить, что в оригинальном UT99 был ещё доступен программный рендеринг без какого-либо ускорения вообще, который к тому же неплохо работал на компах того времени (ну, может, плюс пара лет).
Во-вторых, PHP с его умиранием после каждого запроса и отсутствием асинхронности и многопоточности, для написания пресловутых приложений подходит весьма посредственно. А если требуется дуплексный протокол типа WebSocket, то вообще туши свет.
Правда, к сожалению, работодатели очень часто требуют именно PHP — чтоб потом проект можно было поддерживать силами дешевых макак (что, конечно, заблуждение — писать на PHP хорошо куда сложнее, чем на нормальном языке, и почти никто из «PHP only» разработчиков на это не способен).
И тянуть за собой WINDOWS sever?
.NET Core (существует с 2014 года) прекрасно работает на Linux. Это если не упоминать Mono (неофициальную реализацию, которая еще старше).
Я видел приложения на IIS+ASP.NET + react, шлак шлаком
А уж сколько приложений на PHP, которые «шлак шлаком»… Более того, я абсолютно уверен, что их больше, т.к. уровень среднего PHP-разработчика близок к уровню макаки.
PHP — объективно плохой язык. На нем, конечно, можно писать хорошо, но зачем, если есть нормальные языки?
PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей
Ну так за 170к можно найти и специалиста по более серьезному стеку, чем PHP. Но «бизнес» не хочет платить 170к, он хочет брать макак с улицы. Это, в том числе, и вина скриптовых языков с низким порогом вхождения — что в принципе возникла такая идея, что программист может быть дешевым.
вы под веб приложениями подразумеваете… когда на JS пытаются писать десктопные приложения?
Да
Не, масштабный сайт не обязательно приложение. Если собрать сто тыщ мильёнов документов в большую кучу, они не станут волшебным образом приложением :) В моём понимании приложение делает что-то интерактивное и существенное, а просто сайты это коллекции документов и связей между ними, которые нужны по сути только для чтения. Вообще, сейчас так смешались в кучу кони люди, что местами хрен разберёшь, кого кем считать. Предлагаю следующее эмпиричское правило: если нечто можно переписать на HTML+CSS без JS полнофункционально и без лютейшей потери неудобства, то это не приложение.
Тогда:
cian
Не доводилось юзать. Если это «база недвижимости», то на первый взгляд это по сути лишь пара простых формочек для поиска и текст с его результатами. Можно запилить аналог хоть для IE4 без каких-либо скриптов. Не приложение. (Могу ошибаться, ибо не юзал)
Яндекс карты — веб приложение
Вся суть в интерактиве, так что да. И в поиске индексировать нечего, кстати. (Точки интереса можно оформить отдельными документами)
Фейсбук — веб — приложение.
Тоже не юзал, но если считать ВК его клоном и сравнение с ним допустимо, то тоже нет, так как это по сути опять же база документов с парой формочек поиска и редактирования. Мобильная версия ВК способна работать без скриптов. Не приложение.
Яндекс Маркет — веб приложение.
Нет по той же причине, что cion и ВК.
Ютуб — веб — приложение.
Спорно. По идее видео уже выходит за рамки текстового документа, но его, наверно, можно считать дополнением к документу, к тому же в HTML5 есть тег video, работающий без скриптов. Если рассматривать ютуб как базу видеофайлов и комментов к ним, то наверно не приложение. А вот имеющиеся там средства для редактирования видео наверно уже тянут на приложения.
рецепты ру — сайт
А если это рецепты.яндекс.ру с миллиардом рецептов блюд всего мира всех времён, то по вашей логике будет уже приложение? :)
пикабу — сайт/Портал
Ага.
нужно писать их на JavaScript + css+ html + svg
Для всего, что я счёл приложениями, данный стек технологий не подходит вообще. Гугл-карты по-моему сейчас рисуются вообще через WebGL, то есть от HTML и CSS там одно лишь название, а JS используется вынужденно по причине отсутствия альтернатив. На картах нет гипертекста, который можно было бы размечать с помощью HTML. В том же скайпе тоже нет гипертекста, за исключением разве что сообщений в чате, но это не основная фича скайпа. Для групповых видеозвонков не нужны ни HTML, ни CSS.
Вообще, для создания простых сайтов с инфой HTML и CSS умеют слишком много, а JS чаще всего вообще не нужен. А для создания приложений возможностей HTML-CSS-JS всё ещё мало.)
95% работы (заказы по вебу) это:
Против этого я ничего не имею, им HTML самое то. Хотя CRM и админки, наверно, спорно, но против них я не настроен столь негативно, как против каких-нибудь слаков и скайпов (да, я буду ещё стопицот раз упоминать скайп, потому что он и тормоза его веб-клиента — единственная причина, почему моих родителей невозможно сейчас перевести на линукс)
Пилить фотошоп и редактор видео в браузере?
Я-то этого не хочу делать, проблема в том, что другие хотят! Компиляторы из C++ в JS есть уже несколько лет, так что появление полноценного веб-фотошопа — лишь дело времени. А потом десктоп-фотошоп возьмёт да и прекратит своё существование (торренты, конечно, никто не отменял, но пользоваться устаревшим ПО тоже не очень круто). Как прекратил своё существование десктоп-клиент скайпа для линукса (некоторые утверждают, что он ещё работает, но это тоже дело времени)
Почему вы не хотите пользоваться фотошопом в веб?
Потому что скорость.
в близжайшие 10 лет о таком даже думать не стоит,
В этом-то и проблема! Через десять лет появится условный веб-фотошоп, и, если веб останется примерно таким же что и сейчас, скорость его будет как на компьютерах 2002-го! За эти условные 25 лет процессоры ускорились на десятки гигагерц и десятки ядер, техпроцесс всё нанометровее, оператива начинает измеряться чуть ли не терабайтами — а производительность конечных приложений не меняется! Весь прогресс уходит в обсуживание многочисленных слоёв абстракции, половина которых к тому же не используется. Меня вот это жутко бесит. Тот же стопицот раз упоминавшийся скайп, который когда-то давно успешно работал на компьютерах 2005-го, не способен работать на компьютерах 2010-го из-за того, что он стал веб. Пора убить веб.
Почему вы не хотите пользоваться фотошопом в веб?
Зависимость и небезопасность. Отключили интернет — работать не могу. Набежали хакеры на сервера — работать не могу. Устроили конкуренты DDOS — работать не могу. Поменяли интерфейс, он не понравился, а не обновляться уже не получится, буду жрать чего дают. Где мои файлы гиговые, на серверах? Как мне их, условно, в типографию отнести? Как мне их в других приложениях использовать? Порисовал в шопе, экспортировал, скачал импортировал в другое приложение. Понадобилось что-то подкрасить, опять экспортировать, скачать, импортировать?
100% будет возможность запустить как обычное приложение
… сделанное на базе Electron со всеми вытекающими )
Эти задача не требует высокой производительности.
Это не даёт им право жрать ресурсы как фотошоп. Вообще-то я хочу, чтобы ресурсы использовались для дела этим самым фотошопом, а не какой-то жалкой формочкой :) Если не запускать формочку и фотошоп одновременно, то проблемы нет, но блин, и нахрена тогда нужна многозадачность в ОС?
Нужно пара формочек (мини CRM) — берем electron
То же самое: в результате «мини CRM» не умеет почти ничего, а ресурсов жрёт как тот же фотошоп. Не кажется ли вам это абсурдом?
Кстати, у меня сейчас открыт Adobe Illustrator CC с двумя совсем не маленькими файлами с кучей слоёв, векторов и встроенных растров, занимает это всё в оперативе 300 мегабайт. Нижеупомянутые гуглдоки с простым текстовым документом жрали те же 300 мегабайт. Мессенджер Slack, когда я его юзал, в котором кроме текста, разбавленного редкими картинками, толком ничего и нету, временами кушал памяти раза в полтора больше.
Хочется разбить монитор.
Продукт сырой, в будущем косяки с оперативкой продумают, мне так кажется.
У GNU нет такой проблемы, соблюдается принцип KISS (Keep It Simple and Small), благодаря OpenSource не приходится постоянно изобретать велосипед, разделяемые библиотеки помогают экономить память. А если чувствуются тормоза, смотрим что в памяти жрёт больше всех, оставляем столько, на сколько хватает ОЗУ и делаем
# swapoff -a
# swapon -a
и нет тормозов
Ваше приложение на C# хавает 120МБ, мое хавает 350.
Мое приложение на Rust+GTK3 будет хавать максимум 40МБ :D
Разница прям ощутимая?
Да. В 230МБ можно запихнуть очень много полезного. Например, Adobe Illustrator с двумя тяжёлыми файлами.
в игровой индустрии тоже разработчики виноваты, что их игры не запускаются на 4 пеньке?
У них есть уважительные причины для потребления всех ресурсов компьютера. И, кстати, их до сих пор не хватает: абсолютно реалистичных игр до сих пор как-то не видать. Им простительно.
Но какие мы имеем плюсы?
Всё так. Но того же самого можно добиться, выбрав какую-нибудь платформу полегче. Только такой платформы для онлайн-приложений не существует, и вся суть поста и комментариев к нему — такую платформу нужно создать!
мало кто понимает что это выгодно для бизнеса
Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные. Сейчас всё делается на «выгодно для бизнеса»: бизнес берёт js-макак-первокурсников, которые за еду клепают веб-приложения (можно вместо «веб-приложения» подставить любую другую модную абстракцию), веб-приложения жрут ресурсы и тормозят, пользователи идут покупать новый комп чтоб не тормозило, веб-приложений становится больше, всё снова начинает тормозить, пользователи идут покупать ещё более новый комп, и всё по новому кругу. В результате компы становятся в десятки-сотни раз мощнее, а возможности те же, что и у компьютеров восьмидесятых. Прогресс имеется разве что в играх, думаю потому что там до сих пор старый добрый C++ без лишних абстракций: ещё 10 лет назад о каком-нибудь VR никто и мечтать не мог (жалкие попытки в 90-х вспоминать не стоит), а сейчас вполне годный шлем можно в любой эльдораде купить, и будет неплохо работать. Или в нейросетях, которые, вовсю эксплуатируя GPU, автоматизируют кучу полезных вещей, которые раньше автоматизировать было почти нереально. А теперь сравним какой-нибудь Word 95 и гуглдоки. Какие есть существенные отличия, кроме онлайна? Куда тратятся три сотни мегабайт? Почему оно жрёт три сотни мегабайт, а тормозит и глючит сильнее, чем Word 95 на компах того времени? Почему текстовый документ оказывается тяжелее, чем пара тяжёлых графических файлов в том же иллюстраторе, который у меня до сих пор запущен? Хотя чего это я — потому что «выгодно для бизнеса». А мне как пользователю нихрена не выгодно.
Почему они пишут на JS вместо своего любимого C#?
Потому что, простите, долбоёбы, экономящие на индусах. Я как конечный пользователь буду безмерно рад, если всё перепишут на C#, хоть сам и не очень люблю C#, но лучше уж C#, чем JS.
Я уже делал несколько других сравнений веба и не-веба здесь в комментариях, мне неохота повторяться.
Веб будет жить, конечно. Но было бы намного лучше, если бы вместо него жило что-нибудь другое. Но, думаю, каждый комментатор здесь понимает, что этому не бывать и вы правы, так что всё, что остаётся — писать нытьё подобное моему в комментах. Ну и ещё я ярый сторонник, как вы выразились, «писькомерства», да.)
Как анализировать сайт который не имеет текста(DOM)?
JSON-LD, я уже писал про это в комментах. И да, сайту DOM нужен, я ничего против этого не имею. DOM не нужен только приложениям, не стоит меня передёргивать.
google свою карту рисует не на DOM а в холсте.
«… а HTML и CSS лежат без дела и жрут память и процессор» и далее по тексту предыдущего и всех остальных моих комментариев.)
В остальном же соглашусь с andreymal: есть информационные сайты, и для них действительно не надо придумывать новый стек технологий, а заставлять людей эффективно использовать уже существующие (т.е. оптимизация картинок, минификация CSS и JS, поддержка HTTP/2 и просто минимализм и отказ от злоупотребления красивостями), а есть именно приложения, где важна интерактивность. И вот для них и нужно создать новое решение, к чему и призывает автор исходной статьи (хотя соглашусь, спорных заявлений у него хватает).
Кажется, что-то пошло не так.
Кстати, свежезапущенный Chromium выкушивает примерно столько же.
Не свежезапущенный Sublime с открытым проектом и несколькими плагинами кушает примерно 100МБ. По-моему тоже многовато, но не полгига всё-таки)
Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные.
Это совершенная глупость. Для бизнеса выгодно делать то, что выгодно для пользователей, т. к. именно пользователи платят бизнесу деньги.
Бизнес именно это и делает.
Предоставим пользователю право выбора, ага.
Безопасность пользователей превыше всего.
Супер выгода — всего $0.99 за одну небольшую настройку!
Можно приводить ещё тысячи и тысячи примеров, как бизнес только и думает, что бы ещё такого сделать ради пользователей. Но мне надоело ещё вчера вести такие бессмысленные разговоры, и я предпочту закрыть тему.
Тогда вопрос к вам:
1) Cкайп это технология Microsoft
2) Visual studio code это технология Microsoft
Почему они пишут на JS вместо своего любимого C#?
1) Только linux-версия скайпа на электроне. Виндовая на Qt. Видимо, им по понятным причинам плевать на Linux-юзеров.
2) В VS Code как раз критические части были переписаны на С++, в следствие чего тормозит она в разы меньше, чем изначальный Atom
Ну и да, они на TS пишут, который, хоть и компилируется в JS, но статически типизирован, и создан автором C#.
Вы согласны платить за мини-CRM цену Фотошопа?
Site — (с англ.) место, то что имеет адрес в сети.
Приложение — дополнение чего либо, например операционной системы ПК или мобильника. Приложение может работать через веб, тогда это веб-приложение.
Просто сейчас цела куча информации может прятаться исключительно внутри приложений.
Можно какой-нибудь пример? Я сходу чё-то ничего не могу припомнить помимо гуглдоков
Инстаграм — обыкновеннейший веб-сайт с картиночками, который хрен знает зачем сделали как SPA, так что не. А индексируется он, похоже, тупо через meta-тег description
UPD: Кстати, картинок из инстаграма в поиске гугла нету)
SPA удобен тем, что мне не нужно жддать перезагрузки страницы
SPA тут вообще ни разу ни причём и нахрен не нужен. Для этого достаточно прикрутить какой-нибудь PJAX или аналог, который будет аяксом подгружать куски HTML-кода с сервера. При этом с включенным js получаем ускорение без всякого мерцания, а с отключенным js просто отваливается PJAX, а сайт остаётся полностью работоспособным, а не с белым экраном, как у инстаграма сейчас. (Я лично не измерял, но поговаривают, что так получается даже быстрее, чем с «классическими» SPA.)
Идеология SPA Такая: Для пользователей включаем режим SPA, для поисковиков и тех кто перешел по GET Запросу — грузим слепок DOM с сервера.
Ну и зачем так мудрить и оверинжинирить, когда можно сгружать DOM и пользователям тоже? Все мерцания фиксятся PJAX'ом.
в чем тогда принципиальная разница между SPA и не SPA
SPA-cайт типа Instagram создаёт HTML на клиенте и не работает без JS. Сайт на PJAX/Turbolinks и аналогах создаёт HTML на сервере и успешно работает без JS. Во втором случае JS занимается лишь ускорением сайта AJAX-запросами и ничем больше (в контексте данного обсуждения; пихать дополнительные скрипты никто не запрещает, конечно).
Или у Вас каждый день встречаются случаи, когда у пользователя отключен JS?
Во-первых, лично знаю нескольких таких человек. Во-вторых, я выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.
выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.
А зачем? Этот момент мне лично не понятен.
Если есть намек на какую-то динамику на странице
Я инстаграмом сильно не пользовался, просветите, что там есть такого очень динамичного?
А зачем?
Все избаловались включенными по умолчанию скриптами, а на самом деле вопрос должен стоять по-другому: зачем я должен включать JS? Типичное времяпрепровождение в вебе (не считая веб-приложений) — это чтение статей, текстов и постов, иногда оставление каких-нибудь комментариев (типа этого), гуглинг, копипаст из stackoverflow и всё такое. Всё это умеет HTML без лишних дополнений, зачем для этого JS? Хорошо, JS может служить неплохим дополнением ко всему этому (предпросмотр коммента без обновления страницы, кнопки HTML-редактора над формой, экономия трафика и времени за счёт ajax-подгрузки только новых комментов, тот же PJAX и т.п.), с этими вещами всё понятно, но это всё лишь дополнительные плюшки; зачем делать на JS такие вещи, которые могут работать и без JS?
Мне как пользователю какая выгода от того, что вам проще взять React? Я вам сегодня доверился и включил JS ради вашего удобства, а завтра вы подсовываете майнер, а послезавтра собираете fingerprint моего браузера и продаёте меня рекламщикам.
Я бы сидел с отключенным JS, но, к сожалению, ВСЕ сайты его требуют. И альтернатив у веба не существует. Приходится прогибаться под любителей реакта :(
Та, что вы получите работающее приложение (пусть и с js).
Напомню, эта ветка про сайты, а не про приложения. В приложениях от исполняемого кода никуда не деться, конечно. А инстаграм — не приложение (то, что его зачем-то сделали SPA, ничего не значит).
А работающий сайт я могу получить и без js. Но я его не получаю, потому что разработчикам лень его таким делать. И это единственная причина, почему все сайты требуют js. То есть мы опять пришли к «выгодно для бизнеса», которое уже обсуждалось в другой ветке.
Ну почему же можете? Именно что не можете! Чтобы получить работающий сайт — его кто-то должен сделать. Либо у вас есть работающий инстаграмм в виде спа, либо у вас нет работающего инстаграмма, потому что разработчики инстаграмма решили, что не хотят делать его не-спа. При этом вам, конечно, никто не мешает сделать свой инстаграмм, без жс и всего такого. Только вот тогда ваш продукт не сможет конкурировать с продуктами тех разработчиков, которые жс используют свободно, и вы к хренам собачьим вылетите с рынка.
Вылечу я или нет, от наличия или отсутствия JS никак не зависит. ВК прекрасно работает без JS (кроме аудиозаписей из-за копирастов; а, например, видеозаписи работают). Что-то не похоже, чтобы он куда-то вылетал.
Стоит заметить, что без JS работает только мобильная версия. То есть дополнительная версия сайта, написанная специально для маломощных и мобильных устройств, а не основная, на которой сидит большиство.
Не у всех компаний есть возможность потратиться на такую спец.версию.
Тем не менее всё равно не вижу никаких серьёзных проблем совмещать JS и не-JS и делать полнофункциональную версию веб-сайта (ещё раз: не онлайн-приложения) в обоих случаях, кроме лени разработчиков. Ну и даже если брать реакт, можно ж было хотя бы server-side рендеринг прикрутить, он это умеет блин
лени разработчиков
это не лень, а прагматизм. Лучше сделать больше свистелок для привлечения обычных пользователей, чем поддерживать 3,5 человек, заходящих на сайт с калькулятора.
Очевидно, фейсбук считает что есть более полезные направления, для приложения усилий. Вы рассуждаете с какой-то странной позиции наличия бесконечных ресурсов. Но на практике ресурсы ограничены, и если вы тратите их на то, чтобы ваш сайт работал без js — то вы то забираете у чего-то другого.
Разработчики Instagram решили, что реализуя приложение как SPA, им будет проще его сопровождать, а может им просто нравился тот инструментарий, получать удовольствие от работы тоже важно. Эти простые истины переписать не так легко.
Опять доводим до абсурда?
Во-первых, про JPG, SVG и графику я ничего не говорил. Они не являются исполняемым кодом. (а в SVG пихать скрипты тем более нефиг)
Во-вторых, я в этой ветке нигде не говорил про отказ от JS. Я говорил про отказ от обязательного JS. Сайты, которые я делаю и буду делать, тоже имеют автокомплит, аякс и прочую дребедень — только, если захочется, всё это можно отключить, и сайт останется работоспособен. Опять же, смотрите мобильную версию ВК — там сделано именно так.
Только зачем это пользователям? Не вам лично, а пользователям и всему миру, какая в этом польза?
Минус ещё одна потенциальная дырка в безопасности, минус майнер на The Pirate Bay, минус шпионство через fingerprint, плюс свобода выбора у пользователей, которые получат возможность выбирать, доверять разработчикам или не доверять, плюс возможность отрезать потенциальный вектор атаки на девайсы людей, плохо умеющих в интернет, вроде всяких бабушек да дедушек (как минимум на первое время, пока не освоятся). Вам этого мало? (В теории ещё экономия электричества и как следствие благоприятное влияние на экологию, но это уже на грани бреда.)
Мне всё ещё плевать, что это сложно и не выгодно для бизнеса.
ну если вы такой молодец, то утрите всем нос, напишите свой сервис без JS но со всей функциональностью.
Пока в этом треде просто какая-то демагогия "все должно работать без JS просто потому что так 10 лет назад все делали и всем было норм". Но это было 10 лет назад, а сейчас все немного по-другому
была бы моя воля я бы ввел на все сайты
Зачем на все? Вводите на свои, это исключительно ваша воля. Кстати, такие сайты уже давно существуют и здравствуют.
Вот лично я был бы не против возможности купить платную подписку на поисковые системы, социальные сети, электронную почту, и т.д. Но с условием: на этих сайтах никакая информация обо мне не будет собираться ни в каких целях. Думаю, не только я хотел бы такую услугу…
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.
Если сайт мне нужен, то плюсом ко всему этому:
г) непонятно то ли сеть отвалилась, то ли просто тормозит
д) а, нет, это всё-таки сеть отвалилась, и приложение не хочет дальше загружать — придётся обновлять страничку: IF (RANDOM() > 0.2) GOTO а)
е) найти бы то место, где бросил читать
ж) в особых случаях: ссылку на текст можно получить, соответственно можно закладку поставить.
Жить в Якутии совсем не обязательно, такого счастья и в Москве предостаточно: от слабого компьютера до отсутствующего интернета. Но конечно, сайту дела нет до того 0,0..1% пользователей.
1) Через RSS и так основная часть настроена. Но его по-тихоньку все задвигают назад. Новые сайты делают сразу без RSS (и не уверен что в SPA вообще где-то видел такое счастье), а старые сайты ломают имеющееся (привет, MS). Ну и целиком мало кто хочет новость отдавать в RSS (ЖЖ и youtube, к примеру, не вставляют видео в эту разметку, хотя когда-то давно вставляли превьюшку; хабрахабр выгружает пост до ката), все хотят чтоб я зашёл на их миленький сайтик.
3) picasa достаточно, фотошопом пользовался когда он был версии 5. Если нет — darktable
4) этим невозможно пользоваться, даже если б оно не жрало память и было быстрым. К счастью альтернатив больше двух.
3) зачем мне мобильное приложение, если есть сайт? Если они сайты писать не умеют (то, что первично для сайта), то почему они вдруг умеют писать мобильные приложения?
Забыли ещё пункт:
4) это их проблемы и мне с ними не по пути.
Если Гугл в AndroidSDK в класс android.widget.Button влепит колбэк на отправку нажатия на кнопочку в Гугл — большинство андроид приложений будет всю свою статистику слать прямиком туда. Потому что никто свои виджеты не делат (разве что в играх на Unity каких нибудь).
А если будет слать через сокет а не через http-запрос — то раз в стопицот быстрее чем Google Analytics.
Так что не вижу принципиальной разницы.
Насчёт установки — я лично считаю что понятие операционная система в современных реалиях должна быть пересмотрена.
Например такие вещи как расширения файлов и древовидная файловая система кажутся очевидными, но это не так :)
Ну конечно, спустя 20 лет очень просто рассказывать, как именно надо было делать Веб.
И, по моему мнению, если бы вместо html мы бы писали TeX, Веб лучше бы не стал.
ущербный язык стилей, в котором до самых последних версий не было даже возможности отцентровать элемент по горизонтали
По вертикали.
зачем надо было придумывать этот велосипед, когда уже существовал хоть тот же TeX
Что-то слабо себе представляю его применение. Как там с изменением размеров окна, например?
Татарский, конечно, ненавидел советскую власть в большинстве её проявлений, но все же ему было непонятно – стоило ли менять империю зла на банановую республику зла, которая импортирует бананы из Финляндии.
Например, реализовать единый стандарт байт-кода. Основать его на байткоде CLR, JVM, V8. WebAssembly же смогли сделать, смогли договориться, так и тут)
И реализовать его поддержку на уровне ОС. В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Для поддержки приложений реализовать единый стандартный язык разметки, можно например на основе XAML. Обеспечить поддержку модных нынче компонентов. Можно встраивать в систему готовые компоненты.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Также в этом интерфейсе можно будет зайти на сайт, а он предложит установить приложение, либо автоустановка в безопасном месте, только с пользовательскими правами. Можно сделать на основе идей мобильных приложений)
В разных вкладках этого браузера 2.0 можно будет запускать как просмотр документов, так и приложения.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Таким образом, получаем настоящие кроссплатформенные приложения, удобство для разработки, красивые интерфейсы, при этом решаем проблему Electron(где отдельный Chromium на каждое приложение), и можно делать на любом языке программирования.
А ОС будут уже соревноваться между собой кто как лучше реализует эти стандарты и быстрее исполняет этот байткод.
И можно будет вводить стандарты на API к различным элементам системы, при этом делать их безопасными. Все равно все корпорации так или иначе стараются выполнять веб-стандарты)
Это будет ОС 2.0 и Браузер 2.0.
Эх, мечты…
Например, реализовать единый стандарт байт-кода… В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.Уже есть. «Система команд x86» называется.
реализовать единый стандартный язык разметкиУже есть. HTML называется. На мой взгляд, ужасен.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.Копию на вкладку сделали не просто так, а ради стабильности и безопасности.
Вобщем, всё уже либо было либо уже придумано и реализовано.
Уже есть. «Система команд x86» называется.
Имелось в виду байт-код, не привязанный ни к платформе, ни к языку программирования. Что-то похожее на WebAssembly или LLVM IL.
Уже есть. HTML называется. На мой взгляд, ужасен.
HTML — предназначен для текстовых документов. Я же предлагал XAML. Можно взять любой другой, tex и т.д. Сделать поддержку компонентов в первую очередь.
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
А чем сейчас документы отличаются от приложений? Я имел в виду единый интерфейс, чтобы юзер захотел — открыл сайт, документ, захотел — запустил приложение и было удобно. Это будет скорее tabbed shell, чем браузер, где каждая вкладка может быть окном, а каждое окно — набором вкладок.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.
Я критикую подход электрона, который запускает Chromium на каждое окно. При этом можно было бы вынести все таки эту общую часть и не грузить ее каждый раз по новой.
это ключевое, давно об этом пишу и говорю — HTML это язык разметки гипертекста, а для современных задач нужен язык разметки приложений. Javascript это клей для вывода alert окон и т.п., а сегодня нужен полноценный, грамотно спроектированный язык.
Так вот, переводчик, Web — это не замена десктопным приложениям, это альтернатива им. «Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки. Не мешай наяривать другим.
Web не должен быть быстрым, это понятно любой мартышке.
Люди пользуются Web-приложениями типа Google Docs, потому что они дают свободу от сраных десктопных приложений. Я могу править документы откуда угодно, все что мне нужно — не удариться по пути головой и помнить данные моей электронной почты.
Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право. Но то, что ты не способен понять и принять парадигму альтернативы — лишь твоя проблема. Не будет универсального «единого приложения», которое придет на смену Вебу, не будет вообще приложений. Потому что Web в том смысле, в котором мы его сейчас обсуждаем, возник как раз для того, чтобы ничего не качать, чтобы все крутилось на стороне больших и умных дядь. Кстати, это, как раз таки, одна из альтернатив на тему и Информационной Безопасности. Да, чтобы за ней следили большие, умные и совсем не ленивые дяди-разработчики на местах. Согласись, это проще, чем пытаться латать дыры у миллионов пользователей на их устройствах. Или нет?
Безопасность — это вообще миф. Идеального кода, приложений, производительности, даже собеседников — не бывает. Весь мир состоит из компромисса между скоростью и функциями, безопасностью и простотой, офлайновым и онлайновым доступом. И хватит тут разводить бредни про «Веб должен умереть!». Вылезь уже из своего уютного мирка, где образ «бородатого разработчика с котэ» все еще моден, и встреться с реальностью.
Без уважения, мимо пробегающий гуманитарий.
Относительно предыдущего коммента — не разделяю хейта к десктопу и прям обожания к вебу, и про дядь всё понимаю. Да и облака оно такое, сегодня есть, завтра ветром развеяло. С винта на винт таскаю конечно всякое нужное, и если о музыке говорить, то в годном качестве, включая флаки. Но это не отменяет того, что к вебу тоже отношусь с теплотой и моё следующее приложение будет разрабатываться на REST JSON API и всё такое этому сопутствующее. А будет что-то лучше, так посмотрим.
Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право.
Как же энтропия?
Почему веб должен умереть
Целый подзаголовок. Или там должно было быть «Почему текущий стек веб-технологий должен умереть»? Что-то не склеивается, знаете ли.
Кстати, как гуманитарий я читать умею внимательно, и карту текста делать в уме. А как активный автор Хабра и Гика — отличить «Веб» как явление от «стека технологий».
«Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки.Если бы мы все жили и работали каждый в своём маленьком индивидуальном пузырьке, то да. После этого вашего высказывания можно было бы поставить точку и закрыть тему.
Но мы живём во взаимосвязанном мире. И поэтому нет, противникам веба отнюдь не всё равно, что выбирают юзеры и организации по всему миру. Распространение продуманных стандартизированных решений полезно для нас всех, т.к. улучшает качество софта, увеличивает количество вакансий, удовольствие от работы, в конце концов.
Поэтому нет, затыкать и тыкать «сперва добейся» никого не надо, наоборот, нужно больше говорить о проблемах, кричать о них в провокационных статьях, вопрошать и убеждать, выступать по телевизору и раздавать листовки,
:)
Но серьезно, если бы не закрытость и платность его прародителя — Ребола, сейчас все могло было бы быть совсем иначе… Только представьте: вместо сотен мегабайт диска и памяти браузера — рантайм в ОДИН мегабайт, а функциональность — выше.
Стараюсь пользоваться web'ом с отключенным JS, включаю его только на тех сайтах, которые без него не работают, но мне очень нужны, либо включаю временно, что бы получить нужный функционал.
Изначально созданный в гонке за фичами, JS стал огромной проблемой для всего web'а…
Слепить несложный стандарт из готовых штук, и впилить в тот же Chromium второй режим вкладки для его поддержки — вполне посильная задача. Там не надо никаких гипертекстов даже — достаточно будет JVM, WebGL, API для мышки/клавиатуры, и RPC. И сразу уже игрушки можно будет по ссылке открывать. А с остальным — заменой для CSS/HTML, accessibility, индексированием, и прочим всем — вполне можно по ходу дела разбираться, добавляя стандарты и библиотеки.
JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
Да ну ёлки, где оно кривее остальных-то?
Я года три назад перескочил из уютного Java мира с Java/Scala в node + frontend. Нормальное оно. Другое просто сильно.
Стандарты менее стандартные, но если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно. И даже работает.
Берёшь Babel — и практически все проблемы с JS закрыты. Берёшь bootstrap, и не надо даже начинать думать о чем-то кроме того, в какой цвет кнопки покрасишь. Фреймворков для того, чтобы формочки и кнопки рисовать уйма. Начиная от крайне ванильного HTML/CSS/JS, заканчивая всякими Elm, ReasonML, ClojureScript, в связке с чем угодно, которые вполне себе работают.
Ну и React, раз уж столько хайпа про него. Автор про Flux упомянул. Он может быть и из времен Win3.1, но проблему-то он решает вполне неплохо. Если сравнивать, условно, Redux, который, конечно не совсем Flux, но из той же оперы, с правильным и расово-верным Qt (или что там автор предлагает?), то хм… кто из этих двоих ребят позволяет сделать replay приложения практически искоробки?
В общем, я конечно не могу сказать, что во фронтенде всё такое классное и блестящее — нужно ещё пилить и пилить. Но сегодня большинство проблем кривизны решается с помощью npm install left-pad… OH WHAI~~
если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно
Это утверждение из разряда «в принципе, если ничего не покупать, цены нормальные». Если не упарываться и ограничиваться примитивными вещами, можно даже продолжать сидеть в IE5 — его возможностей хватит почти для всего «не упоротого». Веб нужно убить именно потому, что как только задача становится капельку сложнее примитивной — начинается лютый трэш и угар. USB, нормальная многооконность, трей, протоколы помимо HTTP(S), FTP, WebSocket и WebRTC, UDP, вменяемый доступ к файловой системе и прочие плюшки — всё это или в зачаточном состоянии, или отсутствует вообще. У меня прямо сейчас запущены мессенджер с протокол XMPP, почтовый клиент с протоколом IMAP, торрент-клиент, аудиоплеер читающий flac-файлы с внешнего жёсткого диска, виртуальная машина с виндой, клиент Steam умеющий запускать заранее установленные игры в оффлайне, VNC-клиент и VNC-сервер. Вполне обычные вещи, но вебу о них остаётся только мечтать. Хотя в том же нижеупомянутом андроиде проблем с этим почти нет.
Здесь можно вспомнить про Electron. Он снимает некоторые ограничения (например, Skype получает возможность запихнуть себя в трей), но, опять же, поделки на нём жутко тормозят и лагают и жрут гигабайты памяти (на интел-атоме 2010 года можно даже не пытаться запускать), а также имеют все проблемы, перечисленные ниже. В то время как все десктоп-аналоги ведут себя довольно скромно, за 50 мегабайт оперативы вылезают редко (хотя по-моему это тоже много, но щито поделать, десктоп-разработчики тоже избалованы гигабайтами оперативы, эх), а проц не кушают вообще.
Берёшь Babel — и практически все проблемы с JS закрыты.
Высокоуровневый язык, компилируемый в другой высокоуровневый язык. Это же полный бред! Особенно когда что-то строгое и статическое компилируется в слабое и динамическое (TypeScript, C++). К счастью, с приходом WebAssembly эпоха полного бреда, возможно, закончится.
Берёшь bootstrap
Я абсолютно не переношу внешний вид бутстрапа (любой версии) и блюю от любой его кнопочки. у меня в системе установлена няшная тема Numix с не менее няшными иконками, и я хочу видеть эту тему везде в своей системе — почему же разработчики сайта решают за меня, как читаемый мной контент должен выглядеть? Ах да, веб же не позволяет использовать системную тему. В тяжёлых случаях приходится обмазываться всякими Stylish. Здесь стоит упомянуть, что даже Java умеет воровать текущую тему из GTK, да и вообще имеет биндинги к GTK.
Фреймворков для того, чтобы формочки и кнопки рисовать уйма.
По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком. Но нет, будем использовать язык разметки текста! И будем обходить его заточенность под текст многочисленными CSS-костылями, включая ранее упомянутый бутстрап. При этом выровнять блок по вертикали возможно лишь пару лет как, а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности). А canvas — лишь один из элементов внутри потока текста. Хотя должно быть наоборот. Опять полный бред получается.
React и Flux это в данном контексте больше про архитектуру (ибо есть ещё React Native, например). Но работают-то они всё равно поверх ущербных HTML/CSS/JS.
И, напомню, всё это жутко тормозит и лагает, не делая при этом почти никакой полезной работы. (Хотя есть надежда, что с приходом WebAssembly тормозить и лагать станет чуть меньше)
А клиент будет каждый раз качать 100мб этого фреймворка?
> Но нет, будем использовать язык разметки текста!
Есть альтернативы? Почему в современных десктопных гуи-фреймворках тоже используется язык разметки текста, а не что-то иное?
А клиент будет каждый раз качать 100мб этого фреймворка?
А сейчас он тоже качает, это называется браузер.) Хотя проблема действительно есть, но, думаю, если посидеть подумать, можно найти пути её решения, например принудительный semver и переиспользование ранее скачанных файлов за счёт него. Но я пока воздержусь от дальнейших рассуждений.
Есть альтернативы?
QML, XAML, GTK XML, XUL в конце концов?
Почему в современных десктопных гуи-фреймворках тоже используется язык разметки текста, а не что-то иное?
А это просто враньё. Выше я перечислил, что используется на самом деле. (Веб-макаки, клепающие говноприложения на электроне, естественно не в счёт)
Так вы и перечислили языки разметки, с точностью до синтаксиса повторяющие html. Если подход с использованием всех этих языков плох — то почему люди их используют, а не хреначат интерфейсы программно, без декларативного описания?
Они все — языки разметки интерфейса (или приложений, суть не изменится), а не языки разметки текста. Я ничего не имею против языков разметки. Я против использования языков разметки не по назначению, как это сейчас происходит с HTML (вы ведь в курсе, как расшифровывается HTML вообще?)
Что особенно странно, если вспомнить, что на заре своей юности HTML5 назывался именно «Web Applications 1.0» :)
В каких конкретно факторах проявляется, что HTML — язык разметки текста, а не интерфейса?
Например, в наличии кучи элементов для выделения в этом самом тексте мельчайших смысловых оттенков, которые даже редакторы спецификаций не всегда одинаково различают (кто сходу ответит без гугла и драки, для чего <mark>, а для чего — обновленный <b>?) при отсутствии даже такого элементарного примитива для интерфейсов, как <panel>.
В философии. Если приложение имеет область отображения, разделенную между компонентами, то HTML и CSS изначально создавались с идеей бесконечно растущего вниз текста.
Тут, например, растут уши у тысячи и одного костыля для того, чтобы web-приложение вело себя подобно десктопному/мобильному.
Более того, из-за этого HTML и CSS имеют очень слабую поддержку постраничного отображения информации (для печати, к примеру).
А клиент будет каждый раз качать 100мб этого фреймворка?
У нас свой фреймворк на C++ и приложение в wasm весит 10Mb, в жатом виде 2.7 Mb. Что бы каждый раз не скачивать используется кеширование.
Выгружать дерево UI-контролов в примитивный невидимый кусок DOM без CSS с aria-тегами. Если фреймворк изначально портируется с десктопа, то там кроссплатформенная поддержка скринридеров скорее всего уже есть и к ней такое прикрутить не сильно сложно.
USB, нормальная многооконность, трей, протоколы помимо HTTP(S)
Стойте. Причём здесь веб? Многооконность и трей, к счастью, не очень про веб. Веб — это про рисовать странички. Многооконность, трей и всё остальное — это про операционную систему. Должен ли это уметь веб? Возможно, но зачем? Кстати, как многооконность с треем должна работать на андроиде, допустим?
Ах да, веб же не позволяет использовать системную тему
Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему. Должен ли это делать веб?
Причём здесь веб?
Если веб — платформа для приложений, то должно присутствовать всё перечисленное и не только.
Должен ли это уметь веб? Возможно, но зачем?
Затем, что веб нынче считается платформой для приложений. Если же рассматривать веб как HTML для разметки текста и его связи гиперссылками, CSS для его разукрашивания и скрипты сбоку для капельки интерактивности (чем он и является на самом деле), то тогда всё мной перечисленное действительно не нужно, но это же означает, что две трети сайтов используют веб не по назначению. Гуглдоки, скайп, слак, дискорд, трелло, Unreal Engine 4 — это всё нихрена не про разметку текста блин!
Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему.
Во-первых, у меня он подхватывает Numix без плясок. Во-вторых, даже если вдруг пляски где-то и нужны, прикрутить системную тему всё-таки можно, и пляски это в минус Qt, а не в плюс вебу.
По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.
Так это и сейчас можно. Только попробуйте продать такую разработку кому-нибудь. И дизайнера впридачу, т.к. на бутстрапе сверстать может даже программист, и от этого не будет тошнить, а рисовать на канвасе — это мы вернемся в век адских самописных утилит с джпег-картинками вместо кнопок.
а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности)
Да вроде можно тем же флексом прижать, если устраивает скролл в рамках области контента
Так это и сейчас можно.
Нельзя. Можно только canvas внутри HTML. А надо чтобы HTML рисовался на canvas. Как следствие, утверждение «Только попробуйте продать такую разработку кому-нибудь» не имеет смысла, потому что такой разработки ещё просто нет. (В десктоп-приложениях можно что угодно, но они требуют установки и поэтому не относятся к данной теме)
а рисовать на канвасе
Портировать бутстрап (или любой другой аналог) на канвас же, не думаю что получится что-то адское. И вообще должна использоваться системная тема и всех дизайнеров выгнать из веба и отправить на создание системных тем, воот))
Да вроде можно тем же флексом прижать
И правда, тут я чёт погорячился. Тем не менее нельзя ещё много чего, но точный список не записываю и прям щас не упомню всё
какую проблему бизнеса
Да плевал я на бизнес, я страдаю как пользователь
Если у вас 4 пенек и 2GB ОЗУ, то это ваши проблемы.
Почему я должен доставать кор-ай-девятьтысяч и 32+ГБ для задач, которые без напряга способен решать даже какой-нибудь третий пенёк с 128МБ оперативки? Почему лет десять назад скайп на компьютерах того времени нормально работал, а сейчас, умея всё абсолютно то же самое, тормозит не то что на мамином, а даже на моём новеньком кор-ай-пять из 2014-го? Почему у меня забирают право пустить ресурсы моего компьютера на что-то полезное и заставляют или тратить проц и оперативу на абстракции над абстракциями, или отказываться от чуть ли не всех приложений вообще? (Вообще десктоп-приложений это тоже касается, но там наглеют ещё не так сильно, как ленивые веб-макаки, клепающие скайпы на электронах.)
Вспоминается классика:
Удивительное это дело — прогресс. Чтобы набрать и распечатать одну страничку красиво оформленного текста мне уже не хватает мощности компьютера, который с легкостью может управлять двумя тысячами советских боевых спутников одновременно. Есть мнение, что если бы неmicrosoftвеб-макаки, то мы давно бы уже покорили вселенную.
1) Конечных пользователей все устраивает.
2) Веб разработчиков все устраивает
Отучаемся говорить за всех.
Берёшь Babel — и практически все проблемы с JS закрыты.
Ну да, щаз. Это вам никогда видимо не приходилось пытаться запускать поделки на JS не в той среде, в которой ожидает автор. Т.е. не в браузере и не в ноде. А такие бывают, поверьте.
В какой-то момент, фронтендеры решили что JavaScript настолько ущербный, что лучше в него какой-нибудь другой язык компилировать, чем на нем писать. Можно было выбрать любой язык. И что же они выбрали? JavaScript 6!
Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.
И штук 10 еще таких цитат в основном вашего авторства. Вы сами себе противоречите, говоря только о C#.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.
Пруфы? На хабре принято использовать аргументы. А про языки — нет идеального языка. PHP стал источников мемов, JS странный и далек от идеала, С++ монстр во плоти, а а Шарп это лазерная пушка, которая не работает без ослика.
Не нужно быть психологом, что бы понимать почему они это делают.
JS не лезет в драйвера, контроллеры и банковский сектор, но JS лезет в средний бизнес, там где обосновался C# разработчик.
C# можно много где использовать — банки, энтерпрайз, хайлоад, десктоп и т.д. Тут JS-у до него ой как далеко. Упадок C# на десктопе связан не с JS, а с общим умиранием десктопа.
Ах да, есть еще Unity и игры. И что-то как-то там C++ и C# правят балом, а не JS.
Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)
WASM — посмотрим, что за зверь, пока что выглядит незрело.
А JS свергать не надо, отличный язык для задачи придания интерактивности на HTML-страницах) Пусть и остается им))
Я уже выше писал про новые стандарты приложений. Они — лучший путь, чем WASM или HTML+JS
— писать эти приложения очень дорого. Что-то примерно 10x по баблу, против Delphi 7, наверное. Т.е. для приложений веб — отвратителен.
— реализовать этот стандарт, по-факту, могут две конторы в мире — Microsoft и Google. Есть только две работающих реализации. Победи одна — и будет нам полное и безоговорочное самодурство одной конторы. А Google что-то не сильно интересно, чтобы было удобно делать на вебе приложения. Реклама крутится, бабло мутится. Нет ни у кого 100500 баксов чтобы написать что-то лучше Gmail? Ну и хорошо, Google это вполне устраивает.
Да, можно поверх веба поверх собрать POC на WebGL. Но это будет лагать, геморройно по тулам, и канет в лету. Нужна реализация с нуля, чтобы ничто не мешало. Как минимум — как выхлоп для кучи идеалистов, которые сейчас делают всякие ReactOS. Будет источник идей, будет фонтан идей, в который можно кунать авторов очередного border-radius или flexbox.
Короче, я считаю, что хайп тут — в тему. Надо всем миром замутить проект «веб X.0 с нуля» — пусть он не выстрелит, и вообще пусть будет вечным, и будет раскалываться на ветки. Но что-то должно быть, что конкурирует с вебом.
Были джава-апплеты. Не судьба. Был Сильверлайт. Был ActiveX. WPF в браузере. Даже Флеш — и тот отходит.
А отвратительный, старый, небезопасный веб, с ужасным Джаваскриптом, с пол-гигов памяти на вкладку — живет.
Делать интерфейсы как в играх — можно с бюджетами, как в играх. Впрочем, их можно в вебе делать и сейчас — да никто не делает. Потому что все описанное в статье — хорошо как теория, как идеальная картинка, но не как решение тех проблем, которые решает веб.
Но точка кипения еще не достигла апогея, да и явные косяки пытаются прикрыть ширмой из webassembly.
пытаются прикрыть ширмой из webassembly.
Можно пример?
Появление первых транскомпиляторов в JS должно было стать звонком тому, что пора что-то делать с JS, а не добавлять костыли. Сейчас например изучают не основы JS, а какой-нибудь модный framework.
Нужно не всё выбрасывать, а 1 раз просто взять и исправить.
Например вместо JS внедрять тот же Dart, вместо websocket использовать нормальные сокеты.
Использовать для тяжелых задач настоящие потоки.
HTML/CSS сериализовывать в бинарный поток данных(на клиенте десериализовывать обратно), чтобы гонять меньше трафика.
Это можно начать делать прямо сейчас, без кардинальных изменений в самих web-сайтах, но всем пофиг, лучше будет написать очередную статью про то, какой web плохой.
WebAssembly не про это. WebAssembly это возможность запускать код на таких языках как C,C++,Rust в браузере. История начинается с Поддержка Portable Native Client появилась в Chrome. Кто победит в гонке за нативным быстродействием — PNaCl или Asm.js?
Что вы там на нём пишете? Куда ещё производительнее? https://habrahabr.ru/post/281879/
Проблема в том, что сейчас весь этот стек пихают куда попало.
А что в этом плохого? Если есть конкуренция, то выживает тот, который больше подходит покупателям. Иначе всё равно будет неудобный продукт.
habrahabr.ru/company/hexlet/blog/303754
Алан считает Интернет, протоколы TCP/IP, интерпретаторы LISP, Nile (Math DSL for Vector Graphics) и OMeta (OO PEG) (PDF) примерами элегантного софта с минимальным кодом.
Он называет Интернет (TCP/IP) одним из немногих масштабных софтверных проектов, который был правильно разработан, и его уровень сложности — в балансе с уровнем комплексности (complication vs. complexity). Этот проект, в котором меньше 20 тысяч строк кода, работает как живая, динамическая система, способная поддерживать миллиарды узлов, и она ни разу не отключалась после первого запуска в сентябре 1969 года. Мы просто перестали считать Интернет нормальным софт-проектом, созданным людьми:
Интернет разработан настолько хорошо, что многие относятся к нему как к естественному ресурсу, вроде Тихого океана, а не к плоду человеческого труда. Когда в последний раз мы видели настолько стабильную, четкую технологию без ошибок?
Для сравнения, Веб это ерунда. Веб создан дилетантами.
Но UI, который вы видите вверху, по сложности довольно похож на UI, который вы видите внизу
И ведь это замечательно! Перегруженные интерфейсы, да ещё и с кучей визуальных эффектов — не то, к чему стоит стремиться.
Был небольшой период времени, когда была мода на новые SPA уже была, а пререндеров нормальных ещё не завезли (да их и сейчас не всегда можно использовать, если у вас фронт запускается несколько секунд). Индексация лечилась посредством тега <noscript> в который сервер лил plaintext-содержимое. В принципе, вполне себе работало и нормально жевалось яндексом и гуглом.
А про лёгкость и широчайший спектр возможностей вы явно приукрашиваете. По состоянию на сейчас даже просто к USB-устройствам достучаться проблема, с криптографией (особенно ГОСТовской) куча проблем, включая тормоза, UDP отсутствует в принципе (ограниченный огрызок в виде WebRTC не считается), даже банальный копипаст оказывается с кучей косяков если покопаться… Перечислять можно долго, в коммент не влезет. Сейчас в вебе только и можно делать примитив типа гуглдоков, и те жутко тормозят и на каком-нибудь интел-атоме 2010 года ими уже хрен попользуешься.
При этом, похоже, в Android всё такое есть и не особо тормозит и без потери «бронетанковости», а с недавних пор куда-то в Google Play завозили работу приложений без установки… Хм, может, за андроидом будущее?))
Я говорю о другом.
Развитие Java было сопряжено с развитием веб. В виде дополнения к браузеру Java получил широкое распространение, но производители браузеров не позволят дополнению компрометировать себя. Как самостоятельные web-приложения (приложения, которые используют веб) JAR не могут заслужить доверия, так как доверять можно только с некоторой долей понимания намерений. В Android и GooglePlay реализовано неплохое решение, можно лучше, можно сделать песочницу с затычками для портируемых пакетов, можно сделать обучаемую систему защиты как AppArmor, чтобы было понятно, удобно и без палева.
Хочу предложить…
Цитирую:
А вы знаете, если допилить к JVM управляемую песочницу, где можно было бы выставить разрешения программы[...]
Всё это делает SecurityManager.
www.jcp.org (что это?)
Есть те, кто способны проворачивать такие инициативы =) А?
Все смешалось в доме бывшего гуглатора и кони, и иконки, и буфер… Несомненно, вебер приложения ещё далеко от идеала, но весы плюсов и минусов не дремлют, например, веб приложения лучшее решение для кроссплатформенных приложений, а это многого стоит.
Разработчики любят писать веб-приложения по одной причине — ожидания пользователей от таких приложений исключительно низки.
Это глупость. Я и как разработчик, и как пользователь люблю веб-приложения по двум причинам:
- Не нужно устанавливать, работает сразу. На этом шаге отваливаются очень много потенциальных пользователей. Нужно иметь сильную мотивацию запустить именно это приложение, чтобы пройти через процесс установки.
- Работает везде, а не только на любомой платформе разработчика. И на линуксе, и на мобилках, везде. Десктопные приложения, как правило, делаются под одну самую распространённую платформу, а все остальные сосут лапу. Кросплатформменность / портирование увеличивает стоимость разработки в разы.
2. Единственное реальное преимущество. Но что, гипотетически, мешает создать нормальную «платформу приложений» (с нормальным языком разметки UI и нормальными протоколами обменами данными) вместо браузера?
Да и установка приложения из «магазина приложений» на современных мобильных платформах ничуть не сложнее, чем заход на сайт.
Во-первых, это дольше.
Во-вторых, никто не будет устанавливать всё подряд, просто посмотреть, потому что это установленное приложение потом будет занимать место на устройстве и в списке приложений.
В-третьих, мобильные приложения хотят всяких разрешений. Иногда — непонятно, зачем.
Но что, гипотетически, мешает создать нормальную «платформу приложений» (с нормальным языком разметки UI и нормальными протоколами обменами данными) вместо браузера?
То, что ей никто не будет пользоваться, очевидно.
Хороший оборот речи. Кто бы мог показать образец такого удостоверения? А то нашлось не совсем то, однофамилица.
вроде очевидные вещи, но люди продолжают писать о том как прекрасен яваскрипт и рест
вот интересная концепция в плане их замены unisonweb.org
Но давайте все-таки задумаемся вот про что. 300МБ оперативки в 2017 и 32МБ в 2000. На сколько это больше? Если мне не изменяет память, то 32МБ это была _вся_ оперативка на среднем компе. 64МБ- это было очень даже хорошо. А 128МБ — это просто восторг. А что сейчас? 2GB это комп- смотрелка интернета. 4GB- разумный минимум если вы хоть что-то собираетесь делать. А так 8-16GB- самое то. Не знаю как вам, а мне кажется, что 300МБ это значительно меньше, чем 32МБ ;)
Но статью я все-таки дочитал. Похоже автор так и не понял, что можно не выбирать, а использовать все имеющиеся технологии одновременно. И как мимо него прошла та же Java ума не приложу.
Но с учетом того, что открытый документ лежит на расстоянии тысяч километров от меня
Это учитывать глупо и бессмысленно. Достаточно скачать файл с облака один раз во временную папку на жёстком диске, а дальше можно работать с ним как с локальным. Ну, может, периодически подгружая позиции курсоров других пользователей и диффы при совместном редактировании. Но ничего из этого не требует трёхсот мегабайт оперативы.
4GB- разумный минимум если вы хоть что-то собираетесь делать.
Всё то, что делает среднестатистический пользователь, можно уместить в полгига при желании, если не говнокодить и не обмазываться лишними абстракциями. Кроме игр, виртуалок и гигантских слоёв в фотошопе разве что, но это отдельные истории, им оператива нужна по уважительным причинам.
А зачем?
Но есть одна нескладушечка. У нас на всех компах 16GB памяти и не могу сказать, что ее всегда хватает. По вашим словам мы должны как-то в 0.5 GB помещаться. Получается не стараемся?
Так оставляйте, в чем проблема?
… ой, кажется мы случайно деградировали до однозадачного DOS. Приехали.
Зачем вам месенджер и скайп, когда вы играете в «простенькую 3д-игру»?
> … ой, кажется мы случайно деградировали до однозадачного DOS.
Во времена ДОС вы бы запустили одно приложение и не булькали бы. В 2017 вы держите активные месенджер, скайп, проигрыватель, браузер с миллионом открытых вкладок, торрент клиент, еще что-то там по чуть-чуть, а потом жалуетесь, что у вас рендеринг тормозит. И проблема-то не в скайпе, проблема в жручем рендеринге. Вот его пусть и оптимизируют, чтобы не отбирал память у скайпа.
Зачем вам месенджер и скайп, когда вы играете в «простенькую 3д-игру»?
Капитан Очевидность замечает, чтобы получать входящие сообщения и звонки и прервать игру по необходимости.
И проблема-то не в скайпе, проблема в жручем рендеринге.
На этот бред даже не буду пытаться отвечать. Может, какой-нибудь оскорблённый тридэшник вам позже ответит.
Это учитывать глупо и бессмысленно. Достаточно скачать файл с облака один раз во временную папку на жёстком диске, а дальше можно работать с ним как с локальным. Ну, может, периодически подгружая позиции курсоров других пользователей и диффы при совместном редактировании. Но ничего из этого не требует трёхсот мегабайт оперативы.
У меня комп есть на работе. Если быть точным, то у меня их 3, но сейчас это не так важно. У меня дома то же есть компы. Тех, с которых я открываю документы 4. Есть телефон. И с него я то же открываю документы. Вы предлагаете мне скачать на все мои устройства все мои документы? И так же предлагаете сделать всем членам моей семьи? У дочки там совсем не много. Относительно. А вот у жены 3 облачных пользователя. Два из которых — корпоративные фактически без ограничения места. И ее работа- документы. Глупо и бессмысленно? Серьезно?
Может быть вы имели ввиду качать по одному? Текущему? Даже у меня есть разные документы, а не очень много с ними работаю. Есть таблички, где нет и 100 строк, а есть и по 1500 страниц с таблицами, формулами и рисунками. Их то же качать? Полностью? Даже если я открою страницу 307 и может быть дойду до 308? А если я в дороге и работаю через мобильный интернет. Я даже не буду говорить, что он не дешев. Он медленный. Думаете разумно ждать возможно и несколько минут только для того, что бы скачать документ целиком?
Вы представляете сколько нас таких у Google, MS, Dropbox и многих других, кто хочет иметь доступ к своим документам? Интернет гиганты тошнят на различные комитеты, что они заголовок сделали длинный, а вы предлагаете документы целиком качать? Серьезно?
Что бы редактировать текст в простейшем редакторе много не нужно. Но вы ведь так не делаете? И я то же. Мы ведь хотим что бы наш документ был красивым. С хорошими шрифтами и красивой графикой. Хотим что бы редактор исправлял ошибки, что бы он на лету менял стили. И вот это уже требует места.
Всё то, что делает среднестатистический пользователь, можно уместить в полгига при желании, если не говнокодить и не обмазываться лишними абстракциями. Кроме игр, виртуалок и гигантских слоёв в фотошопе разве что, но это отдельные истории, им оператива нужна по уважительным причинам.
Я все хочу выяснить кто такой этот среднестатический пользователь. И еще более непонятно чем он должен заниматься. В моей семье все совсем не среднестатические. Я как вы выражаюсь говнокодю, жена вообще математик. На ее компе уже вторые сутки моделирование идет. Может быть мой ребенок потянет. Хотя в последний раз когда мы были в магазине электроники мы от нечего делать на витринном ноуте написали однострочник на питоне (я придумывал, дочка реализовывала), который потребовал 57GB оперативки. Это получается, что дочка моя не среднестатическая на 56,5 GB?
Может быть вы расскажите как «не обмазываться лишними абстракциями»? Сейчас оно как-то само по себе получается. Ты тыкнул в ярлычек, а оно как-то все само, само.
Вы предлагаете мне скачать на все мои устройства все мои документы?
Не надо доводить до абсурда, это должен делать онлайн-редактор автоматически при открытии документа. А при закрытии или отсутствии свободного места удалять, оставляя лишь сохранённую копию в облаке. Между прочим, именно так любой кэш любого браузера и работает.
Даже если я открою страницу 307 и может быть дойду до 308?
И ещё раз: не надо доводить до абсурда, грамотно организованный онлайн-редактор может скачать только нужную часть документа. И всё это по-прежнему не требует трёхсот мегабайт оперативы, даже наоборот — скачивание документа по частям позволяет эту самую память экономить.
Ты тыкнул в ярлычек, а оно как-то все само, само.
Это не имеет никакого отношения к абстракциям. То же самое можно написать хоть на голом x86 ассемблере без абстракций. И, думаю, оно потребляло бы мегабайт десять оперативы при схожем с гуглдоком функционалом. (Только этого делать никто не будет, потому что слишком сложно, поэтому делают абстракции для упрощения, но в 2017 году абстракций стало СЛИШКОМ много.)
На остальной коммент отвечать не буду, так как он весь состоит из таких доведений до абсурда.
Вы, кажется, забыли, что оперативная память работает быстрее, чем жесткий диск. По-этому если что-то можно хранить в оперативной памяти — оно должно храниться в оперативной памяти. Я покупал 16гб оперативки именно для того, чтобы они были заполнены, это позволяет приложениям работать быстрее. Ну а у тех, у кого памяти мало — те, да, пусть сбрасывают на жесткий диск — к слову, для этого есть файл подкачки и работает он автоматически. Но делать это (использовать жесткий диск) надо в том и только в то случае, когда памяти нет. Не когда ваше приложение ее много занимает — а когда оно пытается занять больше, чем есть.
Во-первых, она очень плохо кеширует (даже винда, с линуксом вообще боль и печаль, к слову — именно хреновым системным кешем объясняется большинство тормозов браузеров), во-вторых — кеш приложения будет заведомо быстрее, так как работает напрямую, без прослоек.
> А приложения не должны без крайней необходимости.
Именно что должны. Выбирая между браузером, который при включении грузит 10гб кеша и браузером, который укладывается в компактные полгига — я (да и любой среднестатистический пользователь) всегда выберет первый. Потому что повышенное потребление памяти заметить нельзя, а вот повышение быстродействия — будет налицо.
Ну и да, если вы уж ратуете за десктопные технологии против веба — давайте вспомни про jvm, которая по дефолту вообще не отдает освобожденную память системе (чтобы потом не пришлось ее опять запрашивать).
Во-первых, она очень плохо кеширует
Ничего подобного ни в одной из используемых мной систем ни на одном из используемых мной компьютеров я не наблюдал. Даже проводил несколько экспериментов: искусственно забивал всю оперативу, чтобы кэш вычистился, потом освобождал — система тупит ещё несколько минут, пока очищенный кэш не прогреется снова, а потом всё норм. Склонен считать, что в ваших случаях ОС кэширует плохо, потому что оперативу уже заняли приложения и кэшировать тупо некуда :)
выберет первый
А я нет. Дайте мне право выбора, сволочи! Где волшебная галочка «экономить память» в каком-нибудь браузере? Почему все всё решают за меня?
повышение быстродействия — будет налицо.
Не спорю. А что если я не хочу быстродействия? Я хочу оставить браузер открытым, чтобы он был «в шаговой доступности», но не хочу, чтобы он занимал память, потому что я, например, сейчас играю в игру, которой память нужнее. И вот здесь этот ваш своп, кстати, не помогает: как только доходит дело до его использования, тупить и лагать начинает абсолютно всё. В тяжёлых случаях браузер приходится всё-таки закрывать, лишь бы своп не юзался.
если вы уж ратуете за десктопные технологии против веба
Замечу, что за jvm я не ратовал
jvm, которая по дефолту вообще не отдает освобожденную память системе
И от этого мне тоже временами хочется плакать. По возможности избегаю всё связанное с jvm.
Вы, видимо, из параллельной реальности. ОС никогда не сможет качественно кешировать данные, т.к. это невозможно сделать, если неизвестно, что это за данные и как они используются. Условное приложение такой информацией о своих данных обладает, ОС — нет.
> А я нет. Дайте мне право выбора, сволочи! Где волшебная галочка «экономить память» в каком-нибудь браузере? Почему все всё решают за меня?
Это рынок. Подавляющее большинство пользователей хочет функциональные, быстрые, красивые программы. А на то, что в диспетчере задач там будет указано высокое потребление памяти — этим пользователям плевать, они этого никогда не узнают. Если вы хотите использовать тормозные браузеры «зато память не жрет» — ну разрабатывайте такие браузеры, или финансируйте их разработку.
> Не спорю. А что если я не хочу быстродействия?
Вы мазохист? Ну купите компьютер послабее. Снимите лишнюю оперативку, оставьте 2гб. Или лучше 1гб. И наслаждайтесь.
> И вот здесь этот ваш своп, кстати, не помогает: как только доходит дело до его использования, тупить и лагать начинает абсолютно всё. В тяжёлых случаях браузер приходится всё-таки закрывать, лишь бы своп не юзался.
Так вот лагать начинает как раз от того, что используется жесткий диск вместо оперативной памяти. И вы сейчас предлагаете сделать так, чтобы лагало подобным образом ВСЕ, ВСЕГДА И ВЕЗДЕ, а не только тогда, когда память закончилась. Извините, но когда я покупаю оперативную память для компьютера, то я хочу чтобы не тормозило, а не чтобы все работало так,, будто этой памяти в 6 раз меньше чем по факту есть в системе.
> И от этого мне тоже временами хочется плакать.
От того, что приложения тормозят меньше, чем могли бы? Почему вы хотите использовать медленные приложения вместо быстрых?
Знать характер данных и то, как они используются программой.
> ОС кеширует файл блоками, блоки используются- они в кеше, блоки не используются- они выгружаются в файл или подкачку.
И именно по-этому эффективность кеша ОС очень низкая.
Проблема в том, что это «скорее всего потребуется» определяется чисто статистически, что на порядок менее эффективно, чем априорное знание, какие конкретно данные, когда и как нужны, которым обладает конкретное приложение.
Вы, видимо, из параллельной реальности.
Рад за себя.)
ОС никогда не сможет качественно кешировать данные
Рад за свой Linux 4.13, он превосходно у меня справляется.)
Это рынок.
Этим я и недоволен.
Вы мазохист?
Нет, я хочу производительности для тех задач, которые выберу сам. Но «рынок» как обычно решает всё за меня. Выбор зачастую есть только между «использовать» и «не использовать». Прощай, многозадачность!
И вы сейчас предлагаете сделать так, чтобы лагало подобным образом ВСЕ, ВСЕГДА И ВЕЗДЕ
Повторю в стопицотый раз: ОС прекрасно справляется с кэшированием файлов сама. Если ваша ОС не справляется — приглашаю к себе в параллельную реальность :)
От того, что приложения тормозят меньше, чем могли бы?
От того, что jvm не умеет эффективно использовать память. Меньшее потребление памяти совсем не обязательно означает тормоза, это вы что-то там себе навыдумавали.
Как я уже говорил выше — линукс в данном случае очень сильно проигрывает винде, а там все очень плохо. За подтверждающим примером далеко ходить не надо — тормозящие браузеры :)
> Нет, я хочу производительности для тех задач, которые выберу сам.
Но вы не выбираете производительность. Вы выбираете, чтобы тормозило все.
> Повторю в стопицотый раз: ОС прекрасно справляется с кэшированием файлов сама.
ОС не знает какие данные и как кешировать. Результат — кеш на 90% забит ненужным хламом, а нужных данных там нет. Это, кстати, одна из причин, по которым файл подкачки так тормозит.
> От того, что jvm не умеет эффективно использовать память.
Но она умеет.
> Меньшее потребление памяти совсем не обязательно означает тормоза, это вы что-то там себе навыдумавали.
Меньшее потребление памяти приведет к тому, что придется чаще просить память у системы. То есть гарантирует замедление работы. Это не говоря уже о практически всех сборщиках мусора, в которых затраты на сборку обратно пропорциональны потребляемой памяти (чем больше памяти потребляет программа — тем меньше итераций гц).
Ах, да, отключить сборщик мусора тоже нельзя, так как ручное управление памятью, опять-таки, тормозит :)
Совсем нет. Выделение памяти в случае копирующего/перемещающего сборщика — это, фактически, простой инкремент указателя, что в десятки раз быстрее стандартных аллокаторов, а освобождение памяти и вовсе происходит мгновенно. В итоге, в случае выделения большого количества короткоживущих объектов, сборщик сильно быстрее. Естественно, можно написать свой аллокатор, который будет работать с памятью по принципу гц, но это уже разговор другой, да и с кастомным аллокатором вы в итоге все равно получите оверхед по памяти, просто не такой большой как в случае с универсальным гц.
Меньшее потребление памяти приведет к тому, что придется чаще просить память у системы.
Вы говорите о случае, когда приложение априори берет много памяти — либо сразу 1 Гб выделить, либо кусками по 10 Мб. А вам говорят о случае, когда приложению в принципе не нужно столько памяти — выделить сразу 100 Мб и всё.
Если вам надо хранить 1гб данных — то вам надо хранить 1гб данных. Если вы не будете выделять этот 1гб в хипе — значит, вам надо выделить ее на жестком диске (тормоза) или пересчитывать данные каждый раз во время работы программы (тормоза). Размер требуемой памяти не зависит от того, выделяете ли вы память маллоком в сишечке или через gc в джаве (да, гц имеет определенный оверхед на алгоритм сборки, но он практически никогда не превышает процентов от общего потребления). В итоге это одна и та же память, которая хранит одни и те же данные.
Это во-первых, во-вторых — на практике у вас нет ограничения на потребляемую память сверху. Вот я работаю в иде, сколько вкладок открою — столько памяти и сожрет. Или сбрасывать вкладки на жесткий диск? Но тогда будет тормозить. Да и все равно нужно хранить в памяти АСТ для какого-нибудь intellisense.
Но они не «лишние», они экономят трудозатраты. Либо у вас есть работающее приложение с абстракциями сегодня, либо без абстракций, но через год (когда оно уже не нужно в силу того, что конкурент вышел на рынок и этот год потратил на допиливание каких-то дополнительных фич, которые дадут ему преимущество). Аналогично с тем же ГЦ — код, который пишется «в лоб», на managed языках в основном работает быстрее, чем на языках с ручным управлением памятью. При желании, конечно, можно заоптимизировать ручное выделение так, чтобы оно работало быстрее — но кто это будет делать и за чей счет?
Речь о том, что переход с условного веба на какие-то другие варианты _сам по себе_ ничего не принесет — наоборот, при прочих равных мы будем получать приложения, которые сильнее глючат, больше тормозят и обладают меньшим функционалом, потому что писать их будет человек, который вчера делал визитки на php.
На мой взгляд автор поднимает правильные вопросы, но в слишком резкой форме…
На самом деле, очень часто посещает мысль: «Чем я вообще занимаюсь и как?». Ведь у большинства разработчиков из задач сейчас такие: «Сделаем эту фичу, чтобы кнопка эта не так отображалась», «Вот нужно это сделать, чтобы SEO-шникам хорошо жилось» и т.д. Да, иногда бывает просветление и попадаются интересные задачи, но очень редко. Естественно, я рассказываю про свою жизнь.
Или возьмем какой-нить новый фреймворк. Осваивается он достаточно быстро, но сколько он пакетов с собой тащит, это ужас. И очень часто работа разработчика (вспомните, мы инженеры, между прочим) это копаться в этих покетах и понять, почему же один с другим конфликтует и почему не работает что-то. И это работа инженера с вышкой и большим опытом? Это что вообще за задачи? В моем понимании инженерная задача, когда ты что-то оптимизируешь и например, увеличиваешь какой-то показатель в 2 раза, т.е. что-то даешь, создаешь, творишь, изучаешь предметную область, анализируешь. Это разве инструмент, который постоянно пытается развалиться или сломаться? Это современные инструменты веба, между прочим.
Давно уже хотел высказаться. Вот и статья подходящая. Спасибо.
Невозможно написать безопасное веб-приложение
У человека какое-то непонятное представление о безопасности. Если нет четких критериев «секурное приложение — это...», то и возражать-то бессмысленно.
А безопасное приложение в моем понимании создать довольно несложно:
1. Не разрешай cross-origin запросы (XSS,XSRF, etc.). Если невозможно — учись предохраняться.
2. Не используй непроверенный код (HEIST). Использование сторонних библиотек иногда просто необходимо, но всегда чревато понятно чем. Да это вообще любых приложений касается.
3. Фильтруй
Во-вторых, все три пункта ничего не значат. Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json, в котором есть и защита от cross-origin, и не используются сторонние библиотеки, и весь ввод фильтруется/экранируется, только какой толк от всего этого, если там разработчик тупо забыл прописать проверку доступа и любой пользователь, узнав про существование этого API, может изменить или в особо запущенных случаях даже прочитать пароль любого другого пользователя?)
Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json
Собственно на приведенный Вами пример я и написал про:
Если нет четких критериев «секурное приложение — это...», то и возражать-то бессмысленно
И
безопасное приложение в моем понимании
Дело в том, что всегда можно найти способ выстрелить себе в ногу практически на любой платформе. Жаловаться на то, что веб позволяет забыть проверить права для некоей функции API — как минимум странно.
Подобную ошибку возможно допустить в любом приложении, хоть в полностью десктопном (хранить данные пользователя плейн текстом), хоть в любом другом клиент-серверном (ну, например «забыть выключить на продакшне тестовую фичу с выдачей списка пользователей, не требующую авторизации»).
Вообще автор ратует за некий NewWeb, который нужно пилить и который будет безопаснее текущего Веба. Как этот NewWeb будет защищать от косяков, подобных описанному Вами, мне не совсем понятно.
Но Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти, в то время как Google Docs со скриншота использует CPU на 2,5 ГГц и почти в десять раз больше памяти.
Вполне разумная плата за то, что веб-приложения (включая Гугл Докс) одинаково запускаются на всех ОС, где имеется браузер.
Пора убить веб