Hacker News Reader

Comment by Spyckie | Hacker News Reader

+2 for Firebug. Firebug should be your number 1 priority to get familiar with.

jQuery... I have mixed feelings about it.

On the one hand, its very good for high level thinking and writing good, readable code. On the other hand, it slows down your javascript code by at least 2x, which is particularly noticeable if you're doing a javascript intensive application. Then again, the future of browsers is speeding up javascript, so this may not be an issue in a couple of years.

My experience with Prototype is that it handles the speed issue much better - however, it is a bloated monster of a framework.

View on HN

I usually approach JavaScript frameworks the same way I approach high-level languages: write the app in whatever way is most convenient, then profile and rewrite the performance-critical sections without the framework. I've never had performance problems with JQuery, because I usually just write my mouseMove handlers so that they operate on the raw DOM without it.

(I wrote something to this effect on Proggit once, and John Resig reply was something like, "Of course. JQuery's not intended for performance-critical code - usually you don't want to be using any framework for that. JQuery's meant to make the other 90% of JavaScript development go faster.)

BTW, I won't go near Prototype (after having used it pretty extensively at a past employer) because it messes with Object.prototype. When libraries do that, you have no way of knowing which libraries are compatible, which means that you'll suddenly get bitten by very odd, hard-to-track-down bugs.

I should say that /any/ framework is not intended for performance-critical code. A framework is designed to be an abstraction - abstractions implicitly remove you from what you're trying to do, causing a performance hit of some sort. If performance is your #1 priority then you should be writing everything from scratch.

Now if development time is a greater priority over performance then I think the choice is pretty obvious.

I don't do intensive enough work, or know enough about Javascript frameworks, to notice speed issues. I generally use it to update a div with the results of an ajax call, to asynchronously submit a form, and to manipulate some UI elements: alternate row striping, show or hide, change the size of elements, etc.

I don't pretend to know what I'm doing with JS, so I'll keep your advice in mind should I have to figure out why something isn't as fast as it should be.

Hmm. My understanding is that it strips out a bunch of unnecessary (correction: able to be simplified, not necessarily "unnecessary") elements and makes it easier to write leaner JavaScript. Also easier to have a browser render JavaScript.

Wittens' talk at http://acko.net/blog/jquery-oscms-presentation-slides at the OSCMS was pretty good; basically, JavaScript is not bad, but too much can be overwhelming to people.

P.S. Not always the slowest set of elements to load on a page. A fun little hack: http://www.spaceminnow.com/school - standard disclaimer -

Reply on news.ycombinator.com