Hacker News new | past | comments | ask | show | jobs | submit login

My browser does 10,000 operations / second with innerHTML, and 15,000 operations / second with DOM. In every ajax application I've ever made, this is negligible, compared to latency, server processing time, and downloading time.

I guess this saves you 1ms for every 30 elements you create? I'm sure there are some cases I'm missing where this might make more of an impact, but from my understanding of the article, this looks like a pretty small improvement.




Keep in mind, not everybody is running a desktop browser with that sort of cpu horsepower behind it.

Half of the iPhones ever sold - something like 80 million devices - are pre iPhone 4. There are a lot of low end Android devices on the market _right now_ with worse browser performance than an iPhone 3 (I've got a <6month old Huawei U8110 here as an example). Sure, top-end Android devices compare well against an iPhone4S (I'm pretty impressed with the Galaxy SII I've got here), but the bulk of Android devices in the wild are not late-model-top-end devices.

I had to drop an entire development branch from a project late last year due to insufficient performance of mobile device on-handset ajax. (We fell back to on-server html rendering and innerHTML updates, and even _that_ is annoyingly slow to me on low-end phones.)

And unless you have gathered data showing otherwise, this _probably_ really does apply to you. I was collecting some mobile use data last week - across ~70 websites that I've got Google Analytics access to, the average mobile visits was 14%, and the peak was just over 28%. This was across a range of markets and a variety of levels of "mobile friendliness" of the web design. (Biggest and probably most obvious takeaways from that exercise: B2B sites are a standard deviation or more below average for mobile visits, personal/leisure B2C sites up to one or two SD's above average. 80+% of mobile visits exit on a page with contact details - a phone# or address.)


Speed wasn't really his main selling point. He was mostly just pointing out that speed isn't a disadvantage for his method.

That being said the speed might actually make a difference with mobile browsers for some applications.


In mobile HTML5 apps _everything_ matters. I spent a significant amount of time building HTML5 apps that mirrored native UI almost perfectly and the primary issue with such an interface was that loading took forever the first time you open the page/app (but was natively-fast thereafter). If you're caching the app offline then JS performance (and moreso CSS performance) quickly become the bottleneck in app usability (because of the huge startup costs of setting up the page on the order of 10 seconds for something your desktop loads instantly).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: