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

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

• 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 работать как другие нативные приложения, особенно на мобильных устройствах?

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

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

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

...

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

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

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

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

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

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

a += b;

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

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

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

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

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