Integrating MooTools into SocialCalc
Casey West
to make front-end development much easier. I like this package
because it's small, modular, portable, and Open Source. Here is the
description from the website:
"MooTools is a compact, modular, Object-Oriented javascript
framework designed to
make writing extensible and compatible code easier and faster.
MooTools lets you
get the job done efficiently and effectively."
http://mootools.net/
I've found that to be true. During some exploratory work on the
SocialCalc user interface I integrated MooTools to great success. It
made the job much easier (minutes over days) and enjoyable. This
package is well documented, compressed (very small footprint), and
memory footprint aware. The base package - for my needs - is just 15k
and it's packed with functionality. Other toolkits are huge.
prototype.js claims to be small and it's 47k!
The current JavaScript in WKCjs.txt and WKCeditjs.txt is 54k and
downloaded each time the user makes a new request. I endeavor to make
that download happen just once (cached). Furthemore, with the help of
MooTools I can decrease the size of our custom JavaScript code
significantly.
MooTools is distributed under an MIT-style license. The MIT license
should not hinder the use of SocialCalc in any way. Here is the main
body of the OSI approved license, verbatim:
Permission is hereby granted, free of charge, to any person
obtaining a copy
of this software and associated documentation files (the
"Software"), to deal
in the Software without restriction, including without limitation
the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/
or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be
included in
all copies or substantial portions of the Software.
http://www.opensource.org/licenses/mit-license.php
Does anyone take issue with this? If so, why? If I don't hear
complaint (and I hope I don't ;-) I'll begin integration tomorrow.
Further reading for those immersive types among us:
* http://en.wikipedia.org/wiki/MIT_License
* http://www.prototypejs.org/license
** Socialtext already distributes prototype.js, which is under the
linked MIT license
--
Casey West
Tony Bowden
> The current JavaScript in WKCjs.txt and WKCeditjs.txt is 54k and
> downloaded each time the user makes a new request. I endeavor to make
> that download happen just once (cached).
Have you a plan for how you're going to do this part?
> Does anyone take issue with this? If so, why? If I don't hear
> complaint (and I hope I don't ;-) I'll begin integration tomorrow.
No complaints from me. Dan?
Tony
Casey West
On May 29, 2007, at 1:33 PM, Tony Bowden wrote:
>
> Casey West wrote:
>> The current JavaScript in WKCjs.txt and WKCeditjs.txt is 54k and
>> downloaded each time the user makes a new request. I endeavor to make
>> that download happen just once (cached).
>
> Have you a plan for how you're going to do this part?
Nothing terrific at the moment. There are a number of things we'd
like to get right in the long term, such as:
* Ensure browser caching
* Invalidate browser caching when JS changes
* Small download size
* Simple to hack on
We can solve these problems fairly easily over the coming weeks, but
here's where I want to start:
Collect JavaScript
Put our JavaScript files in a directory
titled `javascript`.
Build JavaScript Payload
As much of our JavaScript as possible
(all the static bits) should be bundled
together in one file as a single download.
This reduces wait on network latency for
gathering all the JavaScript together on
the browser side.
Handle the Request
Next, a handler must be built that responds
to something like the following CGI query:
?action=javascript_payload; and responds
with the Javascript Payload.
Update HTML Header
Add a <script> tag to the HTML header that
downloads the JavaScript Payload.
How's that for a start?
--
Casey West
Tony Bowden
> Build JavaScript Payload
> As much of our JavaScript as possible
> (all the static bits) should be bundled
> together in one file as a single download.
> This reduces wait on network latency for
> gathering all the JavaScript together on
> the browser side.
What's the trade-off here between this and invalidating the entire
'cache' when you change something in what would have only been one file?
It's not an area I know a lot about, so if someone has already written
it all up feel free to point me to a URL somewhere, rather than trying
to explain it all from scratch...
> How's that for a start?
I look forward to watching it come together!
Tony