Blog

|

Projects

|

Photos

|

About

|

Contact

JavaScript Utilities Project

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

I am finally getting around to cleaning up and sharing something I started a long while ago: an extended JavaScript format, and some conversion tools to convert it into regular javascript.

The extended javascript format (.jsx) introduces preprocessor definition capability (#if, #else etc. along with my very own single line preprocessor definition mechanism such as ##if DEBUG) to allow writing conditional code. This would for example, enable you to build a debug mode of your script, without impacting the performance of your code once its in production. The tools also condense script by stripping out whitespace, and comments while allowing you to specify and preserve significant comments such as copyright headers, so as to minimize download size, and make the script somewhat harder to read.

The conversion utility can be run as a standalone tool if you want to deply regular .js files to your web site. However, the real value of this tool is that it can be used as an http handler to allow dynamic conversion of .jsx files into .js files. In the dynamic conversion case, you can also use preprocessor directives such as #if IE and #if MOZILLA to conditionally generate browser-specific code from the server!

I am putting this out as a project... so it has a page of its own, along with a comment form, an RSS feed etc. Head on there now for more details and binaries...

Posted on Thursday, 8/4/2005 @ 10:41 PM | #Projects

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

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.

All content © Nikhil Kothari.
The content on this site represents my own personal opinions and thoughts at the time of posting, and does not reflect those of my employer's in any way.