Linked by snydeq on Tue 16th Aug 2011 16:46 UTC
Permalink for comment 485542
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



Member since:
2007-09-23
While most people see future web apps as more basic application aimed at consumers I have recently been in charged of creating specialized tools for internal use at a company. Of course, these tools had to be HTML5.
You will get into trouble when you are working with lists of several thousand items (some of our databases have row counts in the millions) and while just doing iterations in pure JS is pretty fast the slowest operations are DOM manipulation and changing the "GUI".
You have to know a few tricks and make good use of localStorage and WebWorkers (+ a lot of ajax to reduce those hundred of thousands of rows to "just" a few thousand) if you want to get these kind of things done. Something you don't have to deal with in native apps.
Mind you, that these issues are not only related to niche, complex applications. Just take the example of a music application. A lot of people have a library of several thousand tracks and working with that in a native app is no problem, but creating an <li> and doing JS manipulation on it will get you closer to the limits of JS speed.
So while some people say that the JS speed race is merely artificial at this point I say: give me moar!