Thank God Java EE Is Not Like Ajax 236
Slightlyright writes, "Java Developer's Journal reports that some people in the community are wishing that "Java EE would be more Ajax-like because 'EJB 3.0 can not save Java EE.' This has caused strong reactions from bloggers such as Rich Internet Application pioneer Coach Wei, who wrote: 'Which aspect of Ajax [do] we really want Java EE to be like? The difficulty in developing Ajax code? The difficulty in maintaining Ajax code? The extreme fragile nature of Ajax code? The extremely fragmented nature of Ajax support from different browsers?'"
You mean the buzz? (Score:5, Insightful)
Re:You mean the buzz? (Score:5, Insightful)
Re:You mean the buzz? (Score:5, Interesting)
<sarcasm>
So what you are saying is that after C, C++ and a number of other golden-oldie technologies have gone through the process, Java has now also become mature enough to be declared to be 'dying' by the buzzword junkies?
</sarcasm>
But on a more serious note this dude coachwei has a point, best practices is a concept that is pretty much non existent in a lot of places and that is not just true of AJAX. There are times I wish that more Java webapp developers knew why it is important to write thread safe code and what polymorphism and inheritance are useful for.
Re: (Score:3, Insightful)
Re:You mean the buzz? (Score:4, Insightful)
Edsger Dijkstra was a troll. His "goto" paper is one of the most obvious examples of this. Now, just because you are a troll, doesn't mean you aren't right at times. Dijkstra was right almost all of the time. He rightly criticized a lot of "best practices" of his day. And coming from academia, he had the advantage of not having to offer anything better. Which he, by the way, didn't. Dijkstra preferred to write provably correct code in non-existing languages. Which is fine in academia...
There are plenty. A quick web-search will likely reveal that there are more of them than you can expect to read in a full year. Programming is no longer such a niche area that a single professor can write a troll that will be quoted by almost everyone 30 years later.
But if Dijkstra lived today, he wouldn't even touch web-programming with a ten-foot pole. He would have been more likely to start by proving some formal properties of a new system designed for the same purpose as web-programming, but never implemented it himself. He would then write papers advocating people start using this system instead of the web. And he would be right, his system would be better... if it only ever got made!
It's not that people don't know web-programming as it exists today is too difficult. It's just that we fail to have better alternatives.
If you had read Dijkstras paper instead of just quoting the title, you would see that this is not in his spirit at all. See also my above comments.
Dijkstra was NOT a troll (Score:5, Informative)
Not so sure... (was: Re:You mean the buzz?) (Score:2)
But I wouldn't go as far and discount it as useless because of it, or just saying "Thank god, we're not like that". If you go down that route, you'll go down a route that ignores the market.
Let me move the original comment back a few decades and put in a slightly different context, and that will hopefully highlight what I mean:
s/Ajax/Java 1.5 + applets (or WebStart) ? (Score:3, Informative)
Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "t
Re:s/Ajax/Java 1.5 + applets (or WebStart) ? (Score:4, Interesting)
As long as you don't hit swap. Once you do, garbage collection lasts for minutes due to having to traverse nearly all of applications memory. I don't think that problem can be solved in an userspace app.
Except that the API documentation lies. Graphics2D methods that are specified as never blocking block. Methods that are supposed to return on true on success always return false, despite being succesfull. And methods throw random, undocumented exceptions. Then there's this weird bug where image scaling takes 10 times as much time if the source image is not in sRGB color space. All this in Sun's own Java implementation. I hate to think what bugs will surface if the program is ran in other implementations.
So no, you don't get rid of workarounds in Java, at least in the GUI.
Re: (Score:3, Insightful)
We could all do with being a little less reactionary IMO.
Python? Who said Python? (Score:2)
For interface, I'd like full SVG 2.0 supported in all the browsers and standardized (i.e. no need for Flash) and for a way for my imaginary browser-embedded Python to manipulate the SVG interface in an easy, clean and Pythonic way...
Ahh, it's nice to dream..
Re: (Score:3, Informative)
Check out Mochikit. It's very close to what you're looking for, and being "pythonish" is its main goal. I find it a nice happy medium between Prototype (a thin hacky wrapper around raw ajax) and Dojo (makes you drink the koolaid with its use of custom tags).
Actually I really like Ajax4JSF, but that's a very different beast.
Re: (Score:2)
I'll leave it as an exercise to the reader to determine which group thinks AJAX is the best thing, and which group in its jealousy thinks its rubbish
Re: (Score:2)
By the time we get around to produci
Which aspect of Ajax? (Score:5, Funny)
How about the Web 2.0 part
(It's a joke. Laugh)
(Well, sortof a joke)
Re:Which aspect of Ajax? (Score:5, Informative)
"What else? The difficulty of finding and hiring Ajax developers? According to Rod Smith (IBM) and Scott Dietzen (Zimbra), both independently mentioned that one out of 40 engineers interviewed would be qualified to learn Ajax."
Not qualified to code,
qualified to learn
Re:Which aspect of Ajax? (Score:4, Insightful)
Re:Which aspect of Ajax? (Score:4, Insightful)
Because if 1 out of 40 S/W Eng. are capable of understanding a javascript function call, then by God I deserve more money.
Re:Which aspect of Ajax? (Score:5, Informative)
Re:Which aspect of Ajax? (Score:5, Informative)
And you've just proven that you don't understand JavaScript. JavaScript != Java (or C++, or C#). It's not designed around functions and classes. Javascript is a functional language [msdn.com], and as such is designed around closures. Closures allow you to define classes and functions, but they also allow you to do quite a bit more (and also let you shoot yourself in the foot if you like).
You're correct in saying that there's more to writing a large-scale AJAX application than just understanding a JavaScript function, but most of the things you mention are irrelevant (well, they're important to understanding JavaScript, but that's a core competency for any type of web design, not just AJAX). Using AJAX is easy, especially with all of the frameworks available that abstract browser compatibility issues for you. Using AJAX well is difficult (dealing with accessibility, server load, concurrency, etc).
Knowing JS today != Knowing JS 5 years ago (Score:2)
Today, with Ajax in mind, "knowing JavaScript" means "I know and understand async. I/O & DOM, I know about XMLHttpRequest and I could re-implement Google Maps for you if you ask me".
All of the sudden JavaScript went from being used as a toy scripting language to a full-blown develpment language. Not saying if it is a good thing or bad thing but you can thank Google for it...
Re:Which aspect of Ajax? (Score:5, Insightful)
AJAX, and multiple other web technologies, suffer from being judged with criteria determined by the critic. In tech this translates into multile disciplines. UI guys love AJAX if used properly - the same build could be looked at from an app programmer's perspective as junk.
AJAX seems to address the cultural side of things. People love flashy things, especially if they can deliver 80% -90% of the functionality they want. An application developer may be able to deliver 100% of wanted functionality, but in a way that a user finds aesthetically displeasing.
I think this brings up an interesting point. When do developers start to realize that users will not conform to what they should do, but what they want to do? Learning the aspects of a development technology inside and out will not give a developer this edge. Paying attention to social aspects will.
I think that's what these guys meant when they said qualified to learn.
Re:Which aspect of Ajax? (Score:4, Interesting)
They also had a
I also Googled Scott Dietzen (Zimbra)
"Scott Dietzen is widely credited with helping put together the J2EE standard, launching the web application server category, and launching the Java Community Process"
"Scott Dietzen is the former CTO of the eCommerce Server Division of BEA Systems. Dietzen came to BEA via the acquisition of WebLogic"
"President and Chief Technology Officer of Zimbra"
And in the other corner, we have IBM. Nobody ever lost their job recommending IBM. Rod Smith (IBM VP of Emerging Internet Technologies) isn't small potatoes either.
So, while I don't disagree with the meat of your post, it seems to me that when those guys say "qualified to learn Ajax" that is what they mean.
I imagine that they interview lots of engineers. I hope that 1 in 40 isn't for engineers trying to get into a job involving AJAX, because that would be a dismal number. It'd make more sense if they were talking about 1 in 40 of all engineers interviewed for various positions... but that's just a wild ass guess with no factual support.
Re: (Score:2)
Digressing to another topic, that comment reminded me about the Gnome/MacOSX vs. KDE/Windows approach to user Desktops. According to the experts in HCI (Human Computer Interraction) field, Mac OS X is more "user friendly" than Windows. Apple has invested a lot more in usability research and it payed off, the interface is easier to learn, it is simpler and more intuitive. I
Re: (Score:2)
Unfortunately the underlying technology hasn't really kept up. What users appear to want in a lot of cases is application functionality deployed over the web. All we have as developers is the AJAX hacks on top of a language designed for sharing research papers and static page content.
Because some developers have started to make websites look more like desktop apps using a variety of ugly hacks, u
Re: (Score:2)
one out of 40 engineers interviewed would be qualified to learn Ajax.
The scary part is the other 39 are all working as consultants on J2EE and ASP.NET projects, and noone at management level questions their ability.
Re: (Score:2, Offtopic)
I wish slashdot would cover more java oriented articles as its commonly used and not as lame as it once was.
Java 6 looks very cool from the desktop end with huge performance gains and the factory object model integrated with the threading with Swing makes gui apps more responsive and java programmers wont have to worry about using threading to make their programs look more responsive which is not as much as an issue with other languages.
The web 2.0 stuff is nice for webdevelopers for
Re: (Score:2)
That's not too bad to say I just hammered in the words and realised the acronyms after previewing.
Isn't Ajax Javascript? (Score:5, Insightful)
Re: (Score:3, Funny)
They both contain the letters "Java"
AJAX between JS and Java servlets (Score:5, Informative)
ECMAScript code on the client manipulates the HTML DOM and requests data in XML or JSON format from a server through XMLHttpRequest. A servlet [wikipedia.org] produces such data.
Re:AJAX between JS and Java servlets (Score:5, Funny)
I'm not sure what's more terrifying, the number of buzzwords in the one-sentence parent post, or the fact that I understood them all.
:-p
Re: (Score:2, Insightful)
Re: (Score:2)
Re:Javascript is ubiquitous, Java VM is non-portab (Score:4, Insightful)
Having read your other post, I almost dare not reply, but here goes...
What sort of app were you trying to get running? I've spent the best part of 6 years now writing web apps in Java, and have never had any problems getting them running on different systems. I develop under Windows, the apps are built on Windows, and are almost always deployed to Linux boxes, and we've not had any problems.
I can't vouch for applets (which I've never done, but they are historically a complete pain in the arse, although I believe that situation has improved) or client-side applications, but on the server, I'm not aware of there being any problems.
That's not to say that the language doesn't have issues (every language does, and Java is no exception), but I've never seen any relating to portability (again, not saying they don't happen, just relating my experience, for what little it's worth).
No connection. (Score:2)
Nothing.
wow, what an excellent point! (Score:5, Funny)
Anyway, just wanted to say that I immediately realized that SOA guy was a real engineer--skilled, one of "us", not a marketroid at all--when I read that quote.
Re:wow, what an excellent point! (Score:4, Funny)
Keep the bubble-sortin' faith, man.
Bubble Memory optimizes Bubble Sorts (Score:3, Funny)
Don't you guys trying to optimize your software bubble sorts realize that these days, all the fast sorting action is happening in hardware accelerated Bubble Memory [wikipedia.org]?
Plus, Bubble Memory is much more secure and less obnoxious than Flash Memory (which everybody hates because it has major security holes and displays annoying advertisements). [wikipedia.org]
-Don
Re: (Score:2)
There is no hope, but's be genetic (Score:2)
but's be = must be (Score:2)
Simple (Score:2, Insightful)
What does AJAX have to do with Java? (Score:5, Insightful)
p.s. There is a reason why Java has withstood the test of time (for 11 years anyways) and that's because it is good platform and a robust one at that.
Re: (Score:3, Insightful)
Re: (Score:2, Interesting)
Re: (Score:2)
static const command_rec core_cmds[] = {
{ "NameVirtualHost", ap_set_name_virtual_host, NULL, RSRC_CONF, TAKE1,
"A numeric IP address:port, or the name of a host" },
ap_set_name_virtual_host is a function.
Re:What does AJAX have to do with Java? (Score:4, Informative)
The Java runtime can handle dynamic discovery and execution of procedures in any old Java class file, passing around Method objects and such. This falls short of first class functions and very short of closures, but that's how it's done.
Re: (Score:2)
Anyway, apart from refection (which I tend to avoid), you could do this simply using a large if-statement I suppose. You could also crea
Re: (Score:2)
Otherwise I have answer tomorrow, and the moron that says that it doesn't compile gets the modpoints, in a typical
Re: (Score:2)
Create a map of concrete classes to your names. As each name comes in, check the map, run the concrete class on the data. If the name doesn't exist, then throw an exception that the process hasn't been implemented yet.
You can 'inject' that map very easily, and you can configure it either using Spring Framework, or by setting it up in some properties file (or XML.)
I do this stuff all the time for scientific workflow pi
Re: (Score:2)
In your case, problably the most common in java would be to define
interface command
{
abstract string getname();
abstract void handle();
}
class NameVirtualHost implements command
{
string getname(return "NameVirtualHost")
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
two words (Score:2)
Re: (Score:2)
AJAX from a UI design perspective (Score:2)
I especially know all about CSS and the nightmare of multiple browser support -- especially when CSS rendering support seems to be inversely proportional to a browser's popularity. It do
Not useful, not particularly entertaining... (Score:5, Insightful)
First of all, there is no careful description of the problem. A problem is the difference between the way things are and the way you want them to be. This takes into account the way things are that already acceptable. AJAX has some deficiencies, and it has some attractions. My questions are: Is it worth the effort to correct those deficiencies in AJAX? Is it worth the effort to include the attrations in EJ?
Secondly, there is no concensus on the appropriate domain for the different tools. Is EJ really a tool for doing the same things that AJAX does?
Thank God (Score:4, Insightful)
Ajax and Java are two completely different ideas/concepts. Second, if AJAX is hard and you do Java, you need to have your head examined. It's probably dyslexia, and you've been writing perl, not Java this whole time. Not to say if you know Java you know Ajax, completely untrue, but if you think it's hard that's a different story.
Re: (Score:2)
The point being made is ... (Score:5, Interesting)
I guess I don't know why "Ajax" was brought up, I haven't used it and it's not something I'm familiar with. Maybe Ajax doesn't belong in the same class of technologies. Arguing about the specifics means missing the point, though.
It often takes "rebel" technologies to move things forward. It also takes some experimentation to develop a technology; i.e. coming up with a rigorous, solid standard might prevent its spread. Sometimes sloppiness is good. RSS, HTML, etc. have done okay despite the sloppiness. Requiring every web page be HTML compliant would have stifled the web.
Recently, I've started working on Weblogic. I used to develop with JBoss. In terms of service deployment, JBoss is superior to Weblogic. I guess with Weblogic, you're still stuck writing a lot of code to deploy JMX services. I noticed at my new company that programmers ended up launching network servers from a Servlet, which was not its intended use. The ease of deploying MBeans and dependency control with JBoss is superior. It can be done easily with a bit of XML, and no code is required. JBoss also handles ordered deployments better. With Weblogic, deployment ordering is done by assigning a deployment order number (1-4000 or something) to your deployment. It reminds me of writing programs with line numbers back in the good old days of BASIC.
It's my guess that functionality from Spring will be eventually refined into a series of JCPs. Sometimes it's better that standards develop in this way.
Re: (Score:2)
Yes, indeed. That last sentence was important. I see a lot of new developments in Java, but most of the time the first implementations and API's are pretty lacklustre. What the JCP is really good at is to get the core ideas, take some time to think them over, and get the gist of them into the language. Sometimes the old implementation is adopted into the l
Why can't JEE be more like AJAX? Simple... (Score:2)
From the article: "The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can't JEE be more AJAX like?"
I still see many of the best practices in AJAX being fleshed out in the year(s) to come. Hopefully things like Comet [ajaxian.com] will become a reality in the near future and the many different toolkits/utilities (dojo, dwr, jmaki, et al) c
That's really kind of funny actually because... (Score:5, Insightful)
Re: (Score:3, Interesting)
As it stands, I've read the books, and the next project I start (in a few weeks) will be ejb3.0, just to give a quick back-to-front application a shot.
I hear where you're comming from, though, a
Re: (Score:2)
Remember caring is sharing
Re: (Score:3, Interesting)
But now there is cope [sourceforge.net] which I try to use as much as a can (read: as much as clients permit me to) since it does everything
Whiskey Tango Foxtrot? (Score:2)
FTA:
"I was always skeptical about AJAX. This technology can be useful for Google , Yahoo, or Amazon, and the like . Because regular businesses can not afford it. They can not hire a team of experts to find workaround for dozens of serious problems browsers/JavaScript introduce. Browsers/JavaScript is not an application development environment."
Oh, shit. I better tell my boss that all the AJAX-based apps I've written over the last six months need to be taken down. Apparently, we can't afford them!
Re: (Score:2)
Compared to writing more traditional desktop applications, I'd say AJAX takes at least t
Re: (Score:2)
Enterprise Class Jive (Score:2)
GWT (Score:5, Informative)
GWT is wonderful. I've programmed ajax stuff (check out my chess and checkers games [tryit4fun.com]. It's definitely brittle if you actually have to write the javascript and parse the xml and convert the xml to java objects manually.
But, using GWT has been a big eye opener for me. You write java code and it's compiled into javascript. It completely turns everything on its head. If you want to communicate some more information to the server from the client, all you need to do is add another method to the remote object (and its interfaces) and you suddenly have another statically type checked rpc call between client and server.
I'll probably still do simple form apps in struts, but I don't intend to ever write another line of javascript that's of any significant complexity. It's no longer necessary. No longer do I need to figure out incompatibilities between browsers. GWT just figures it out.
All these years people have been trying to make a good java webapp framework and GWT comes along and does things in a way that just turns everything on its head. Struts and Tapestry and JSF are all solving the wrong problems. They all try to make it easy to take html forms and retrieve and validate that information.
GWT turns it around and just lets you communicate java objects. I used to be unhappy that I needed to settle for choosing which framework was the least bad. Now I just say to hell with the lot of them except in situations where javascript isn't allowed.
Re: (Score:2)
XML11 is better than GWT (Score:3, Interesting)
Although it doesn't get the hype that GWT does, XML11 is a much better implementation of the idea. It works with java byte code instead of source like GWT so it's more stable. GTW doesn't yet work with java 5 because of the new language syntax. XML11 works fine since the java byte code is the same between java 4 and java 5.
Also, it's based on the AWT framework (same classes with different implementations) so developers already familiar with AWT can get productive faster - instead of h
NewI\O (Score:2, Interesting)
Re: (Score:2, Funny)
Roads need to be more car like (Score:2)
If what is meant is Java EE needs some of the AJAX hype... well Java EE has the tools, libraries and maturity to continue thriving with or without AJAX.
I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship.
Monarchy, worship
Which aspect o they want? (Score:2)
Re: (Score:2)
Java EE is *different* from AJAX, and vice-versa (Score:5, Insightful)
Java EE is a framework to write business applications, for any kind of business, from issue trackers to ERP, the "business" in it doesn't mean "$$$ business" literally.
When writing business applications, it tries to enforce you to separate your concerns, especially, the presentation layer (Servlets & JSP), the business logic (EJB) and enterprize information systems (EIS) (JDBC, EJB container managed persistence etc). Its a complete stack for developing applications.
AJAX deals with presentation layer, and more specifically, the interaction part of it. its a piece in the whole stack. The Java EE presentation layer does NOT depend on even having an HTML frontend even! (no sane framework does!).
So now, if you have an HTML/XML browser frontend and a human user using it, you may use AJAX for enhanced user experiece. There is nothing in Java EE that says you cannot take your favorite AJAX toolkit and use that to build your frontend.
So both technologies are not even competing on even a single issue. Both are complementary. You can use Java EE stack to develop your application, and when time comes to develop the frontend, you choose from plain old HTML, XHTML, XML, AJAX etc (or a combination thereof), to develop your application's "frontend".
Please stop this ignorant war. To make another bad
Re:Java EE is *different* from AJAX, and vice-vers (Score:2, Interesting)
Maybe I am in the minority but I have spent a lot of time reading the Java EE specs and trying to implement them. After implementing them for a couple of years
Religion aside... (Score:4, Insightful)
- Java EE
- CORBA using C, C++, Pascal, and Java
- Microsoft DCOM
- Various proprietary protocols
AJAX isn't really a distributed software development technology... it's a sloppy mixture of features written by a varied group of contributors. What makes it interesting, is that no matter how implemented, the goal is the same. I think that's what the writer of this article was trying to articulate. With Java, there's only ONE way to do anything. Drink the punch, or don't use Java. If you dare suggest that any part of Java needs work, you get a room full of angry & militant Java advocates ready to stone you into submission. I'd like to say that I'm exaggerating, and I am, but only a little. I too wish that Java engineers could think outside of the "sandbox," instead of encouraging others to make due.
Re: (Score:2)
The Java community is pretty millitant against adding features, that's true. The reason behind that is that it quickly becomes very complicated to read and manage all those different concepts. If the Java community wasn't, with the popularity of the language, it would now be D+++.
Every time that some developer gets modded
RTFA!!! (Score:5, Insightful)
What was meant by this is that Ajax is a loose collection of cooperating technologies, without a standard, that develops very rapidly, and allows a lot of choices to the developer -- as opposed to Java EE as a rigid platform. Kind of like Linux vs BSD.
Even TFA understood this in the response.
The Slashdot response, so far, is roughly equivalent to if I said I wish Java had something like CPAN, and people jumped all over me with comments like "You want Java to use
It's like a Wikipedia of code -- NO! Not in that anyone can edit any module. It's like Wikipedia in that it's a central repository of the collective programming skill of mankind. It's sort of the library to end all libraries.
Anyway. -1 Offtopic to the entire comment section this time. RTFA!
Re: (Score:3, Interesting)
J2EE is very well standardized, and goes through a very controlled process before it is extended. However that doesn't mean that Java in a larger sense can't take in external projects. Some of these like Struts, Spring, Hibernate, and so on fall into the loose
this really comes down to: (Score:2)
or in other words:
strongly-typed statically checked compiled language proponents vs weakly-typed dynamically checked interpreted language enthusiasts.
which is really as old a debate as C vs LISP...
yawn...
Re: (Score:2)
By some definition...or at least the one I chose to believe. Static and dynamic are well defined, but strong and weak are anything but.
So basically (Score:3, Insightful)
God? (Score:2)
I wonder if He has contributed to any fully open source projects - the comments alone may be worth reading.
More about *Rich Internet Pioneer* Coach Wei (Score:2)
Quote - "I live in Cambridge, MA. I work at Nexaweb Technologies (http://www.nexaweb.com), an Enterprise Web 2.0 software company. &...Many moons ago (1997 to 1999), I wrote an Ajax-based word processor, which is published and open source at http://www.ajaxword.com./ [www.ajaxword.com] I also worked at EMC Corporation in the late 90s, doing work in the enterprise storage area. "
Oh & Btw - I'm Yuri Gagarin.
--
In Soviet Russia, the Rich Internet pioneers YOU. Obligator
J2EE & AJAX handle complexity differently (Score:3, Interesting)
J2EE and EJB on the otherhand are very standardized and highly organized, but complex by design and harder to initially grasp. Personnally, I'd rather try to detange AJAX than try to figure out what is going on with the dozen-odd layers of interfaces that EJBs seem to implement. I'd really wish EJB would get rid of all the complex interfaces and just allow direct acess to the object and its methods. It would much easier to grasp and work with. Why do I need muliple layers of interfaces when I just want to manipulate the object?
Wow. Talk about bad comparisons (Score:3, Insightful)
Of course, that is actually the point of the article... That Java EE shouldn't be a bunch of specs for implementation, that it should be a bunch of loosely coupled ideas that end up getting something done. I mean, AJAX originally stood for Asynchronous Javascript and XML, but today, you see things that don't use XML and aren't asynchronous using the buzzword. Ajax is 'just a bunch of ideas'.
Of course, those ideas are based on Javascript, html, cascading stylesheets, the XMLHTTPRequest function in browsers, etc. If these things weren't all spec'd out, Ajax wouldn't have come into existence. The article makes it seem like the author is somewhat against specs, so I find this rather ironic.
A little clarification (Score:5, Insightful)
JSPs and Servlets, with or without EJBs, can be (and are) used for web-based user interfaces on the Internet, although on their own they suffer scalability problems for concurrent access by many users and for speed of prototyping and developement of new features.
They are, however, pretty orthogonal to AJAX since they are server-side technologies. Both an Javascript controlled asynchronous HTTP request comming from a browser and a user triggered browser HTTP request look exactly the same to both JSPs and Servlets - they're just another HTTP request (HTTP/1.1 GET
Saying that J2EE should be more like AJAX is like saying that PHP should be more like AJAX or that CGI-scripts should be more like AJAX - complete nonsense!!!
Having better architectural support in J2EE for AJAX (for example, for being able to access a server-side business function in Javascript from the browser just as easilly as you can do it from the JSP layer) would be a good thing. However the groundwork need to support this on the server (J2EE) side is already done (it's called Web Services), and thus the biggest part of the work still needed to seamless provide the Javascript/AJAX code running on the browser with access to such remotely hosted business functions is
Just as a reminder, AJAX is the kludge it is because there's so very little standardized functionality in the browser to allow dynamic, localized refreshing on a page of information which is externally hosted.
To wrap things up: server-side support is there already in J2EE that provides, via HTTP, seamless access to business functions hosted in a J2EE server. Whether the requester is a piece of AJAXified-Javascript running on a browser or a batch C application makes no different. As usual, most of the necessary stuff missing, is missing from the browser.
To the writter of the article: Server-side technologies are mature already, AJAX is far from it. Stop demanding that servers are adjusted to serve a single client implementation methodology. If you really want an architecturally sound solution, get up from your fat ass and start coding a Web Services client in Javascript.
Re: (Score:2)
Honestly, as sad as it is, I find myself wishing something like Flash had picked up more than it did. Flash or another technology. Yeah 99% of Flash sites are annoying as hell, but thats the implementation. You can do annoying stuff with javascript and DHTML too
Re: (Score:2)
All web apps are kludges in one way or another simply because the web standards were never designed to support them. The mistake we made early on was not throwing the whole thing out and starting all over with a set of standards that were designed from the ground up for web apps. It's probably too late now.
Re: (Score:3, Insightful)
The web was built up on the need to make easily accessible complex documentation using a markup language and hypertext links at first.
Because the browser gave the impression the easy access to documents means the browser is a one-size fits all solution to every content, everywhere many peoples dedicated most of the last 10 years to fill holes to make it behave like the client-server applications already existing just before the web tsunami hit the IT world.
I'm not sure it is really les
Wrong article? (Score:2)
Are you a cut'n'paste troll, or are you simply in the wrong article? Or maybe you intended to reply to a specific comment?
Re: (Score:2)
You're an elitist "engineer". (Score:2)
x86 is an engineer's nightmare. It's horrible, it's ugly, it's loaded with legacy crap.
But the true engineer doesn't care, because he's likely working in a high-level language, like, say, Java.
Now, if you want to engineer a web app (and you're sure that's not an oxy-moron), you can do it in the low-level -- you can write the code manually, deal with browser issues, hack around. It'd be kind of like writing x86 assembly. Or you could do true engineering, just