Shadow's Workshop

I shall do a presentation about CodeIgniter an open source PHP framework on the 12th of April at Rosdev. I got the news on friday and it really made my day, what more can I say? Rosdev is held in Bucharest and this will be my first trip to that city, I'm really curios too see how it stacks up again's Budapest and Vien.

As a little side not to this post I do have to tell you that my knee feel's alot better.

Have a great day

Yesterday i picked up a book. You know one of those phone book sized category of technical books. At first i thought, it's okey i won't read it all, just the good parts but as soon as i started i was hooked. I started around 8-9PM and i couldn't put it down till like 4 AM. I think this is the first ever tehnical book i read in which i found something that i agreed on with the author. The book claimed to be a complete reference on ajax, but turned out to be more than just a reference. It's more then those books which tell you something like:

In order to start an XHR request you just instantiate the XMLHttpRequest object and then send it off.

It does that too don't get me wrong, but it also tells talks a great deal about network problems and how to deal with them. In short it does everything and then in the end it even gives you a bag of chips.

As i was reading it, i felt like the author really knows what i as a client-side developer go trough and i'm not talking about javascript problems only. Especially in the chapter about ajax architecture i found a part with which i totally agree with.

Originally posted by Ajax: The Complete Reference:

Whether it is an IDE generating the code like ASP.NET, a special magic statement you
run like Rails, a function call to make the JavaScript go in, language translation from what
you like to JavaScript or some newfangled tag abstracting the details away, underneath it all
is our friend JavaScript and likely lots of it. JavaScript using XHRs, filled with closures and
chock-full of all sorts of interesting challenges both annoying and inspiring.
So why do we pretend so hard that JavaScript isn’t there? Some people are ignorant of
JavaScript, some just don’t like it, and some do, but whatever your feeling is about it, the
fact is that it isn’t going anywhere. JavaScript is what is driving Ajax, like it or not. So why
abdicate your ability to make Ajax fly? Instead we encourage you to dive in.

I know just recently i had a discussion with someone about the place javascript should be written. I am a php guy so i come from a server side background and yet i still think that javascript should be written and not generated. At work just recently i created a clone of Xajax using the YUI and even though it can be used by people who do not know javascript i find myself tring to find a use for it, i wrote because i had to i rather use my own then xajax, but i for one do not use it at all and still struggle to find a proper use case for it.

I found it that it limits me, i can't do stuff if i only rely on the server side, then again it all depends on whether you like a thick or a thin client, loose or tight coupling. Generating client-side code on the server side with the use of some kind of wrapper does mean that no time is spent on training people the intricate ways of javascript with all it's quirks and inconsistencies.

Originally posted by Ajax: The Complete Reference:

Ajax development environments that generate JavaScript or leverage
and insert existing libraries automatically give us the illusion that there are less moving
parts, but the situation is the same. What’s worse is now we lack control and find ourselves
only as good as the framework we use, with no way to easily fix client-side issues without
getting into the plumbing of the development system and overriding what it does. When
we start to get into that depth, it begs the question of why we bothered to do it this way.

I couldn't agree more, i wrote that clone i mentioned above and gave it kind of nice usefull extra features like selectors, but it is still ridiculous to try to think of the client just in terms of a limited number of functions. Even though it's made with the help of YUI which basically means that i could use any of it's numerous widgets, it would still mean that i would have to know how to write the javascript code to send it back to the client as a string and then have it evalueted or write a wrapper in javascript so exactly as pointed out we are just as good as our framework/tools.

Using this pattern of calling client side code from the server is like having to have to hit a nail with a hammer, but since we do not like to hammer, we go over to our friend(the framework) and tell him to use his hammer, if he doesn't have a hammer we'll need to make one for him. So in the end we still need to atleast know how a hammer works, and how we can make one, we still need to touch it, no matter how much we dislike hammering.


To draw a conclusion i defenetly recomand this book for anybody interested in Ajax, and i also would like to leave you with some words of wisdom straight out of the book:

Originally posted by Ajax: The Complete Reference:

Do end users care what your application is written in? Do they feel a sense of security
knowing you wrote it in Ruby or do they have fear and dread because JavaScript was
included? Do they marvel at your MVC pattern and programming prowess? Do they read
your comments and wonder what you were thinking when you build off that neat recursive
algorithm? We hope these ludicrous statements drive home a point: the users don’t care.