Recently I experimented with a jQuery event calendar on our Booking System. Our previous version uses ASP.NET to build the booking chart as a whole on the server and then renders the lot to the browser. It was a bit slow and clunky, but worked.
I wanted to have a PHP version of the Room Booking System so did a quick port from the ASP.NET C# to PHP, and then I dropped the jQuery fullcalendar component on the page. I used a web service for the data which was still written in C# against a Microsoft SQLServer database.
On a little more tinkering and refactoring, I found I could get rid of almost all the PHP/.NET code as it was only used to initialise the page. Now I was left with a page with effectively just HTML and JavaScript using a AJAX to call a JSON data feed from a REST web service.
The effects were stunning! Besides looking nicer, the speed of update was incredible – like a Windows application. Of course, this is achieved because the page runs almost entirely in the browser and calendar navigation may request just small amount of data using AJAX against the web service.
Could I write the entire application like this?
It reminded me of programming in the 1990’s. Web pages were HTML with a bit of JavaScript; we then added a little ASP to get data from a database and stick that on the page. Getting data on a page was relatively easy even then; the problem has always been when we want the user to interact with it. Even the simple stuff, like only allowing a numeric digit into a text box, checking for valid date, data grids or even simple popups were not as easy as in a Windows app.
Why? Because pure JavaScript is slow to write, it’s easy to make mistakes, difficult to debug and you’re at the mercy of whichever browser the user has preference for.
Programmers looked for other means and found them in applets, DLLs,.NET, JSF and other technologies and server frameworks. I moved on to ASP.NET because it took the drudgery out of programming, automatically generated the JavaScript and was easy to write and debug; a much friendlier model. It still is, but jQuery and other JavaScript Frameworks are now threatening the status quo.
Microsoft has adopted jQuery in a big way and it will replace the AJAX Toolkit. Many software developers have already adopted jQuery or YUI. Combined with HTML5, these JavaScript Frameworks may pressurise Flash and Silverlight. jQuery certainly has a place in the near future of web development
Can I just use jQuery and nothing else? Maybe – but not yet, not entirely. As impressed as I am with jQuery, I feel it’s just one of the tools in the software developer’s toolbox. I’ll use jQuery more and more but I’ll be using.NET and PHP too. Here’s how I summarise it:
For and Against jQuery and JavaScript Frameworks
FOR:
- Good User Experience, close to a Windows GUI
- Much easier to use than plain JavaScript
- Impressive speed
- Coders don’t have to worry about Browser differences
- Reduces Server Load as fewer round-trips
- Widely used, good community support
- Many components already developed
- Open Source
AGAINST:
- You probably still need a Server framework for initialisation and Session management
- You need another app to supply your data (like a web service) written in another language (like.NET, Java or PHP)
- In larger apps, slower to code than PHP or ASP.NET
- You need to understand CSS
- Can still be difficult to debug, especially if scripts interfere with each other.
- Source code is difficult to protect
- Can be a little cryptic to read
If you haven’t tried jQuery then you should definitely do so. It’s easy to get into and will enhance your web applications
