For my various, larger PHP projects I have used frameworks, most of which have enforced MVC to some degree. Having come to PHP from Java I have been very comfortable in that environment. Frameworks get heavy quickly, though. In recent years I have done less of the big projects and am now down to being mostly a one-man show. If I use a framework at all it is CodeIgniter, which is refreshingly light and solidly MVC.

When it comes to jQuery, I have mostly followed progressive enhancement concepts, building a solid site/app with PHP and then enhancing the user experience with stripy, sortable, refinable tables, accordion menus, client-side form validation, autocomplete/suggest fields, date pickers, and the like. Pretty humdrum, I suppose. I’ve built a couple of web apps with ExtJS, but I’ve never gone that far with jQuery.

Lately I’ve looked at what is being done with MVC for jQuery. I’m disappointed, so far. JMVC is cool, but it is pretty monstrous in view of how light jQuery really is. Maybe I’m wrong, but one of the first things they started talking about was needing Java, installing this and that, and downloading large files.  At the small framework end of the discussion are Ben Nadel’s CorMVC, which is spartan and seemingly orphaned, or Jamal, which seemed to be going somewhere, but has not seen any updates in over two years. At the huge end, SproutCore is cool and PureMVC is spiffy, but they require all-or-nothing buy-in and a major investment of time to start up with, which brings me right back to ExtJS 4 where I’ve already invested myself.

Maybe I’m not ready for an MVC framework with my jQuery, or maybe jQuery is better off outside of that box. Or, perhaps I’m just missing the point somewhere along the line. If I’m going to be building a fairly large application that will be used in an environment where I can control a lot of the variables, perhaps jQuery is the wrong tool for the job. Tell me if I’m all wet. Programming is scheduled to start in late April. All suggestions appreciated.

There are plenty of ways to debug JavaScript. The first one you ever used was probably just running it in the browser and seeing if it failed. A step up from that is to open a console window and look for errors or warnings. Some IDEs have JS debugging and some even have JSLint available. I’ve tried JSLint, but having never worked with more than one other person on a JS project, I trust my browser add-on tools most often.

This past week there has been a bit of hubbub about a fork of JSLint named JSHint. Since I will be working on an open source project soon, I figured I’d have a look at this fork and see if it was a usable tool. I’m not sure if this is good or bad, but I was able to tweak the rules so that my jQuery got a passing grade. Here are my settings…

• Allow assignments inside if/for/while/do
• Require curly braces around all blocks
• Allow debugger statements
• Allow logging statements
• Require ===
• Require for..in statements to be filtered
• Apply strict whitespace rules

Notice that I don’t require variables to be declared before usage, nor do I disallow bitwise operators. Plus, I allow assignments inside if/for/while/do blocks. Perhaps I’m just a bad programmer. On the plus side, I am not giving a pass to evals or checking line breaks. I used to put commas at the beginning of the second and subsequent declaration lines, but that’s probably not something I should inflict on other people.

After playing with it for a bit, I really like JSHint. It allows groups to agree on what works for them. Win-win.