В конце концов пользователь должен получить возможность запускать реально «тяжелые» приложения, иметь возможность играть в браузере в топовые игры и т.д.
Нет. Не нужно все это в браузере. Браузер нужен для просмотра html документов, не более. Хватит уже тащить все в браузер и браузер во все.
Ну так может прямо в браузер будем загружаться? Кому вообще нужна ОС когда есть всемогущий браузер?
Надеюсь, что такое не случится никогда.
И я скорее против переноса всего в браузер. Некоторые вещи конечно удобно иметь в браузере, как было с квейк лайв по началу. Или IDE в браузере(они есть, но не все удобные)
прямо в браузер будем загружаться?
Уже, гуглите ChromeOS
Ну и в целом концепция, как ни крути, все-таки порочна. По сути-то это «jvm + принудительное автообновление» только реализованное в веб-браузере. И нафига тут нужен именно веб-браузер не вполне понятно.
Пока свыше 90% пользовательских устройств работало на винде, на все эти VM смотрели с усмешкой. Но вот когда возникла задача обеспечить рендеринг GUI на множестве принципиально различных устройств и окружений, вот тут без слоя абстракции в виде VM уже никуда. Потому что фрагментация просто охрененно замедляет и удорожает разработку нативного кода.
Например, если я хочу писать код под iOS, но при этом сидеть на Linux, браузер — единственный уверенно и без танцев с бубном работающий вариант.
Если когда-нибудь удастся установить новую монополию, чтоб подавляющее большинство устройств работало под одной-единственной ОС, то все эти VM вновь станут оверхедом.
Свои танцы с бубном там будут, но не больше чем с зоопарком веб-браузеров.
«Зоопарк веб-браузеров» сейчас гораздо менее актуальная проблема. Тем более в контексте js-приложений для телефонов/десктопов.
Веб-приложения решают три проблемы: переносимость, изоляция (sandboxing) и деплой.
1. Да, переносимости можно было бы добиться с любым языком программирования.
2. Для изоляции найдутся какие-то решения. В мобильных ОС она есть, например.
3. Доставка и автоматические обновления — киллер фича веба. Опять же, в мобильных ОС эта задача решена чуть лучше, но этого всё равно недостаточно. С точки зрения простых пользователей процедура установки — бессмысленное действие. Где грань между программами, которые могут встраиваться в «html документы» и которые требуют установки? Для кредитного калькулятора банка, например, нужно делать установку или нет? А зачем тогда нужно делать какие-то специальные манипуляции, прежде чем поиграть в игру или отретушировать фотографию? Зачем эта сложность простым пользователям? Веб образует единое пространство для работы с компьютером. Потому что разница между страничкой из трёх html-тегов и AutoCAD — условна как для пользователя, так и для разработчика.
Неужели не очевидно, что все эти проблемы разбухающего и тормозящего веба вызваны переходным периодом? Как раз WebAssembly на это прямо указывает. Он сокращает разницу между вебом и нативными приложениями. А когда веб вытеснит всё, что мешает превратить веб в нейтив? Заточить процессоры под WebAssembly, а операционные системы переделать в браузер. И слава богу, что во всём сегодняшнем зоопарке технологий появляется абсолютно доминирующая высокоуровневая платформа для приложений. Потому что, если такой платформы не будет, то нужно сохранять совместимость на уровне ниже — придётся тащить x86 до бесконечности.
а операционные системы переделать в браузер.
Уже. Chromebook'и более менее успешно продаются. Хотя с точки зрения пользователя — там именно один браузер и есть (в новых версиях правда добавили поддержку Android).
Насколько я знаю, когда появился Си, многие также сопротивлялись его внедрению и продолжали писать на Ассемблере более эффективный код. Но по мере развития компиляторов производительность сишного кода стала обгонять ассемблерный за счёт сложных для человека оптимизаций.
Безопасность, песочница это конечно здорово но где механизмы лимитирования вычислительных ресурсов, памяти и потребляемой энергии. Реклама на flash-е умудрялось останавливать любую машину.
С нетерпением ждём windows10 на webassembly
На Хабре, кстати, есть ее перевод: WebAssembly — это возвращение апплетов Java и Flash?
Прикладные программы — ОС — Железо
Теперь, по ходу, концепция дополняется новым обязательным элементом:
Прикладные программы — Браузер — ОС — Железо
А поскольку давать браузеру полный доступ к локальным данным никто (надеюсь) не собирается, фактически получаем следующее:
Прикладные программы — Браузер — Чей-то сервис
(ОС и железо тоже где-то сбоку есть, но суть уже не в них т.к. логически мы от них избавились)
Если в изначальной схеме я, владея компьютером, являюсь хозяином всего, что в нём есть (в частности, текстов, которые написал, фоток, которые наснимал и т.п.), то в конечной прекрасной похожей на сказочную мечту схеме я не владею ничем. Ну то есть если поставщик сервиса скажет, что ему всё надоело и вырубит рубильник, почтеннейшей публике останется только хлопать глазами и пить валидол.
Может быть, я устарел, но меня сильно напрягает то, что понятия «технозависимость» и «личная свобода» в значительной мере друг другу противоречат. Личная свобода — это всё-таки такая штука, которую до конца отдавать нельзя.
Поэтому существуют децентрализованные сети. В вашей схеме Чей-то сервис — им может быть и децентрализованный сервис, и машина самого пользователя, в том числе.
Кроме того, если клиент децентрализованной сети не будет хоститься на ноде, а в виде какого-нибудь WebAssembly-приложения скачиваться с чьего-то сервиса, это будет на редкость криво. Трудно объяснить, почему.
Я к тому, что проблема в принципе решаема и некоторые решения уже есть. Их не так много и они не так хороши, как хотелось бы, потому что проблема эта еще не стала массовой.
Я не склонен верить в теории заговора. Скорее всего (вспоминаем бритву Хэнлона), это некоторые особенности нашей человеческой натуры гонят нас на рифы.
Если делается изделие, которым удобнее всего в мире забивать гвозди, будьте спокойны, им обязательно будут забивать гвозди. Кто-то, может быть, будет ещё им ковыряться в зубах, кто-то, может быть, будет дарить девушкам вместо цветов, но это всё будет экзотика в пределах статпогрешности.
Wasm — штука, о которой мир SaaS мечтал, без которой страдал. Использование Wasm для других целей — да, возможно, но в каждом случае целесообразность будет под большим вопросом. А вот SaaSу Wasm — то, что доктор прописал. Расцветёт, родимый, пышным цветом. В том числе и в формах, которые мы сейчас даже вообразить не можем. Технологии и практики социального скотоводства поднимутся на новый прекрасный уровень.
простити, но вьі сильно устарели. Даже новости перестали читать.
сейчас в винде
- программа
- виртуальная машина — дотнет
- ос
- uefi — по сложности как ос
- микрокод процессора — содержит свою ос
- каждая железка — по сути отдельньій компьютер — с процессором, оперативкой и микрокодом.
Я молчу про облака. Где добавляются слои легкой виртуализации (аля докер), тяжелой (аля вагрант) и еще железной (аля квм). Одновременно
можно. но я перечислил свои, которьіе являются черньім ящиком для предьідіщих. И єто те, про которьіе я
- слои которьіе я
как же сложно ночью с телефона
Фреймворки можно добавить. И библиотеки. И всякие подсистемы ОС. И наверно что-то еще, о чем я не подумал. Но я перечислял слои по принципу черного ящика. Когда предыдущий слой — царь, бог и возможность существования.
Более того. Я, как и большинство тут, узкий специалист. Я знаю только про свой слой (и то можно было бы и лучше). А про остальные прочитал в статьях вроде этой. То есть возможно слоев больше, а я про это ни бум-бум.
Просто не нужно забывать, что бороться с нарастающей лавиной сложности методом её, сложности, добавления — не очень перспективно. Ну и, конечно, чётко следить за зависимостями. Если при вырубании инета перестаёт работать текстовый редактор (или считаться бухбаланс, или ещё какая зараза), то в пекло такие решения.
Как можно бороться со сложностью, если не с помощью слоёв абстракций?
1. Сложность с точки зрения пользователя.
2. Внутренняя сложность.
С точки зрения ребёнка айпад — на редкость простой предмет: кнопочку вот здесь нажать, вот в ту картинку ткнуть, и сиди смотри мультики. А сумасшедшая сложность происходящего скрыта за красивым корпусом.
Накручивание уровней абстракции снижают сложность №1 ценой увеличения сложности №2.
Со сложностью №2 есть ряд подлянок:
а). Рискуем захлебнуться собственным дерьмом в плане тормознутости и прожорливости наших изделий. Core i7 с 16ГБ оперативы под Win10 по ощущениям работает так же, как Pentium133 c 16МБ под Win98. Слои абстракции — ни фига не бесплатны. Пока прогресс аппаратуры скрывал от конечного потребителя косячность происходящего, можно было не беспокоиться. Но прогресс аппаратуры по восходящей экспоненте вечно идти не может. В нашем грешном мире вечных восходящих экспонент вообще не бывает.
б). Рискуем захлебнуться собственным дерьмом в плане собственного понимания того, что и как у нас работает. Накручивать уровень абстракции — весело и приятно, но грамотно документировать, и тем более досконально изучать — скучно и противно.
в). Сложность №1 эффективно маскирует сложность №2, и в этом большое коварство. Кажется, что всё просто, что нет проблем чутка подкрутить, начинаешь копать вглубь, а там… матерь божья, что за ацкий мрак?
г). Ещё хохмочка с маскировкой. Допустим, есть вариант Х, и по сложности №1 примерно такой же вариант Y, но у последнего есть приятная фишка, которая не то что бы позарез нужна, но пусть будет. Ничтоже сумняшеся меняем Х на Y, даже не включая голову насчёт того, что сложность №2 у варианта Y в разы выше.
д). Кроме чисто технической сложности есть ещё социальные, экономические, политические и прочие «мягкие» аспекты, которые нам, технарям, вообще не близки.
С айпадика ребёночек может смотреть мультики, которые залиты на сам айпадик, а может смотреть их из Интернета. По сложности №1 один фиг, а по сложности №2 второй вариант на порядок заковыристее. Если при просмотре с айпадика зависимость только от исправности конкретной вот этой железки, то с сетевыми мультиками зависимость от целого мира, включая закон Яровой и крысиную возню копирастов.
Извиняюсь за длинную сказку. Чё-то меня понесло…
Все проблемы, которые вы описали — лишь от того, что слои абстракции недостаточно хорошо сделаны. Как я уже писал здесь же в комментариях — пример качественно сделанной абстракции — язык Си.
а) Выдаваемый код лучше оптимизирован, чем это тот, что напишет человек на Ассемблере.
б) Опускаться на нижний слой не требуется.
в) Гибкость такая же как у Ассемблера.
г-д) эти сложности я понял недоконца.)
Конечно, я немного приврал.) Конечно, идеального слоя абстракции не может существовать. И наслоения будут давать издрежки. Но другого способа всё равно нет. Просто разработка ПО сейчас находится в зачаточном состоянии. Нижние слои абстракции уже неплохие, а наверху — сплошной бардак. И причина этого в сегментировании. На нижних слоях основывается большее количество решений, чем на верхних. На одной процессорной архитектуре работают множество языков программирования. Для каждого языка существует множество фреймворков. Для каждого фреймворка — множество библиотек решающих одну и туже подзадачу. И чем выше по дереву — тем ниже качество. Сегментирование не даёт нормально развиваться ПО. Дерево растёт вширь, а не вверх. Чтобы оно росло вверх, нижние слои должны укрепляться. Но это обычный эволюционный процесс.
Про рост дерева согласен, но не надо питать лишних надежд на рост дерева вверх. Есть ряд концептуальных затыков, про которые народ предпочитает не думать. По сути, у нас всё совсем плохо с теоретической базой нашего ремесла. Есть немножко действительно прочных камешков в фундаменте, но в общем и целом оно в значительной своей части похоже на набор шаманских практик. Постучали в бубен — пошёл дождь, и мы легко себя убеждаем в том, что понимаем, почему пошёл дождь. Не пошёл — не имеем никаких сложностей с выдумыванием задним числом объяснения, почему не пошёл.
Єто не просто не возможно. Єто бьіло невозможно 15-20 лет назад, когда слоев бьіло меньше.
Єто не возможно начиная от биологически — человеческий мозг банально не вьітянет такое число абстракций за раз. Заканчивая юридически — интелу за сорцьі драйверов (тем более железа) проще вас убить и понести наказание.
Но если мечтать. Далеко, светлом, сказочном будущем вместо установки будет компиляция. И облачньй компилятор с ИИ и бигдатой скомпилирует так, что вьікинет все абстракции. И вьікинет куски кода которьім вьі не возпользуетесь. Соптимизирует лично под ваше железо, вьікинув оптимизации остального железа.
Кстати, я забыл добавить.
Сейчас очень хорошо видно, что будет следующим слоем. Это будет легкая виртуализация. Сейчас все операционки (включая мобильные) с той или иной скоростью работают над тем, чтобы каждое приложение положить внутрь виртуалки. Громче всех — опять таже винда. Они говорят о том, что засунут все программы юзера в HyerV. И начали с браузера.
Все основные контрибьютеры линукса (те каждый игрок энтерпрайза) работает над засовывинием всего в докер. Или как стандарт назывантся — ОСИ?
Так что, по видимому, в будущем все программы станут платформонезависимыми. И будут делится на потребителей (платформа веба) и профессионалов (платформа докера). Там и там межпрограмное общение идет через http. А в очень далеком будущем обьеденят виртуалки и браузер.
Радует, что Rust — на передовой линии, в плане поддержки Wasm. Хороший современный системный язык, который все больше становится языком общего назначения. Может быть лучшие дни популярности FireFox уже и прошли, но мне нравится, как Mozilla борется за "место под солнцем", вкладываясь в такие фундаментальные технологии, как Wasm и Rust.
Вроде бы уже в Firefox 64 beta https://www.mozilla.org/en-US/firefox/64.0beta/releasenotes/
Initial releases will be for selected Nvidia GPUs. (Firefox 67, limited roll-out.)
WebAssembly -> больше возможностей по оптимизации –> больше приложений на Electron.
Идея переноса всего и вся в браузер, по мне так не правильна.
Я очень сильно надеюсь, что они смогут добится первых трех ачивок. И ускорить современный веб на порядок.
Но, к сожалению, остальные очивки — путь по захвату мира. Или борьба с JVM за вершину пищевой цепочки. И тут оно может не выстрелить. А ресурсы с первых трех ачивок украдены.
Скорость веба не упирается в скорость JS. Движки JS очень быстрые. Поэтому WebAssembly здесь ничего не изменит.
Только скорость исполнения скриптов зависит не только от скорости языка. В данном случае, всё упирается в DOM. Уж столько раз об этом сказано…
Очень интеречно почитать про эту проблему и пути ее решения. Не подскажите ссылок каких?
Вы правы, это не доказывает, что большая часть времени в современных приложениях уходит на другие вещи. Мне не попадалось статьи, в которой бы исследовалась производительность большого количества сайтов. На отдельном взятом сайте вы можете проверить медлительность DOM с помощью профайлера.
Скорость веба не упирается в скорость JS.
Скорость не упирается в хорошо написанный JS.
Точно так же, хорошо написанный PHP ждет БД (и прочего ИО) дольше, чем работает.
Как хорошо написанный Python перемалывает числа на супер комьютерах, отставая от си на долю процента.
Как хорошо написанная Java не течет памятью и не падает.
Хорошо написанный дотнет — работает на линухах.
Сейчас меня закидают тапками. Потому что я открываю ящик пандоры нескольких холиваров. JS худший из популярных языков. У него напрочь отсутствуют инструменты по оптимизации и ускорению. Процент хорошего кода\программистов — наименьший среди всех популярных языков. Его фреймворки самые жирные и быстрее остальных разбухают (и тормозят) при росте проекта.
И да. Еще раз. На JS и его фреймворках можно писать так, что все будет летать. Проблема в том, что это сложно, дорого и редко. Потому что сейчас мидл JS принципиально не умеет писать быстрый JS. Только синьеры и лиды
И развитие языков, компилируемы в JS напрямую зависит от двух причин. Вторая причина, что строгий язык + перекомпиляция дает более быстрый js, чем проект на чистом JS.
Суммируя.
WebAssembly ->
- ускорение фреймворков (в разы, возможно на порядки).
- перекомпилированный код из другого языка станет еще быстрее.
- возможность дешевле и быстрее научить мидла писать не тормозящий код.
Фреймворк + статический язык + более дешевый спецы быстрогоJS == ускорение веба на порядок.
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
> Процент хорошего кода\программистов — наименьший среди всех популярных языков.
На каком исследовании вы основываетесь?
> На JS и его фреймворках можно писать так, что все будет летать
> ускорение фреймворков (в разы, возможно на порядки)
Так фреймворки сделаны хорошо или нет? Если их можно ускорить в разы, очевидно, что плохо. Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
Хорошие ввопросы. Потребовалось время, чтобы собрать ответы.
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
Перепись тяжелых мест на си. Кстати знаю человека, которое уже делает тоже на JS2asm. Минимальное, но таки управление байткодом. Передача тяжелой работы в отдельные потоки и внешние шелл скрипты.
На каком исследовании вы основываетесь?
Исследовании — никаком. На своем личном опыте. Учитывая, что сайты я делаю 10 лет как. И что вся работа (кроме первого года карьеры) была уровня "проекты более 5 лет разработки". Я уверен, что мой опыт таки имет уровень аккредитованности.
… Если их можно ускорить в разы, очевидно, что плохо.
Их можно ускорить. Проблема в том, что если это делать сейчас. Они внутри и снаружи станут нечитаемой лапшой. А таки фреймворки никому не нужны, даже с большей производительностью.
Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
Очень точное и верное описание моих мыслей.
Похоже, что сейчас это не в приоритете, решили основные проблемы со стандартизацией работы с памятью и нацелены на х64. Так что ускорение будет скорее всего ближе к релизу или после, когда начнется полномасштабная битва браузеров за производительность.
Но как я говорил выше. Конечная цель уже прослеживается. Борьба с языковыми виртуальными машинами — jvm, .net, etc.
Но я отвечу.
Да. jvm/.net/flash/silverlight сложно интегрировать. Как минимум — это очередная система, которая хочет получить доступ ко всем ресурсам ОС. Это как выкинуть всю безопастность из браузера. И начать ее делать с начала.
В то же время asmJS не является полноценно новой ВМ. Очень грубо можно сказать — что это набор мощных оптимизаций существующей JS VM для очень редких случаев использования старого JS. Тем самым, ряд вопросов (от интеграции с существующим сайтов до безопастности) уже решены. И требуют лишь оптимизации и донастройки.
wasm — вполне себе новая WM, со всеми детскими болячками, описанными в статье.
Про флеш забыли? Как каждую неделю дыру находили.
>… со всеми детскими болячками, описанными в статье.
Безопастность в статье идет уже тогда, когда вішли из браузера. Безопасность ноды такая же. То есть нет причин говорить о новой ВМ.
PS
Обратил внимание, что безопастноти (и еще пары картинок) нет на суммирующей картинке
Про флеш забыли? Как каждую неделю дыру находили.
Это всё потому, что его пилили и прикручивали не разработчики браузеров, а сторонняя компания, для которой безопасность не была приоритетом. В любом случае, при чём тут флеш, если мы говорим про куда более зрелую JVM?
Будущее WebAssembly в виде «дерева навыков»