bgrins

For an introduction, read the section on limiting DOM manipulation here: http://www.artzstudio.com/2009/04/jquery-performance-rules/#...

Here is the Gecko DOM reference: https://developer.mozilla.org/en/DOM/element (listing common manipulation methods) https://developer.mozilla.org/en/Gecko_DOM_Reference

Basically, if you catch yourself calling DOM functions in a loop (or in a function that gets called in a loop, like the grid_canvas example here), it should be done in memory and then manipulate the DOM outside of the loop.

I see your point. Thanks for posting this code - I implemented the a* pathfinding algorithm in javascript, so I looked into some of these options also. I ended up using the basic 2d structure to store the grid, since it was the most straightforward and seemed somewhat equivalent to 1d.

For a demo of it (http://briangrinstead.com/files/astar/), I used divs to represent the grid on the page, but I think it would be awesome to use the canvas grid representation since I suspect it will have much better performance than thousands of divs on the page (switch it to 100x100 to see what I mean).

Calling fillRect is massively slower than calculating the an index in the array. As a general rule, it is more efficient to modify native data structures directly, while updating the DOM as infrequently as possible.

I understand that you may have been wanting to benchmark the actual speed of updating the canvas, but it really isn't a fair comparison with updating arrays.

Invalidating the canvas 24 times a second doesn't help with the benchmark, but it would make the example usable, in that it would actually update the canvas element on your screen.

On my computer, the example from jdavid ran in 287ms, instead of the original which ran in 7427ms.

There are some already listed in this thread: http://news.ycombinator.com/item?id=1938859

I launched a CSS sprite generator at http://instantsprite.com.

I finished http://instantsprite.com. It's not really a startup, but it is an app that I was motivated by the startup sprint posts to finish.

I submitted it a few days ago, and got a few comments: http://news.ycombinator.com/item?id=1922845

Glad to hear it! I was hoping it could be useful to other people. I'm still working on it, so let me know if there is anything you'd like to see in it.

I have noticed that recently the Chrome web inspector has gotten much better at working with pseudo classes. Maybe it is just the nightly version of Chrome, but when I inspect one of those links, I can see and edit the a:before pseudo class.

It's a really nice upgrade, because in the current version of Firebug and older versions of the Chrome inspector it was not possible to modify or even see these properties.

A couple of sites that have similar functionality:

http://css3please.com http://www.css3maker.com

Can you explain this a little more?

Do you load the rasterized image using a base64 url, or do you store specific drawing instructions in JavaScript (lineTo, moveTo, etc)? For the vectorized icon, do you load SVG inside canvas, or just display SVG directly?

Also, how do you fall back for older browsers that do not support Canvas or SVG?

Here is a contrived example, that shows the pros and cons of each, as I see them. Pretend you have an 'link' object in JavaScript and you want to generate the view for that link using templating:

  var link = { url: 'http://news.ycombinator.com, title: 'Hacker News' , extraStuff: someBigObject };

With JS templating:

  <div id='template'><a href='${url}'>${title}</a></div>

  $('#template').tmpl(link);

* Pros: if you have to generate 100 links, you only passed down the template div once. Also, if the extraStuff property is really large, there is no bandwidth spent on sending it up, since it runs on the page

* Cons: if you generate 0 links, you still passed down the template div once. If you have this view defined also in a server side template, you have duplicated view logic (really annoying).

With server side templating:

  $.load('url/to/template', link);

* Pros: If you generate 0 links, no extra data is sent or received. Also, your view logic is all in one place (on the server).

* Cons: If you generate 100 links, there are 100 extra HTTP requests, and you have to deal with timeouts, loading indicators, etc.

I don't think that it is useful for a standard site, one that needs to be indexed by search engines and needs all of it's content to be available on page load. I have made use of it in single page web applications before, though.

It completely blows hand generation of HTML out of the water for maintainability. You can keep your templates inside of the HTML page using a <script> element with a special type, and keeps a lot of that view logic out of your JavaScript. It also provides a nice alternative to using a hidden element and cloning it, then switching attributes, text, and values.

Thanks, I signed up. I am working on a project for generating CSS sprites in the browser without any file uploads.

I'm a little confused about what exactly I share with the emails. It says there will be three links, and I click on one that records my progress. Are these goals I set up myself? Am I sharing this with anybody who wants to see it, or is it just something to use to stay motivated as an individual? I am definitely interested to see how it works.

One of the benefits that web development offers that the App Store doesn't is that the code you write runs on any machine that has a web browser. Certainly dealing with IE is a headache - but to completely discount that fact that it doesn't run on Windows and ignore the majority of potential paying customers seems silly to me.

Certainly people can and will make money selling software in the App Store - there are some good reasons why listed in the article - but I disagree that web developers being acquainted with Mac OS tools is going "to put a final nail in the web-coffin". Web development seems alive and well. It is not dying - it is still in it's awkward adolescent years.

"A Fire Upon The Deep" by Vernor Vinge.

That was quick! I was wanting to see some sample apps with backbone, thanks for sharing.

By the way, if you have the .0.1.1 release, you can call this.handleEvents(); inside of the initialize() function on the template instead of the render() function. This prevents having to rebind the element every time you call render. This probably won't be a huge issue considering that you are only binding one event each time, but it is probably best practice anyway.

Make sure to read "A Deepness in the Sky" first. It's a prequel to "A Fire Upon the Deep", and also a Hugo award winner.

I found a video that helped me to visualize this design better than I could from the article. It is a 4 minute long animation of the interchange in action from the Missouri Department of Transportation found on this page: http://www.modot.mo.gov/springfield/major_projects/Greene/I-....

And here is a direct link to the video (13MB): http://www.modot.mo.gov/springfield/major_projects/Greene/DD...

There are also some more pictures: http://www.modot.mo.gov/springfield/major_projects/Greene/Di...