Re:Learning from our Mistakes: The Failure of OpenID, AtomPu...
by __david__ on Sunday January 30, 2011 @05:27PM
(#2159375)
You're right, but I think it speaks less to client side and more to current trends in server side technologies. The #1 feature of JSON is that it maps directly into the dictionary and array built-in types of all the popular "scripting" languages (Perl, Python, Ruby, Javascript, PHP). This makes it absolutely trivial to work with in both the browser and the server unlike XML which demands either DOM traversal to extract data (yuck!), or XPath (cleaner, but yet another thing to learn).
I think this points to Ruby/Python/Perl/Javascript becoming more and more popular on the server side, even for "serious" apps.
Re:Learning from our Mistakes: The Failure of OpenID, AtomPu...
by j_baker on Sunday January 30, 2011 @07:35PM
(#2159717)
I agree. JSON is inherently dynamically typed. Trying to make it work in a static language is a pain just like using XML in a static language.
Re:Learning from our Mistakes: The Failure of OpenID, AtomPu...
by kenjackson on Sunday January 30, 2011 @05:16PM
(#2159350)
Actually its more like on the server side the stacks are richer and more diverse so you can consume and easily use anything, XML, JSON, etc.... Whereas on the client you're pretty much stuck with Javascript. So the choice is obvious -- use the technology that works best with your most constrained environment.
The fact that JSON has won over XML on the web says a lot about the technologies people are using to build websites these days. JavaScript client-side data processing seems to be a lot more popular than server-side processing with an XML-loving language like Java or C#.