The weird state of mobile web apps(position-absolute.com)
position-absolute.com
The weird state of mobile web apps
http://www.position-absolute.com/news/the-weird-state-of-mobile-web-apps/
21 comments
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.
> it has weak keys, not weak values.
Wow. That does seem backwards. What's the use-case for that sort of thing?
Wow. That does seem backwards. What's the use-case for that sort of thing?
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.
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.
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).
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.
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.
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.
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.
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.
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!
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!
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...
http://venturebeat.com/2013/04/17/linkedin-mobile-web-breaku...
Thanks, I also added a link in the article for reference
elephant in the corner: app store exposure and the lack thereof for web based apps.
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.
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.
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.
However, I can attest that Javascript/browser memory leakage is a very real problem. It's manageable, but also very easy to screw up.
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.
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.
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.
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.
Do you know any other web app for HN? I'm looking for something that offers login functionality. All the webapps I found so far, incl. premii, are just read-only. I've tried so many others, but nit even a single one offers login capability...
List of all hn webapps. https://github.com/cheeaun/hackerweb/wiki/Hacker-News-apps
Try it out and let me know if you find any with login capability.
Try it out and let me know if you find any with login capability.
I tried all. None with login :(
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.