On Tue, Jul 12, 2011 at 10:54 PM, austincheney
<[email protected]> wrote:
> Here is what I did for the Pretty Diff tool. If you want you can
> following along by passing the Pretty Diff code through the tool.
> tool: http://prettydiff.com/
> code: http://prettydiff.com/prettydiff.js
>
> 1) I ALWAYS avoid use of object literals with only one exception.
> Object literals are the slowest containers in JavaScript, so therefore
> fast programs do not use them.
I don't disagree with this in principle, but I made no effort to avoid
using object literals in the app that I've just finished, and the app
is as fast as you like. The only place I can see this being
significant is if you're chugging through an iterator, or something.
> 2) I ALWAYS use a single var keyword per function and put it near the
> top of the function.
var foo, bar; baz;
Can you see the mistake?
var foo;
var bar;
var baz;
Explicit, and a typo will result in a syntax error at worst.
> 3) I ALWAYS use anonymous functions assigned to variables.
var foo = function() {
return bar();
}
var bar = function() {
return "hello";
}
calling foo() will result in an error because bar has been hoisted but
not defined yet.
function foo() {
return bar();
}
function bar() {
return "hello";
}
This time bar is defined and calling foo will work. Also, I find the
latter easier to read.
A very quick summary of the last single page app I worked on, which is
a bookmarklet consisting of about a dozen models:
API
Model
Controller
View
The same principle as Austin says applies. Application logic and
state is in the model layer, firmly separated from presentation. We
used various patterns: decorators, mixins, pubsub etc. There is
currently some view logic in the controllers, which I'm not too happy
about. It may get moved away from there at a later date, into a view
model, perhaps.
I think, like with all projects, it comes down to separating code into
its logical domains and writing code in such a way that you can
rewrite it later on. Test driven development helps with this because
it requires decoupling by definition, and allows you to refactor with
confidence when you have to. This is the first project I worked on
where the model layer (which is the majority of the app) is 100%
covered by tests. I think we've had about 2 bugs raised in UAT so far
that weren't cosmetic issues.
As far as pubsub is concerned, I find it most useful where
modification of one widget requires modification of another. So far I
haven't had any issues with it. I limit the data that is published
and keep events specific, so that there is no ambiguity about what the
state of a model is at time of publishing.
I suppose we could have used a micro-framework for this, but we didn't
bother. We used jQuery as a dependency, which provides most of the
tools we needed. Had we not used it, perhaps we would have used more
external libs. I have personally never come upon a situation where I
have wanted to use a fully featured MVC framework for developing a JS
app. For me the overhead in learning outweighs the potential
short-cuts gained. I say potential, because JS is so expressive that
I don't find they add much. For personal projects, I'd stay away from
them. That said, if your development team doesn't know JS, and you
are unable to control the quality of their code for whatever reason, a
large framework will at least ensure some consistency.
So that's the short version, and it's already too long!
David M
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
