Let’s make 2008 the year of embracing the server side with Ajax
I am always fascinated by the amount of Ajax tutorials and examples out there that totally ignore the backend part of an Ajax app. A lot of times you'll find page-long ravings about the 6-7 lines of JavaScript that allow the client to make an HTTP request but when it comes to talking about the proxy script needed to allow for cross-domain requests a lot is glossed over as “you don't need to know this, just use this script”.
That would not really be an issue if the scripts offered weren't that bad. Unsanitized URLs are the main attacking point for cross-server-scripting attacks. If you use a PHP_SELF as the action of your forms you shouldn't be too confused about a lot of mail traffic from your server or text links on your site you didn't sign off and get money for.
The other thing about Ajax information on the web that amazes me is that people keep complaining about the slowness and problems with converting data from one format to another on the client side. Let us not kid ourselves: even after all the articles, books and podcasts about Ajax we still have no clue whatsoever what a visitor uses to look at our products. We cannot tell for sure what browser is used, if there is assistive technology involved or anything about the specs of the computer the browser runs on. This to me makes the client side the least preferable place to do heavy calculation and conversion.
The server side, on the other hand, is in your control and you know what it can do. Complex regular expressions, XSLT conversion, all of this is much easier to do on the backend – and you know that the text encoding will work to boot. A lot of complexity of Ajax apps is based on bad architecture and design decisions and on relying on the client side to provide necessary functionality.
So if you ask me what the ratio of client-to-server code of a good Ajax app is I'd say 30% client and 70% server. The 70% on the server should be used to provide security, non-JavaScript fallback functionality (yay accessibility) and conversion of data to small, easy-to-digest chunks for the client (think HTML and JSON). The 30% client side code should mainly be used up to enhance the usability of the product and make it easier for your visitors to reach their goals.
So here's my plan for 2008: whenever I talk Ajax I will try to cover as much backend as frontend. I'll do this by partnering with other experts as I myself created some terrible PHP in the past. I hope that others will follow that example as Ajax is a wonderful opportunity to bridge the gap between frontend and backend engineering – and we have to talk to each other to create a good app.
Technorati Tags: ajax, development, php, security, xss, architecture, tutorials
December 30th, 2007 at 4:41 pm
Well said. I think you could actually drop the Ajax from the title. Let's all go out and hug a server-side developer. Everyone can learn something new in this mad cat multi-disciplinary world of ours and more thought going into web application architecture the better.
December 30th, 2007 at 8:00 pm
indeed, well said. Let's not forget that the other half, the back-end developer is a fellow developer as well. And if he is properly trained, he can provide the front-end developer with proper code. That is if the front-end guy knows what he needs.
In the end it all comes down to communication...
December 31st, 2007 at 4:51 am
That's a solid plan. I've seen some pretty horrendous stuff (and probably contributed to it, a little, myself). I think the reason people have often foregone covering the backend is in the desire to be generic. When I wrote my book, I specifically left out any server-side code (even though they asked for examples) because it was a client-side book. I didn't want to single out any particular language.
The idea of including more server-side info will be good to see, in whatever language.
December 31st, 2007 at 5:45 am
Isn't the point of Ajax to bring the front and back end together. Ajax for just front end prettiness is missing the point. Guess it come down to it's easier to do. People are lazy in general.
December 31st, 2007 at 10:57 pm
@Jonathan That's also the reason that conference organisers I've spoken to give for not including more back end bits and pieces in your average conference programme, even with two tracks. I actually think their are a number of areas which are generic enough, or interesting enough, to warrant some attention; messaging systems, Erlang, RESTful design principles, deployment, scaling and caching to name but a few. Or maybe that's just me?
January 2nd, 2008 at 10:24 pm
Yes, yes, yes! A hundred times, yes.
This last quarter, I’ve had the luxury to work on a project where I got to actually campaign for (and make a strong business case for) 100% functionality support for non-javascript users. (Of course, it’ll be slower without javascript, a bit less slick and sexy, and generally not quite as cool. But everything will work, and will work about the same, but with more page loading.)
We’ve built each feature first assuming that there will be absolutely zero javascript involved. It must work and look right and function before writing a line of script. Then expose only the bits of the API that you’ll need so that you can hit them as a web service. Last, wire up a bit of script to hit the API and move the DOM around. In the end, the DHTML bit turns out to be the easiest part (with the YUI connection lib, it’s damn near trivial sometimes.) The tricky thing has been avoiding duplicated code, another zero-exceptions mandate we’ve accepted.
Wannabes and inexperienced developers write a lot of code because they want to show how clever they are and how much they can do. A good developer writes as little code as possible, because he knows that his goal is a product that works, and that each line of code is a necessary evil. Don’t be flashy! If it can be hidden on the server, do it there!
January 4th, 2008 at 8:17 pm
Absolutely, the client side is the last place you want to do any transformation.
January 9th, 2008 at 3:19 pm
Glad to hear it. As a beginner trying to learn this stuff, I’m amazed at how MANY client-side scripting tutorials, libraries, etc. there are on the web (a lot of it contradictory or over-simplified) and how little server-side code there is to find.
I’m finding the server-side stuff to be much trickier, especially when trying to provide both JS and non-JS capable code (as Isaac Z. Schlueter discussed above).
January 15th, 2008 at 11:38 pm
Interesting that the Technorati tags only contain one backend language - PHP. Is it because there are many more variations in environments server side that tutorial and example authors are reluctant to come up with anything based on any one technology for fear of losing an audience?
Not that I don't agree with the sentiments, I'm in the lucky (some would say) position of being the client and server developer both professionally and for fun - one thing that does give is the ability to more easily decide the best (not the correct, sometimes) place to "do stuff", there's certtainly fewer meetings and less red tape ;)