Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The viability of JavaScript frameworks on mobile

joreteg.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: The viability of JavaScript frameworks on mobile

#31

Post by kraig911 »

Blame the language and not the platform is what you're essentially saying. Ok so initial payload can be what 600kb per your argument. But at least once I have delivered that my actual interactions on the server side can be somewhat a minimum instead of re-rendering more HTML and sending across the wire to the handset.

That being said yes you must develop on a crappy computer if you want to be known as dev that's known for making apps snappy. Is there a lot of fat one can cut from these frameworks yes... but I think Atwood's initial argument is that android just sucks with Javascript. The many cores, single thread per tab just makes the experience anemic with rich web applications.

Re: The viability of JavaScript frameworks on mobile

#32

Post by dahdum »

thinkcontext wrote: post #27

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

I think that's the key, from the Atwood article:

"In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing."

Re: The viability of JavaScript frameworks on mobile

#33

Post by exelius »

thinkcontext wrote: post #27

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible.

This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manufacturers bundle their own browser that it will be a long time before those users with "old, slow" JS on Android go away. I don't know how the JS engine is bundled on Android, but if it's bundled with the core OS then the vast majority of phones would just never get updated. Developers have to deal with that, so unless you're ok with excluding a large percentage of mobile devices on the street, dealing with slow JS performance is simply a fact of life on mobile.

Re: The viability of JavaScript frameworks on mobile

#34

Post by HenrikJoreteg »

kraig911 wrote: post #31

Blame the language and not the platform is what you're essentially saying. Ok so initial payload can be what 600kb per your argument. But at least once I have delivered that my actual interactions on the server side can be somewhat a minimum instead of re-rendering more HTML and sending across the wire to the handset. That being said yes you must develop on a crappy computer if you want to be known as dev that's know…

Just to clarify, I'm not suggesting doing we should do full page refreshes or that we shouldn't be doing single page apps.

I'm all for minimal server-side interactions once loaded too.

Re: The viability of JavaScript frameworks on mobile

#35

Post by luketheobscure »

I think Ember is ahead of the curve on this one. Ember 2.0 introduced no new features, and instead only focused on stripping out deprecations, dead code, or platform specific stuff for browsers they don't support any more.

(Disclaimer: I'm heavily invested in Ember.)

Re: The viability of JavaScript frameworks on mobile

#36

Post by exelius »

kraig911 wrote: post #31

Blame the language and not the platform is what you're essentially saying. Ok so initial payload can be what 600kb per your argument. But at least once I have delivered that my actual interactions on the server side can be somewhat a minimum instead of re-rendering more HTML and sending across the wire to the handset. That being said yes you must develop on a crappy computer if you want to be known as dev that's know…

> Blame the language and not the platform is what you're essentially saying. Ok so initial payload can be what 600kb per your argument. But at least once I have delivered that my actual interactions on the server side can be somewhat a minimum instead of re-rendering more HTML and sending across the wire to the handset.

Unless your mobile browser aggressively purges its cache due to the limited memory on most mobile devices. Then you're going to have to reload the payload every time you bring the page to the foreground; or at a minimum reload the framework (which usually takes a noticeable amount of time as the framework creates a bunch of temporary data structures).

Re: The viability of JavaScript frameworks on mobile

#38

Post by nostrademons »

exelius wrote: post #33
thinkcontext wrote: post #27

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manuf…

It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things:

1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it before execution can even begin.

2. The native Android GUI frameworks render views on the GPU. Chromium will only render views on the GPU if you have a CSS transform or opacity property set. If you're not very careful, you can easily trigger an expensive layout + repaint calculation on every frame.

It's possible to write webapps that perform just as well as native, with fancy animations and fluid user experiences. I had some existence prototypes when I was still at Google, and some of the research for that went into the current Google Search app experience on Lollipop. But it was a huge pain as far as the developer experience went, and a lot gets lost in translation when productionizing. It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window.

Re: The viability of JavaScript frameworks on mobile

#39

Post by albemuth »

kra34 wrote: post #37

or you could just write regular Javascript. Browsers seem to be pretty good at handling Javascript, CSS, and HTML. The default size of vanilla js is actually 0 KB and that's not even gzipped.

And after reaching a certain level of complexity what you have is an ad-hoc framework of about the same size but is a slow, bug ridden implementation of half of one of the ones in the OP.

Re: The viability of JavaScript frameworks on mobile

#40

Post by mwcampbell »

nostrademons wrote: post #38
exelius wrote: post #33

Earlier quoted context omitted.

It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manuf…

It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…

Why doesn't Chromium render more elements on the GPU?
Post reply on HN