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
[email protected]
http://josephscott.org/
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
