Что мешает приложениям HTML5 и JS работать так же хорошо, как нативные приложения?

9

Из того, что я понимаю,

  • HTML - это язык разметки, равно как и содержимое XAML, XIB и всего, что использует Android, и других собственных сред разработки пользовательского интерфейса.
  • JavaScript - это язык программирования, используемый вместе с ним для обработки сценариев на стороне клиента, которые будут включать такие вещи, как обработка событий, проверки на стороне клиента и все остальное, что C #, Java, Objective-C или C ++ делают в различных таких средах.
  • Существуют шаблоны MVC / MVVM, доступные в каркасах форм, таких как Sencha, Angular и т. Д.
  • У нас есть localStorage в виде хранилища sqlite и key-value, как и у других фреймворков, и у вас есть спецификация API почти для всего, что в нем отсутствует.
  • Всякий раз, когда собственные структуры пользовательского интерфейса должны отображать пользовательский интерфейс, он должен анализировать аналогичную разметку и отображать пользовательский интерфейс.

Разбивка вопроса

  • Что мешает сделать то же самое в HTML и самом JS?
  • Вместо того, чтобы иметь веб-элемент управления или браузер в качестве промежуточного слоя, почему нельзя заставить HTML (наряду с CSS) и JS работать одинаково?
  • Даже если есть слой, то же самое можно сказать о среде выполнения .net и JVM в других случаях, когда C ++, C не используются.
  • Итак, давайте возьмем случай Android, как Dalvik, почему Cannot Chromium может быть другим вариантом (наряду с dalvik и NDK), где HTML делает то, что делает разметка Android, и JavaScript используется для того, что делает Java?

Вопрос в том,

Даже если текущие реализации не так хороши, но теоретически возможно ли заставить приложения на основе HTML5 работать как другие нативные приложения, особенно на мобильных устройствах?

Амог Талпалликар
источник
1
Пожалуйста, измените рефакторинг, чтобы уточнить, с каких утверждений вы исходите, и каков реальный вопрос.
funkybro
Не могли бы вы уточнить, что вы подразумеваете под «Что мешает делать то же самое в HTML и самом JS?» Я не понимаю, что вы подразумеваете под «тем же самым» - вы уже сделали четыре заявления ранее, и я не уверен, на что вы ссылаетесь в этом вопросе.
Апсиллеры
Если у меня есть собственная платформа разработки, которая использует HTML в качестве разметки вместо чего-то нового. и использует JS в качестве языка, производительность будет лучше? Google в этом I / O сказал, что они практичны и используют Android на телефоне, а не Chrome OS. Значит ли это, что ОС FF не является практической концепцией? Возможно ли, чтобы приложения FFOS работали так же хорошо, как приложения для Android на соответствующих платформах, если следовать всем лучшим практикам?
Амог Талпалликар
Посмотрите на приложения Windows Metro. Это нативные приложения, которые используют HTML для дизайна GUI и Javascript для логики, стоящей за ним.
Филипп
Производительность HTML / JS, как правило, более чем достаточна для пользовательского интерфейса, который отображает информацию и на основе действий пользователя отправляет запросы на внешний сервер. Первоначально он не был построен для чего-то большего, но теперь он впечатляюще более способный. Тем не менее, в ситуациях, связанных с более прямым доступом к устройству, взаимодействием с собственным кодом или взаимодействием с операционной системой (например, уведомлениями), все еще нет хорошего способа использовать веб-технологии общего назначения для этого.
Katana314

Ответы:

11

Создатель плакатов для приложений HTML5, LinkedIn вышел в свет в начале 2013 года. В интервью VentureBeat они объясняют, почему.

Я думаю, что эта часть наиболее актуальна для вашего вопроса:

Прасад сказал, что проблемы с производительностью не вызывают сбои или замедляют работу приложения. То, что он сказал, показывает, что у HTML5 для мобильного Интернета все еще есть светлое будущее - но только если разработчики захотят создать инструменты для его поддержки.

...

Есть несколько вещей, которые критически отсутствуют. Одним из них является поддержка инструментов - наличие отладчика, который действительно работает, инструментов производительности, которые сообщают вам, где заканчивается память. Если вы посмотрите на Android и iOS, есть две очень большие корпорации, которые сосредоточены на создании инструментов, которые дают много подробной информации, когда что-то идет не так в работе. Что касается мобильных веб-приложений, заставить эти инструменты рабочего стола работать на мобильных устройствах действительно сложно. Второй большой кусок, с которым мы боремся, это работоспособность, информация о диагностике во время выполнения. Даже сейчас, когда мы создаем HTML5, мы создаем его как приложение на стороне клиента. Это скорее клиент-серверная архитектура. ... Работоспособность этого, дающая нам информацию, когда мы рассылаем ее большому количеству пользователей, также не так много хороших инструментов для поддержки этого.

[Прасад также отметил, что инструменты dev и ops для быстрого решения проблем «не существуют».]

Поскольку этих двух вещей не существует, люди возвращаются к родным. Дело не в том, что HTML5 не готов; это то, что экосистема не поддерживает это. ... Есть инструменты, но они в начале. Люди просто выясняют основы.

Vartec
источник
Я не понимаю У нас есть очень крупные корпорации: Google, Microsoft, Apple, ориентированные на поддержку Chrome, Safari и IE. У нас есть Mozilla, преданная Firefox. У нас есть Chrome Dev Tools, веб-инспектор, Firebug. А Прасад говорит, что нет инструментов?
niutech
@niutech: допустим, вам нужен такой инструмент, как Valgrind для приложения HTML5. Там не так много.
vartec
5

Отсутствие стандартной библиотеки Javascript - ужасный ингибитор. Существуют отличные фреймворки, такие как jQuery, Dojo, YUI и многие другие, но все они сосредоточены исключительно на уровне представления и XHR.

Хотите ли вы настраиваемое ведение журнала, криптографические инструменты, графовые алгоритмы, генераторы UUID, карты, наборы, деревья, шаблоны, управление зависимостями, манипулирование датами, локализация / интернационализация, операции с матрицами, внедрение зависимостей, модульные тесты, уменьшение карт, обработка XML? Тривиально для языков JVM или .NET - в Javascript вам часто приходится использовать собственную реализацию.

Марос Урбанец
источник
Добавьте отчет к этому.
Алан Б
ECMAScript 6 добавляет большинство этих функций. Google Closure Library - еще одно решение.
niutech
Angular обеспечивает хороший декларативный способ.
Амог Талпалликар
2

Одна из причин, почему Javascript работает медленно, это полное отсутствие безопасности типов. Любая переменная может быть любого типа в любое время. Кроме того, большинство операций допустимы для множества разных типов, но имеют разную семантику . Простой термин

a += b;

не так тривиально для интерпретатора, потому что aи bмогут быть числа или строки. Когда оба числа, это арифметическое дополнение. Когда оба являются строковыми, это конкатенация строк. Когда один является строкой, а другой - числом, число должно быть отформатировано перед выполнением конкатенации строк. Это совершенно разные операции, которые требуют разной интерпретации аргументов.

В зависимости от типов aи b, тип aтеперь может быть целым, двойным или строковым, независимо от того, какой это был тип.

Поскольку переменные в JS могут изменить свой тип в любое время, интерпретатор с трудом справляется с оценкой типов всякий раз, когда вызывается эта инструкция, чтобы избежать неправильной операции. Это требует дополнительных циклов ЦП.

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

Взгляните на asm.js - это подмножество Javascript, которое позволяет значительно улучшить оптимизацию, избавившись от некоторых функций JS, в частности, от динамической типизации.

Philipp
источник
1
Современные JIT-компиляторы Javascript генерируют специализированный машинный код на лету для типов, которые вы используете, если они стабильны при фактическом использовании во время выполнения. Если вы действительно кодируете таким способом, который aможет быть целым, строковым или двойным и т.д., тогда вы правы. И старые браузеры, которые все еще используют интерпретаторы, конечно, также не имеют этих оптимизаций.
Esailija
1
@Esailija Современные среды JavaScript намного-намного быстрее, чем старые. Но они все еще медленнее по сравнению со статически типизированными современными средами, такими как .NET, JVM, ErlangVM и т. Д.
David Sergey
@nirth да, я не говорю об этом, просто говорю, что этот пост описывает, как это сделает интерпретатор / неоптимизирующий компилятор jit, и это серьезно медленно.
Esailija