3 ms·

After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster w

by pcunite 13y ago

After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster ways. I'm use to threading database calls, using message queues, and views updating themselves from caches. It’s a new world for me and feels somewhat like a step backwards. Here I come html5!

TheAceOfHearts 13y ago
The only thing that matters in most cases is that it's being done over 60FPS. Use Chrome Dev Tools and to monitor the framerate.
oscilloscope 13y ago
You can use queues when creating a large number of elements. Use requestAnimationFrame and each frame pop some elements off the queue to render them. This will help prevent the page from locking up during render events.
- PavlovsCat 13y ago
  Also, when adding many elements (or not so many, but over and over), add them to a DocumentFragment [ http://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment http://developer.mozilla.org/en-US/docs/Web/API/DocumentFrag... ] first, and then attach that to the DOM in one piece (one big DOM update is better than many small ones).
hising 13y ago
I guess knowledge like yours are important in making better tools and patterns available for JavaScript developers who haven't yet had the opportunity to work with those types of tools, patterns and languages you have. A big opportunity for people who come from more mature environments to share their knowledge!
ivanca 13y ago
For performance any platform is a step backwards, the leveling for easier/broader access is never free.
- fuckjavascript 13y ago
  Rubbish. "Leveling" done in userspace (e.g. libraries) doesn't create a fundamental step back. The browser is just a horribly designed, and why, in spite of years of procrastination and denial - and HN is no exception - it has ultimately ended up as a virtual machine combined with basic primitives (albeit years too late and not done very well at all). My hellbanning on this site is a great example of why this site sucks. How many of the losers who hang out on this site all day collecting karma (as opposed to.. programming) called these problems? Practically nobody, and yet HN is deprived of my wisdom because I am too blunt and don't have an established account.
tlarkworthy 13y ago
try angular JS for self updating views.
slacka 13y ago
Avoiding writes to the DOM is a good tip for beginners. As a desktop developer, you're going to realize quickly that DOM is decent model for documents, but a terrible paradigm for interactive applications. Overall performance is terrible and varies widely between browsers. We either need a new standard or a DOM browser battle like what happened with JavaScript, bringing it from 100x to 3x of native.

by pcunite 13y ago

TheAceOfHearts 13y ago

The only thing that matters in most cases is that it's being done over 60FPS. Use Chrome Dev Tools and to monitor the framerate.

oscilloscope 13y ago

You can use queues when creating a large number of elements. Use requestAnimationFrame and each frame pop some elements off the queue to render them. This will help prevent the page from locking up during render events.

PavlovsCat 13y ago
Also, when adding many elements (or not so many, but over and over), add them to a DocumentFragment [ http://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment http://developer.mozilla.org/en-US/docs/Web/API/DocumentFrag... ] first, and then attach that to the DOM in one piece (one big DOM update is better than many small ones).

hising 13y ago

I guess knowledge like yours are important in making better tools and patterns available for JavaScript developers who haven't yet had the opportunity to work with those types of tools, patterns and languages you have. A big opportunity for people who come from more mature environments to share their knowledge!

ivanca 13y ago

For performance any platform is a step backwards, the leveling for easier/broader access is never free.

fuckjavascript 13y ago
Rubbish. "Leveling" done in userspace (e.g. libraries) doesn't create a fundamental step back. The browser is just a horribly designed, and why, in spite of years of procrastination and denial - and HN is no exception - it has ultimately ended up as a virtual machine combined with basic primitives (albeit years too late and not done very well at all). My hellbanning on this site is a great example of why this site sucks. How many of the losers who hang out on this site all day collecting karma (as opposed to.. programming) called these problems? Practically nobody, and yet HN is deprived of my wisdom because I am too blunt and don't have an established account.

tlarkworthy 13y ago

try angular JS for self updating views.

slacka 13y ago

Avoiding writes to the DOM is a good tip for beginners. As a desktop developer, you're going to realize quickly that DOM is decent model for documents, but a terrible paradigm for interactive applications. Overall performance is terrible and varies widely between browsers. We either need a new standard or a DOM browser battle like what happened with JavaScript, bringing it from 100x to 3x of native.