Pull to refresh

Comments 60

Ну невозможно на HTML5 сделать большое сложное приложение, нужны штуки типа Qt, которые позволяют оставлять общим ядро и делать интерфейс под каждый девайс.
Ну невозможно на HTML5 сделать большое сложное приложение
Почему?
Потому что программы не ограничиваются формочками для баз данных.
Он про то и говорит, что программы должны быть просто обертками. И продвигает в качестве средства написания этих оберток html/css/js, а в качестве протокола HTTP/REST.
Эх, лучше бы поспособствовал наличию сети на каждой сопке, и в каждом лифте.
p.s: это я так мечтаю…
Не везде есть интернет и не везде он настолько хорош, что бы отвечать требованиям к скорости приложений на сегодншний день.
Проблема, что интернет не везде есть, а еще проблема вторая, что постоянный доступ в сеть очень быстро сажает аккумулятор, сажает быстрее, чем расчет математики на самом устройстве.
Отвечаю сразу и комментаторам выше:

Html5 и js это языки на которых можно писать пользовательские интерфейсы. Как и на любом другом, но html5 и js есть на любом устройстве. Таким образом, одну и туже программу можно запустить везде, а не писать отдельные версии для windows/iOS/Android/KDE/GTK etc.

Естественно, код приложения можно сохранить локально, и обращаться к серверу когда нужно, когда нужно.
Напишите мне простейший гитарный тюнер на html5 я посмеюсь.
Вы не поверите

github.com/corbanbrook/dsp.js/

Js ничем не хуже и не лучше других интерпретируемых языков. А если OS предоставит API к железному ускорению, то программа на js будет ничем не медленнее чем на C.
Вы точно понимаете разницу интерпретируемых и компилируемых приложений? И к слову — все языки чем-то лучше, чем-то хуже. Я знаю человека, который плюеется от Ruby и тащится по JS, а я плююсь от JS и тащусь по Ruby. Кстати на Ruby тоже можно писать под любую платформу — хоть Android, хоть iOS и даже прямо сейчас, просто берете SDK для Ruby и пишите. Но я как-то плохо вижу его перспективы там, хотя чем черт…
И как у него с задержками, как у него с точностью, насколько оно грузит процессор, насколько оно вообще способно в реальном времени работать?
Хочу бенчмарки и графики.
Особенно на телефоне. Т.к. комп не всегда рядом.
Во-первых, js, конечно же, не будет таким же быстрым как с. Во-вторых, это неважно, потому что проблема не в нём, а в HTML и том, как он рендерится — медленно, коряво и несовместимо.

Есть обёртки которые позволяют писать приложения для Android и iOS на HTML5+js, но все такие приложения выглядят и работают довольно убого. В настоящее время невозможно даже сделать плавную прокрутку достаточно длинного списка — сравните мобильный сайт твиттера и его же нативное приложение.
Видимо в командах GNOME, KDE, FirefoxOS, WebOS, Win8 сидят полные придурки:

GNOME:
treitter.livejournal.com/14871.html
> Our decision is to support JavaScript as the first class language for GNOME application development. This means:

>There's a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.

KDE:
www.opennet.ru/opennews/art.shtml?num=36039
C точки зрения производительности, эффекты на JavaScript ничем не отличаются от эффектов на C++. Система наложения эффектов в KWin разделена на две стадии: реагирование на изменение в оконном менеджере (например, закрытие окна) и рендеринг. Скриптовый API взаимодействует только с оконным менеджером и не касается отрисовки, все операции рендеринга как и раньше производятся низкоуровневыми подпрограммами на C++;

Win8:
habrahabr.ru/post/131500/
Спасибо, что подкрепили мой комментарий
Всё равно для каждой платформы интерфей придётся писать заново — у каждой свои гайдлайны, а пользоваться приложением, которое выглядит и ведёт себя непривычно не удобно — будут проблемы.
UFO just landed and posted this here
например, с помощью PhoneGap, но если вам действительно нужно приложение, то советую скорее смотреть в сторону Titanium
Путь он напишет на html5 библиотеку типа ffmpeg. Посмотрим как оно будет работать.
Декодеры mp3/flac на js уже работают. Дальше дело только за оптимизацией. Со временем и hd-видео взлетит.
Вы про троллейбус и буханку хлеба видели кратинку?
Вопрос — зачем?!
Всё равно нативная реализация будет быстрее.
Вон как народ выл, когда на тегре видео тормозило из за того что там NEONовские инструкции отсутствовали.
Тут, наверное, должна быть картинка по троллейбус.

Он говорит об разделении представления, бизнес-логики и API. И соверженно правильно говорит. ffmpeg это библиотека, к которой предоставлен интерфейс со стороны браузера, поэтому можно смотреть youtube без флеша.
Вы это проверяли в браузере?
Может быть, что это серверный JS?
Всё конечно не проверял, но многие видел. Да хотя бы Flash, html2canvas, pdf.js, psd.js, FabricJS, JSZip.
Лично Я проверял — PDF, PSD и немного Java (он нестабилен — ИМХО).
В случае с PDF есть проблемы со шрифтами и текстурами.
У PSD не все цветовые гаммы и эффекты работают.
Но нужно учесть что все это написано на чистом JavaScript — и это достойно уважения.
Оно тормозит… кушает мою оперативку. О каком мобильном устройстве может идти речь? Еле тянут топовые модели, а что уж говорить о бюджете.
А Javascript.js есть?
Есть только Esprima.js и acorn.js.
>«Нет URLа сверху, и я не могу сделать закладку. Я не могут твитнуть. Не могу поставить «Нравится». И не могу поставить «Не нравится». Оно не является частью дискурса», — отметил Бернерс-Ли.

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

А, погодите-ка. Есть же +1 в гуглплее.
Просто идея всяких лайков и прочей херни, разбивается об человеческий фактор. Ибо любому, у кого есть хоть немного мозгов понятно, что эти рейтинги будут накручивать как только могут, и им все равно верить нельзя ни на грош.
С одной стороны да, я с Вами согласен.
С другой стороны — лайки страничек/статей в моих друзей в фейсбуке/вконтакте с кратким описанием «что там на страничке» меня заинтересовывают в несколько раз чаще, чем топ приложений апстора/маркетплейса/гугльплея, который лично мне безразличен в силу того, что комплект софта, необходимый мне по жизни/либо в бизнес задачах в любом компьютере — будь то телефон или десктоп/сервер, меняется после установки и запуска устройства в эксплуатацию крайне редко, и то, по большей частью только установка новый версий.
URL нужен для стандартизации доступа к ресурсам. У вас есть текстовый адрес одного формата для статей, рисунков, видео, документов. В случае приложения у вас этого нет. Причем он говорит не о том, что файловый менеджер нужно писать на js, а о глобальной тенденции вместо сайта делать нэйтивный интерфейс к апи, то есть если это новостной сайт, то у него вместо сайта будет приложение которое тянет статьи все-равно с удаленного сервера.
Вот именно URL нужен для ресурсов, и если у вас контентный сайт, то для него лучше хорошая мобильная версия, а не приложение. А если это сервис, то нужно приложение. Именно поэтому привет автора дурацкий.
Бернерс-Ли также выступил против тренда в написании нативного приложения для каждой платформы – одно для iPhone и iPad, другое для Android и так далее. Это дублирование усилий и «скучно для разработчиков» писать и тестировать одинаковый код на каждом устройстве, сказал он.

Это хорошо, да. Но, лишь с одной стороны. Ибо с другой, возможность разработки приложения так, чтобы сразу для разных систем, означает ту или иную схожесть этих систем. Как минимум SDK, а то и совместимость глубже. А далее можно будет прийти к тому, что не будет конкуренции, монополизация и т.д. Этого никогда не будет.
UFO just landed and posted this here
BTW: Господв, подскажите, почему не работает цитирование. Не смотря на исользование тэга blockquote.
Теги не работают с кармой ниже нуля.
UFO just landed and posted this here
Мне тоже часто кажется, что нативные приложения для каждой платформы — это странно, но что-то не видно html5 приложений, похожих по удобству и функционалу на нативные клиенты.
UFO just landed and posted this here
ИМХО тогда лучший подход из тех, что я видел, это QML, вот это удобный язык описания интерфейса, он удобнее, чем HTML5.
Лайка, ставить рейтиниги, шарить и т.п. уже давно делают и в нативных приложениях, и без html5.
По крайне мере там, где это востребовано — например в играх.
А проблему рута в комментах как-то обошли. А ведь это болезнь которой сейчас болеет 99.9% планшетов и телефонов. А в этом случае может быть и есть защита от нежелательных и вредных приложений, только вот нежелательность и вредность определяет производитель (телефона или софта) а не пользователь. Например Moon+ Reader очень нежелательный и вредный.
По заголовку зашел ознакомиться с мнением уважаемого человека о root правах. Я полностью согласен что у пользователя должна быть документированная возможность ими пользоваться.
Однако в статье про них ни слова больше чем в шапке…
Пора уже внедрять аббревиатуру ЗДПВ — по аналогии с КДПВ?
Когда в HTML появятся нормальные инструменты для работы с лейаутами, тогда и поговорим. В данный момент сделать вменяемый интерфейс без тонн JS-хаков в принципе невозможно. Где банальный RelativeLayout, как в Android? Как делать гриды без оверхеда таблиц?

Тим конечно хороший дядька, но HTML5 для написания софта — отказать!
Сравнил язык с SDK. JS — это язык, а Android SDK — набор библиотек и API, в Java точно так же без «тонны» хаков ты не напишешь приложение.
Но точно так же и у JS есть библиотеки, типа Ext.JS, Sencha Touch, etc…

Я уже писал простенькие апликухи под заказ на Phonegap -> остался доволен. Phonegap далеко не панацея, все зависит от того, что приложение должно делать, потому что HTML5 по производительности еще далеко до Native — вот это куда большая проблема, чем надуманное отсутствие интсрументов.

Для любителей JS — есть Titanium(SDK на JS, но не HTML5).
Язык тут ни при чём. Тим ратует за то, чтобы писать софт используя открытые веб-технологии. Вот только они не готовы по многим пунктам, в том числе они абсолютно непригодны для создания сложных интерфейсов. API ни разу не хаки. Попробую обьяснить.

Штука в том, что «кубики» из которых вы составляете UI, во-первых, написаны на нативном уровне (C/C++), во-вторых, используют аппаратное ускорение для своей отрисовки. Всё это означает, что кубики эти работают ОЧЕНЬ БЫСТРО и эффективно. Для браузера кубики UI — это HTML+CSS. Такие вещи, как скроллинг аппаратно ускорены, работа со слоями (какие блоки как накладываются, где там прозрачности и т.д.) написаны на нативном уровне. Всякие спец-эффекты тоже сегодня в браузерах аппаратно ускорены.

И самое важное то, что позиционирование блоков и их взаимодействие (паддинги там, марджины, флоаты, вот это всё) тоже обрабатывается нативным кодом и чертовски быстро. Тоже самое и во всяких андроидах — кубики написаны нативно и максимально сильно используется аппаратное ускорение всего, что только возможно.

Так вот, реализация тех же лейаутов на JS — это провал. Вы можете посмотреть любые демки так называемых «browser os» — они все чертовски тормозят, особенно, когда обьектов много.

Именно поэтому хэтээмэлу — отказать. До тех пор, пока не будут готовы кубики для построения полноценных UI. Без хаков, затычек, кривых флоатов и прочего бреда. У кубика не может быть стопицот вариантов display, у кубика всегда один display, зато есть visibility. Это всё — ключевые моменты.
То что технология — сырая, это бесспорно, но он лишь говорит, что это направление нужно разивать. ИМХО, нельзя не согласится.
Простите, А только мне не понятно, какое отношение отсутствие рута имеет к практике написания приложений на HTML5?
Да-да, дайте мне RAW конвертер на HTML5.

Я серьёзно.

Нативные не быстрее, потому что их на множество систем просто нет.
> Нет URLа сверху, и я не могу сделать закладку.
Закладку можно (и нужно) делать не кнопкой, имеющую только эту функцию, а через меню, в котором прячутся несколько команд. Место надо экономить, а не делать раздутый интерфейс, а потом — ОПА, мама, у меня приложение не влезло — увеличивать разрешение и диагональ экрана.

Про URL сверху даже не смешно: у половины веб-приложений URL-ы динамические настолько, что тот же URL второй раз просто не вернет в точно то же место приложения, у остальных ситуация лучше, но контекст работы меняется, и URL все равно бессмыслен (пример — в URL имеем ссылку на конкретное почтовое сообщение; письмо удалили/переместили — URL более недоступен, юзеры вовсе не в восторге).

> Я не могу твитнуть. Не могу поставить «Нравится». И не могу поставить «Не нравится».

У кого жизнь — Твиттер и лайки, тому, конечно, проблема. Отлично, сделаем лайк странице поиска писем в веб-интерфейсе почтового ящика или твитнем сообщение из частной jabber-переписки, нам не жалко, мы же горим желанием ПОДЕЛИТЬСЯ.

Помните, "… наш-то, молодец, говорят, блох завел в свитере" — т.е. у человека просто есть время, и он нашел, на что его потратить :)

> Оно не является частью дискурса

Ага. Многое не является частью обсуждения — многое, что в жизни занятого делом человека имеет место. С этим, конечно, надо что-то делать.

Так рассуждая, могу себе представить, наконец, твит от сотрудника бухгалтерии, с ее мнением, ссылкой на 1с-ку у нее на экране, где видна моя з/п, и приглашением к диспуту :)
Sign up to leave a comment.