JavaScript Utilities Project

A set of javascript-related utilities and components for Web developers doing client-side development...

The JavaScript Utilities project is oriented at developing a set of tools and components geared toward enhancing the development model around JavaScript as used for implementing rich Web applications. For example, if you are developing script-based code, you probably have desired the ability to add debug code, to increase the robustness of your code, but do not want to take the performance hit of doing so. Or you may be writing lots of script, and want to break it out into multiple files, but do not want to take the hit of multiple downloads. You might even want to generate different script for each browser, without sending down the code for all browsers to any one browser? Any of these problems sound familiar? If so, this project aims to provide some solutions. Read on...

The project introduces the notion of .jsx (extended JavaScript) and .jsa (JavaScript assembly) files. JSX files provide the ability to include conditional code via familiar preprocessor directives such as #if, #else, #endif and so on. I have also introduced a special single-line syntax to avoid requiring a terminating #endif for convenience: ## DEBUG. The tool processes these directives in order to produce a standard .js file. JSA files build on top of .jsx files. While they can include normal JavaScript and preprocessor directives, they are primarily there for including individual .jsx and .js files via #include directives. This allows you to split your script into more manageable individual chunks.

In addition to processing preprocessor directives, the tools also allow minimizing the script by stripping out whitespace, and comments. If you want to preserve some comments, which are significant, such as copyright headers, you can use the //! comment syntax introduced by this tool which results in a regular // style comment being emitted.

The full set of preprocessor directives, and the options, tools etc. are described in the readme. The downloadable binary consists of the tools, a sample Web project, a sample msbuild project, and an msbuild targets file to get you started.

The functionality can be used in three modes:

  1. A set of standalone tools that output standard .js files that you can then deploy to your web site. Command line parameters are used to control the behavior of the tools.
  2. A couple of IHttpHandler implementations that allow you to dynamically convert your code into standard .js files. This is the mode where you can benefit from implementing per-browser code in a conditional manner. AppSetting values in configuration are used to control the conversion behavior.
  3. As a script project in VS using an msbuild project along with an msbuild task that comes along with the project. MSBuild project properties are used to control the conversion behavior.
So you have some options to pick the approach most suitable for your needs.

Give this a try. There are some perf related enhancements I plan for the next release, but in the meantime, if you have suggestions for useful features, or bug fixes, or just want to share your experience in general, then by all means, the comment form below is your channel to pass along that information.

Updated on Thursday, 8/4/2005 @ 10:41 PM

Announcements and updates:
[7/7/2006, StripCommentsOnly + Inline conditional directives] Added a minimization option to strip comments and preserve whitespace as well as a new inline conditional pre-processing directive
[11/12/2005, RTM Support, Bug Fixes] Updated to work against RTM .NET/VS, and bug fix regarding #else directives
[8/17/2005, MSBuild Support] Added ability to use the utilities in an msbuild project via a custom task.
[8/7/2005, JSA Files] (Internal Release) Added JavaScript Assembly (.jsa) files support

Comments

17 comments have been posted.

Manu

Posted on 8/5/2005 @ 2:43 AM
Nik, the idea seems cool to me but with binary only one can't get into it to improve it or tweak it. Any chance to get the source?

Javier G. Lozano

Posted on 8/5/2005 @ 7:09 AM
This looks really cool, Nikhil! How far are you thinking of taking this project? Also, would you like any help? ;-)

Nikhil Kothari

Posted on 8/6/2005 @ 11:09 AM
Currently I have a few ideas around and better script authoring/management approaches and performance of the dynamic conversion as next steps for the project. I am sure users will find other things... so please do leave suggestions, ideas for improvements or tweaks here... I will track the comments, reply and incorporate them as appropriate into the project over time.

Jarred Nicholls

Posted on 8/16/2005 @ 9:22 AM
I think this is a great idea Nikhil. If you would like help to incorporate a obfuscator-type engine to make javascript code extremely hard to read, I'll certainly be glad to help you. That's my one major fear of committing to an AJAX-style of web development, that most of my logic will be open for everyone to reverse engineer and steal. I'm ok w/ Open Source and all...but if this were for a production application for a company who wanted close-source, it wouldn't be viable.

Thanks for your efforts. We all appreciate it.

Nikhil Kothari

Posted on 8/17/2005 @ 3:59 AM
Jarred, thanks.

I have been thinking about obfuscation functionality. I totally buy in to the concern about script being easily vieweable. Currently the tools condense the script, which makes it a bit ugly, but doesn't mangle names or do anything fancy. There are actually quite a few complications for obfuscation that need to be thought through the moment you have a large script framework, or use external frameworks because you would need have all script references, and do symbol resolution to figure out what is private and what is not in order to obfuscate. This also means you have to write a parser - the logic for the current set of functionality does not need a lexer, much less a parser.

However, I am interested in hearing thoughts and feedback... so keep it coming.

Jim Geurts

Posted on 8/18/2005 @ 12:12 PM
Nikhil,

This is a great idea! I'm curious if you've thought about (or would be interested in) extending the idea to work with .css files too...

Nikhil Kothari

Posted on 8/18/2005 @ 10:27 PM
Jim, interesting question. Yes, the thought of minimization for css files did cross my mind but I didn't expect it to be a common thing to want to do. Same question about splitting up of css files into smaller bits. I'll be curious to hear your thoughts. Others want to chime in?
One side effect of doing so for css files is it will probably get in the way of design experience. For JavaScript there isn't much in terms of design experience for this approach to get in the way of.

Jim Geurts

Posted on 8/19/2005 @ 6:38 AM
The design experience is minor compared to the user experience, IMO. For the project I'm working on, we have about 5-10 stylesheets. We have browser specific stylesheets as well as common/shared styles... I would say that about 50% of the time, when refreshing the page, the browser will fail to load one or more of those stylesheets. btw, this behavior happens in both IE and Mozilla...

I would personally think that the browser would have a better chance of completely downloading just one file, rather than 10. So it's all or nothing.. rather than sporadic style loading behavior.

The way I see it, is that if a developer wants to maintain their design experience, they can create a temp .css file and just import those into the .cssx (or whatever it would become)

Brian Zinn

Posted on 9/4/2005 @ 5:34 PM
Nikhil,

By combining the javascript and css obfuscation/minimization you could obfuscate/minimize the code even more like when, for example, the javascript sets a style for an element.

I'm wondering, however, if that's a good idea when you could also set CssClass properties in code that would no longer line up... Also, by minimizing the code (assuming renaming of variables) it is not possible for other code to be registered using the same variable names. ASP.NET takes care of this with controlId, which is available before rendering - I don't see how you could easily do this with javascript variables and css names.

Nikhil Kothari

Posted on 9/7/2005 @ 8:44 AM
Brian, the minimization currently does not rename identifiers. The prerequisite to doing such a thing requires a compile-like step, taking into account all scripts involved. Otherwise, it would have to be based on naming conventions which sort of doesn't work out, because everyone might believe in different naming conventions, and/or has to change code to use the tool.

Jim, thanks for the feedback on the css scenarios. I will think about it further, in terms of whether to create such a tool, or perhaps let someone else in the community take a shot at it :-)

Tatham Oddie

Posted on 11/13/2005 @ 4:48 AM
I'd be interested in the CSS support as well.

Currently I write CSS files like this: http://viavirtualearth.com/VVE/Skins/Vision.css so that I only have one file to import, but I have some basic ways of breaking it up. On really complex sites (like http://whatcanido.com.au/Skins/NoLimits.css) we end up with about 15 HTTP calls just to get the CSS though which is a performance hit itself.

Combining, and minimizing the CSS would be great I think. (And if it was open source i'd be happy to help out.)

sasa

Posted on 12/14/2005 @ 1:32 AM
<html>

Jason Bunting

Posted on 12/19/2005 @ 9:43 AM
Hey Tatham Oddie (if you ever read this) - Rory Blythe created an HttpHandler for CSS files quite a while ago, check it out at http://neopoleon.com/blog/posts/4069.aspx. I am sure it would be easy to extend it.

Alex Osipov

Posted on 5/5/2006 @ 9:18 AM
Hi Nikhil - great tool. Any plans to extend this further? Would be great to be able to add #region's with collapse/expand support in VS. Some of my Atlas JS objects are getting large and are becoming a large pain to navigate (I currently use bookmarks). #region support as well as class outline support would really make this tool great.

Silvia

Posted on 5/28/2006 @ 5:09 PM
Hm... Nice project....

Mari

Posted on 5/29/2006 @ 3:16 PM
I think this is a great idea Nikhil.
I would personally think that the browser would have a better chance of completely downloading just one file, rather than 10. So it's all or nothing.. rather than sporadic style loading behavior.

Nikhil Kothari

Posted on 7/31/2006 @ 3:12 AM
I have revamped my http://projects.nikhilk.net site to add bug tracking lists, discussion forums (and a wiki which I'll use over time to better talk more about the projects). The site runs on Sharepoint 2007 beta, and additionally I am also new to Sharepoint itself (it is nice to use something built on ASP.NET though :-) ... so if things aren't working for some reason, just use my contact form.

Over the next day or so, I'll be closing the comments on this post. If you think there is a comment here, where you asked for a bug fix, or provided feedback, now would be a good time to test out how well the bugs list works on the new site by adding your entries there. It will hopefully provide a much better tracking mechanism.

Thanks for all the comments! Looking forward to more conversation ... perhaps a bit more structured.
The discussion on this post has been closed. Please use my contact form to provide comments.