What stops HTML5 and JS apps to perform as good as native apps?

Question

From what I understand,

• HTML is a mark-up language, so is the content of XAML, XIB and whatever Android uses and other native UI development frameworks.
• JavaScript is a programming language used along with it to handle client side scripting which will include things like event handling, client side validations and anything else C#,Java,Objective-C or C++ do in various such frameworks.
• There are MVC/MVVM patterns available in form frameworks like Sencha's, Angular etc.
• We have localStorage in form of both sqlite and key-value store as other frameworks have and you have API specification for almost everything that it missing.
• Whenever a native UI frameworks has to render UI , it has to parse a similar the markup and render the UI.

Question break-down

• What stops from doing the same in HTML and JS itself ?
• Instead of having a web-control or browser as a layer in between why can't HTML(along with CSS) and JS be made to perform the same way ?
• Even if there is a layer,so does .net runtime and JVM are in other cases where C++,C are not being used.
• So Lets take the case of Android, like Dalvik, why Can't Chromium be another option(along with dalvik and NDK) where HTML does what android markup does and JavaScript is used to do what Java does ?

So the Question is,

Even if current implementations aren't as good, but theoretically is it possible to get HTML5 based applications to work as other native apps specially on mobile ?

Answer 1

The poster boy for HTML5 apps, LinkedIn went native early 2013. In the interview in VentureBeat they explain why.

I think this is the part most relevant to your question:

Prasad said performance issues weren’t causing crashes or making the app run slowly. What he did say shows that HTML5 for the mobile web still has a bright future — but only if developers are willing to build the tools to support it.

...

There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out. If you look at Android and iOS, there are two very large corporations that are focused on building tools to give a lot of detailed information when things go wrong in production. On the mobile web side, getting those desktop tools to work for mobile devices is really difficult. The second big chunk we are struggling with is operability, runtime diagnostics information. Even now, when we build HTML5, we build it as a client-side app. It’s more of a client-server architecture. … The operability of that, giving us information when we’re distributed to a large volume of users, there aren’t as many great tools to support that, as well.

[Prasad also noted that dev and ops tools for solving issues quickly "don't exist."]

Because those two things don’t exist, people are falling back to native. It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but they’re at the beginning. People are just figuring out the basics.

Answer 2

A lack of a Javascript standard library is a horrible inhibitor. There are great frameworks like jQuery, Dojo, YUI, to name a few, but all of them are solely focused on the presentation layer and XHR.

Do you want configurable logging, cryptographic tools, graph algorithms, UUID generators, Maps, Sets, Trees, templates, dependency management, date manipulation, localization/internationalization, matrix operations, dependency injection, unit tests, map-reduce, XML processing? Trivial for JVM or .NET languages - in Javascript you often have to roll your own implementation.

Answer 3

One reason why Javascript is slow is its total lack of type safety. Any variable can be of any type at any time. Also, most operations are valid with many different types, but have different semantics. A simple term

a += b;

isn't that trivial for the interpreter, because a and b could be numbers or strings. When both are numbers, it's an arithmetic addition. When both are string, this is a string concatenation. When one is a string and one is a number, the number must be formatted before performing a string concatenation. These are completely different operations which require to interprete the arguments differently.

Depending on the types of a and b, the type of a can now be integer, double or String, regardless of what type it was before.

Because variables in JS can change their type at any time, the interpreter hardly gets around evaluating the types whenever this instruction is called to avoid doing the wrong operation. This requires additional CPU cycles.

Other features which make optimization much harder are sparse arrays or garbage collection and event handlers which can fire at any time.

Take a look at asm.js - It's a subset of Javascript which allows much better optimization by getting rid of some JS features, notably dynamic typing.