Better Web Apps With Ajax 184
An anonymous reader wrote to mention an article on IBM's site detailing the fundamentals of Java-based Ajax. From the article: "This article gives you a good understanding of the fundamental principles of Ajax, and a nuts-and-bolts knowledge of the client and server side components that participate in an Ajax interaction. These are the building blocks of a Java-based Ajax Web application. In addition, you will be shown some of the high-level design issues that come with the Ajax approach."
An "arrr" solution. (Score:2, Interesting)
--
The "are you a script" word for today is platform.
The problem with AJAX is the X (Score:5, Interesting)
Why? Less verbose (easier on bandwidth) and no parsing (ever tried parsing XML using XmlHttpRequest? It sucks). JSON is object syntax. It is a real, live object serialized to string.
It just so happens that JSON is also legal Python object notation.
Hmmm... GMail, Google Maps, Google Suggest... none of these use XML. Google is also renowned for using Python. JSON syntax is the same in client-side javascript and server-side python... hmmm... makes me think twice, anyway, instead of drinking the web services kool-aid Sun and Microsoft are serving.
Erlang and AJAX (Score:1, Interesting)
Better Java Apps with AJAX? (Score:2, Interesting)
Ajax, Java, Echo2 (Score:2, Interesting)
Ajax library for Java (Score:3, Interesting)
If you're looking for a Java library to do some of the heavy lifting, check it out.
Re:The problem with AJAX is the X (Score:2, Interesting)
You can move anything over HTTP, and as long as the receiving end understands you, you'll be OK. You can move INI files if you want. But some people prefer to use existing infrastructure (stable/tested parsers, WS-*, schema validation and so on) so as to avoid reinventing the wheel. Reinventing the wheel is expensive. So you take a small hit on the badwidth. Most people are not Google so they don't have to worry about measuring transport bandwidth overhead in terabytes and spending a year doing characterization testing.
AJAX can be fun! (Score:4, Interesting)
http://dugnet.com/klown/ajwm/ [dugnet.com], all that's needed are some AJAX functions to swap out the contents of each window, instant freakish web-app thing..
JWP has a great AjaxTags component (Score:4, Interesting)
http://javawebparts.sourceforge.net/javadocs/inde
This is a component of the larger Java Web Parts project called AjaxTags. It's a taglib that allows you to easily add AJAX functionality to arbitrary page elements in a purely declarative manner, i.e., *NO* coding on your part (although there is more capability there if you need more). It really makes AJAX a breeze, and is pretty powerful at the same time. If you are a Java web developer, have a look, you may very much like what you see!
P.S., The parent projects' page is here:
http://javawebparts.sourceforge.net/ [sourceforge.net]
Re:Remarkable omission (Score:3, Interesting)
Totally untrue!
There's also the issue of latency and local computation time. The less time between the click of a button, and the reciept of data, the better it is.
The lower bound is very, very low, and every little bit helps.
Re:Third camp sees this? (Score:3, Interesting)
Re:Atlas (Score:2, Interesting)
ASP.NET lets me develop web applications that are fast, cross platform, and extremely robust. When I encounter a cross-browser issue, I look at the HTML and I fix it.
Blaming Microsoft when you should be blaming ignorant developers is plain stupid.
Are you arguing that development tools and platforms should be inherently difficult to use so that the chance of a stupid developer getting anything done is minimal?
Making a platform difficult to use results in even the smart developers getting less done. I would rather risk facilitating idiots than not giving the smart developers the best bang for their buck.
ASP.NET is about a lot more than drag/drop. It's about creating an event-driven web development platform that comes just about as close as you can get to separating code from presentation. It's about making everything as object oriented and encapsulated as possible to both facilitate reuse and help maintainability. It's about providing an incredibly rich development platform that frees up developers to concentrate on features and business logic.
I'll give you a simple example. I was tasked with exposing a large portion of an existing web site to mobile users. This site needed to be accessible by a wide variety of cell phones, PDAs, and other mobile devices. Normally, this task would be huge. I would have to detect virtually every model of phone and render things just a little differently.
Thankfully, ASP.NET Mobile Controls do this for me. They have what amounts to a huge browsercaps file and the controls sense the requesting device and modify their output accordingly. I went from zero mobile support to supporting thousands of kinds of phones in about 3 days... and all of that 3 days was spent doing easy if not mundane things like figuring out the best flow for the mobile version of the site.
On the other side of things, I've used ASP.NET to create applications that handle millions of requests a day. One application I recently finished mimics Google's AdSense technology. I can easily support over 1000 requests a second on a single Dell server with fairly modest hardware. (2.4 Ghz, 1 GB ram.)
ASP.NET also has some awesome reliability features. I can make a change to a site and all existing requests are fullfilled using the previous version while all new requests are run on the updated version. This means not a single request is lost, even when deploying a new version of an application. I deal with applications that must have 100% availability... not a single request can get lost. Ever. Is this possible without ASP.NET? Sure! I could bring down a segment of my web farm at the load balancer, update that segment, bring it back online, and then move to the next segment... but that's a pain in the ass. And that's just one small example. There are hundreds more.
So stop bashing something you obviously don't really understand. Go back to writing your web apps in PERL or PHP or JSP and enjoy it. You don't know what you're missing.
Re:Atlas (Score:3, Interesting)
As far as portability in general... think about this. What would happen if you had to port one of your apps to Gameboy? What would YOU do!? What about my TI-86? Huh?
Since I'm a developer who knows what they're doing, I know my target platforms before I start the project. If there is a chance I might need to port this to another platform in the future, then I take that in to account before I start the project.
Crippling your application, or dramatically increasing development time, or being forced to choose a less than ideal development platform, because you want to make sure you can run it on another platform regardless of the business requirements right now is a bad idea.
Sorry, but that VAST MAJORITY of web application will be created for one platform and stay on that platform for the foreseeable future. Applications that do require portability typically start off with that requirement from the get go. This is especially true for server side applications. (Which makes it all the more ironic that Java is so popular on the server side.)
Nonetheless, there is Mono. They have made great progress. Is it perfect? Of course not. But neither is Java's portability.
Lastly, you seem to view
Re:When you're using java, you can... (Score:3, Interesting)
You might as well use html if you have to redo the whole page anyway.
Repeat this to yourself until you remember:
WIRE PROTOCOL! WIRE PROTOCOL! WIRE PROTOCOL!
Its not for making a page! Its for moving data from server to client! Just data! Thats the whole point! And it requires javascript. Without javascript, you can forget all of it entirely.