[UPHPU] Ajax frameworks

[Justin Carmony]

I'd just like to ditto what Joseph Scott wrote when it comes to the 
client side. I'm a huge fan of jQuery, and it takes the headache of 
cross-compatibility with browsers almost completely out of the question. 
jQuery is also pretty lightweight and has a huge following (you can tell 
the .NET people that MS now has built-in jQuery support out of the box 
for Visual Studio. :P)

The other question that comes into play is the "server side" aspect, 
which is the PHP code that feeds your ajax requests. Having worked in a 
.NET shop before, I  know for a fact their probably comparing your Ajax 
code to ASP.NET's Ajax. .NET with Visual Studio abstracts a lot of the 
behind the scenes stuff. You can drag and drop a calendar, go to its 
properties and say "enable Ajax" (not a real example, since I haven't 
used it in over a year now). .NET will handle all the JavaScript and 
server side JSON for you.

However, if you just use Services_JOSN for PHP and write a little custom 
logic, you can achieve just about the same thing. If the .NET guys give 
you hard time, then I suggest you tell them this: This gives you so much 
more control and power of your AJAX. .NET's problem is if you really 
want to make anything cool with Ajax outside from their very basic 
framework, it is much more complicated and difficult in .NET. PHP might 
not let you drag and drop, but make a more roboust solution is a LOT 
more straight forward.

Anyway, my two cents. ;)

Justin Carmony

Joseph Scott wrote:
>
> On Mar 11, 2009, at 8:12 AM, Scott Hill wrote:
>
>> I recently completed a small ajax application and thoroughly enjoyed
>> learning more about ajax.  Now that it is complete and in production, 
>> it is
>> being suggested that I should have used a framework.  "They" were 
>> also quite
>> chagrined that I got away with using php for the project. (It's those 
>> .net
>> people again)
>>
>> So, why should I use an ajax framework instead of doing the ajax coding
>> myself?  What are the benefits.  The down side?
>
>
> As far as the Javascript part goes, probably looking for more of a 
> library than a framework.
>
> My JS library of choice right now is jQuery, and the reason I'd use 
> that over rolling my own XHR wrapper is mostly maintenance.  
> Supporting a large range of browsers can be painful, having that 
> effort more centrally focused (many people contributing to a library 
> versus only me writing a new one) helps get better coverage.  
> Optimizations going forward, so when a new browser (or new version of 
> a browser) adds some additional feature or changes implementation I 
> can benefit from the work done in the library.  That sounds like a 
> contrived situation, but it's already happened in IE.  As we see 
> things like JSON and cross domain XHR moving forward in the future I 
> think we'll see more situations like that.
>
> In the jQuery case there's also features that I find useful, that I 
> probably wouldn't haven't implemented myself, like JSONP support.  
> Performance is another area that could potentially go either way.  You 
> could certainly make a smaller library by only including the bits you 
> need, but it isn't always clear that it would execute faster, 
> especially across all browsers.
>
> It really doesn't matter at what level we are talking about (lower 
> level like C, or high level like Javascript) the library discussion is 
> pretty much the same.  It's a series of trade offs and you need decide 
> which set of trade offs you want to deal with.
>
> -- 
> Joseph Scott
> joseph at josephscott.org
> http://josephscott.org/
>
>
>
>
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net