This post originated from an RSS feed registered with PHP Buzz
by Alan Knowles.
Original Post: SVG Graphing - And prototype stripping
Feed Title: Smoking toooo much PHP
Feed URL: http://www.akbkhome.com/blog.php/RSS.xml
Feed Description: More than just a blog :)
Remember the good old days where phpnuke was the worst code since
sliced cheese, and thousands of idiot's had installed in on their
server waiting to be hacked into..
Well, It's a bit like how I felt this week trying to solve my svg graphing issues..
A bit of background, In the last week I just pushed out the latest
version of our Anti-spam / Mail control application, the big new
feature was a beta version of the statistic's and analysis section.
Where we showed nice little graphs about how much work your staff where
doing and if they had really been sending jokes all day long or just
reading facebook spam
Open Flash Charts
While the database side , the design is quite interesting, I did not
really spend to much time thinking about the frontend - as I like to
keep that flexible (read throw away). So for the first beta I decided
to use Open Flash Charts. The current version is extremely well
designed, in terms of the chart generation consists of delivering a
JSON file to a static single Flash file. The JSON file sets the graph
type, and date etc..
It's very quick to set up and work with, and the graphs are quite
pretty, and a cutely interactive. And for our first beta it's just
about OK.
However for anything other than a beta, there are rather serious problems with it.
a) It's dog ass slow, to load, render on anything but a brand new overspec'd PC
b) The flash file is quite large, and yet another overhead to a already large application.
c) Having multiple Flash graphs on a single page, just makes the above two problems worse.
d) It depends on closed source tools (Actionscript compilers etc.) - Never a good idea.
e) Printing of Flash in firefox is broken (at least on linux)
or basically all summed up... Flash sucks
PlotKit
So after beta 1 was released to testing, I started the hunt for an
alternative. Since the 'correct' method to do graphs on the web is
really SVG, and as I like to shift all the pointless processing to the
end users PC. JavaScript to convert the data into a chart is really
the ideal solution.
Pretty high up on google's list is PlotKit, which has some really nice
demo's on the site, It depends on two other pieces of code, excanvas
(as nice self contained javascript file that handles SVG compatibility
issues with IE/FF/Safari etc.) and MochiKit.
MochiKit
Since MochiKit is none too small, and would add to my javascript
overhead, I thought I'd check out what it was, and see if it was really
needed. What I saw, was more "nightmare on nuke street".
The front page of the web site claims quite large "MochiKit makes
JavaScript suck less", That should be paraphrased, "only if you are a
Python nut-head" - otherwise it make your Javascript code into complete
jibberish. __self__, __new__, __screwed_up_language__ everywhere....
<big rant> The dumb f*** who wrote it decided that Javascript was
not Python, so they should try and make it's syntax as close to python
as possible. Ignoring the fact that Javascript syntax just solves
problems differently, it does not need fixing or even breaking to be as
badly designed as python.. </big rant>
Anyway after digging through the code to plotkit, and mochikit, I came
to the conclusion that they had developed a piece of code that was
completely unmaintainable or extend-able. So was forced to keep looking
for an alternative.
Quite a way down google's list (search svg javascript graph) I finally
found Plotr, Basically someone else had obviously looked at PlotKit,
and decided that Mochikit was just so ugly, that removing it from the
application was the only sane thing left to do.
What they chose rather than MochiKit, was Prototype, which in general
is considerably better than MochiKit. And basically removed all the
Mochikit dependancies and replaced them with Prototype. This made the
code quite a bit simple to read and understand, (they also added
comments), although I'm not to keen on this type of commenting, as I
find it add's noise, and makes the code less readable.
** It looks like the author of Plotr as gone on to start Flotr -
another graphing library.. - did not notice that until I'd commited to
working with Plotr...
Prototype
What I wanted to do however was reduce the size of the Prototype
dependancy. So I started having a look at Prototype's internals.
Splattering the namespace
Unlike Ext, and Roo, Prototype's core creates quite a few global
properties, $, $R, $$, JSONSomething and Element which by the looks of
things are totally unnecessary, and make it difficult to work with
other frameworks (or potentially other code), This is downright bad
design, and could easily be rectified by putting almost all of those
under the Prototype.* object.
Along with this, there is quite excessive use of adding to Global
Prototypes, String.prototype gains about 20 extra methods, some quite
useful, or wrappers for compatibility, other seem more like features
for features sake, and should really be moved to a Prototype.String
object or just removed.
What make me wonder the most was the way that prototype adds properties
to HTML and DOM objects, $("xxxx") - get's does a getElementById(
"xxxx") and returns the DOM/HTML object overlaid with all of the
properties from the Element object. In Ext/Roo's 'Roo.get("xxx")'
method create's something like the 'Element' object , Roo.Element, it
puts the original DOM object in the return value ".dom" property. Hence
making documentation clearer and code considerably more managable. Not
so much of WTF did that method come from? when reading code.
Anyway - I managed to give Prototype a bit of a diet, so it's not so
much of a Namespace/bandwidth hog. You can download the lightwight code
here: http://www.akbkhome.com/svn/javascript/plotr
Note the full bundle (protolite, excanvas + plotr comes in at 54K or ~
15K if you are serving javascript with the mod_gz library...
Previous Topic
