Syntax Highlighter

Google+ Badge

2009-12-17

One server to rule them all

Ok so I had a rant today on another blog, I felt I wrote enough I should put it here in case I need to cut and paste it again next time I come accross someone who is ignorant of Java servers and the benefits available for a script agnostic approaach to server design.

Neil said: "Why on earth would you even consider using Railo et al to run your
code, when it could never be as good as your language/platform specific
setup you're using now."

1. From what I have read Quercus is
faster than the standard PHP engine and can do several things like db
obfuscation that the dll version doesn't do well. I've heard a lot
about how slow Ruby is so I had assumed that jRuby may also be faster (I have since checked and yes jRudy claims to be faster and more powerful).

2.
If I ran a hosting company and had the option to install languages
separately with all their different admins or settings or all at once
with a well thought out admin structure and a more powerful level of
security sandboxing, I think it would be a no brainer if there were not
a huge number of compatibility issues.

3. jRuby, Quercus and
Rhino all have very active development teams already so that wouldn't
change and other servers can integrate them without obscene amounts of
effort. Quercus is already installed with Railo, you just have to
manually add it in the Resin config file currently so adding a switch
in the admin to do that would be simple I suspect.

CFgroovy2
makes it easy to switch between the languages already so given it is
already done as a proof of concept I would not expect adding files to a
class path via admin toggles to be a full time job, perhaps Sean could
clarify?

You may have switched to Ruby, that's no doubt been
great for you, like when I switched from ASP & PHP to ColdFusion.
But for many Java developers who want fast scripting languages with the
ability to use elements of Java they love then Java based versions of
the scripting languages can be very advantageous especially when it
comes to working with and using legacy code.

I think you are
very wrong in being so dismissive of the idea just because in your
perception it wont suite you, think outside your box, there's plenty of
issues developers around the globe face and there is definitely
positive movement for change and having options to get past them. .NET
has JScript, VBScript, FSharp and CSharp because MS are smart enough to
know that some jobs are done better by different languages.

JavaScript
is the most important language for the web and is grow in popularity
rapidly (more Java/JavaScript servers than any other language now I
believe thanks to Rhino looking up SSJS on wikipedia), supporting Rhino
is a no brainer, support for actionscript could also potentially be
added as it is based on JavaScript.

More options is always
better who cares if there are some narrow minded users of a language
that stubornly refuse to investigate better options, Mono, Quercus,
jRuby all show that there is a need for languages to be implemented in
different ways for different needs. Bringing several of these into one
place would draw in more communities of developers to one place which
can only be a good thing as shown by Apache foundation itself!

2009-12-03

CFJS, one step closer to paradise

I have been obsessed for a long long time about JavaScript and the need for it to be a core factor in bringing ColdFusion out of the niche and into the mainstream. I have a dream, that dream is CFJS a JavaScript specification for CFML. A spec for CFML engines to implement so that they can create the first real consensus of a JavaScript server standard, with potentially three different servers all implementing the same spec that'd be two more than any other implementation! There are plenty of JavaScript servers out there, Rhino hacked into them in one way of form, but none that really offer any real appeal or power behind them. All ColdFusion engines offer superior clustering and database handling with well established power and performance and with integrated JavaScript with mapped functions and classes there's no reason for it not to take off among developers who love both ColdFusion and also the new masses of JavaScript developers who have come into the fold via jQuery.

CFJS is a concept that is almost a reality in one form now thanks to Alan Williamson over at Open Blue Dragon: http://alan.blog-city.com/cfjs_alpha.htm While I really like the work Alan has done there are a few things I would suggest, the first being the JavaScript scope/namespace to be used, currently $cf I would prefer to see one of CFjs, CfJs or preferably cfjs if it is encapsulated by a closure then developers can use whatever shortcut they like just as they do with jQuery becoming $ within a closure when making plugins (when they're done well! ;).

My next desire is to create a clear specification for running frameworks within CFJS, a clear definition within the Application.cfjs file for a framework scope with functions to enable/disable and choose versions of frameworks to use, so cfjs.framework.list() would return an array of framework property objects with their versions and they could be used like:

$ = cfjs.framework('jQuery','1.4');
Fb = cfjs.framework('FuseBox','6.0');  \\(-_o)//
Spry = cfjs.framework('Spry','0.1.6');
CommonJS = cfjs.framework('CommonJS','1.0');
cfjs.application({
    onApplicationStart: function(){}
})

Then the frameworks could be pre-loaded compiled and poentially optimised to hopefully be even faster.

Speaking of compiled and faster, have you seen John Resig's Micro Templating project example?

http://ejohn.org/blog/javascript-micro-templating/



I like the  idea of using something like that only adding
a (potentially jQuery based) compiler so there are no variables in your HTML code AT ALL. I wrote
some code earlier and included three tbody tags in a table one
with a class for no-data-items one for data-items and another called
data-item-template.



The template version looked kind of like:

<tr class="data-items template">


    <input type="hidden" name="temp-id" class="data-item-id" value="temp-value" />



    <td class="data-item-name">User Name</td>



    <td class="data-item-email">User Email</td>


</tr>



I then added a call to:

jQuery(HTML template selector).template(array, function(template, record){


    template.find('data-item-id').val(record.id);


    template.find('data-item-name').text(record.name);


    template.find('data-item-email').text(record.email);

    tbodyData.append(template);


});



Now I haven't actually built it to work yet just throwing ideas around
in my head of just how beautiful templating in server-side JavaScript
can be, but what I intend on checking when I have time is how fast this
performs and whether or not parsing the template first so record.id
would be the text '<cfout>record.id</cfout>' and then using
Mr Resig's templater to do the rest would potentially be faster given
it wouldn't need to continually run a bunch of jQuery calls. Then
there's the option of e4x which I suspect would be faster again. I really wish I had more time each day to play with cfml!