The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен ORBX.js - сравнимый с H.264 видеокодек, реализованный целиком на JavaScript

07.05.2013 21:52

Бренден Айк (Brendan Eich), создатель языка JavaScript, занимающий пост технического директора Mozilla Corporation, представил проект ORBX.js, в рамках которого компанией OTOY подготовлена высокопроизводительная реализация видеокодека, реализованного целиком на JavaScript и WebGL. Новый проект подчёркивает возведение JavaScript на новый уровень развития и знаменует стирание границ между Web и нативными приложениями. ORBX.js может работать в любых современных браузерах, в том числе для мобильных платформ, не требуя никаких дополнительных компонентов, кроме поддержки существующих web-стандартов.

Среди основных областей применения ORBX.js, кроме отображения потокового видео, называется создание работающих в окне браузера средств удалённого доступа к рабочему столу, играм и виртуальным окружениям. В частности, продемонстрированы средства для запуска в облачных окружениях ресурсоёмких 3D-пакетов и игр с трансляцией вывода в окно браузера, запущенного на маломощном нетбуке или планшете.

Кроме того, так как ORBX.js не требует наличия отдельных браузерных плагинов и не зависит от наличия кодеков в браузере, он может использоваться в качестве альтернативного пути предоставления средств защиты контента, не требующих продвижения DRM-механизмов в web-стандарты. Вместо DRM предлагается добавлять в кадры уникальные для каждого сеанса водяные знаки. Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.

С позиции эффективности, активное использование GPU в процессе работы, позволяет ORBX.js на обычной системе декодировать видеопотоки c разрешением 1080x600 и 60 кадров в секунду. Используемые в ORBX.js методы кодирования позволяют достигнуть на 25% более высокого уровня сжатия, по сравнению с H.264, при близком уровне качества. Среди достоинств нового кодека отмечается поддержка адаптивного изменения битрейта в зависимости от параметров полосы пропускания, более эффективные методы кодирования промежуточных кадров, изначальная ориентация на параллельную обработку данных, лучшая глубина цвета.

Для браузеров без поддержки WebGL, таких как Internet Explorer и Safari для iOS, предусмотрен режим упрощённого кодирования, при котором в потоке передаются только ключевые кадры, которые могут быть достаточно быстро и эффективно декодированы без привлечения GPU. Для браузеров с поддержкой WebGL, таких как Firefox, Opera и Chrome, герерируется более изощрённый поток, в котором присутствуют P-кадры, содержащие только информацию об изменениях, что позволяет сократить размер потока в два раза без изменения качества картинки. Декодирование подобных кадров выполняется с привлечением выполняемых на стороне GPU шейдеров.

Дополнительно, можно отметить публикацию демонстрации игры Epic Citade, портированной для работы внутри браузера. Работа игры в браузере основана на использовании компилятора Emscripten, преобразующего код проектов на C/C++ в представление на языке JavaScript (поддерживается подмножество языка JavaScript Asm.js). Для вывода 3D-графики задействован WebGL, а для вывода звука - Web Audio API. Для запуска демонстрации желательно использовать свежую ночную борку Firefox, компоненты которой войдут в состав релиза Firefox 23. Демонстрация также работоспособна и в Firefox 20, но в этом случае не будет обеспечена должная производительность, так как данным выпуском не поддерживается Asm.js.



  1. Главная ссылка к новости (https://brendaneich.com/2013/0...)
  2. OpenNews: Представлен декодировщик видео H.264, оформленный на языке JavaScript
  3. OpenNews: В состав GTK+ 3.2 будет включен HTML5-бэкенд, отображающий приложения через web-браузер
  4. OpenNews: В Firefox 22 появится Asm.js, низкоуровневое высокопроизводительное подмножество JavaScript
  5. OpenNews: Проект Mozilla представил работающий в браузере порт движка Unreal 3 и технологию многопользовательских P2P-игр
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/36879-javascript
Ключевые слова: javascript, codec, video, orbx
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (63) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:55, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Просто оставлю здесь ссылку

    PeerCDN is a peer-to-peer distributed CDN
    - https://peercdn.com/
    - http://www.youtube.com/watch?v=PnBIIdmKO9o&hd=1

     
  • 1.2, Аноним (-), 22:57, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А где демо?
     
     
  • 2.4, Аноним (-), 22:59, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно еще не стабильный, закрытая бета (защита от повседневного использования хрупкого кода в продакшене)
     
  • 2.9, Аноним (9), 23:48, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.unrealengine.com/html5/
     
     
  • 3.11, Аноним (-), 23:53, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Подвешивает окно браузера как в старые добрые времена Windows XP
     
     
  • 4.55, винке (?), 23:15, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на 23 фоксе пускал? если нет, то тебя предупредили.
     

  • 1.5, Аноним (-), 23:39, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    осталось допилить в браузерах поддержку реалтаймового захвата видео и аудио.
     
     
  • 2.17, thrt (?), 00:30, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Уже есть. WebRTC
     
     
  • 3.42, Аноним (-), 09:29, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Уже есть. WebRTC

    стандарты - да, есть (но многие еще допиливаются), в браузерах еще не везде есть (в FF наверно допилят к 22..23 версии)

     
     
  • 4.56, винке (?), 23:17, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Уже есть. WebRTC
    > стандарты - да, есть (но многие еще допиливаются), в браузерах еще не
    > везде есть (в FF наверно допилят к 22..23 версии)

    в фф 20 уже есть в статусе релиза. ну и сегодня они дополнительно предложили код для встраивания на любой сайт...

     
     
  • 5.61, Aleks Revo (ok), 23:29, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Уже есть. WebRTC
    >> стандарты - да, есть (но многие еще допиливаются), в браузерах еще не
    >> везде есть (в FF наверно допилят к 22..23 версии)
    > в фф 20 уже есть в статусе релиза. ну и сегодня они
    > дополнительно предложили код для встраивания на любой сайт...

    В 20-м как раз очень глючно работает с видеопотоком - для полноценной работы желательна 21-я бета

     
  • 3.60, Aleks Revo (ok), 23:28, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    «Допилить» - это значит допилить ;-)
    Крэщащиеся браузеры, внезапное отваливаение функции до перезагрузки браузера, игнорирование некоторых типов камер - пока скорее правило, чем исключение.
     

  • 1.6, hakushka (ok), 23:40, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.

    Как дети, чес-слово. Что мне помешает скачать видео 2-3-42 раза под разными пользователями и выбросить водяные знаки на основе стат. анализа?

     
     
  • 2.12, Аноним (-), 23:58, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>>Подобные водяные знаки дают возможность пользователю копировать и сохранять контент для собственных нужд, но в случае распространения контента среди других пользователей, позволяют выявить источник утечки.
    > Как дети, чес-слово. Что мне помешает скачать видео 2-3-42 раза под разными
    > пользователями и выбросить водяные знаки на основе стат. анализа?

    Это усложняет задачу и для большинства пользователей теряется смысл шарить этот контент.

     
     
  • 3.19, ВовкаОсиист (ok), 00:37, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Автоматизировать этот процесс, первое что приходит в голову.
     
  • 2.14, develop7 (ok), 00:06, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    придётся покупать его 2-3-42 раза, не?
     
     
  • 3.39, Evtomax (??), 09:16, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Социальные сети на что? :)
     
     
  • 4.62, Aleks Revo (ok), 23:30, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Социальные сети на что? :)

    Чуть выше тут как раз за краудфандинг ратовали ))

     

  • 1.8, CPP (??), 23:41, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Заголовок статьи прикольный: Сегодня я увидел будущее.

    Я его ещё позавчера увидел, FF сожрал два гига и встал колом -))

     
  • 1.10, Аноним (-), 23:50, 07/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    JavaScript и производительность — два понятия которые у меня не стыкуются в голове…
     
     
  • 2.13, Аноним (-), 00:01, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Не повезло тебе с головой)
     
  • 2.21, exist (ok), 00:45, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Заблуждение. Asm.js позволяет писать код близкий по скорости выполнения к "pure C". Плюс неблокирующий I/O и асинхронность. JS очень интересный и гибкий язык, если на нем не быдлокодить, а писать хороший код.
     
     
  • 3.24, Lain_13 (ok), 01:46, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем так. Ты пишешь код на каком-либо языке программирования (лучше всего Си или плюсы) и потом этот код компилируется в asm.js-«байткод», который уже и выполняется в браузере. Писать такой «байткод» вручную практически равносильно написанию вручную программы на ассемблере, а это просто гигантский простор для быдлокода. Писать хороший код под asm.js сложнее, чем писать хороший код на Си и лучше этого не делать — для этого есть emscripten.
     
     
  • 4.43, exist (ok), 09:53, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если Asm.js жесток в синтаксисе, то LLJS выглядит как современный С-подобный язык, на которым можно сразу писать ручками быстрый код.
     
  • 3.25, Crazy Alex (ok), 01:47, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не писать, а генерировать из исходников на приличных языках. И, если повезет, его оптимизируют. В этом случае его можно рассматривать не как JS, а как  транспортный слой для байткода, полученного компиляцией сей или плюсов. И остаётся под большим вопросом, что и как будет эффективно работать в такой форме. А то подобрать отдельный примеры, хорошо подающиеся заданному набору оптимизаций - дело нехитрое.

    Ну и остаётся сакраментальный вопрос - зачем оно надо? В чём проблема скормить поток системному видеоплееру, который хоть на линуксах, хоть на винде умеет встраиваться в другие приложения, и заведомо более прилично отработает?

     
     
  • 4.32, Lain_13 (ok), 03:16, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А то подобрать отдельные примеры

    Unreal Engine и ORBX это подобранные отдельные примеры хорошей скорости работы asm.js-байткода или таки просто примеры его хорошей работы? Мне почему-то кажется, что второе. По крайней мере ни чего общего с затачиванием под конкретный код не наблюдается.

    > В чём проблема скормить поток системному видеоплееру,

    1. Это мене безопасно.
    2. К нативному плееру не прикрутишь своей «клёвой» морды + неприятные проблемы фокуса и горячих клавиш при управлении табами в браузере.
    3. Не у всех h264 в системе есть (да, в винде он уже несколько лет как «из коробки», но в линукс-дистрибутивах его обычно нет).
    4. Не у всех установлен/активен плагин видео-плеера и далеко не все его хотят устанавливать/активировать.
    5. Можно реализовать DRM не трогая сам браузер и систему (даже нам это может помочь избежать принятия в стандарты куда большей дряни — пусть лучше уже на JS свой DRM делают).

    И наверняка есть и другие причины.

     
     
  • 5.46, Crazy Alex (??), 13:18, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Разумеется это специально подбранные примеры. ORBX - так вообще целенаправленно под Asm.js написан, насколько я понимаю. Вот когда оно хотя бы с 40-роцентной производительностью будет произвольный код преобразовывать или когда будут четкие правила, проверяемые хотя бы человеком как надо писать код, чтобы asm.js это жрал - тогда другой будет вопрос. Хот как по мне - лучше бы они сделали несколько более полноценный байткод, который, в частности, умел бы предсказуемо работать с памятью.

    Теперь по видеоплееру:
    1) это не более и не менее безопасно, чем браузер. Точно так же есть баги, их фиксят, и так далее. На винде проблем чуть больше, на линуксе - чуть меньше, но в общем ничего особо ужасного нет. даже для флеша, который дыряв по самое не могу, проблем именно с видеопотоком я не припомню.
    2) клёвая морда, разумеется, прикручивается. В винде управление будет идти через COM, в линуксе - через D-Bus. Всё, что надо - чтобы плагин предоставлял стандартизированное JS-API.
    3) наличие h.264  в браузере менее вероятно, чем наличие h.264 в системе - тот же файрфокс его тащить, например, не может. Хотя при чем здесь h.264?
    4) А что мешает тащить этот плагин вместе с браузером? Роль у него-то маленькая, определить,что установлено да команды проксировать.
    5) А так можно оставить DRM на откуп собственно плееру и вообще его не реализовывать - сказать "не наше дело".

    А причина одна - браузероделы - не важно, хром они делают или мозиллу - очень стараются перетащить весь софт под себя, сделать вещь в себе, не взаимодействующую с остальным десктопом. Фактически - отобрать пользователя контроль над его системой.

     
     
  • 6.51, Lain_13 (ok), 16:38, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С ASM js несколько мутно, согласен По крайней мере я пока не нашёл на чём именн... большой текст свёрнут, показать
     
     
  • 7.52, Crazy Alex (ok), 19:51, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    У asm.js, насколько я понимаю, большие проблемы с управлением памятью. При этом во всех "больших" играх далеко не зря оно по сей день ручное. А статичекая компиляция никак не мешает программе  нагенерировать миллион объектов, а рантайму - вовремя их не собрать.

    А что до "ронять" - с подходом asm.js, думаю, будет куда больше риска, чем, скажем, с дубовым NaCl. Ну и да, песочницы нынче вполне хороши - и в отличие от всего браузера видеоплеер в песочницу засунуть вполне реально, к примеру, доступ к FS на запись ему, в общем-то, не нужен.

    Что до стандарта сжатия - меня вообще срайне смущает идея, что поток будет идти невесть в чем. С плеером есть понятная распространенная реализация декодера, заведомо есть всякие фильтры, возможности отдать на аппаратное декодирование и тому подобное. А когда каждый сайт может безнаказанно гнать ни с чем не совместимый поток - как-то это дурно пахнет.

    Насчет изменения плагина под свои нужды - не понял. Там, по идее, должен определяться простейший API, в котором указывается, куда плеер должен встроиться и в каких размерах, откуда брать источник ну и управление, сколько там его есть. Плагин это транислирует в команды того плеера, который найден в системе. На винде это вообще один вариант (WMP есть всегда и встраиваться умеет отлично), на линуксе будет пара вариантов, идущих из коробки. Плюс любители экзотики смогут сравнительно легко добавить поддержку своего любимого плеера - это да, ставить отдельно надо будет - как и сам плеер, впрочем.

    А вот ставить себе в систему неведомый код как раз и не хочу - хоть бинарный,хоть нет. Поэтому, в частности, у меня поддержки DRM просто не будет (или будет "поддержка", позволяющая рипать контент). На винде DRM в систему встроен - но там пользователь ССЗБ. Кому на линуксе сильно нужен DRM-контент - пусть ставит что хочет, в любом случае если есть DRM то система уже недоверенная. Но это ж точка зрения защиты пользователя, а мозилловцы давным-давно защищают кого угодно только не его.

     
     
  • 8.53, Lain_13 (ok), 20:54, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На счёт памяти таки ничего не могу сказать, может и так На счёт того, что проще... текст свёрнут, показать
     
  • 4.37, jOKer (ok), 05:13, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >А то подобрать отдельный примеры, хорошо подающиеся заданному набору оптимизаций - дело нехитрое.

    Да, вы правы.

    Но заглянем чуть-чуть дальше в будущее и увидим открытые программы, которые даже можно эксплуатировать у себя дома, без нагрузки, и которые глючат и вываливаются под нагрузкой потому что их не обработали фирменным оптимизатором. Само-собой что код оптимизатора - тайна за семью печатями. При таких раскладах, навыки написания программ особого значения уже не имеют - в счет идет только владение оптимизатором, который стоит бешеных денег... если вообще будет продаваться.

    Вас устраивает такое будущее? Меня вот что-то не очень....(((

     
     
  • 5.47, Crazy Alex (??), 13:22, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, это какая-то фантастика. А вот то, что софт уползает в веб и, соответственно, пользователь лишается контроля над ним - это уже грустно. Грубо говоря, проблема не в том, что этот ORBX на какой-то дряни писан, а то, что эта дрянь грузится с сервера и без специальных усилий пользователя только сервер решает, что и как эта штука будет делать.
     
     
  • 6.63, freehck (ok), 09:40, 09/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    То, что софт уползает в веб - только свидетельство того, как много появилось в наше время низкокачественных программистов, занимающихся повторением в вебе уже существующих программ.

    И сервер не решает, "что и как эта штука будет делать". Если Вы захотите выдрать видео с сайта - вы это сделаете. Музыку - пожалуйста, тот же трюк. Книги - фигня вопрос.

    А вот что действительно удивляет, так это Ваше отношение к "фантастике". Вы думаете, что если что-то описано в книге под заголовком "фантастике", то этого никогда не будет? Зря Вы так. Вот парень выше всего лишь развивал тему засилья DRM, которую Столлман описал еще 15 лет назад в рассказе "The Right to Read".

    И если бы люди несколько десятилетий назад не спохватились бы, и не организовали оборонительный фронт в виде FSF, то так бы сейчас все и было, как Столлман описал. В этом у меня сомнений нет.

     
  • 2.28, energia (ok), 01:53, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Они этот бред просто ведрами откуда-то черпают
     
  • 2.41, Аноним (-), 09:26, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > JavaScript и производительность — два понятия которые у меня не стыкуются в
    > голове…

    вылезай из пещеры, сейчас уже JIT во всех движках. Производительность на уровне Java, и всего в 2..3 раза ниже С...

     
     
  • 3.65, Аноним (-), 00:19, 12/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Производительность на уровне Java

    А, ну тогда всё ок )))))))))

     
  • 2.57, винке (?), 23:18, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > JavaScript и производительность — два понятия которые у меня не стыкуются в
    > голове…

    добро пожаловать в 21,2 век

     

  • 1.15, Аноним (-), 00:06, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    папку мозиллы indexedDB забил sqlite файлом 103MB O_o
     
  • 1.16, FSA (??), 00:21, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Новый проект подчёркивает возведение JavaScript на новый уровень развития и знаменует стирание границ между Web и нативными приложениями.

    У меня разрыв шаблона. Как код, который требует какой-то другой код для своей трактовки может работать также, как нативный код, который имеет возможность быть оптимизирован в местах требующих максимальной производительности путём вставок хоть до уровня ассемблера (машинного кода)?

     
     
  • 2.20, ВовкаОсиист (ok), 00:41, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    У них свои понятия о производительности. То, что там у них 30% проца отъело, нативно будет есть 1-5%.
     
  • 2.22, exist (ok), 01:02, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Рекомендую изучить, что такое "адаптивная JIT-компилиция". Для интерпретируемых языков ассемблер конечно не достигаем по производительности, но к скомпилированному из высокоуровневых языков обычному коду приближается очень близко (см. тесты с LLJS и Asm.js).

    p.s. адаптивный JIT-компилятор умеет находить проблемные участки кода при выполнении байткода и перекомпилировать этот участок с учетом получаемых результатов. А вот "нативный" код так не умеет.

     
     
  • 3.26, Crazy Alex (ok), 01:49, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Угу. А ещё он умеет сожрать кучу памяти на вспомогательные данные, статистику выполнения и т.д., а ресурсы процессора - на сбор этой статистики и многократные перекомпиляции. Знаем, проходили. Крутящийся много часов, а то и дней на сервере в одиночку Java-процесс может себе такое позволить, а штуковина, которая грузится на минуту - как-то не очень. Особенно с нынешней модой на планшеты, смартфоны и ноутбуки.
     
  • 3.58, винке (?), 23:19, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Рекомендую изучить, что такое "адаптивная JIT-компилиция". Для интерпретируемых языков
    > ассемблер конечно не достигаем по производительности, но к скомпилированному из высокоуровневых
    > языков обычному коду приближается очень близко (см. тесты с LLJS и
    > Asm.js).

    даже обходит в некоторых местах

     

  • 1.18, IdeaFix (?), 00:32, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Помнится, одна конторка уже хотела запихать весь-весь юзерский софт в вордовский документ.... оле, дде, дна... и где оно всё?
     
     
  • 2.27, Crazy Alex (ok), 01:51, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, идея-то хороша была, а вот реализация... как обычно у MS. Но те не схоиди с ума и просто оставляли указание на формат, который обрабатывался кем угодно, кто это умеет. А у производителей браузеров какая-то навязчивость на тему "всё своё ношу с собой". При том, что это "своё" по понятным причинам убого.
     

  • 1.23, Аноним (-), 01:35, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пришла смерть адоб флэшу!
     
     
  • 2.29, Аноним (-), 01:56, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Адоб сворачивает поддержку настольных продуктов и уходит в облака с HTML5 браузером :)
     

  • 1.30, Аноним (-), 02:35, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Два раза смерть!
     
  • 1.31, Аноним (-), 02:54, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я же говорю - эти уроды, скоро, сделают поганый JS основным языком написания прикладных приложений, а потом, ещё, всё это дело в браузеры попытаются запихнуть.
     
     
  • 2.33, Lain_13 (ok), 03:24, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только asm.js этому никак не способствует. Скорее, даже, наоборот — сводит его до уровня вспомогательной прокладки.
     
     
  • 3.35, rshadow (ok), 04:25, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Самое удивительное во всем этом почему за столько лет в браузеры не запихали стандартные скриптовые яп (питон, пхп, перл, руби ...) хотя бы в виде плагинов, предлагаемых для скачки при нахождении <script language="phyton">...

    И у нормальных языков и так производительность хуже нативной в 2-3 раза, так же как и у этого проекта. ТОлько танцы с бубном не нужны, и каждый программирует на любимом языке.

     
     
  • 4.36, angra (ok), 05:00, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то в прошлом в браузерах уже были VBScript и PerlScript, но особой популярности у разработчиков не сыскали и остался только JavaScript.
     
  • 4.40, Аноним (-), 09:24, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    пыхпых в браузере ? омг... js в 100500 раз лучше...
     
  • 2.34, Xasd (ok), 04:16, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    '
     
  • 2.38, web (?), 06:48, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во всём виноват Брендан Айх(Mozilla CTO), ссудя по его твиттеру неимоверно горд созданием JS, и тем что он один из главных персонажей в вёб, хотя и с интересом почитывает о разработках конкурентов в Google.

    Тем не менее в мозиле работает значительное количество видных Python-разработчиков, и их ряды пополняются, а так же выпускаются в опенсорс утилиты на отличных от JS языках, "Go" и т.п

     
  • 2.59, винке (?), 23:21, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я же говорю - эти уроды, скоро, сделают поганый JS основным языком
    > написания прикладных приложений, а потом, ещё, всё это дело в браузеры
    > попытаются запихнуть.

    с наступающим вас 2012, друг мой живущий в обратном порядке

     

  • 1.44, Аноним (-), 12:15, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот скоро-скоро и WebGL со всёми дровами будет работать, и о да!
     
     
  • 2.50, Аноним (-), 16:02, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот скоро-скоро и WebGL со всёми дровами будет работать, и о да!

    Ну когда уже, блин!

     

  • 1.45, Аноним (-), 12:34, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В частности, продемонстрированы средства для запуска в облачных окружениях ресурсоёмких 3D-пакетов и игр с трансляцией вывода в окно браузера, запущенного на маломощном нетбуке или планшете.

    ... alienware :D

     
     
  • 2.48, exist (ok), 14:54, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На alienware крутили нативное приложение, а ORBX.js работал на нетбуке с облаком. Не нужно передергивать.
     

  • 1.49, Аноним (-), 15:53, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Minecraft если тормозит у меня, значит мой друг может на своём новом компе запустить два минекрафта, первым будет сам управлять, а второй расшарит для меня.
    А кукую программу нужно использовать для Windows?
     
  • 1.54, Аноним (-), 23:10, 08/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Заинтересовало имя компании. Если включить в самую середину маленькую букву s, то не получится ли то, о чем мы все вместе думаем?
     
  • 1.64, неАноним (??), 10:44, 09/05/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хотел посмотреть на ORBX.js но не нашел где его качнуть. Или я чего не так понял. Пинайте меня пока я не начну кашлять темными сгустками крови.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру