I recently experimented with a jQuery event calendar in our booking system. Our previous version uses ASP.NET to create the booking graph as a whole on the server and then displays the batch in the browser. It was a bit slow and clunky, but it worked.
I wanted to have a PHP version of the room reservation system, so I did a quick port from ASP.NET C# to PHP, and then downloaded the jQuery fullcalendar component on the page. I used a web service for the data that was still written in C# to a Microsoft SQLServer database.
With a bit more tinkering and refactoring, I found that I could get rid of almost all of the PHP/.NET code, as it was only used to initialize the page. Now I’m left with a page with just HTML and JavaScript using an AJAX to call a JSON data source from a REST web service.
The effects were awesome! In addition to looking better, the update speed was amazing, just like a Windows app. Of course this is achieved because the page runs almost entirely in the browser and the calendar navigation can request only a small amount of data using AJAX against the web service.
Could you write the whole application this way?
It reminded me of programming in the 1990s. Web pages were HTML with a bit of JavaScript; then we add a bit of ASP to get data from a database and paste it into 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 simple things like allowing only one numeric digit in a text box, checking for valid date, data grids, or even simple popups weren’t as easy as in a Windows app.
Because? Because pure JavaScript is slow to write, it’s easy to make mistakes, hard to debug, and at the mercy of the user’s preferred browser.
Developers looked for other means and found them in applets, DLLs, .NET, JSF, and other server technologies and frameworks. I moved 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 now threaten the status quo.
Microsoft has embraced 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 can put pressure on Flash and Silverlight. jQuery certainly has a place in the near future of web development.
Can I use jQuery and nothing else? Maybe, but not yet, not quite. As impressed as I am with jQuery, I feel like it’s just one of the tools in the software developer’s toolbox. I’ll be using jQuery more and more, but I’ll also be using .NET and PHP. This is how I sum it up:
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 with fewer round trips
- Widely used, good community support
- Many components already developed
- open source
AGAINST:
- You probably still need a server framework for session initialization and management.
- You need another application to provide your data (such as a web service) written in another language (such as .NET, Java, or PHP)
- In larger applications, the code is slower than PHP or ASP.NET
- You need to understand CSS
- It can still be difficult to debug, especially if the scripts interfere with each other.
- Source code is difficult to protect
- Can be a bit cryptic to read
If you haven’t tried jQuery, you definitely should. It’s easy to get into and will enhance your web applications.