Comments 87
UFO just landed and posted this here
Не хватит. Приложения-которые-надо-скачивать-и-устанавливать-а-потом-обновлять до сих пор не вымерли только потому что веб не мог с ними соревноваться по скорости. Когда WA взлетит — вымрут. И туда им и дорога.
UFO just landed and posted this here
Так оно и будет, когда все приложения станут жить в браузере
UFO just landed and posted this here
Согласен. И тут дело даже не в удобстве, если приложения будут не локально, то можно устроить допустим гос. регулирование какие приложения могут использовать а какие нет. Так себе перспективка.
И я скорее против переноса всего в браузер. Некоторые вещи конечно удобно иметь в браузере, как было с квейк лайв по началу. Или IDE в браузере(они есть, но не все удобные)
И я скорее против переноса всего в браузер. Некоторые вещи конечно удобно иметь в браузере, как было с квейк лайв по началу. Или IDE в браузере(они есть, но не все удобные)
прямо в браузер будем загружаться?
Уже, гуглите ChromeOS
Не только по скорости, еще по памяти. И WA всегда будет там проигрывать и проигрывать сильно. Топовые игры где достигается лишь 50% fps и требуется 32 Гб оперативки? Ну-ну, удачи в продажах веб-версии. Причем поверх всего этого всего всегда будет еще висеть вопрос «а что будет если не будет соединения с интернетом или оно будет стоить 100500$ за Гб». Который для меня, например, как пользователя довольно существенен.
Ну и в целом концепция, как ни крути, все-таки порочна. По сути-то это «jvm + принудительное автообновление» только реализованное в веб-браузере. И нафига тут нужен именно веб-браузер не вполне понятно.
Ну и в целом концепция, как ни крути, все-таки порочна. По сути-то это «jvm + принудительное автообновление» только реализованное в веб-браузере. И нафига тут нужен именно веб-браузер не вполне понятно.
Нужен не браузер. Нужна кроссплатформенность, которую он даёт.
Пока свыше 90% пользовательских устройств работало на винде, на все эти VM смотрели с усмешкой. Но вот когда возникла задача обеспечить рендеринг GUI на множестве принципиально различных устройств и окружений, вот тут без слоя абстракции в виде VM уже никуда. Потому что фрагментация просто охрененно замедляет и удорожает разработку нативного кода.
Например, если я хочу писать код под iOS, но при этом сидеть на Linux, браузер — единственный уверенно и без танцев с бубном работающий вариант.
Если когда-нибудь удастся установить новую монополию, чтоб подавляющее большинство устройств работало под одной-единственной ОС, то все эти VM вновь станут оверхедом.
Пока свыше 90% пользовательских устройств работало на винде, на все эти VM смотрели с усмешкой. Но вот когда возникла задача обеспечить рендеринг GUI на множестве принципиально различных устройств и окружений, вот тут без слоя абстракции в виде VM уже никуда. Потому что фрагментация просто охрененно замедляет и удорожает разработку нативного кода.
Например, если я хочу писать код под iOS, но при этом сидеть на Linux, браузер — единственный уверенно и без танцев с бубном работающий вариант.
Если когда-нибудь удастся установить новую монополию, чтоб подавляющее большинство устройств работало под одной-единственной ОС, то все эти VM вновь станут оверхедом.
Да делали уже эту кроссплатформенность и не один раз. Я потому JVM собственно и упомянул. И он не один — тот же Qt к примеру вроде бы позволяет «писать код под iOS но при этом сидеть на Linux». Свои танцы с бубном там будут, но не больше чем с зоопарком веб-браузеров.
не вымрут, браузер никогда не даст выполнять нативный код.
Как же надоело это зашоренное нытьё.
Веб-приложения решают три проблемы: переносимость, изоляция (sandboxing) и деплой.
1. Да, переносимости можно было бы добиться с любым языком программирования.
2. Для изоляции найдутся какие-то решения. В мобильных ОС она есть, например.
3. Доставка и автоматические обновления — киллер фича веба. Опять же, в мобильных ОС эта задача решена чуть лучше, но этого всё равно недостаточно. С точки зрения простых пользователей процедура установки — бессмысленное действие. Где грань между программами, которые могут встраиваться в «html документы» и которые требуют установки? Для кредитного калькулятора банка, например, нужно делать установку или нет? А зачем тогда нужно делать какие-то специальные манипуляции, прежде чем поиграть в игру или отретушировать фотографию? Зачем эта сложность простым пользователям? Веб образует единое пространство для работы с компьютером. Потому что разница между страничкой из трёх html-тегов и AutoCAD — условна как для пользователя, так и для разработчика.
Неужели не очевидно, что все эти проблемы разбухающего и тормозящего веба вызваны переходным периодом? Как раз WebAssembly на это прямо указывает. Он сокращает разницу между вебом и нативными приложениями. А когда веб вытеснит всё, что мешает превратить веб в нейтив? Заточить процессоры под WebAssembly, а операционные системы переделать в браузер. И слава богу, что во всём сегодняшнем зоопарке технологий появляется абсолютно доминирующая высокоуровневая платформа для приложений. Потому что, если такой платформы не будет, то нужно сохранять совместимость на уровне ниже — придётся тащить x86 до бесконечности.
Веб-приложения решают три проблемы: переносимость, изоляция (sandboxing) и деплой.
1. Да, переносимости можно было бы добиться с любым языком программирования.
2. Для изоляции найдутся какие-то решения. В мобильных ОС она есть, например.
3. Доставка и автоматические обновления — киллер фича веба. Опять же, в мобильных ОС эта задача решена чуть лучше, но этого всё равно недостаточно. С точки зрения простых пользователей процедура установки — бессмысленное действие. Где грань между программами, которые могут встраиваться в «html документы» и которые требуют установки? Для кредитного калькулятора банка, например, нужно делать установку или нет? А зачем тогда нужно делать какие-то специальные манипуляции, прежде чем поиграть в игру или отретушировать фотографию? Зачем эта сложность простым пользователям? Веб образует единое пространство для работы с компьютером. Потому что разница между страничкой из трёх html-тегов и AutoCAD — условна как для пользователя, так и для разработчика.
Неужели не очевидно, что все эти проблемы разбухающего и тормозящего веба вызваны переходным периодом? Как раз WebAssembly на это прямо указывает. Он сокращает разницу между вебом и нативными приложениями. А когда веб вытеснит всё, что мешает превратить веб в нейтив? Заточить процессоры под WebAssembly, а операционные системы переделать в браузер. И слава богу, что во всём сегодняшнем зоопарке технологий появляется абсолютно доминирующая высокоуровневая платформа для приложений. Потому что, если такой платформы не будет, то нужно сохранять совместимость на уровне ниже — придётся тащить x86 до бесконечности.
Ну в целом установка всегда была своего рода оптимизацией канала передачи данных. Пока данные передвигались со скоростью грузовика, груженного 5 дюймовыми дискетами — выгоднее было держать бинарники и ресурсы локально. Потом скорость передачи данных выросла достаточно, чтобы можно было приложению находится на удаленной машине, а клиенту получать описание интерфейса и передавать события. Теперь благодаря усилиям JS разработчиков приложения становятся достаточно тяжелыми, чтобы приходилось уже ощутимое время ждать загрузки, но по сути до сих пор каждый раз когда мы запускаем JS приложение — оно вполне может полностью обновиться. Подождем еще немного — и electron наконец-то будет собран в webassembly и тогда опять придется приложения кэшировать (предустанавливать) на клиенте.
а операционные системы переделать в браузер.
Уже. Chromebook'и более менее успешно продаются. Хотя с точки зрения пользователя — там именно один браузер и есть (в новых версиях правда добавили поддержку Android).
Filippok, извините за мой тон. Не нужно было пускаться в оскорбления. В последнее время перечитал наездов на JavaScript, Electron и прочее.) Мне кажется эта критика очень недальновидной. Да, сегодня кажется, что веб не предназначен для создания приложений. Но в будущем всё поменяется.
Насколько я знаю, когда появился Си, многие также сопротивлялись его внедрению и продолжали писать на Ассемблере более эффективный код. Но по мере развития компиляторов производительность сишного кода стала обгонять ассемблерный за счёт сложных для человека оптимизаций.
Насколько я знаю, когда появился Си, многие также сопротивлялись его внедрению и продолжали писать на Ассемблере более эффективный код. Но по мере развития компиляторов производительность сишного кода стала обгонять ассемблерный за счёт сложных для человека оптимизаций.
Уже были java-aplets, flash теперь webassembly. Очередная попытка отвязаться от windows. Всегда рассказывают как хорошо и замечательно будет, но не очень про то нафига оно вообще.
Безопасность, песочница это конечно здорово но где механизмы лимитирования вычислительных ресурсов, памяти и потребляемой энергии. Реклама на flash-е умудрялось останавливать любую машину.
С нетерпением ждём windows10 на webassembly
Безопасность, песочница это конечно здорово но где механизмы лимитирования вычислительных ресурсов, памяти и потребляемой энергии. Реклама на flash-е умудрялось останавливать любую машину.
С нетерпением ждём windows10 на webassembly
Рекомендую почитать статью Стива Клабника, где в том числе разбирается и ваш вопрос.
На Хабре, кстати, есть ее перевод: WebAssembly — это возвращение апплетов Java и Flash?
Почитал. Выводы в статье не логичные, сравнивают мягкое с тёплым. WA просто больше пиарят. А по факту в таком виде который он есть он нафиг не нужен. Кривая виртуальная машина (грабли с integer overflow), нет платформы всё через жо... js преподносится как плюс. Современное по выкатывает exe-шники по 100мб и больше. Неужели WA сможет уменьшит запросы этих бегемотов.
UFO just landed and posted this here
Когда деревья были большими а жёсткие диски маленькими, нас учили, что в компе у нас как-то так:
Прикладные программы — ОС — Железо
Теперь, по ходу, концепция дополняется новым обязательным элементом:
Прикладные программы — Браузер — ОС — Железо
А поскольку давать браузеру полный доступ к локальным данным никто (надеюсь) не собирается, фактически получаем следующее:
Прикладные программы — Браузер — Чей-то сервис
(ОС и железо тоже где-то сбоку есть, но суть уже не в них т.к. логически мы от них избавились)
Если в изначальной схеме я, владея компьютером, являюсь хозяином всего, что в нём есть (в частности, текстов, которые написал, фоток, которые наснимал и т.п.), то в конечной прекрасной похожей на сказочную мечту схеме я не владею ничем. Ну то есть если поставщик сервиса скажет, что ему всё надоело и вырубит рубильник, почтеннейшей публике останется только хлопать глазами и пить валидол.
Может быть, я устарел, но меня сильно напрягает то, что понятия «технозависимость» и «личная свобода» в значительной мере друг другу противоречат. Личная свобода — это всё-таки такая штука, которую до конца отдавать нельзя.
Прикладные программы — ОС — Железо
Теперь, по ходу, концепция дополняется новым обязательным элементом:
Прикладные программы — Браузер — ОС — Железо
А поскольку давать браузеру полный доступ к локальным данным никто (надеюсь) не собирается, фактически получаем следующее:
Прикладные программы — Браузер — Чей-то сервис
(ОС и железо тоже где-то сбоку есть, но суть уже не в них т.к. логически мы от них избавились)
Если в изначальной схеме я, владея компьютером, являюсь хозяином всего, что в нём есть (в частности, текстов, которые написал, фоток, которые наснимал и т.п.), то в конечной прекрасной похожей на сказочную мечту схеме я не владею ничем. Ну то есть если поставщик сервиса скажет, что ему всё надоело и вырубит рубильник, почтеннейшей публике останется только хлопать глазами и пить валидол.
Может быть, я устарел, но меня сильно напрягает то, что понятия «технозависимость» и «личная свобода» в значительной мере друг другу противоречат. Личная свобода — это всё-таки такая штука, которую до конца отдавать нельзя.
Поэтому существуют децентрализованные сети. В вашей схеме Чей-то сервис — им может быть и децентрализованный сервис, и машина самого пользователя, в том числе.
Пока они не очень хорошо существуют, несмотря на бодрые реляции.
Кроме того, если клиент децентрализованной сети не будет хоститься на ноде, а в виде какого-нибудь WebAssembly-приложения скачиваться с чьего-то сервиса, это будет на редкость криво. Трудно объяснить, почему.
Кроме того, если клиент децентрализованной сети не будет хоститься на ноде, а в виде какого-нибудь WebAssembly-приложения скачиваться с чьего-то сервиса, это будет на редкость криво. Трудно объяснить, почему.
Я к тому, что проблема в принципе решаема и некоторые решения уже есть. Их не так много и они не так хороши, как хотелось бы, потому что проблема эта еще не стала массовой.
Вы правы, но всё же загон публики в браузерные решения — это движение в строго противоположном направлении. В направлении делегирования всей полноты власти поставщику того сервиса, с которого это браузерное решение раздаётся.
Я не склонен верить в теории заговора. Скорее всего (вспоминаем бритву Хэнлона), это некоторые особенности нашей человеческой натуры гонят нас на рифы.
Я не склонен верить в теории заговора. Скорее всего (вспоминаем бритву Хэнлона), это некоторые особенности нашей человеческой натуры гонят нас на рифы.
А разве со свободными операционными системами не та же история? Есть репозитории пакетов, поставщики, которым ты так или иначе доверяешь.
Абсолютно другая история. Если накрывается репозиторий, то я просто не могу стандартным путём получить то, что не удосужился получить ранее. А если программа где-то не у меня, и мои данные где-то тоже не у меня, то собственно у меня остаётся только валидол и понимание собственной ничтожности в этом хрупком мире.
Так есть же кэши и локальные хранилища, разве это не решает проблему?
В модели SaaS кэши и локальные хранилища — необязательные компоненты.
А по вашему Wasm применим только для SaaS? Тогда извините, мы говорим о разном.
Понятно, что не только SaaS. Можно и дедовским способом налабать браузерную прогочку в виде html-файлика, и запускать с жёсткого диска. Сам сто раз так делал. Но надо понимать, что это всё извраты для ценителей. Мэйнстрим использования Wasm — это всё же раздача ПО с сервиса. То есть SaaS (и прочие «aaS») во всей идейной чистоте.
Пока еще не понятно, что именно станет мейнстримом в использовании Wasm. Я не думаю, что старые схемы использования веб-приложений не претерпят изменений.
У нас в инфотехнологиях всё весьма причудливо и непредсказуемо, но не до такой же степени!
Если делается изделие, которым удобнее всего в мире забивать гвозди, будьте спокойны, им обязательно будут забивать гвозди. Кто-то, может быть, будет ещё им ковыряться в зубах, кто-то, может быть, будет дарить девушкам вместо цветов, но это всё будет экзотика в пределах статпогрешности.
Wasm — штука, о которой мир SaaS мечтал, без которой страдал. Использование Wasm для других целей — да, возможно, но в каждом случае целесообразность будет под большим вопросом. А вот SaaSу Wasm — то, что доктор прописал. Расцветёт, родимый, пышным цветом. В том числе и в формах, которые мы сейчас даже вообразить не можем. Технологии и практики социального скотоводства поднимутся на новый прекрасный уровень.
Если делается изделие, которым удобнее всего в мире забивать гвозди, будьте спокойны, им обязательно будут забивать гвозди. Кто-то, может быть, будет ещё им ковыряться в зубах, кто-то, может быть, будет дарить девушкам вместо цветов, но это всё будет экзотика в пределах статпогрешности.
Wasm — штука, о которой мир SaaS мечтал, без которой страдал. Использование Wasm для других целей — да, возможно, но в каждом случае целесообразность будет под большим вопросом. А вот SaaSу Wasm — то, что доктор прописал. Расцветёт, родимый, пышным цветом. В том числе и в формах, которые мы сейчас даже вообразить не можем. Технологии и практики социального скотоводства поднимутся на новый прекрасный уровень.
UFO just landed and posted this here
Можно ещё вспомнить фреймворки поверх фреймворков поверх фреймворков :))
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Да что уж там говорить, накручивание слоёв абстракции — наше любимое дело. И даже для многих из нас то, чем зарабатываем на хлебушек с маслицем.
Просто не нужно забывать, что бороться с нарастающей лавиной сложности методом её, сложности, добавления — не очень перспективно. Ну и, конечно, чётко следить за зависимостями. Если при вырубании инета перестаёт работать текстовый редактор (или считаться бухбаланс, или ещё какая зараза), то в пекло такие решения.
Просто не нужно забывать, что бороться с нарастающей лавиной сложности методом её, сложности, добавления — не очень перспективно. Ну и, конечно, чётко следить за зависимостями. Если при вырубании инета перестаёт работать текстовый редактор (или считаться бухбаланс, или ещё какая зараза), то в пекло такие решения.
>Просто не нужно забывать, что бороться с нарастающей лавиной сложности методом её, сложности, добавления — не очень перспективно.
Как можно бороться со сложностью, если не с помощью слоёв абстракций?
Как можно бороться со сложностью, если не с помощью слоёв абстракций?
У нас понятие «сложность» имеет как минимум две совершенно разные по смыслу трактовки:
1. Сложность с точки зрения пользователя.
2. Внутренняя сложность.
С точки зрения ребёнка айпад — на редкость простой предмет: кнопочку вот здесь нажать, вот в ту картинку ткнуть, и сиди смотри мультики. А сумасшедшая сложность происходящего скрыта за красивым корпусом.
Накручивание уровней абстракции снижают сложность №1 ценой увеличения сложности №2.
Со сложностью №2 есть ряд подлянок:
а). Рискуем захлебнуться собственным дерьмом в плане тормознутости и прожорливости наших изделий. Core i7 с 16ГБ оперативы под Win10 по ощущениям работает так же, как Pentium133 c 16МБ под Win98. Слои абстракции — ни фига не бесплатны. Пока прогресс аппаратуры скрывал от конечного потребителя косячность происходящего, можно было не беспокоиться. Но прогресс аппаратуры по восходящей экспоненте вечно идти не может. В нашем грешном мире вечных восходящих экспонент вообще не бывает.
б). Рискуем захлебнуться собственным дерьмом в плане собственного понимания того, что и как у нас работает. Накручивать уровень абстракции — весело и приятно, но грамотно документировать, и тем более досконально изучать — скучно и противно.
в). Сложность №1 эффективно маскирует сложность №2, и в этом большое коварство. Кажется, что всё просто, что нет проблем чутка подкрутить, начинаешь копать вглубь, а там… матерь божья, что за ацкий мрак?
г). Ещё хохмочка с маскировкой. Допустим, есть вариант Х, и по сложности №1 примерно такой же вариант Y, но у последнего есть приятная фишка, которая не то что бы позарез нужна, но пусть будет. Ничтоже сумняшеся меняем Х на Y, даже не включая голову насчёт того, что сложность №2 у варианта Y в разы выше.
д). Кроме чисто технической сложности есть ещё социальные, экономические, политические и прочие «мягкие» аспекты, которые нам, технарям, вообще не близки.
С айпадика ребёночек может смотреть мультики, которые залиты на сам айпадик, а может смотреть их из Интернета. По сложности №1 один фиг, а по сложности №2 второй вариант на порядок заковыристее. Если при просмотре с айпадика зависимость только от исправности конкретной вот этой железки, то с сетевыми мультиками зависимость от целого мира, включая закон Яровой и крысиную возню копирастов.
Извиняюсь за длинную сказку. Чё-то меня понесло…
1. Сложность с точки зрения пользователя.
2. Внутренняя сложность.
С точки зрения ребёнка айпад — на редкость простой предмет: кнопочку вот здесь нажать, вот в ту картинку ткнуть, и сиди смотри мультики. А сумасшедшая сложность происходящего скрыта за красивым корпусом.
Накручивание уровней абстракции снижают сложность №1 ценой увеличения сложности №2.
Со сложностью №2 есть ряд подлянок:
а). Рискуем захлебнуться собственным дерьмом в плане тормознутости и прожорливости наших изделий. Core i7 с 16ГБ оперативы под Win10 по ощущениям работает так же, как Pentium133 c 16МБ под Win98. Слои абстракции — ни фига не бесплатны. Пока прогресс аппаратуры скрывал от конечного потребителя косячность происходящего, можно было не беспокоиться. Но прогресс аппаратуры по восходящей экспоненте вечно идти не может. В нашем грешном мире вечных восходящих экспонент вообще не бывает.
б). Рискуем захлебнуться собственным дерьмом в плане собственного понимания того, что и как у нас работает. Накручивать уровень абстракции — весело и приятно, но грамотно документировать, и тем более досконально изучать — скучно и противно.
в). Сложность №1 эффективно маскирует сложность №2, и в этом большое коварство. Кажется, что всё просто, что нет проблем чутка подкрутить, начинаешь копать вглубь, а там… матерь божья, что за ацкий мрак?
г). Ещё хохмочка с маскировкой. Допустим, есть вариант Х, и по сложности №1 примерно такой же вариант Y, но у последнего есть приятная фишка, которая не то что бы позарез нужна, но пусть будет. Ничтоже сумняшеся меняем Х на Y, даже не включая голову насчёт того, что сложность №2 у варианта Y в разы выше.
д). Кроме чисто технической сложности есть ещё социальные, экономические, политические и прочие «мягкие» аспекты, которые нам, технарям, вообще не близки.
С айпадика ребёночек может смотреть мультики, которые залиты на сам айпадик, а может смотреть их из Интернета. По сложности №1 один фиг, а по сложности №2 второй вариант на порядок заковыристее. Если при просмотре с айпадика зависимость только от исправности конкретной вот этой железки, то с сетевыми мультиками зависимость от целого мира, включая закон Яровой и крысиную возню копирастов.
Извиняюсь за длинную сказку. Чё-то меня понесло…
Чтобы легче было различать назову первую сложность «качеством интерфейса» (а можно и читать как «качество программы», потому что интерфейс — и есть суть программы), а вторую — «сложность реализации». Очевидно, что наша задача — повышать качество интерфейса. И чтобы это делать, приходится бороться со сложностью реализации. И единственный способ это сделать — слой абстракции. Т.е. опираться на другой интерфейс, скрывающий другую сложность реализации.
Все проблемы, которые вы описали — лишь от того, что слои абстракции недостаточно хорошо сделаны. Как я уже писал здесь же в комментариях — пример качественно сделанной абстракции — язык Си.
а) Выдаваемый код лучше оптимизирован, чем это тот, что напишет человек на Ассемблере.
б) Опускаться на нижний слой не требуется.
в) Гибкость такая же как у Ассемблера.
г-д) эти сложности я понял недоконца.)
Конечно, я немного приврал.) Конечно, идеального слоя абстракции не может существовать. И наслоения будут давать издрежки. Но другого способа всё равно нет. Просто разработка ПО сейчас находится в зачаточном состоянии. Нижние слои абстракции уже неплохие, а наверху — сплошной бардак. И причина этого в сегментировании. На нижних слоях основывается большее количество решений, чем на верхних. На одной процессорной архитектуре работают множество языков программирования. Для каждого языка существует множество фреймворков. Для каждого фреймворка — множество библиотек решающих одну и туже подзадачу. И чем выше по дереву — тем ниже качество. Сегментирование не даёт нормально развиваться ПО. Дерево растёт вширь, а не вверх. Чтобы оно росло вверх, нижние слои должны укрепляться. Но это обычный эволюционный процесс.
Все проблемы, которые вы описали — лишь от того, что слои абстракции недостаточно хорошо сделаны. Как я уже писал здесь же в комментариях — пример качественно сделанной абстракции — язык Си.
а) Выдаваемый код лучше оптимизирован, чем это тот, что напишет человек на Ассемблере.
б) Опускаться на нижний слой не требуется.
в) Гибкость такая же как у Ассемблера.
г-д) эти сложности я понял недоконца.)
Конечно, я немного приврал.) Конечно, идеального слоя абстракции не может существовать. И наслоения будут давать издрежки. Но другого способа всё равно нет. Просто разработка ПО сейчас находится в зачаточном состоянии. Нижние слои абстракции уже неплохие, а наверху — сплошной бардак. И причина этого в сегментировании. На нижних слоях основывается большее количество решений, чем на верхних. На одной процессорной архитектуре работают множество языков программирования. Для каждого языка существует множество фреймворков. Для каждого фреймворка — множество библиотек решающих одну и туже подзадачу. И чем выше по дереву — тем ниже качество. Сегментирование не даёт нормально развиваться ПО. Дерево растёт вширь, а не вверх. Чтобы оно росло вверх, нижние слои должны укрепляться. Но это обычный эволюционный процесс.
В Советском Союзе тоже думали, что нужно просто лучше работать, и тогда будет всё хорошо. Но про системные проблемы нельзя так рассуждать. Если система имеет тенденцию идти под откос, хоть уработайся. Повысят соцобязательства, а за ударный труд никто спасибо не скажет (скорее наоборот). Можно вылизать код на С, до предела всё оптимизировав, но кому это нужно, если сейчас модно на JS поверх какого-нибудь прекрасного фреймворка? Ну и что с того, что только для того, чтобы загрузиться, оно отожрёт метров 200 оперативы, и потом будет тормозить в самых неожиданных местах?
Про рост дерева согласен, но не надо питать лишних надежд на рост дерева вверх. Есть ряд концептуальных затыков, про которые народ предпочитает не думать. По сути, у нас всё совсем плохо с теоретической базой нашего ремесла. Есть немножко действительно прочных камешков в фундаменте, но в общем и целом оно в значительной своей части похоже на набор шаманских практик. Постучали в бубен — пошёл дождь, и мы легко себя убеждаем в том, что понимаем, почему пошёл дождь. Не пошёл — не имеем никаких сложностей с выдумыванием задним числом объяснения, почему не пошёл.
Про рост дерева согласен, но не надо питать лишних надежд на рост дерева вверх. Есть ряд концептуальных затыков, про которые народ предпочитает не думать. По сути, у нас всё совсем плохо с теоретической базой нашего ремесла. Есть немножко действительно прочных камешков в фундаменте, но в общем и целом оно в значительной своей части похоже на набор шаманских практик. Постучали в бубен — пошёл дождь, и мы легко себя убеждаем в том, что понимаем, почему пошёл дождь. Не пошёл — не имеем никаких сложностей с выдумыванием задним числом объяснения, почему не пошёл.
UFO just landed and posted this here
UFO just landed and posted this here
Какая-то у вас слишком однобокая схема. Вроде никто не собирается совсем исключать локальные хранилища и другие программы. Просто браузер потихоньку становится основной платформой для доставки медиа и контента.
Радует, что Rust — на передовой линии, в плане поддержки Wasm. Хороший современный системный язык, который все больше становится языком общего назначения. Может быть лучшие дни популярности FireFox уже и прошли, но мне нравится, как Mozilla борется за "место под солнцем", вкладываясь в такие фундаментальные технологии, как Wasm и Rust.
Лису рано списывать. Посмотрим что будет, когда WebRender появится в релизе. Обещают буквально в ближайших версиях.
WebRender активируют В Firefox 67, для некоторых пользователей с Nvidia.
Вроде бы уже в Firefox 64 beta https://www.mozilla.org/en-US/firefox/64.0beta/releasenotes/
Да, но у них в Roadmap: wiki.mozilla.org/Firefox/Roadmap
Initial releases will be for selected Nvidia GPUs. (Firefox 67, limited roll-out.)
Ну WebRender — это просто композитор (собирает кучу изображений из разных частей кода в одно большое и выводит на экран). Не стоит ожидать от него слишком многого.
Надеюсь развитие webassembly похоронит Electron-приложения
За Мозиллу нарадоваться не могу. Пойду задоначу.
Ну десктоп приложения никуда не денутся, на сегодняшний день они доминируют например в мобильных технологиях.
Идея переноса всего и вся в браузер, по мне так не правильна.
Идея переноса всего и вся в браузер, по мне так не правильна.
UFO just landed and posted this here
> И ускорить современный веб на порядок.
Скорость веба не упирается в скорость JS. Движки JS очень быстрые. Поэтому WebAssembly здесь ничего не изменит.
Скорость веба не упирается в скорость JS. Движки JS очень быстрые. Поэтому WebAssembly здесь ничего не изменит.
UFO just landed and posted this here
> всё упирается именно в скорость исполнения скриптов
Только скорость исполнения скриптов зависит не только от скорости языка. В данном случае, всё упирается в DOM. Уж столько раз об этом сказано…
Только скорость исполнения скриптов зависит не только от скорости языка. В данном случае, всё упирается в DOM. Уж столько раз об этом сказано…
UFO just landed and posted this here
Я даже не знаю, какие ссылки искать. В каждой статье про JS-фреймворки будет написано про оптимизацию работы с DOM. Это и есть путь решения. А бенчмарки показывают, что JS — один из самых быстрых языков.
Наткнулся на подходящую статью, пока искал бенчмарки: habr.com/post/281879
UFO just landed and posted this here
UFO just landed and posted this here
Это бенчмарки, показывающие, что JS и так уже очень быстрый. Замена его на другие языки повлияет только на узком классе задач.
Вы правы, это не доказывает, что большая часть времени в современных приложениях уходит на другие вещи. Мне не попадалось статьи, в которой бы исследовалась производительность большого количества сайтов. На отдельном взятом сайте вы можете проверить медлительность DOM с помощью профайлера.
Вы правы, это не доказывает, что большая часть времени в современных приложениях уходит на другие вещи. Мне не попадалось статьи, в которой бы исследовалась производительность большого количества сайтов. На отдельном взятом сайте вы можете проверить медлительность DOM с помощью профайлера.
UFO just landed and posted this here
> У него напрочь отсутствуют инструменты по оптимизации и ускорению.
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
> Процент хорошего кода\программистов — наименьший среди всех популярных языков.
На каком исследовании вы основываетесь?
> На JS и его фреймворках можно писать так, что все будет летать
> ускорение фреймворков (в разы, возможно на порядки)
Так фреймворки сделаны хорошо или нет? Если их можно ускорить в разы, очевидно, что плохо. Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
> Процент хорошего кода\программистов — наименьший среди всех популярных языков.
На каком исследовании вы основываетесь?
> На JS и его фреймворках можно писать так, что все будет летать
> ускорение фреймворков (в разы, возможно на порядки)
Так фреймворки сделаны хорошо или нет? Если их можно ускорить в разы, очевидно, что плохо. Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
А никто не знает, в плане доступа к памяти еще что-то делается в webassembly? Кажется это самое критичное место в плане производительности
А чем JVM не угодил?
UFO just landed and posted this here
Можно подумать JVM/.NET сложно интегрировать. Всяко лучше было бы, чем примитивный велосипед, который почти ничего не умеет и который надо всем пилить с нуля.
UFO just landed and posted this here
Зачем выкидывать безопасность? Она работает вне песочницы. И ей по большому счёту по барабану какой байткод крутится внутри. Хоть брейнфак. Как минимум jvm уже десятилетями используется в качестве изолированной песочницы.
wasm — вполне себе новая WM, со всеми детскими болячками, описанными в статье.
wasm — вполне себе новая WM, со всеми детскими болячками, описанными в статье.
Sign up to leave a comment.
Будущее WebAssembly в виде «дерева навыков»