Attention to detail

10 views
Skip to first unread message

Frank Schroeder

unread,
Oct 10, 2010, 4:45:56 PM10/10/10
to JavaScriptMVC
Hi Javascript MVC team,

I'm in the process of evaluating JavaScript frameworks and tools for a
small to medium sized application. Although I my JS is a bit rusty I
got plenty of experience and I think you are taking an interesting
approach. One that I would prefer over more complex things like
ajax.org or dojo which again impose a programming model instead of
just providing the tools.

However, my head is spinning from trying to figuring out which of the
tools to use as they all come with some level of commitment and nobody
wants to pick a loser. So one thing I usually look out for is the
attention to detail the developers give to the code they publish as it
gives me a good indication on the focus. I realize that in times of
github and constant updates everything can be fixed instantly and
writing code is more fun than fixing bugs or cleaning up.

So I'm looking at the 3.0 alpha 12, ran the update, create an app and
look at the files. Sometimes the indent is right, sometimes it isn't.
There are lots of blank lines where they shouldn't be and sometimes
they're missing. Some of the files have windows line endings and some
are UNIX. The generated code in the tests looks like it is missing
semicolons. So that should work with semicolon injection in JS but it
doesn't look good to me. The qunit.html and funcunit.html files are
not generated and on your web page the production.css file is missing
so that the 3.0 page doesn't load correctly.

I realize that there is a lot of competition out there right now and
speed is a factor. However, when an outsider has to decide whether the
tool he is looking at is a toy or will turn into something serious the
things I've mentioned are a factor. You might want to keep that in
mind.

Here is is an excerpt of my "Cookbook" app. I've called it "frank" and
the "Recipes" are "Customers". Other than that I didn't change
anything.

Frank

test("findAll", function(){
stop(2000);
Frank.Models.Customer.findAll({}, function(customers){
start()
ok(customers)
ok(customers.length)
ok(customers[0].name)
ok(customers[0].description)
});

})

test("create", function(){
stop(2000);
new Frank.Models.Customer({name: "dry cleaning", description: "take
to street corner"}).save(function(customer){
start();
ok(customer);
ok(customer.id);
equals(customer.name,"dry cleaning")
customer.destroy()
})
})

Justin Meyer

unread,
Oct 10, 2010, 10:48:11 PM10/10/10
to javasc...@googlegroups.com
Frank,
  3.0 is still alpha.  Code completion, testing, documentation, etc all come way before code formatting.  Semicolons don't matter at all.  With the addition of steal.clean : http://v3.javascriptmvc.com/index.html#&who=steal.clean , maintaining the correct formatting and indentation will be much easier and has been planned before the final release.

  Addressing your concerns is the work of 1/2 a day.  The rest of the framework is the work of 3 years.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com



--
You received this message because you are subscribed to the Google Groups "JavaScriptMVC" group.
To post to this group, send email to javasc...@googlegroups.com.
To unsubscribe from this group, send email to javascriptmv...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javascriptmvc?hl=en.


Jeremy Kahn

unread,
Oct 10, 2010, 11:22:00 PM10/10/10
to javasc...@googlegroups.com
Frank, 

I understand your concern about maintaining code visually.  To that end, I have added "directory.js."  Essentially a wrapper to the clean.js script that Justin mentioned, directory.js will batch-process scripts to be beautified.  This will help maintain the code and keep it readable going forward.

--
Jeremy Kahn
Twitter:  @jeremyckahn

Frank Schröder

unread,
Oct 11, 2010, 4:44:57 AM10/11/10
to javasc...@googlegroups.com
Hi Justin,

I realize that 3.0 is still alpha but that should mean that there are
rough edges and missing features. Code quality is something that
should be built into the release process from day one. The same goes
for the semicolons. They matter as they show consistency. Either you
use them or you don't. If it is sometimes like this and sometimes like
that then it looks like you don't care.

All I'm saying is that there are dozens different frameworks out there
and they all want to attract a large user base. From what I've seen
their weak point across the bench is documentation, examples, getting
started guides and sometimes code quality. The examples are too
shallow or they don't match the current version or they focus mostly
on theming but not on how to use the framework. To a certain extent
that is also true for JavaScriptMVC.

You obviously want to attract more serious programmers who are writing
more sophisticated applications who understand and appreciate your
tool set. These people look at different things when evaluating your
code and code quality and documentation even of the development
version are important factors.

Looking at this blog post on jupiterit.com
(http://jupiterit.com/news/jquery-s-object-literal-coding-conventions)
I think you're already heading down that road.

Keep up the good work. I really think your toolset is needed.

Frank

2010/10/11 Justin Meyer <justin...@gmail.com>:

--
Frank Schröder

Justin Meyer

unread,
Oct 11, 2010, 6:18:36 AM10/11/10
to javasc...@googlegroups.com
Frank,
  In my opinion, code formatting related but does not equal code quality.  There are other, and more important, factors that go into code quality.

For example:

if (!isNaN(object) && (+object) !== Infinity) {
return 'number';
}

that should actually be:

if (!isNaN(object) && isFinite(+object)) {
return 'number';
}

IMO, that change, which will only cause errors in 1 in 100 apps is far more important than if the function looks like:

if ( !isNaN( object ) && ( +object ) !== Infinity ) {
return 'number';
}

(spaced correctly w/ jQuery's conventions)

I understand that some will use it for a leading indicator of the over all quality of a project.  This is exactly why I wrote that blog article and added steal.clean.  But, with our standard development practice, formatting is something that gets added at the end of the project.  It's far more efficient that way.  We have standardized on jQuery's conventions, but this happened in 3.0 and we haven't 'converted' 2.0's code.

  We do have 'real' code quality built into the project, it's our nightly automated tests.

  I've never really cared about code formatting.  If' someone would like to be the project's formatting czar, I'm all for it.  But I'm too busy to even spend even 1/2 a day working on this before the production release when there are far more important problems. 

  If there are big gaps in the documentation, please let us know.  

  Finally, JavaScriptMVC has been used in some of the most serious and sophisticated applications.  Attracting 'serious' developers has never been the problem.

  

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com


Justin Meyer

unread,
Oct 11, 2010, 6:24:40 AM10/11/10
to javasc...@googlegroups.com
Btw,
  I really appreciate your feedback. We definitely care about code formatting, and you can expect the production release, and likely most releases going forward to have a unified coding style.

  I just have never personally cared.  


Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com


Reply all
Reply to author
Forward
0 new messages