| 1.1, анонимм (?), 18:46, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
звоните в микрософт, пусть срочно патентуют "ехе" в конце имени файла. этак можно будет ещё по паре баксов сверху наваривать
| | |
| 1.2, ENik (?), 18:48, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Одни переходят на HTML5, другие делают Native Client для браузера. Интересно чем это закончится.
| | |
| |
| 2.11, Crazy Alex (ok), 20:55, 23/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Единство и борьба противоположностей во всей красе :-) Только вот мало надежды, что даже Mozilla это поддержит, а об остальных и говорить нечего.
| | |
| |
| 3.30, другой аноним (?), 10:16, 24/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
зачем поддержка от мозиллы - сами для нее плагин пишут:
"Изначально Native Client был интегрирован в Chrome начиная с выпуска 10 (активирован по умолчанию в Chrome 14) и дополнительно поставлялся в виде браузерного плагина для Firefox, Safari и Opera. "
| | |
|
| |
| 3.21, Crazy Alex (ok), 22:30, 23/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Для веб-приложений - ох, не факт, если взлетит. Всё же HTML, даже пятый, для формочек подходит очень условно, там вечно в вёрстке куча странностей. Не удивлюсь совершенно, если (при условии повсеместного распространения NaCl) вместо приложений на HTML5 будет какой-нибудь QT/NaCl/Canvas. Или вообще нативная отрисовка через OpenGL ES в выделенном буфере примерно как у флеша.
| | |
| |
| 4.27, Xasd (ok), 00:43, 24/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Всё же HTML, даже пятый, для формочек подходит очень условно, там вечно в вёрстке куча странностей
это временная проблема. потомучто:
1. всё больше и больше мир технологий плавно переходит к тому что вёрстка должна выполнятся -- именно на стороне клиента а не сервера. и HTML5 не протеворечит этой тенденции.
и это справедливо! сервер должен выдавать только статические файлы (html,js,css,png,xml) и чистые данные (json), а не заниматься HTML-вёрсткой.
2. нет нужды дожидаться когда в HTML5 появтся очередные виды Layout . уже сейчас можно можно создавать/использовать Javascript-Фрэймворки, которые будут выполнять реализации различных Layout.
> Не удивлюсь совершенно, если (при условии повсеместного распространения NaCl) вместо приложений на HTML5 будет какой-нибудь QT/NaCl/Canvas. Или вообще нативная отрисовка через OpenGL ES в выделенном буфере примерно как у флеша.
тоесть всё что перечисленно в пунктах выше [1]и[2] -- реализовывается более дешёвыми человекочасами, чем переход к "QT/NaCl/Canvas" [хотя это и ведь тоже частный случай вёрстки на стороне клиента:)] :)
| | |
| |
| 5.34, Crazy Alex (ok), 15:49, 25/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Ок. Как на HTML5 можно сделать, чтобы некий элемент формы забрал всё оставшееся свободное место по X или по Y?
Джаваскрит-фреймворки - это отдельная песня. Оверхед там просто феерический - помнится, сенча успешно тормозила на своих же демках. И это логично - когда вместопростейших операций по отрисовке надо поднять кучу DOM-объектов и задать довольно сложное поведение по их прееключению/смене стиля - откуда здесь скорость?
Другое дело, если б разработчики HTML5 дали какую-то низкоуровневую механику для построения контролов - хотя бы стандартизировали бы доступ к Shadow DOM, плюс создали хоть один лайаут, имеющий понятие free space у контейнера, и дающий соответствующие средства маштабирования его детей - тогда может и вышло бы что. Неужели так трудно с Gtk или виндового декларативного языка содрать (забыл, как там его)?
А пока, разумеется, форма на Qt делается много быстрее (хотя бы за счёт того, что там костыли из стилей рисовать не надо). Портирование кутей на канвас - да, займёт время. Думаю, что довольно небольшое - там чуть ли не линейный маппинг одних примитивов в другие. Кроме того, - процесс разработки десктопных приложений наработан за много лет, для вебовских и близко ничего подобного пока нет.
Пока что HTML5 - это не дешевый, а просто единственный способ разработки приложений, которые не надо было бы устанавливать, мучаться с апдейтом и при этом чтобы они запускались более-менее везде (тот же флеш на айпаде не взлетит, как известно, джавы - тем более много где нет). Здесь вообще не о скорости разработки речь, а о том, что альтернатив нет.
| | |
|
|
|
|
| |
| 2.6, мшефд (?), 19:52, 23/01/2013 [^] [^^] [^^^] [ответить]
| +33 +/– |
>NaCl
>прочичал как натрий хлор
Так в этом-то вся и соль. :)
| | |
|
| |
| 2.7, ананим (?), 19:59, 23/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нет.
При чём 2-а раза — сабж продолжает выполнятся в песочнице и не имеет доступа к ресурсам и библам целевой системы, апплеты же ограничены искус..но, но фактически ничем не отличаются от клиентского ПО на жабе.
Зыж
Проще понять сабж, представив как ПО выполняющееся в черуте/контейнере/виртуалке(с_натяжкой).
| | |
| 2.8, Имя (?), 20:08, 23/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
В данный момент это машинный код, выполняемый в песочнице, который безопаснее чем байт-код
| | |
|
| 1.9, lucentcode (ok), 20:32, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Использование LLVM - это круто. Насчёт языков программирования, так можно будет задействовать и Python, и Lua. Это не проблема. Мне интересно, есть ли возможности писать OpenGL приложения на NaCl. По идее - можно. И ещё. Будет ли добавлена возможность дёргать вызовы системных либ за пределами песочницы(естественно только для доверенных приложений).
| | |
| 1.10, Crazy Alex (ok), 20:54, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Эх, выстрелила бы эта штука, можно было бы о JS забыть как о страшном сне для всего мало-мальски серьёзного. Правда, на что менять - не совсем понятно, но это уже дело наживное.
| | |
| |
| 2.12, Имя (?), 21:25, 23/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Эм, ну не получится.
Отображение через прямоугольник, а вот доступ к файлам и ещё кое чему через мост на js.
| | |
| |
| 3.20, Crazy Alex (ok), 22:26, 23/01/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну, мост - это не страшно. Страшно, когда на JS пишется развесистая логика, а в нём ни типизации, ни контрактов, ни интерфейсов - ничего, сплошной duck typing.
| | |
|
|
| 1.14, nal (??), 21:55, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Если этот NaCl такой изумительный инструмент (нативно в Chrome, в виде плагинов для остальных браузеров), то почему на нем не запилят, например, воспроизведение видео в web? Зачем-то используют Адоб Флэш...
| | |
| |
| 2.16, Усатый ниндзь (?), 21:57, 23/01/2013 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> почему на нем не запилят, например, воспроизведение видео в web?
потому что оно и так нативно запилено через тэг video
> Зачем-то используют Адоб Флэш...
извращенцы
| | |
|
| 1.19, Аноним (-), 22:23, 23/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Сплошные приветы из 90-х на этой неделе. Facebook поиском на естественном человеческом языке озаботился, Google Java-апплеты реанимировать хочет...
| | |
| |
| 2.36, Гость (?), 14:53, 30/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Был билд, пробовал его 2 года назад. С трудом но кое-что работало.
| | |
|
| 1.26, Xasd (ok), 00:19, 24/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Кроме того, в течение 2013 года планируется выпустить Native Client нового поколения, который будет поставляться под именем Portable Native Client...
всё это имеет определённую степень замечательности -- ТОЛЬКО лишь в том случае если разработчики web-приложений НЕ будут использовать NaCL (отличный от PNaCL).
тобишь если Google выпустит PNaCL но НЕ закроет проект старого NaCL -- то это будет эпичный FAIL
| | |
| 1.29, ДяДя (?), 10:09, 24/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Portable Native Client - вот это правильно! Я прям угадал, что так будет.
Надо было Ведроид на подобной технологии делать, а не Далвик мутить.
Все серьёзные приложения под Ведроид по факту нативный код юзают.
| | |
|
