Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
1  
please refactor to clarify which are the statements you're starting from, and what is the actual question. –  funkybro Jun 19 '13 at 11:35
    
Could you clarify what you mean by "What stops from doing the same in HTML and JS itself?" I don't understand what you mean by "the same" -- you've made four statements previously, and I'm not sure which you're referring to in that question. –  apsillers Jun 19 '13 at 12:50
    
If I have a native development platform which uses HTML as markup instead of anything new. and uses JS as the language, will the performance be better ? Google in this I/O said, they were being practical and using Android on phone and not Chrome OS. So does it mean, FF OS is not a practical concept ? is it possible for FFOS apps to perform as good as android apps on respective platforms if all the best practices are followed ? –  Amogh Talpallikar Jun 19 '13 at 12:53
    
Take a look at Windows Metro applications. They are native applications which use HTML for GUI design and Javascript for the logic behind it. –  Philipp Jun 19 '13 at 13:41
    
HTML/JS performance is generally more than good enough for a user interface that displays information, and based on user actions, makes requests to an outside server. It wasn't originally built for more than that, but by now it's impressively more capable. Still, for situations involving more direct device access, interfacing with native code, or interacting with the operating system (ie, notifications), there's still no good way to use general-purpose web technologies for that. –  Katana314 Jun 19 '13 at 13:43
show 2 more comments

3 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
I don't get it. We have very large corporations: Google, Microsoft, Apple focused on backing Chrome, Safari and IE. We have Mozilla committed to Firefox. We have Chrome Dev Tools, Web Inspector, Firebug. And Prasad says that there are no tools? –  niutech Mar 12 at 19:44
    
@niutech: lets say you want a tool like Valgrind for HTML5 app. There isn't much. –  vartec Mar 13 at 8:55
add comment

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.

share|improve this answer
    
Add reporting to that. –  Alan B Dec 13 '13 at 15:07
    
ECMAScript 6 adds majority of these features. Google Closure Library is another solution. –  niutech Mar 12 at 19:46
    
Angular provides nice declarative way now. –  Amogh Talpallikar Mar 13 at 11:04
add comment

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.

share|improve this answer
1  
The modern Javascript JIT compilers generate specialized machine code on the fly for the types you are using if they are stable in your actual runtime usage. If you are really coding in a way that a can be integer, string or double etc then you are right. And older browsers that still use interpreters of course don't have these optimizations either. –  Esailija Jun 19 '13 at 14:03
1  
@Esailija Modern JavaScript environments are much-much faster than old ones. But they are still slower when compared to staticly typed modern environments, such as .NET, JVM, ErlangVM etc. –  nirth Jun 19 '13 at 16:04
    
@nirth yeah I'm not saying that, just saying that this post described how an interpreter/non-optimizing jit compiler would do it and that's seriously slow. –  Esailija Jun 19 '13 at 16:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.