In fact, even with precached DOM representations of images, our basic tests have shown that Canvas based rendering of an isometric scene is almost always 2-3x slower than just dumping out a big HTML string with some class names linked to external stylesheets.
The author of Aves Engine for browser-based games discusses technical limitations of current canvas implementations.
This was a technology often used in 8-bit video games of the era, to achieve interesting visual effects by cycling (shifting) the color palette. Back then video cards could only render 256 colors at a time, so a palette of selected colors was used. But the programmer could change this palette at will, and all the onscreen colors would instantly change to match. It was fast, and took virtually no memory. Thus began the era of color cycling.
1990's techniques make their way back with HTML5 and mobile devices.
It's always dependant on the problem they're trying to solve, but in lieu of a better jQuery plugin ranking system, here's a couple of tips that should raise a red flag.
Few hints on writing jQuery plugins.
By far the most difficult thing the editor does is figure out where to draw text. For this, we built a new layout engine. Here’s an example of how the new engine works: say you type the letter ‘a’. We notice you pressed the ‘a’ key and respond by drawing a single ‘a’ off-screen. We then measure the width and height of that ‘a’, combine those measurements with the x and y position of your cursor, and place the ‘a’ at the correct spot on the screen. If you’re in the middle of a word, we push the characters after your cursor over. If you’re at the end of a line, the editor moves your word to the next line and pushes any overflow to the lines after it.
Amazing piece of front-end programming from Google Docs.
In 1974, Daniel P. Friedman published a little book called The Little LISPer. It was only 68 pages, but it did a remarkable thing: It could teach you to think recursively. It used some pretend dialect of LISP (which was written in all caps in those days). The dialect didn't fully conform to any real LISP. But that was ok because it wasn't really about LISP, it was about recursive functions. You didn't need a computer in order to work through the exercises. After reading the book, I was changed. In a good way. There are very few books that deeply change the way that you think. This is one of those books.
Douglas Crockford on The Little Schemer and his own JavaScript version of code samples from the book.
This is not how the XML parser sees things. It reads sequentially.
First is sees an open script, then it sees the CDATA which simply says escaping is not necessary. It then sees the close script tag, which by what appears to be coincidence is not needed to be escaped, and it closes the script block there, since one is open.
Detailed explanation of one of the JavaScript caveats.
Any savvy web developer can tell you how many kilobytes their code consumes. They bundle, minify, compress and tune the data sent out to within an inch of its life. Wire weight is easy to measure and has a direct impact on your application's launch time. But how many milliseconds does it take the user's computer to parse and load your code once it's arrived? What differences are there between CPUs, operating systems, browsers and plugins? What speed leaks are we overlooking?
A benchmark for JavaScript parsing times.
Quiz mainly focuses on knowledge of scoping, function expressions (and how they differ from function declarations), references, process of variable and function declaration, order of evaluation, and a couple more things like delete operator and object instantiation. These are all relatively simple concepts, which I think every professional Javascript developer should know. Most of these are applied in practice quite often.
Have phun!
I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.
Amen.
Today, we released jQuery 1.4, a mostly backward compatible release with a few minor quirks. One of these quirks is that jQuery now uses the native JSON parser where available, rejecting malformed JSON.
This probably sounds fine, except that by malformed JSON, we mostly mean:
{foo: "bar"}
The case for eval().
