What does chrome mobile app convert html code into?

[Ryan D'Souza]

You know the whole web app vs native app dilemma. Where native is faster and web app works on any device. But I am trying to understand why web apps are slower.

Chrome app is a native app. When it downloads html code in a http request, what does the chrome app do with that text to render it on the screen? What exactly does it convert it to? Is it a collection of native widgets (like radio buttons, buttons, text fields, layouts, etc...) for the o.s.? If its native, then why does it not feel as smooth as other native apps. If its not native, then what is it and why did it not go with native?

By native widgets I mean like, if you literally start a blank android project on eclipse ADT, and put a button on the screen, that button is native.

Thanks

[Evan Langlois]

THINK - You are asking why adding an HTTP request (which adds significant latency PER request and a page has many) coupled with the overhead of parsing html and then rendering through what amounts to a virtual machine, from the graphics right down to Javascript, is not as fast as native machine code. Does that answer your question?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PhistucK]

It is a long read, but here is kind of the full story -

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

In short, form controls are native widgets (unless customized). The rest is manually calculated, computed, laid out and painted by the browser. This adds a lot of overhead. Also, it is not compiled - it is interpreted and runs just in time when it downloads (it is not machine code). Converting it to machine code takes time and converting it to really optimized machine code - takes even more time. Compiled applications are already pretty much optimized.

And yes, of course, network latency and bandwidth are also factors.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Ryan D'Souza]

I don't think that answers my question. My main question is, what is the stuff we see on a chrome app after it renders the html code. Is it native widgets or not?

If its native widgets, then shouldn't the web app perform as fast as a native app (like AFTER the page has been fully loaded). Like button clicks, scrolling, responsiveness as smooth compared to a native app with the same content.

If its not native, then what is it, and why did they not go with native widgets.

[Ryan D'Souza]

Just for clarification, when I talk about speed, I mean after the page has loaded, so excluding http request time. I mean more in terms of responsiveness in interactions. Like clicking buttons, scrolling, etc...

[Bryan Holmes]

As per PhistucK, everything is rendered by the app and nothing is native with the exception of form controls (unless customized). Which is precisely why it's not similar to system UI elements.

PhistucK

--

[Ryan D'Souza]

So then what if I made a native android app with 100 different widgets, each performs fast cause its a native app and compiled code. Lets call this A.

Then I made a blank (no widgets by default) native app, that downloads a html code via http request, and then I parse the code with xml parser, and everytime I see a input tag, I dynamically add a android equivalent widget to the activity view, thus simulating the html page but in android view. Lets call this B.

Which is faster A, or B, or they the same? (i mean faster as in responsiveness of buttons, scrolling, etc...)

My question is, why does chrome app not do situation B? (ignore the latency time for downloading he html code and images)

[Ryan D'Souza]

Clarification: why does chrome app, not do situation B, instead of keeping non-compiled form tags.

[Evan Langlois]

No, you are missing the point. What do you do when that button is clicked? In a native app, its a function call. For the web, its interpreting javascript. The button drawing being native or not isn't an issue since you are talking about responsiveness which means we are counting after the button is drawn, right?

[Ryan D'Souza]

yes after its drawn.

So then why does chrome choose to keep things rendered like a website, and not convert the form tags and javascript into native widgets and java code. Because i'm pretty sure the html/js code can be converted into native. Software like cordova, phone gap does it.

So why does Google not make the chrome app do it? I want to know what are the flaws/limitations.

[PhistucK]

Hm, as far as I know, PhoneGap and Cordova do not do that. They use a WebView, which is an embedded browser, that runs JavaScript, parses and renders HTML, SVG, CSS and so on. The Java part is just filling in for missing privileged APIs (NFC, Bluetooth and so on) by injecting JavaScript objects into the page (that later call back to Java code), as far as I know.

Do you have any references that show that they convert JavaScript into Java and native widgets?

Even so, a website is more than just a few form controls. It is a very complex system and Android (or Windows, or whatever) does not support all of the options (for example, CSS features) natively.

You can imagine it is sort of (but not really) converting them to machine code, which is, well, faster than Java code. ;)

Have you read that long article I mentioned? I am sure it will enlighten you.

☆PhistucK

--

[Evan Langlois]

Uhmm ... First, Java is not native code. Its translated into native code but this takes time. It doesn't matter if its interpreted (which is easier to sandbox for security) or JIT compiled. It still takes time and there will always be an overhead to go convert the graphics API ... Not all CSS features are available with native widgets. Compatibility with html standards is a requirement that native apps don't have.

Really, this is beginning to sound like whining. Chrome isn't slow (in fact, I'm a huge Firefox fan but I have to admit that Chrome on mobile is beating Firefox with one hand behind its back on intensive sites). All developers know there are tradeoffs. The further you get from bare metal, the more portable but slower things get. And a browser is intentionally far from the metal. That's the way it is. Period. Its not the developers fault. They haven't done anything wrong or stupid.

Lets let this thread die.

[Ryan D'Souza]

before death, I just want to know, so the main reason chrome app doesn't convert the html/js/css into android native widgets and java code, is because
1) not all of the html/js/css is supported natively on android
2) the process of doing it, would slow down page loading time by a good amount

But then I want to confirm, if the above is possible, then after that process is finished (doesn't matter how long), the app would perform as fast as a regular native app with the same content but having all of it initially.

Is this right?

[Bryan Holmes]

1. No. There are lots of reasons why it doesn't take pages and convert them on the fly to a whole other language to be parsed and interpreted itself. There are things specific to HTML, sure, but there are things you don't want a webpage to have access to without permissions (hence the use of Chrome Apps on other devices, and Android Apps on android) like Bluetooth or Contacts.

2. More than a good amount. You'd be pulling in data, then converting it, then interpreting it. By running it like it is, it's MORE performant than your option. 

The above IS possible, and it DOES matter how long it would take after being finished. After all, if it took 10 minutes for it to interpret a website, then convert it to native/Java PER PAGE, that would be way too long. And yes, it would perform as fast as a normal app but not with the same content (as Android doesn't itself have support for things like WebRTC which IS built into Chrome but unneeded for Android since GCM exists as a similar data channel).

So, no, yes and no.

[Ryan D'Souza]

Actually when I say convert it to native, I would mean dynamically create the widget elements and insert it to view. Something like this

psedocode

html :
t = document.createelement("table");
div.insertchild(t);

->

android:
LinearLayout ll = new LinearLayout(this);
view.addView(ll);



and for javascript

js:
alert(1);

->

java:
toast.maketoast("1");

So this is not literally dealing with machine code or any low level conversions explicitly.  But this is what I meant as conversions. So why cant an android app take html and do the above conversions with the html code/js/css code, and put it all in the android view?

Were you talking about this kind of conversion in your post?

[Siva P Thumma]

Ryan,

Its all about advertising and tapping user freetime. Why people still play spartan x when they have nintendo ready...?

You must agree that all these web2.0 bluff (including angular and polymer) can not make a compelling app like mxml swf can do. Moreover swf is an open spec. But still all this chrome BS survives as long as people are BS.

--

[Evan Langlois]

Did you just call everyone on this list BS?   I'm pretty sure I'm a person!  And nothing you said has anything to do with the topic - you are just spouting off insulting trash.  And SWF?  Flash is DEAD and its security issues with it.  And how dare you tell someone what they MUST agree to!  I must NOT.

[Bryan Holmes]

Yes, you're right. Angular must be unable to make compelling apps (whoops, https://www.madewithangular.com/#/) Polymer too (http://builtwithpolymer.org/)

Except that these are open standards. https://github.com/polymer/polymer and https://github.com/angular/angular.js/tree/master/src respectively. 

SWF isn't just dead, it's rotting. Every major browser has dropped it or is planning on dropping it. 

Meanwhile saying 'it's all about Advertising and tapping free time" might apply to google platforms, but chromium is open source and has nothing to do with Google. Chrome is just a google branded chromium.

Look, guys, if you are looking for something that's high performance then you can do that on HTML5/Canvas/Javascript/Jquery in any browser. If you need a webpage that performs as well as a native app, then code it in c++ and port it to anything (write once, run everywhere is their motto). 

The technical difficulties between the two (that is, web tech and C++) are night and day, but if you need performance that bad, just use native. Write something that turns html into native code yourself, if you find the browser is too slow but as of Aug of this year, Chrome has a 64% dominance on the market. Firefox is second at a third of that. Billions of people aren't wrong.

[PhistucK]

On Thu, Sep 10, 2015 at 6:23 AM, Bryan Holmes <b.hol...@gmail.com> wrote:

SWF isn't just dead, it's rotting. Every major browser has dropped it or is planning on dropping it. 

​You probably mean that every major mobile browser dropped or planning to drop it, because every desktop browser supports it - two of them even embed it (Chrome - and Internet Explorer or Edge).​

☆PhistucK

[Siva P Thumma]

@Evan langlois, It was just my opinion.

@Brian Holmes, If what you are arguing about is open source, why would apps built around its API be put in google's play-store ? why would a chrome plugin that is hosted on our own machines is warned to public that it is "not secure" ? If it is not a market share game, why would Google spent the whole picture to define a new browser instead improving firefox. ( A pure open source thing ) ?? Do you think fixing security bugs in swf takes 5 + years ?

you probably don't understand business or you are pretending by your obsessive domination.

-Siva P Thumma

[Evan Langlois]

No, Google went with Chrome and not Firefox because they had certain criteria. Look at when Android and Chrome were released. As a mobile OS, they knew Android would have hybrid apps and would need an html control and WebKit makes a lot of sense. And as they are competing with Apple they were able to use the same technology and let Apple do the work! Gecko isn't as mature as far as being embeddable in a control. Once you have WebKit in a control, you make a native browser out of it. Might as well go all the way and do desktops too .. enter Chrome browser.

So are you just here trolling?

[Siva P Thumma]

Probably guys in this thread are too young. 

I am 35 and following the industry very well. If something does not make sense we better ignore.

Flex, AIR, deliver a far, far better user experience even after 3 - 5 years from now after taking the continuous evolution all these web2.0 things put on to account.

If 10 years back Adobe would have come up with a mobile embedded with that bundle, that could have been better than galaxy s6 note. 

As far as chrome matters for me, I just think it is what we have (market share) but not what we want (Aesthetically pleasing) .

[Evan Langlois]

Please stop trolling. You know better because you think you are older? Not only is that a logical fallacy, but you are younger and I've been using computers since before you were born and had an Internet address before the WWW even existed. So ... I'm not too young to know better.

[Siva P Thumma]

okay.

[profe...@gmail.com]

Siva... buddy... if you were "following the industry" so well, you'd know "Web2.0" was TEN YEARS AGO. It had more to do with HTML 4 and XHTML and plugins. HTML 5 and CSS 3 far surpass any vision that "Web2.0" ever had.

But let's ignore THOSE semantics in your statement and look at your premise as you probably intended.

The security failings in Flash/SWF are not "bugs", they are FLAWS intrinsic in its very protocols. The same doors that allow Flash content to play AT ALL, also open it up to malicious use. So it's not a matter of fixing bugs, its a matter of rethinking the entire architecture. And Adobe isn't going to spend the time to do that. They've already unofficially signaled that Flash is waning, by building Flash Builder to export to HTML 5. That's where they will be focusing their attention and resources. Like it or not, end-of-life for Flash is on the horizon.

Also, I've got over 15 years on you, and have been developing and engineering for the web since the ground floor. I was at the SIG-CHI where Berners-Lee and friends introduced the "World-wide Web" to the masses and have been hooked ever since. I developed market-first  websites (literally... the very first websites in some markets) and bleading-edge web applications. So, no, I "remember" more than you do.

I also was an avid RIA developer back in the day. Since before Flash was around and we had to use a kludge of MacroMind Director and Shockwave. I've developed probably hundreds of RIAs, with Flash, Flex, and AIR (I was one of the first folks to be certified in Flex). From multimedia-rich presentations with tons of eye-candy, to utilitarian data admins and management apps. And I've since converted almost all of them (that still made sense) to HTML5. I have yet to find ANYTHING that I could do in a SWF that I can't do in HTML5... often with less development time and lower resource load during runtime.

We'd all like to think that any technology we invest so much in to learn and support will live on forever. But that's a fantasy. Flash is a dinosaur, and we will see its extinction sooner than you'd think.

Sent by Outlook for Android

[Siva P Thumma]

Http does not have any security from the start and no session we all blamed it for. Why do we use it in this context then?.

I took this easy as it does not end up. I always feel ridiculous about how google plays dramas.

We know link=rel is part of rss spec in the first place. How much foresight spec writers would've had. But it is now google led pubsub protocol.

Did they ever mention they are copycats ?

[Evan Langlois]

Dear troll, 

Please remove my name from your list.  Its bad enough its coming through the discussion list, don't send it directly too!

On Thu, Sep 10, 2015 at 11:01 AM, Siva P Thumma <siva...@gmail.com> wrote:

Http does not have any security from the start and no session we all blamed it for. Why do we use it in this context then?

I took this easy as it does not end up. I always feel ridiculous about how google plays dramas.

[Siva P Thumma]

@evan langlois, do you have brain?

On Sep 10, 2015 9:41 PM, siva...@gmail.com wrote:

Do you have brain ?

[Siva P Thumma]

Do you have brain ?

[Siva P Thumma]

@evan langlois, did you get a private mail from me?

Etiquttes are things we have.
Not gotten by reading through dos and donts.