The weird state of mobile web apps

http://www.position-absolute.com/news/the-weird-state-of-mobile-web-apps/

by posabsolute • 13 years ago

43 21 13 years ago

marknutter2• 13 years ago

How about instead of basing which tools you use on what high profile companies are using, you analyze them based on their own merit. For every LinkedIn and Facebook that's ditching HTML5 there's 100 no named outfits using it just fine for mobile development (my team included).

lukifer3• 13 years ago

There's a selection bias on the quality of hybrid apps; the good ones are so hard to distinguish that you'd never know.

I've also used several mobile websites that are WAY better than the app (Redbox, for instance). Depending on the use case, the browser can sometimes be the best experience, though obviously not always.

Each set of needs is a beautiful and unique snowflake. Anyone reflexively choosing Technology X solely because Company Y does(n't) is probably not qualified to decide on tech stacks.

posabsolute3• 13 years ago

Well in the case of facebook, they did not had a great html5 app from the get go.

But when you see LinkedIn push back when they had one of the best known html5 app in the appstore, that warrants questions, specially since they are farther in the process than most teams

(they created an html5 app, iterated on it for couple of months, decided to revert back because of memory performances )

The lack of teams being open about their process or them being more in the shadow certainly does not helps, we need more success story with html5 being in the appstores. It still certainly considered a risk by management teams when you associate all your mobile efforts with html5.

marknutter2• 13 years ago

Yeah, without a post-mortem from LinkedIn their switch away from HTML5 is barely worth mentioning. It sounds to me like they engineered themselves into a corner somehow. I guess we'll never know.

user242• 13 years ago

elephant in the corner: app store exposure and the lack thereof for web based apps.

clauretano2• 13 years ago

This article is talking about apps that are in the app store, but in the case of iOS are basically just UIWebViews. Exposure is some of the reason they aren't mere mobile sites.

Since UIWebViews those lack access to the Nitro javascript engine, I'm surprised to see rendering performance wasn't the real reason to go native.

lukifer3• 13 years ago

DOM engine and network lag are a much bigger bottle-neck for most mobile apps; where the lack of Nitro really hurts is <canvas>-based games, and specific CPU-heavy tasks (real-time photo effects, etc). For simple stuff like string manipulation, non-Nitro JS is still crazy-fast enough to be negligible in most cases.

However, I can attest that Javascript/browser memory leakage is a very real problem. It's manageable, but also very easy to screw up.

posabsolute3• 13 years ago

You can make it work, I can even have good animation performance with css3 on the iphone 3gs. Animating one or 2 items works well,

Things you need to be careful is too much animations at the same time & accessing and modifying the DOM while you animate, you need to "block access", something IOS does natively it seems.

But for Android that's another story, one device it's goint to be pretty good, on another it's complete crap and you need to deactivate animations all together.

thekingshorses2• 13 years ago

Actually Nitro is not that bad. When you compare that to chrome on mobile, Nitro is same or better than chrome.

Try this out http://premii.com/hn - Hacker news webapp. I couldn't get same performance on chrome. Even Android browser performs better when it comes to animation.

lukifer3• 13 years ago

The giraffe in the opposite corner: the lag time on pushing updates, and navigating the rules and restrictions of app stores.

user242• 13 years ago

I'd rather that than not be in the place where my users are looking.

clauretano2• 13 years ago

Instead of one sentence about why LinkedIn went native, here's a link to the whole chat:

http://venturebeat.com/2013/04/17/linkedin-mobile-web-breaku...

posabsolute3• 13 years ago

Thanks, I also added a link in the article for reference

pixelcort2• 13 years ago

One reason memory management is poor in webapps is due to the lack of weak pointers. WeakMap goes part way, but it's backwards: it has weak keys, not weak values.

In larger webapps, you often end up wanting an identity map for your model instances, so you don't instantiate multiple instances of the same record. At the same time, you don't want your identity map holding strong pointers to all those instances, preventing them from being GC'd if nothing else is using them.

Over time your identity map just fills up with unused stuff and your app is killed.

Finally, if there are low-memory warning APIs in the browser, I'm not yet aware of them.

kevingadd• 13 years ago

I've been pushing for proper, no-foolin' Weak References to be added to the ECMAScript spec for something like a year now. App developers who want them need to speak up, because most of the people who work on the spec don't even understand the concept of a weak reference or comprehend why devs want them. It's an uphill battle, but with enough support they will probably add them - they were actually considered for ES6 but abandoned.

qu4z-2• 13 years ago

> it has weak keys, not weak values.

Wow. That does seem backwards. What's the use-case for that sort of thing?

pixelcort2• 13 years ago

The weak keys is nice as it gives you a place to put "hidden" properties that can only be accessed when combining an object and the WeakMap. When the object is GC'd, the hidden properties in the WeakMap can as well.

But you can get close using a naming convention on the objects proper, say double underscore prexix or whatnot.

What can't be easily approximated right now is weak values, for identity maps in particular.

joebeetee• 13 years ago

I've just done exactly the same thing - built a (Backbone/RequireJS) web app (https://mealmatch.org/app) to get the product out fast and across all devices and have just published the Phonegap app to the iTunes store (https://itunes.apple.com/us/app/mealmatch/id641639510).

I'm glad we did it that way. You're always going to need a good web version and it meant we could quickly get feedback and fix stuff before committing to and app.

The bulk of the work was changing the way the API required authentication. With the webapp I was dependant on cookies/sessions so had to change quite a bit for Phonegap - so save yourself some pain there.

Finally, there are a ton of good plugins - my 2 favourites were the native header/footer - super simple to integrate and easy to use. Bear this in mind when designing your navigation.

Good luck!

The weird state of mobile web apps

Related Stories