Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 192
Главный спонсор данного проекта почему-то не указан. Догадываюсь что это АНБ.
Круто! Я ждвадцать лет ждал этого стандарта!
Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)
Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011), а поддержка стандарта хорошо если будет в IE12. Экстраполируя, необходимости в библиотеке не будет только лет так через 10 минимум.
Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)
что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly
Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011), а поддержка стандарта хорошо если будет в IE12. Экстраполируя, необходимости в библиотеке не будет только лет так через 10 минимум.
Как только Микрософт всех пересадит на десятую винду с годовой подпиской и принудительным обновлением, динозавров со старыми браузерами станет значительно меньше, а следовательно и внедрять стандарты в широкие массы станет легче и быстрее.
Вот вот, еще бы стандарты для верстки ввели, причем жесткие, а не как чейчас.
Жесткие стандарты и сейчас есть. Многие знакомые верстальщики выработали собственные жесткие гайдлайны и следуют им. А тот факт, что 80% веб-страниц сделано с нарушениями любых стандартов — это, по-моему, как раз то, что позволило Web вырасти так быстро и вовлечь огромное количество людей и бизнесов в индустрию.
Низкий порог входа — это драйвер роста, как бы нам с вами не хотелось, чтобы все писали совершенный код по Макконнеллу
Низкий порог входа — это драйвер роста, как бы нам с вами не хотелось, чтобы все писали совершенный код по Макконнеллу
>Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011)
В куче проектов проще реально забить. Я давно сайты даже в IE не тестирую т.к. на моих площадках его доля составляет около 6%. Гораздо полезнее время потратить, чтобы доступность контента для людей с плохим зрением обеспечить, чем тратить кучу времени на поддержку малопопулярных браузеров.
В куче проектов проще реально забить. Я давно сайты даже в IE не тестирую т.к. на моих площадках его доля составляет около 6%. Гораздо полезнее время потратить, чтобы доступность контента для людей с плохим зрением обеспечить, чем тратить кучу времени на поддержку малопопулярных браузеров.
а поддержка стандарта хорошо если будет в IE12
IE 12 не будет, вместо него сделали Edge
Интересно, какой язык лет через 10 станет стандартом де-факто для фронта.Дак по-моему абсолютно очевидно, какой. Такой же, какой и сейчас.
> Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)
Наверняка тот, который будет самым популярным на бекэнде, не буду тыкать пальцем…
*(благодаря подобной же логике вырос node.js)
Наверняка тот, который будет самым популярным на бекэнде, не буду тыкать пальцем…
*(благодаря подобной же логике вырос node.js)
Аллилуя! Аллилуя!
Наконец то можно будет выгнать всех js-кодеров и начать писать SPA на хаскеле! :)
Наконец то можно будет выгнать всех js-кодеров и начать писать SPA на хаскеле! :)
Новый бинарный формат для Web
От такого заголовка ожидал анонса нового: флеша, джава-апплетов, джава-эф-икс, сильверлайта…
Я очень надеюсь, что до написания «движка ECMAScript -like на WebAssembly» дело не дойдёт :D
P.S. уже предвижу срачи на форумах верстальщиков через 5 лет: «У меня Boost 1.67 под Chrome не компилится, что делать?»
P.S. уже предвижу срачи на форумах верстальщиков через 5 лет: «У меня Boost 1.67 под Chrome не компилится, что делать?»
Это ещё не самые смелые предсказания!
www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
D? Тоже хороший язык.
Может ли он заменить формат SWF от Adobe? Ну то есть, его можно попытаться использовать как контейнер для всего всего всего (вместо тысяч картинок, JS и CSS файлов), что позволит добиться такой же виральности, как и у Flash.
Переезжайте уже в 2015: Packaging on the Web.
То есть больше никаких исходников по Ctrl-U?
И каждый сайт теперь — черный ящик?
И каждый сайт теперь — черный ящик?
Как сказать. Раз предоставят полифил для трансляции в JS, значит возможность понять в общих чертах что именно происходит в коде вполне возможно.
На самом деле — это путь к более мощным клиентским скриптам, в которые можно встраивать сокрытую логику, которая раньше была возможна только на сервере
Это так.
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
Не драматизируйте. Нормальный код на asm даже понятнее, чем код на asm.js, ибо используются нормальные низкоуровневые инструкции с запоминаемыми мнемониками, а не хаки, которые их имитируют. Главное не бояться, и бинарный код — вовсе не преграда. Да и наверняка у этого WebAssembly байт-код будет значительно проще, чем x86, всё же промежуточное представление.
а вы сейчас как детектируете подозрительные скрипты? — вручную просматриваете исходники?
Код в браузере будет работать быстро и при должном умении и старании не будет жрать столько, сколько сейчас жрет джаваскрипт. В наш век вебгл это особенно важный момент. К этому у разработчиков добавится возможность писать на языках, которые будут хорошо подходить к тем задачам, которые они будут решать и не городить костыли в виде компиляции в джаваскрипт. Я какое-то время назад писал свою фантазию о таком проекте, многим эта идея не понравилась (возможно, не стоило писать её в треде про джаваскрипт), а на мой возгляд, это одно из самых разумных начинаний для улучшения жизни как пользователей, так и разработчиков.
а чем принципиально отличается «ковыряться в js» от «ковыряться в asm»?
Ну во первых — есть отличные мониторы того, что делают скрипты. Какую информацию откуда и куда отправляют.
Единственное — круто было бы — возможность выборочно давать доступ по мере возникновения потребности, например, как сейчас реализовано. Жмёшь на загрузить файл — появляется — вы хотите дать доступ к каталогу (не ко всем, а да, к отдельному каталогу)?
Единственное — круто было бы — возможность выборочно давать доступ по мере возникновения потребности, например, как сейчас реализовано. Жмёшь на загрузить файл — появляется — вы хотите дать доступ к каталогу (не ко всем, а да, к отдельному каталогу)?
Будет можно переводить в человекочитаемый формат, как я понял. На гитхабе в целях:
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
Вы ещё скажите, что каждый екзешник чёрный ящик, а дизассемблеров в природе нет :)
С другой стороны, возможно, обфускация браузерного кода примет новые формы.
С другой стороны, возможно, обфускация браузерного кода примет новые формы.
Не надо пугаться
github.com/WebAssembly/design/blob/master/FAQ.md
Will WebAssembly support View Source on the Web?
Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.
github.com/WebAssembly/design/blob/master/FAQ.md
Я уже и не думал, что это когда-нибудь произойдет, наконец таки их осенило.
Думаю, все только выиграют от того что клиентская разработка станет не привязанной жестко к JS, хотя деплой клиентской логики при таком подходе существенно усложнится
И в чем это будет сложнее чем то, как это работает сейчас?
Компиляция
Я не знаток фронтенд-разработки, но вангую, что пайплайн из одного шага (компиляция) проще и короче пайплайна из полудесятка (трансляция, проверка, конкатенация, минификация и прочие -иции).
ну чисто практическая ситуация — кусок кода, который написан для обработки данных, которых пока нет на страничке, но они могут быть туда в какой то момент добавлены аджаксом. Компиляция подразумевает не только преобразование кода, но и установки ссылок на обьекты поздействия, в случае браузера это DOM обекты. Без привязки к структуре DOM вся эта компиляция — пшик, основное время как раз и занимает ползанье по модели, а не интерпретация команд скрипта. Получится очередная надстройка над html которая внутри себя все равно все приведет в реальный для браузера формат.
Ну вы же в курсе, что вроде как в современном вебе вообще принято делать сборку проекта, минификацию файлов, и хорошо бы еще инвалидацию кеша предусмотреть. Так что компиляция — практически и не проблема вовсе.
Не могли бы вы подсказать, как это повлияет на судьбы JS разработчиков, по вашему мнению?
Никак. Абсолютно.
Кого не выбросит из профессии необходимость вместо коллбеков использовать промисы и затем вместо промисов использовать йилды да эвэйты (то есть буквально два раза стать с ног на голову после выхода ES5 и затем ES6), того добьёт WebAssembly.
Немалая часть народа, программирующего сегодня фронтенд, к моменту реального запуска уже будет на пенсии.
Я так понимаю что разница между JS и WebAssembly лишь в скорости парсинга. Но не понимаю чего все так ликуют ведь по сути не так много изменится. т.е. будет аля TypeScript на С# с набором абстракций типа DOM'а который как и обычный нужно компилить для браузера и в конечно счете получить тот же JS просто в более компактном виде.
Если где то ошибся ткните носом. =)
Если где то ошибся ткните носом. =)
Ну так и хорошо, что хоть кто-то денег на клиентских(frontend) разработках сможет поднять без риска мгновенного форка
для этого +- подходит только nacl, тут смысл в том что на клиент будет приходить уже распарсенное AST дерево, то есть тот же код, только без комментариев и уже с проставленными аннотациями о типах как в asm.js
и сами авторы это прямо заявляют, что код можно будет свернуть обратно в некий код для чтения человеком, пруф:
github.com/WebAssembly/design/blob/master/HighLevelGoals.md
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
и сами авторы это прямо заявляют, что код можно будет свернуть обратно в некий код для чтения человеком, пруф:
github.com/WebAssembly/design/blob/master/HighLevelGoals.md
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
Это лично мое мнение, но выбор первичных языков огорчает. И честно говоря непонятен, с/с++/с# мало распространены среди веб разработчиков, взялиб JVM языки. Ну хоть гугл пропихнул go, уже кое что. А еще печалит что стек разработки веб приложения, усложняется огромными темпами… Зп веб девов бы так росли.
6 минусов и ни одного комментария… то есть — несогласны, но возразить не чем?!
Здесь уже несколько раз отвечали на подобные вашим комментарии. Повторяться — удовольствие из малоприятных. C/C++ — это первый обязательный язык для поддержки для любого низкоуровневого байт-кода или машинного кода. Потому что на этом языке написано огромное количество библиотек для всех возможных задач. Наверняка без C++ не обошлось и при разработке Java, и т.д. Это системный язык, и он построен так, чтобы генерировать эффективный машинный код, а не для того, чтобы на нём можно было писать не думая и не понимая как это вообще работает. Вообще если технология взлетит, то под неё быстро напишут кучу разных компиляторов под все популярные языки, для которых вообще возможно сгенерировать эффективный машинный код. В других случаях под WebAssembly будут собирать виртуальные машины, которые будут выполнять байт-код нужного вам языка. В общем, они всё правильно делают. Главное только чтобы этот WebAssembly действительно оказался близким по производительности к нативному коду :)
Для вас ничего не изменится. Больше возможностей — лучше. Но вас никто не заставляет изучать их все. Вы как кодили на JavaScript, так и можете продолжать. Под WebAssembly будут программировать другие специалисты, и это актуально только для проектов, где нужна большая производительность на клиенте. Даже если вы захотите использовать это для того, чтобы сжать и оптимизировать картинку/видео на клиенте до отправки на сервер (без флэша) — наверняка для обычных кодеров под веб будут сделаны готовые библиотеки для удобного использования из JavaScript.
Для вас ничего не изменится. Больше возможностей — лучше. Но вас никто не заставляет изучать их все. Вы как кодили на JavaScript, так и можете продолжать. Под WebAssembly будут программировать другие специалисты, и это актуально только для проектов, где нужна большая производительность на клиенте. Даже если вы захотите использовать это для того, чтобы сжать и оптимизировать картинку/видео на клиенте до отправки на сервер (без флэша) — наверняка для обычных кодеров под веб будут сделаны готовые библиотеки для удобного использования из JavaScript.
Спасибо за ответ, вы дали повод для размышлений. На что и надеялся сделав комментарий, а не молча минусы ловить.
Я не пишу на js, умею, но не хочу. Так вот, как раз в этой ситуации, писать на с/с++ придётся мне, так как не ограничиваю себя познаниями лишь веб яп. И с этим фактом высказал личное мнение, что мне не нравится выбор языков. И привёл свои мысли на тему популярности с/с++ среди веб разработчиков, ведь технологий много создавалось, вопрос в том будут ли использовать…
К тому же, цель проекта получить бинарник для браузера и для этих целей с/с++ не обязателен.
П.С. Таки был прав в догадках, сишники минусовали.
Я не пишу на js, умею, но не хочу. Так вот, как раз в этой ситуации, писать на с/с++ придётся мне, так как не ограничиваю себя познаниями лишь веб яп. И с этим фактом высказал личное мнение, что мне не нравится выбор языков. И привёл свои мысли на тему популярности с/с++ среди веб разработчиков, ведь технологий много создавалось, вопрос в том будут ли использовать…
К тому же, цель проекта получить бинарник для браузера и для этих целей с/с++ не обязателен.
П.С. Таки был прав в догадках, сишники минусовали.
Ну я не сишник, я вообще PHP-программист. Вам не придётся писать на C/C++, если вы не хотите. Подождёте компилятор языка, который вам нужен, и будете писать на нём. Всё равно после появления стандарта до момента, когда это распространится и можно будет использовать в продакшне пройдёт не один год. За это время все востребованные языки получат свои компиляторы, не переживайте.
Цель получить быстрый код. Код на C++ будет быстрее кода на Java, потому что C++ ближе к железу. Эта технология создаётся для тех вещей, которые при помощи JS решались плохо, костыльно (через asm.js), медленно. Соответственно и язык выбран — самый популярный из подобных эффективных и близких к машинному коду языков.
А C++ хотя бы поверхностно знать и уметь писать на нём полезно для общего развития. Для понимания как это всё работает, чтобы делать меньше глупостей.
Цель получить быстрый код. Код на C++ будет быстрее кода на Java, потому что C++ ближе к железу. Эта технология создаётся для тех вещей, которые при помощи JS решались плохо, костыльно (через asm.js), медленно. Соответственно и язык выбран — самый популярный из подобных эффективных и близких к машинному коду языков.
А C++ хотя бы поверхностно знать и уметь писать на нём полезно для общего развития. Для понимания как это всё работает, чтобы делать меньше глупостей.
Я же написал, что меня огорчает «первичный выбор»… А go меня вполне устраивает. Вы так защищаете си будто я написал что это плохой или никчёмный язык, но ведь, суть моего поста в другом.
И да, я писал на сях, не много. Но мне хватило этого для понимания, что я этим пользоваться не хочу. Благо есть компилируемые языки способные заменить си почти в любой ситуации.
И да, я писал на сях, не много. Но мне хватило этого для понимания, что я этим пользоваться не хочу. Благо есть компилируемые языки способные заменить си почти в любой ситуации.
Я вам объясняю, почему в данном случае C/C++ — наиболее логичный выбор для «первичного выбора». Вас устраивает Go, кого-то устраивает Rust, а промышленный стандарт — C++, и с этим нужно считаться.
Еслиб веб относился к промышленным технологиям, у меня вопросов не возникло, но ведь это не так. Я понимаю, что си прекрасно подходит для этой задачи, но у меня сомнения, что он подходит для сферы веб разработки.
И кстати ваши мысли, что если я не захочу писать на сях, мол и не придётся… Вы не правы, первым выйдет си и наиболшее количество библиотек выйдет на сях и мне таки придётся как минимум ковырятся в этом.
И кстати ваши мысли, что если я не захочу писать на сях, мол и не придётся… Вы не правы, первым выйдет си и наиболшее количество библиотек выйдет на сях и мне таки придётся как минимум ковырятся в этом.
Вы сможете обращаться к модулям написанным на C/C++ из обычного JavaScript.
Ваш же вариант, первоочередная реализация JVM, попахивает оверинженерингом и большим оверхидом: по сути каждая бинарная сборка WebAssembly должна будет содержать полный код JVM на байт-коде WebAssembly, в которой будет крутится байт-код Java или Scala
Ваш же вариант, первоочередная реализация JVM, попахивает оверинженерингом и большим оверхидом: по сути каждая бинарная сборка WebAssembly должна будет содержать полный код JVM на байт-коде WebAssembly, в которой будет крутится байт-код Java или Scala
К годалке не ходи что код jvm ни кто включать не будет, есть всякие jaccelerator и прочие. Собственно если они надумают включить java в список поддерживаемых языков им и так придется с этим что то делать.
Вы серьёзно думаете, что я не понимаю как это будет работать? То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.
Предвидя ваше возрожение по поводо либ php — да я туда лажу, приходится.
Вы серьёзно думаете, что я не понимаю как это будет работать? То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.
Предвидя ваше возрожение по поводо либ php — да я туда лажу, приходится.
Если включать в список поддерживаемых JVM языки, в рамках объявленной парадигмы, то есть три пути:
1. игнорировать существующие компиляторы для них и писать компиляторы Java, Scala и т. д. в wasm
2. писать компиляторы байт-кода jvm в wasm или поддерживаемый уже язык (тот же С++)
3. написать jvm на wasm и включать её в загружаемые с сайтов бинарники.
Первый вариант совсем маловероятен. Второй в принципе возможен, но видится много подводных камней, особенно если компилять не напрямую в wasm. Третий будет оверхидный по ресурсам, но, имхо, обеспечит лучшую переносимость.
Так код либы будет представлен в виде wasm-кода, на каком языке она была написана изначально мало будет иметь значения, если только нет желания запушить свои изменения в её исходники или поддерживать свой форк её.
1. игнорировать существующие компиляторы для них и писать компиляторы Java, Scala и т. д. в wasm
2. писать компиляторы байт-кода jvm в wasm или поддерживаемый уже язык (тот же С++)
3. написать jvm на wasm и включать её в загружаемые с сайтов бинарники.
Первый вариант совсем маловероятен. Второй в принципе возможен, но видится много подводных камней, особенно если компилять не напрямую в wasm. Третий будет оверхидный по ресурсам, но, имхо, обеспечит лучшую переносимость.
То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.
Так код либы будет представлен в виде wasm-кода, на каком языке она была написана изначально мало будет иметь значения, если только нет желания запушить свои изменения в её исходники или поддерживать свой форк её.
Второй вариант: http://habrahabr.ru/post/240999/
Интересная смесь подходов 1 и 2: TASTY. Это промежуточное представление для компилятора скалы. А раз уж scalac умеет компилировать и java классы, то, полагаю, это представление будет доступно и для java.
Это фактически голые AST, после всех преобразований. Таким образом компилятор уже сделал всю сложную работу, но у нас все еще не потеряна никакая информация и мы все еще имеем высокоуровневое представление. В частности одна из целей этого формата в scalac — последующая компиляция в JavaScript.
От подхода 1 здесь наличие всей высокоуровневой информации, от подхода 2 — выполнение существующим компилятором всей основной работы.
Это фактически голые AST, после всех преобразований. Таким образом компилятор уже сделал всю сложную работу, но у нас все еще не потеряна никакая информация и мы все еще имеем высокоуровневое представление. В частности одна из целей этого формата в scalac — последующая компиляция в JavaScript.
От подхода 1 здесь наличие всей высокоуровневой информации, от подхода 2 — выполнение существующим компилятором всей основной работы.
Для Javascript может наступить новая эра и это может оказаться совсем ни шуткой.
ЗЫ.
По всей видимости Javascript превзойдет по сфере применения все остальные языки и будет их вытеснять из традиционных ниш.
ЗЫ.
По всей видимости Javascript превзойдет по сфере применения все остальные языки и будет их вытеснять из традиционных ниш.
Разве не уже пытается? NodeJS(iojs) и т.п. под сервер, NW.js под винду, Apache Cordova под мобилки. Увы WebAssembly лишь ускоряет парсинг и уменьшает вес.
Да, вы абсолютно правы, но WebAssembly даст гораздо больше.
WebAssembly позволит создавать на javascript нативные приложения для различных платформ.
Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.
WebAssembly позволит создавать на javascript нативные приложения для различных платформ.
Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.
WebAssembly в любом случае должен парсится движком (например V8 аля NodeJS(iojs)).
т.е. по факту не даст гораздо больше.
т.е. по факту не даст гораздо больше.
Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.
Предполагаю, что там есть уже ВМ(VM) а скомпилированный код(b-code) представляет из себя код для это ВМ.
PS.
Скорее всего, вопрос времени когда нам покажут спецификацию ВМ.
Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.
Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.
Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.
ой не факт )
Flash тоже планировали повсеместно заменить на HTML5
Хм, интересно, а как же дебажить тогда?..
И будут ли ли либы на одном языке доступны для другого языка безо всякой магии (и как надо будет дебажить в этом случае)
И будут ли ли либы на одном языке доступны для другого языка безо всякой магии (и как надо будет дебажить в этом случае)
отвечу сам себе: у них в FAQ это всё сказано
О да, как только после многих годов изучения Javascript я его постиг и полюбил, пришли сишники и все испортили. Теперь они будут диктовать мне условия и в вебе. :(
Внимательней прочтите. Они не учат браузер работать с C/C++. Они делают формат который быстрей парсится и по пути делают трансляторы. Клиент так и останется на JS. Условно вам делают формат в который можно собирать проект. Не нужно будет использовать минификаторы и т.п.
Не Ему, а Вам. :)
Поясните.
А слона то я и не заметил.
sarcasm ->
А слона то я и не заметил.
1. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре. И ещё один, да, вот тот в пыльном углу, его используют в сепулькарии на Бетельгейзе.
2. Мы же можем придумать ещё один, который заменит те 10 которые всеми уже изучены, чтобы всем НАМ было хорошо. Мы знаем C|C++ и т.п., и всё в наших руках. В конце концов, мы же всё это написали, так? Для того, чтобы сказать о «снижении порога входа» мы оставим трансляцию в байткод на уровне обратной совместимости с Нашими JS Engine.
3.…
4.…
5. Ещё один Web стандарт, используемый непонятно кем и непонятно где.
Но они могут, да, это Плюс. И они реально помогут товарищам, которые любят лепить Паттерны и Архитектуру там где достаточно Костылей и Велосипедов.
И да, конечно, правильным людям с нормальными задачами они тоже помогут. Но это будет другая история.
2. Мы же можем придумать ещё один, который заменит те 10 которые всеми уже изучены, чтобы всем НАМ было хорошо. Мы знаем C|C++ и т.п., и всё в наших руках. В конце концов, мы же всё это написали, так? Для того, чтобы сказать о «снижении порога входа» мы оставим трансляцию в байткод на уровне обратной совместимости с Нашими JS Engine.
3.…
4.…
5. Ещё один Web стандарт, используемый непонятно кем и непонятно где.
Но они могут, да, это Плюс. И они реально помогут товарищам, которые любят лепить Паттерны и Архитектуру там где достаточно Костылей и Велосипедов.
И да, конечно, правильным людям с нормальными задачами они тоже помогут. Но это будет другая история.
Не Ему, а Вам. :)
В этом вы все таки не совсем правы. =)
Ну, не знаю, у них там в FAQ написано:
Я так понимаю, что на начальном этапе компилировать в .wasm можно будет только из C++. Это приведет к тому, что появятся библиотеки на C++, своя собственная субкультура и пр. Пока появятся компиляторы из других языков, C++ станет де факто стандарт. И, хотя я понимаю, что браузеру будет все-равно из чего .wasm получился, писать не на том, на чем написано большинство библиотек, мне будет неприятно а плюсы прийдется учить почти с нуля. Я не говорю, что так и будет, но вероятность всегда имеется. Хорошо, что хоть разрешили модули подключать из JS.
As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++. However, by integrating with JS at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JS.
Я так понимаю, что на начальном этапе компилировать в .wasm можно будет только из C++. Это приведет к тому, что появятся библиотеки на C++, своя собственная субкультура и пр. Пока появятся компиляторы из других языков, C++ станет де факто стандарт. И, хотя я понимаю, что браузеру будет все-равно из чего .wasm получился, писать не на том, на чем написано большинство библиотек, мне будет неприятно а плюсы прийдется учить почти с нуля. Я не говорю, что так и будет, но вероятность всегда имеется. Хорошо, что хоть разрешили модули подключать из JS.
Поддерживаю. В С/C++ самом по себе нет ничего плохого, кроме чудовищного оверхеда.
Я свои пределы знаю, Матан учил на троечку-четвёрочку, потому, что мозгов не хватило. Но это моя троечка была, я её заслужил всё-таки, и сдавал без шпор, просто интересно было себя всё-таки проверять. И да, это был не технический вуз.
На JavaScript можно что-то начать писать даже будучи полным неофитом, и не разбираясь вообще в технологиях.
И, если есть желание и стремление можно достичь в целом неплохого уровня, даже рисуя мелкие опусы для всяких нудных задач.
Предлагаемый подход может изменить векторы приоритетов. Т.к. написание любого «мало-мальски» кода на любом «нормальном» языке, требующем запуска «компилятора» по определению не может быть простым, надеюсь это очевидно.
А следовательно, не однозначно, но потенциально может сложиться ситуация, когда программирование для Web будет считаться элитарным занятием. Таким, как, например, считается сейчас умение программировать на ассемблере и C\C++.
И не надо говорить, что на самом деле это типа «просто». Нихера это не просто, у кого нет в базе нормального матана и сотни регистров памяти в межушном нервном узле, может просто нехватить потенциала. И, да, я пробовал. Может попробую ещё, но сейчас не вижу смысла, мне хватает JS, и в нём нет оверхеда. Под Windows у меня есть HTML Applications и Windows Scripting Host. Под Linux у меня есть node.js, Rhino, commonjs (lib). Для общих задач я могу использовать NW.js. А так же у меня есть расширения для браузеров и куча других возможностей сделать ВСЁ самому. С приходом компилятора в веб лично моя жизнь может и не усложнится, но вероятность есть.
Я свои пределы знаю, Матан учил на троечку-четвёрочку, потому, что мозгов не хватило. Но это моя троечка была, я её заслужил всё-таки, и сдавал без шпор, просто интересно было себя всё-таки проверять. И да, это был не технический вуз.
На JavaScript можно что-то начать писать даже будучи полным неофитом, и не разбираясь вообще в технологиях.
И, если есть желание и стремление можно достичь в целом неплохого уровня, даже рисуя мелкие опусы для всяких нудных задач.
Предлагаемый подход может изменить векторы приоритетов. Т.к. написание любого «мало-мальски» кода на любом «нормальном» языке, требующем запуска «компилятора» по определению не может быть простым, надеюсь это очевидно.
А следовательно, не однозначно, но потенциально может сложиться ситуация, когда программирование для Web будет считаться элитарным занятием. Таким, как, например, считается сейчас умение программировать на ассемблере и C\C++.
И не надо говорить, что на самом деле это типа «просто». Нихера это не просто, у кого нет в базе нормального матана и сотни регистров памяти в межушном нервном узле, может просто нехватить потенциала. И, да, я пробовал. Может попробую ещё, но сейчас не вижу смысла, мне хватает JS, и в нём нет оверхеда. Под Windows у меня есть HTML Applications и Windows Scripting Host. Под Linux у меня есть node.js, Rhino, commonjs (lib). Для общих задач я могу использовать NW.js. А так же у меня есть расширения для браузеров и куча других возможностей сделать ВСЁ самому. С приходом компилятора в веб лично моя жизнь может и не усложнится, но вероятность есть.
sarcasm ->
Как я Вас понимаю. Эти злые сишники, лепят свои паттерны и архитектуру, где надо и где не надо. И при этом они почему-то считают, что это и есть программирвоание. А нас, JavaScript Developer'ов при этом за людей вообще не признают. И вот сейчас они решили, что JavaScript стал не совсем нужен.
Как я Вас понимаю. Эти злые сишники, лепят свои паттерны и архитектуру, где надо и где не надо. И при этом они почему-то считают, что это и есть программирвоание. А нас, JavaScript Developer'ов при этом за людей вообще не признают. И вот сейчас они решили, что JavaScript стал не совсем нужен.
Взять бы туда Swift в качестве основы. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
Ого, а почему тут Swift не любят?
Речь идёт про низкоуровневый двоичный код. Как можно взять высокоуровневый текстовый язык в качестве основы для низкоуровневого двоичного кода? Выглядит как глупость, вот и минусы. А компилировать в низкоуровневый двоичный код можно будет всё что угодно (для чего будут написаны соответствующие компиляторы).
А вот это:
Не хочу и не могу навязывать свою модель поведения кому-либо, но, обычно, если я не понимаю чей-то коментарий, то либо спрашиваю, либо прохожу мимо…
на текущий момент разработчики сфокусировались на C/C++видимо, тоже глупость?
Не хочу и не могу навязывать свою модель поведения кому-либо, но, обычно, если я не понимаю чей-то коментарий, то либо спрашиваю, либо прохожу мимо…
Я процитирую чуть больше из статьи:
Ваш комментарий написан чётко и ясно. Вы предлагаете WebAssembly основать на Swift. Если бы вы выразили желание получить компилятор Swift под WebAssembly — другое дело.
Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже).Нет, это не глупость. Это значит, что первые компиляторы появятся для самых популярных системных языков программирования — для C и C++.
Ваш комментарий написан чётко и ясно. Вы предлагаете WebAssembly основать на Swift. Если бы вы выразили желание получить компилятор Swift под WebAssembly — другое дело.
</зануда>
Вы забыли за собой закрыть.
Ок, специально для вас перефразирую мой первый комментарий:
Вы забыли за собой закрыть.
Ок, специально для вас перефразирую мой первый комментарий:
Вот бы там на Swift сфокусировались. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
Я вам минусов не ставил, и специально для меня ничего не нужно делать. Я вам просто пояснил наиболее вероятную причину, почему вам прилетело столько минусов, и что ваше предположение что «Swift здесь не любят» скорее всего неверно.
Смысл у вашей новой формулировки отличается от первоначального. Вместо того, чтобы признать, что высказались неправильно, зачем-то пытаетесь оправдаться.
Сколько раз встречал случаи, когда кто-то публично огорчался по поводу минусов (а часто пишут, мол ну хоть кто-нибудь написал бы причину, негодяи, прикрываются анонимностью, трусы и т.д.), я писал в личку наиболее вероятную причину, и мне всегда тут же начинали присылать зачем-то кучу оправданий и даже каких-то обвинений. Не удивлён, что мало кто желает описывать причины поставленного минуса. Как оказалось, если человек сам не в состоянии адекватно отнестись к критике в виде минусов (и оценить что не так), то скорее всего и прямое указание причин ничего хорошего не даст.
Хорошо. Будем считать, что вы хотели бы, чтобы разработчики в первую очередь бросили все силы на создание компилятора для языка Swift. Разумно ли это? База существующего кода на C++ намного богаче, чем на Swift. Компиляторы, архиваторы, декодеры аудио/видео/изображений, огромное количество различных библиотек. Полагаю, что и при создании самого Swift не обошлось без C++. То есть от реализации компилятора C++ будет намного больше пользы, чем от компилятора Swift, или Rust, или что там ещё кто-нибудь может захотеть. А когда стандарт будет готов, тогда и сами авторы этих языков смогут создать соответствующие компиляторы под WebAssembly.
Смысл у вашей новой формулировки отличается от первоначального. Вместо того, чтобы признать, что высказались неправильно, зачем-то пытаетесь оправдаться.
Сколько раз встречал случаи, когда кто-то публично огорчался по поводу минусов (а часто пишут, мол ну хоть кто-нибудь написал бы причину, негодяи, прикрываются анонимностью, трусы и т.д.), я писал в личку наиболее вероятную причину, и мне всегда тут же начинали присылать зачем-то кучу оправданий и даже каких-то обвинений. Не удивлён, что мало кто желает описывать причины поставленного минуса. Как оказалось, если человек сам не в состоянии адекватно отнестись к критике в виде минусов (и оценить что не так), то скорее всего и прямое указание причин ничего хорошего не даст.
Хорошо. Будем считать, что вы хотели бы, чтобы разработчики в первую очередь бросили все силы на создание компилятора для языка Swift. Разумно ли это? База существующего кода на C++ намного богаче, чем на Swift. Компиляторы, архиваторы, декодеры аудио/видео/изображений, огромное количество различных библиотек. Полагаю, что и при создании самого Swift не обошлось без C++. То есть от реализации компилятора C++ будет намного больше пользы, чем от компилятора Swift, или Rust, или что там ещё кто-нибудь может захотеть. А когда стандарт будет готов, тогда и сами авторы этих языков смогут создать соответствующие компиляторы под WebAssembly.
Мне как бы всё равно на минусы (иначе и не пытался бы спорить), но интересна была причина негативного отношения к комменту.
Спасибо, вы назвали возможную — непонимание смысла моего первоначального комментария (либо неправильная формулировка комментария, что, в общем-то, равноценно в данном случае – оценивался не тот смысл, который я вкладывал).
Спасибо, вы назвали возможную — непонимание смысла моего первоначального комментария (либо неправильная формулировка комментария, что, в общем-то, равноценно в данном случае – оценивался не тот смысл, который я вкладывал).
Думаю, проблема вашего комментария не в том, что его не поняли, а в том, что он выявляет ваше непонимание. Вы не понимаете того, что новый стандарт не пытается сменить основной язык на что-то вроде свифта, а создает возможность для выполнения высокопроизодительного кода в первую очередь. В этой связи, ваш комментарий звучит несколько неуместным, и особенно неуместен из за предложения проприетарного языка для открытого стандарта.
Спасибо, что разъяснили мне мои же мысли. ;)
И, к слову, Apple пообещали сделать Swift 2.0 опенсорсным.
И, к слову, Apple пообещали сделать Swift 2.0 опенсорсным.
А за что его любить?
Там просто нет основы как таковой. Вернее она есть, но простому разработчику лезть в неё практически никогда не нужно, как не нужно Swift-разработчику лезть в генерируемый компилятором машинный код, а С++ разработчику в код LLVM. Какая вам разница исполняется ваш код на х86 или ARM и какая вам будет разница исполняется ваш код на JS-движке, JVM или напрямую в машкоды компилируется?
… также планирует запустить библиотеку polyfill… что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly
Абсурдно — это запускать технологию, под которую никто не будет писать пока _все_ браузеры на неё не перейдут. Тут всё логично.
Как человек далекий от веба, скажу, что я немного удивлен. Вроде как для тяжелых приложений лет много назад были придуманы Джава-аплеты (компилироваанная Джава) и исполение их в песочнице, предоставляемой браузером. Почему не стали развивать это направление? Чем оно хуже WebAssembly?
Так же удивляюсь до сих пор, что для самого медленного типа связи, веба, стандартом стал самый длинный формат передачи данных — XML и его призводные: SOUP и т.п. и т.д. Получилось «медленно в квадрате»,
Так же удивляюсь до сих пор, что для самого медленного типа связи, веба, стандартом стал самый длинный формат передачи данных — XML и его призводные: SOUP и т.п. и т.д. Получилось «медленно в квадрате»,
-1 вместо внятного объяснения? Так держать.
Про Флэш понятно, это полностью свой фреймворк со своим GUI.
Сервелат — это сервлеты? Они вроде как вообще не про это и испоняются на сервере.
Теперь к апплетам. Если у апплетов и есть своя GUI-библиотека (от Java), то она явно не проприетарная, а очень даже стандартная и кроссплатформенная, как и сама Java. Но что мешает писать на ней только логику?
DOM? Я всегда думал, что это стандарт иерархической структуры сложных документов, а также навигации/поиску по ней. Она уже и GUI-контролы включает?
Еще раз: казалось бы, уж что есть еще более кроссплатформенное, чем Java? Хотя сами исходники закрыты, конечно…
Сервелат — это сервлеты? Они вроде как вообще не про это и испоняются на сервере.
Теперь к апплетам. Если у апплетов и есть своя GUI-библиотека (от Java), то она явно не проприетарная, а очень даже стандартная и кроссплатформенная, как и сама Java. Но что мешает писать на ней только логику?
DOM? Я всегда думал, что это стандарт иерархической структуры сложных документов, а также навигации/поиску по ней. Она уже и GUI-контролы включает?
Еще раз: казалось бы, уж что есть еще более кроссплатформенное, чем Java? Хотя сами исходники закрыты, конечно…
До изобретения Явы осталось совсем чуть-чуть…
Это намного более низкоуровневая вещь, чем Java. В нее можно компилить C — попробуйте сделать это с JVM…
В нее можно компилить C — попробуйте сделать это с JVM…Да вы не поверите…
А человеку минусы поставили незаслуженно.
Это скорее LLVM для веба.
Мне вот интересно, можно ли будет из нативного js прозрачно работать с кодом загруженным в этом формате? Например скомпилировать к примеру node.js, отдать клиенту и вызывать node.js api из js скрипта?
Хм, может кажется это вполне возможно github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration
точно, js как клей для скомпилированных библиотек это очень круто. github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript
и еще хороший обзор www.2ality.com/2015/06/web-assembly.html
Интересно,
а что с безопасностью?
Кто-нибудь посоветует работы, посвященные ИБ в WebAssembly?
а что с безопасностью?
Кто-нибудь посоветует работы, посвященные ИБ в WebAssembly?
Web-разработка на Qt? :) Запуск десктопных программ в браузере?!
Уже реальность с emscripten-qt.
Почему то никто из здесь собравшихся не обсуждает проблему веса всего этого кода, который будет компилироватся. Тот же boost или qt довольно прилично занимают.
Спираль развития вернулась к модели Java — компиляция в bytecode где-то на стороне — исполнение bytecode в песочнице browser — это наверное хорошо.
Сомнения вызывает конкретно browser как target песочница.
У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?
Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.
Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.
Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.
Сомнения вызывает конкретно browser как target песочница.
У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?
Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.
Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.
Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.
Место HTML займет WPF уверен в этом. Получится тот же Silverlight только с черного входа, чтоб никто не заподозрил.
Ни к HTML ни к CSS этот ray-tracer не пришьёшь.
DOM доступен точно, вероятно и CSSOM. Собственно, всё что доступно JS в браузере должно быть доступно и WA-коду.
Ребята, я немного не понял. То есть теперь веб-приложения потенциально могут состоять из c++ \ c# \ go \ js кода одновременно? Как все это поддерживать? Возможна ли ситуация, когда над проектом будет работать несколько разработчиков и каждый будет писать на языке, который он знает, в итоге превратив код в кашу?
С emscripten не работал, к сожалению, поэтому не знаю, как там все устроено. Пытаюсь разобраться в такой ситуации: веб-проект писался на C#, C++ и т.д. Ты приходишь устраиваться на работу, как JS разработчик. Сможешь ли ты поддерживать (редактировать, добавлять новый функционал) в модули, написанные на этих языках, зная только JS? Или же будущему веб разработчику нужно будет знать кучу языков?
Ну вот Angular2 пишется на TypeScript. Значит нужно будет знание TypeScript если захочется его исходники понять.
Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.
Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.
TypeScript ничто иное как синтаксический сахар над JS, это немного другое. К тому же у меня язык не повернется сравнить TS и тот же C++, это как минимум неуместно. Поймите, я не против веб технологий и того веб стека, который сейчас есть в вооружении у веб разработчика. Я всерьез обеспокоен приходом низкоуровневых ЯП в веб
Сложилось довольно скептическое отношение к таким новшествам. Что будет с рынком труда, во что превратится веб-разработчик? Не хотелось бы внезапно (утрирую конечно) в вакансиях увидеть: требуется веб разработчик: уверенные знания js, c++, java, c# опыт от 5 лет. Ясно, что человеку, ушедшему в веб дев в наше время будет сложно переключиться на низкоуровневые языки (да и зачем? я не хочу, я веб-разработчик), чего не скажешь об обратном. По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?
> По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?
Я думаю люди на «низкоуровневых» языках решают другие задачи и вашей зарплате изменения не грозят. Просто теперь в их вакансиях реже будет появляться «JS» рядом с «веб».
Я думаю люди на «низкоуровневых» языках решают другие задачи и вашей зарплате изменения не грозят. Просто теперь в их вакансиях реже будет появляться «JS» рядом с «веб».
Собственно, в подавляющем большинстве веб-проектов используется минимум два языка (не считая языка СУБД) — JS и C++/C#/Java/PHP/Python/ Ruby/… И в вакансиях требования знать оба не редкость, а «будет плюсом» уже давно норма. И к низкоуровневым (по современным меркам) из моего списка только C++ можно отнести, и то с натяжкой.
Плюс то он плюс, но за этот плюс (из моей практики) редко доплачивают. Работадателю будет дороже нанять разработчиков, которые уверенно знают конкретно свою область, проще (дешевле) взять того кто знает что-то хорошо, а остальное на уровне «понимаю\разбираюсь». И это только касательно языка.
С приходом c++\c#\java и пр. в веб так же появятся тонна библиотек. И разработчику уже надо будет знать не просто язык, а кучи архитектур. Взять нынешнего PHP разработчика. Надеюсь, согласитесь, что не просто найти того, кто отлично может разрабатывать \ масштабировать Drupal, WP, Joomla, Symfony, Laravel, Doctrine, хотя это один и тот же язык. Да, я намешал фреймворки, CMS и ORM, но это именно то, чего я и опасаюсь с приходом ряда языков в веб. Одних JS библиотек\расширений появляется с десяток в неделю.
С приходом c++\c#\java и пр. в веб так же появятся тонна библиотек. И разработчику уже надо будет знать не просто язык, а кучи архитектур. Взять нынешнего PHP разработчика. Надеюсь, согласитесь, что не просто найти того, кто отлично может разрабатывать \ масштабировать Drupal, WP, Joomla, Symfony, Laravel, Doctrine, хотя это один и тот же язык. Да, я намешал фреймворки, CMS и ORM, но это именно то, чего я и опасаюсь с приходом ряда языков в веб. Одних JS библиотек\расширений появляется с десяток в неделю.
Все это ради задач с повышенным требованием к производительности, знание этих языков еще ничего не дает, потому что писать производительный код умеет не каждый.
Java-ненавистники активно минусуют упоминания о Java… А будет ведь по сути всё то же самое, только с отставанием на несколько лет. Жалуетесь, что в Java (и в JavaScript) есть уязвимости, позволяющие обойти «песочницу»? Так они и в этой технологии появятся, никуда не денешься. Не один год пройдёт пока всё закроют. Жалуетесь, что «тормозит»? Про JIT-компиляторы безнадёжно упоминать, не слышат. Так и эта технология будет поначалу тормозить. Жалуетесь, что JRE раздута по объёму? Так там смотрите сколько в стандартной библиотеке полезного. Так и в этой технологии — будет либо почти голый рантайм с минимумом библиотек (и пишите всё сами и подгружайте динамически), либо когда всё это обрастёт стандартными библиотеками — точно так же раздуется сам браузер. Жалуетесь, что Java подгрёб под себя Oracle (а ранее Sun)? А вы уверены, что комитет из не очень дружественных компаний будет лучше, а не как в басне про лебедя, рака и щуку?
WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++. Зато под WebAssembly можно будет собрать и Flash, и JVM, и Silverlight. И всё это будет выполняться в стандартной песочнице браузера. Разве не прекрасно? :)
Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java. Здесь уже несколько раз об этом упоминали, а любители Java продолжают писать те же глупости. Такое впечатление, что научились стучать молотком, и пытаетесь забивать им даже шурупы. И вообще непонятно, почему тогда уже не Flash или Silverlight? Flash, кстати, вполне себе позволяет выполнять код, скомпилированный из C++. И он очень популярен, есть на большинстве машин, в отличие от столь упоминаемой здесь Java. Но от него уже сколько лет пытаются избавиться. Всё потому, что это совершенно отдельная сущность, которая плохо интегрирована с браузером, и предлагает много лишнего.
Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java. Здесь уже несколько раз об этом упоминали, а любители Java продолжают писать те же глупости. Такое впечатление, что научились стучать молотком, и пытаетесь забивать им даже шурупы. И вообще непонятно, почему тогда уже не Flash или Silverlight? Flash, кстати, вполне себе позволяет выполнять код, скомпилированный из C++. И он очень популярен, есть на большинстве машин, в отличие от столь упоминаемой здесь Java. Но от него уже сколько лет пытаются избавиться. Всё потому, что это совершенно отдельная сущность, которая плохо интегрирована с браузером, и предлагает много лишнего.
Вы знаете, я ничего не писал про высокоуровневость или низкоуровневость. На что именно вы отвечаете? Ответьте уж лучше на те пункты, что были в моём комментарии.
И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.
И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.
Чуть промахнулся, ответ здесь.
И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.У Google уже есть PNaCl, у него уже есть опыт в разработке таких штук. Просто другие не поддержали его начинания, видимо из-за того что это разработка лишь одного игрока. А теперь гиганты объединились, и вместе они наверняка смогут сделать нечто достойное стандарта. Не объявляли бы о создании такого альянса, если бы не были уверены в том, что у них что-то получится. А если не получится — конечно, жаль, но от этого идея не станет хуже, и JVM от этого не станет привлекательнее.
>> WebAssembly будет значительно более низкоуровневой, чем байт-код Java.
Не вижу здесь никакой «большей низкоуровневости»: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/wasm-opcodes.h
Скорее даже с точность наоборот:
— Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
— Зачем-то есть отдельные опкоды для IfThen и для Ternary (вероятно, это flag?foo:bar) с показательным комментарием «TODO(titzer): reduce duplication with kStmtIfThen.» вот здесь: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/decoder.cc#L683
>> Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java.
И там и там байткод, и там и там виртуальная машина.
Умеющий абстрактно мыслить да увидит аналогию.
>> WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++.
Выбор C/C++ в качестве основного языка о наборе инструкций ничего не говорит.
Как вы и упомянули, под Flash Player тоже можно скомпилировать исходники на C/C++ и это при том, что набор инструкций AVM2 весьма высокоуровневый.
Хотя, замечу в скобках, что со временем там и добавили ряд инструкций специально для оптимизации такого кросс-компилированного кода.
>> Но от него уже сколько лет пытаются избавиться.
Кто пытается и отчего у него это до сих пор не получилось?
Не вижу здесь никакой «большей низкоуровневости»: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/wasm-opcodes.h
Скорее даже с точность наоборот:
— Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
— Зачем-то есть отдельные опкоды для IfThen и для Ternary (вероятно, это flag?foo:bar) с показательным комментарием «TODO(titzer): reduce duplication with kStmtIfThen.» вот здесь: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/decoder.cc#L683
>> Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java.
И там и там байткод, и там и там виртуальная машина.
Умеющий абстрактно мыслить да увидит аналогию.
>> WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++.
Выбор C/C++ в качестве основного языка о наборе инструкций ничего не говорит.
Как вы и упомянули, под Flash Player тоже можно скомпилировать исходники на C/C++ и это при том, что набор инструкций AVM2 весьма высокоуровневый.
Хотя, замечу в скобках, что со временем там и добавили ряд инструкций специально для оптимизации такого кросс-компилированного кода.
>> Но от него уже сколько лет пытаются избавиться.
Кто пытается и отчего у него это до сих пор не получилось?
Ну так код на C/C++ можно скомпилировать и в JavaScript. Только в нём нет адекватных подходящих инструкций для типичных операций для низкоуровневого кода типа работы с данными по указателю. Для того чтобы это как-то исправить, придумали asm.js, но получилось всё равно сильно громоздко. К слову, текущая экспериментальная реализация — это по сути asm.js, переведённый в двоичный формат.
Байт-код Java даже банально не то что указатели не поддерживает, там нет и простейших структур. Даже IL из .NET намного лучше годился бы для такой роли, потому что там разработчики изначально подумали над тем, чтобы предложить широкий набор способов оптимизации, не загоняя разработчиков в узкие рамки, и там целиком поддерживаются как полноценные структуры, так и указатели (но это с ограничениями, если не выходить за пределы управляемого кода).
То есть компиляцию из C++ в байт-код Java конечно можно сделать (как и в любой другой байт-код или язык), вопрос только в том, насколько он получится эффективным. Байт-код Java — неэффективен, потому что он оперирует только слишком высокоуровневыми объектами и не разрешает работать с сырой памятью, то есть при компиляции в байт-код Java мы вынуждены были бы использовать неэффективные структуры данных для имитации простейших и всегда используемых низкоуровневых операций. Костыль, однако. Говорить о том, что этот байт-код можно расширить и добавить нужное, не приходится. Вспомните какими костылями прицепили туда поддержку generics в погоне за C#/.NET IL :)
Формат у WebAssembly будет не просто линейным набором команд. Там будет готовое к употреблению AST, что сделано для возможности однозначного перевода двоичного формата в текстовый и обратно в двоичный. Но набор то инструкций всё равно создаётся с расчётом на компиляцию из языков типа C/C++, а значит он будет изначально рассчитан для эффективного представления типичных низкоуровневых операций. И то что там условия и циклы будут похожи на макросы FASM ничего не меняет. Все эти плюшки легко и без накладных расходов переводятся в машинный код для любого процессора.
Байт-код Java даже банально не то что указатели не поддерживает, там нет и простейших структур. Даже IL из .NET намного лучше годился бы для такой роли, потому что там разработчики изначально подумали над тем, чтобы предложить широкий набор способов оптимизации, не загоняя разработчиков в узкие рамки, и там целиком поддерживаются как полноценные структуры, так и указатели (но это с ограничениями, если не выходить за пределы управляемого кода).
То есть компиляцию из C++ в байт-код Java конечно можно сделать (как и в любой другой байт-код или язык), вопрос только в том, насколько он получится эффективным. Байт-код Java — неэффективен, потому что он оперирует только слишком высокоуровневыми объектами и не разрешает работать с сырой памятью, то есть при компиляции в байт-код Java мы вынуждены были бы использовать неэффективные структуры данных для имитации простейших и всегда используемых низкоуровневых операций. Костыль, однако. Говорить о том, что этот байт-код можно расширить и добавить нужное, не приходится. Вспомните какими костылями прицепили туда поддержку generics в погоне за C#/.NET IL :)
— Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.Вот именно, что в этих инструкциях нет ничего высокоуровневого — они легко переносятся на любой машинный код без потерь в производительности даже при компиляции под какой-нибудь древний 6502, который ещё в Dendy стоял. В том же FASM подобные вещи легко реализуются на макросах, можно делать полноценные условия, циклы, вкладывать код и т.д. Выглядит это так:
— Зачем-то есть отдельные опкоды для IfThen и для Ternary
.if eax<=100 & ( ecx | edx )
inc ebx
.endif
Формат у WebAssembly будет не просто линейным набором команд. Там будет готовое к употреблению AST, что сделано для возможности однозначного перевода двоичного формата в текстовый и обратно в двоичный. Но набор то инструкций всё равно создаётся с расчётом на компиляцию из языков типа C/C++, а значит он будет изначально рассчитан для эффективного представления типичных низкоуровневых операций. И то что там условия и циклы будут похожи на макросы FASM ничего не меняет. Все эти плюшки легко и без накладных расходов переводятся в машинный код для любого процессора.
Кто пытается и отчего у него это до сих пор не получилось?Разработчики браузеров? На мобильных платформах с поддержкой уже совсем плохо. На десктопе ещё держится, но пропаганда отказа от Flash не прекращается. А почему его до сих пор используют — это вопрос не ко мне. Я не использую, на некоторых компьютерах, чтобы не возиться с убогим обновлятором Flash, просто отключаю его совсем. Например, мои родители полгода назад начали жаловаться, что youtube перестал работать. Оказалось, что Firefox заблокировал Flash и стал требовать активировать его отдельно для каждой страницы, поскольку его версия устарела. Чтобы не объяснять им процедуру обновления Flash (который почему-то не научился делать это полностью автоматически), я его просто отключил целиком и всё стало хорошо. Аудитория у мобильных ОС уже очень большая, и все основные поставщики контента вынуждены реализовать нормальную работу и без Flash. Так что процесс идёт.
Если это был не сарказм — то какая связь между указателями, верификацией, и вируснёй?
Вирусы писали даже на VBScript, где указателями и близко не пахнет.
Вирусы писали даже на VBScript, где указателями и близко не пахнет.
Вирусы выживают только за счёт того, что файловое пространство едино для всех приложений.
Когда в ОС приложение будет иметь доступ только в разрешенном пространстве, отдельно от других приложений, в этом случае — вирусы просто не смогут ничего сделать (если в самой ОС не будет подходящих дыр). Например — в защищенном режиме процессора у каждого приложения — своя отдельная от других приложений память, с дисковым пространством было бы круто сделать то же самое.
А указатели, байткод здесь вообще не причём. Любое приложение — это байткод )
Когда в ОС приложение будет иметь доступ только в разрешенном пространстве, отдельно от других приложений, в этом случае — вирусы просто не смогут ничего сделать (если в самой ОС не будет подходящих дыр). Например — в защищенном режиме процессора у каждого приложения — своя отдельная от других приложений память, с дисковым пространством было бы круто сделать то же самое.
А указатели, байткод здесь вообще не причём. Любое приложение — это байткод )
Я вас не до конца понимаю. Но попробую ответить.
Указатели и вирусы не зависят друг от друга.
Вы изучите сначала что такое защищенный режим и как работает страничная адресация. Там отлично описано почему одно приложение не имеет доступ к ОС и к другим приложениям (хотя отлично использует указатели).
Указатели и вирусы не зависят друг от друга.
Вы изучите сначала что такое защищенный режим и как работает страничная адресация. Там отлично описано почему одно приложение не имеет доступ к ОС и к другим приложениям (хотя отлично использует указатели).
Вам человек пытался объяснить, что у процесса нет физического доступа к страницам памяти ядра системы или других процессов, за счет того что у них независимая адресация страниц. Единственная возможность это использовать ошибки в коде ядра, которые позволяют в конечном итоге получить доступ к страницам ядра или доступ к исполняемым файлам других программ. Если первое более менее оперативно исправляется, то второе выглядит как большущая дыра, закрывать которую даже не пытаются.
Давайте представим, что у вас совершенно дырявый браузер. Да действительно, если мы захватили контроль над браузером, мы можем слить все письма, аккаунты и т.д. Но проблема еще и в том, что мы можем внедрить троян в калькулятор или еще куда нибудь, просто потому что система позволяет каждой программе делать на жестком диске все что ей вздумается. Система была бы намного более защищенной, если бы права доступа к файлам ограничивались по умолчанию папкой установки. Вот о чем речь.
А будет ведь по сути всё то же самое, только с отставанием на несколько лет.Это не то же самое. Все пункты что вы написали автоматически становятся бессмысленными, если понять это. Я думал, это будет очевидно из моего комментария.
Не очевидно. Кому очевидно? Слёту сказать «очевидно» — это демагогический приём.
Вы сказали:
Вспомнилось, как лет 10-15 назад учителя оценку снижали за отсутствие вывода в лабах :)
А будет ведь по сути всё то же самое, только с отставанием на несколько лет.На что я ответил:
WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами.Я указал на существенное различие. Извините, я не знал, что нужно обязательно в конце добавить «вывод: это не одно и то же».
Вспомнилось, как лет 10-15 назад учителя оценку снижали за отсутствие вывода в лабах :)
Забавно, одна и та же новость привела к двум противоположным выводам:
1) JS умрет
2) JS все зохавает
:)
1) JS умрет
2) JS все зохавает
:)
Интересно, а можно ли будет в хроме вставлять cpp код, что бы тестить скрипты на лету?
ActiveX-ом пахнет… Кроссплатформенным…
Я как и все рад, что программы будут исполняться быстрее. Но для браузерного веба этот прирост скорости будет незаметен. DOM по прежнему останется медленной задницой.
По сути это идея платформы .net там тоже assembly и несколько языков. Давно пора имхо. А вот шутку с C\C++ я не заценил, писать юзер интерфейс на С это уже слишком.
Можете писать на чём угодно и никто WA использовать для интерфейсов не обязывает. Один из стандартных юзкейсов — ядро скомпилировано под WA, интерфейс — обычный HTML/CSS/JS. Общаются между собой прозрачно синхронными вызовами в обе стороны. Ну и логично после C/C++ первым ожидать компилятор JS для WA — многие заинтересованы увеличить быстродействие без переписывания кода.
Посмотрите здесь и поймёте, что никто не собирается заставлять разработчиков писать ui на c++, стандарт предназначен для работы в браузере тяжелых задач вроде игр, видео, возможно какого-то сложного программного обеспечения вроде кад-ов, виртуализация и тому подобные вещи. Плюс дает возможность компилировать в производительный машинный код и другие языки за счет промежуточного низкоуровневого байткода. Более того, джаваскрипт по прежнему будет основным языком для работы на странице — по большому счету, эта новость в первую очередь для тех кто раньше в вебе вообще не работал или пытался компилироваться в asm.js.
Youtube сможет наконец сжимать видео в браузере перед отправкой, фотохостинги — сжимать изображение нужны алгоритмом (а не тем что в canvas) перед заливкой. В прочем, последнее делалось через flash/silverlight/java, но кого это волнует.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google, Microsoft, Mozilla и другие объединились для запуска WebAssembly, нового бинарного формата для Web