Ajax web framework support
on
Head Rush Ajax
·
· Score: 4, Interesting
I would like to see more web frameworks include a mature AJAX framework to facilitate more dynamic interaction. To date the best I have seen so far is Echo2 which incorporate an event driven architecture that allows for seamless integration of client side events transmitted to the server side architecture.
Hotline was ahead of its time. It was doing file sharing, instant messaging et al. back in the dark ages of 9600 modems. It was a great product and was as underground as one could get. It is sad that they had their troubles.
Re:The one place I can really see this used...
on
WebOS Market Review
·
· Score: 1
You hit the nail on the head. Many posters are thinking of these desktops in terms of home use in which I agree it is not applicable and will fail. But in the Corporate environment where thousands of desktops and application instances must be managed on a daily basis these technologies can be a god sent. They allow IT departments to manage a client side, platform independent, single install from a single location. Upgrades for 10K users are instantaneous; problems do not arise from different configurations on the client. For corporate application such as accounting systems this is one of the most promising developments in usability and manageability.
Yeah, I know it sounds wacky but I guess you would just have to see the application in action to understand the mitigation to bookmarks it does. My team is pretty well verses in a variety of frameworks. With a lot of experience in ASP / ASP.NET and JSP / Servlets so my guys do have a lot of experience with the options available and the design philosophies, but with the dynamic nature of Ajax it has been extremely easy for out users to implement document retrieval solutions that are more robust than just book-marking. Case in point I had one developer that built an XML file format that could save any applications state and be emailed, IM'ed or stored and then that application and session could be recreated via that document to the T. The user could pick up at any time (a year later) exactly where they left off. We are currently cleaning up the code and are going to submit it as an open library. It's like book-marking on steroids.
Don't worry about it; I have severe dyslexia as you may have gathered from my spelling mistakes. So compared to me you look pretty good. I thank you for the discussion as well.
The landing after login can be accomplished in either a HTTP Authentication or a "roll your own model" and I agree that it is the best design. My point with the authentication page was not that it did not matter that a user need land on the page but to highlight that in certain systems there is more involved in the process then just bookmaking a page for return. After reading my post it may seem that I was drawing the conclusion that it did not matter because the user must log in anyways.
The session expiration is a problem and I don't believe that it is the end all of a role your own system. This is where Ajax and a keep alive are now starting to help in fixing this model as you can issue keep alives without user interaction. By no means is the session based roll your own model the end all be all but it offers far more flexibility than HTTP Authentication.
Security is an ancillary note to this argument, not that it is not important but the fact of the matter is any way you slice it you are going to have to send credentials over the wire I take no issue with that point, The problem is in the design restriction HTTP Authentication presents on a web application. It is fine for restricting access to a single document or set of documents but what happens when you need code level access. What happens when you need to masquerade permissions for the execution of a certain code block. The problem is that HTTP Authentication is not exposing this functionality to the application. In some cases there are libraries but in many cases there are not or they may not exist for your languade of choice. Not to mention restrictions with distribution and scalability. What if you system is compromised with a contained solution there are no worries about a breach of the web-servers permissions system as they are not authenticated on it, or worse the OS's permissions system. An abstracted model allows for this buffer. As well, there is the issue of managing the authentication. With HTTP Authentication the server assumes that a user is authenticated until the browser is closed while this may not be a problem for some application it can present a major problem for say a banking application that may want to terminate specific permissions as soon as a transaction is completed. Security systems such as BOA's site key are virtually impossible to duplicate using a HTTP Authentication model.
The links I provided where merely to highlight the problems that developers are encountering with trying to retrofit a HTTP Authentication model. Nothing more can be inferred from them.
This bit of information would probably do a lot for Echo2's acceptance
I agree but I think the problem is that as many of us use Echo2, we find less and less reasons to use book-marking capabilities. I have used it from time to time to show invoices and records but for the most part my developers have moved away from book-marking to other representation of data such as an icon on a user's workspace when they log in and our users love the simplicity of such a model. Anyway, I am rambling the point is your are correct the developers at Nextapp should tout this ability more as for some applications, not being able to bookmark is a show stopper.
As well here is some info on the inter application communication. I am a little vague on Echo2's implementation of this as I have not had to cross this bridge with any of my applications, but these problems are being evaluated and addressed to my understanding.
Indignation and personal attacks are indicative of a diminished capacity to reson. Lets leave them out of the conversation or it is over. If you have a beef with my information then attach my information as attacking me will show its hollow end.
As for the HTTP Authentication comment you are talking about HTTP authentication vs "role your own" in which I will defer you to this discussion as the problems with HTTP Authentication are so numbered that it would be redundant to spew them all out here
No one in the field actually uses Http Authentication. I mean who EBay? Amazon? E-Trade? Yahoo? Microsoft? So I don't see your point. They all roll their own many of them use built in system accounts (which is a whole other argument) and put a front end on it. I mean really no one has used HTTP Authentication in years.
There is a common design pattern that developers using Echo2 use to bookmark internal elements of within the application. It is via a URL string as many other web apps use. One only need grab the string from the servlet context and parse it to return the application to a specific state, say maybe a string added on to the URL such as &invoice_id=7 parsing out this value will allow the developer to retrieve and display the invoice. You can even do this after a log in screen. Currently you have to build your own parser and command interpreter but given the other benefits of Echo2 this is a small piece of software to write and if built correctly fairly reusable among applications.
Where Echo2 fails in my opinion is in inter-application communication you cannot have an application that passes it context to another application. The developers are currently proposing solutions for this problem but in reality it is a small problem as it is rare that a developer needs full context passed between applications. Few frameworks offer this feature but it allows for more robust applications and allows for greater reuse.
I did not move into another environment. I started out building web apps back in the CGI / Perl days when their was no framework and I know all to well the time frame it takes to develop a web app from the ground up when you have to slog through 12 different document, markup, script, and programming languages to get it out the door. I do not differ with the conclusion that sometimes resources need to be immediately accessible via a URL but some times they just don't. Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page. I am not trying to shoehorn an archaic model onto a web model I am trying to develop new models which enable my developers to develop web applications quickly. It may not work for all but it has worked successfully for me. Where it has failed I have opted for other frameworks.
Web applications are not desktop applications that happen to be used through a web browser.
Ross,
I do not totally agree with your conclusion, different application requires different architectures. This is the very reason that there is a plethora of different frameworks some solve different problems while some tackle the same tasks ad nasium.
Echo2, is aimed at tackling the problem of a thin rich clients over the internet. It is not designed to supplant you standard page based web applications where bookmaking content is necessitated. For a portal type application it is not the right tool for the job. Where it is the right tool for the job is in building a dynamic application that is distributable and maintainable in a single instance. It is very good for enterprise system development of say and accounting system or a admin system in which the user is accomplishing a business process. I am not talking about end user content based sites but applications that have traditionally been the domain of the desktop. The savings on administration alone are astronomical. As I have said it is not the right tool for ever job but to discount it out of hand is to not give it due diligence. In my realm of work Echo2 has liberated me for have to make the choice of either giving up the simplistic distribution of the web or the dynamic nature of the desktop.
The Nextapp devs and marketers say you shouldn't need to tell someone a URL that takes them directly to a particular piece of information
Again, an application designed to input information to store in a DB or to transact a process is where such frameworks shine not in content rich applications such as a shopping site or a documentation project. It depends on the nature of the application. If you are just creating a word document and saving it on a server then there is no need to bookmark said information. A completely different architecture exists for retrieving information in this design, such as opening the saved document from the web application.
I thank you for the heads up on the possibility of problems with the Ajax components of RoR as of now I am not currently evaluating RoR for any projects so my knowledge of the framework is limited to small test applications to gain personal knowledge of the framework as a whole. I concur with many conclusions that both you and the author of the article you cited draw. Breaking core functionality of a language is neither a good practice nor is it advisable. If I have the chance to evaluate RoR for a project I will keep your notes in mind and test my proof of concepts to test the fabric of the framework to ensure that they will not hinder my design.
As someone who's evaluated various JavaScript frameworks
I do not evaluate JavaScript frameworks as JavaScript is only one portion of a mutli-teir application. I focus my efforts on comprehensive frameworks (such as RoR, Echo2, ASP.NET, JSF, etc.) that incorporate front to back solutions in an effort to reduce the overall development lifecycle of which AJAX is but one small facet (if existent, which was the point of my original post). Having to wire up the back end for AJAX communication does not serve this end that is why pure JavaScript frameworks such as MochiKit or SAJAX are a partial solution and not the solution as a whole, which as an architect is what I have to concern myself with the most. Linux would draw a similar parallel, though the kernel is an important piece of the OS pie, it is in the end, a partial solution you need user land tools, as well as drivers and applications in order to have a complete and useful system. If RoR implemented their AJAX architecture incorrectly (or did not use a proven JavaScript kit) then that is a problem that you must sort with them and not me, as I am neither the designer nor an authority of RoR. As I said in my original post I welcome the incorporation of an AJAX layer into any of the prospective frameworks that I may have to use at some point and as I said from my evaluation the most intuitive and well designed framework that I have used to date is Echo2 as a developer need not concern themselves with any layer of the client communication. Ajax and HTTP communication are seamlessly integrated into the event model. As well HTML is encapsulated in their component model. Therefore a developer only need concern themselves with one language and one technology. Narrowing technological focus directly translates into increased productivity. I let the framework developers concern themselves with their implementation specifics. If it is broken take it up with them as that is exactly what I would do or I would find a new framework.
It is nice to see them add the AJAX / JavaScript integration. I would like to see more frameworks include a mature AJAX framework to facilitate more dynamic interaction. To date the best I have seen so far is Echo2 which incorporate an event driven architecture that allows for seamless integration of client side events transmitted to the server side architecture. In all good show, I hope more frameworks will follow suit.
I suspect that the Open Invention Network was set up to defend against this very possibility. If Microsoft makes a move the alliance will use their patents to counter. Which the companies involved have a pretty comprehensive portfolio.
Or are you claiming some kind of racial superiority
I don't think I would be so bold to claim a racial superiority, but races do tend to excel at different tasks and view problems and solutions in different ways. What I would claim is a distinct cultural advantage based on location. An offshore individual does not understand the intricacies of American business processes and therefore things as simple currency transfer can seem foreign to them. This creates a source of error and an overall loss of quality. This is where American programmers have a distinct advantage. Developers that understand their business domain are generally more productive than those that do not. This allows a development team to be more agile while decreasing the amount of bodies needed to complete a task. Many savvy managers are now starting to realize that two 70-80K a year guys that know their domain can outpace a team of 10 10-15K a year guys that are just reading specs. As much as we all like the idea of software manufacturing it just does not work that way in the real world. Quality not quantity of personnel effects the feasibility of a project and business acclimate is a quality that affects results. I for one would not take a business software contract for, say a German company as I have no idea about the intricacies of even macro elements like their economics how am I going to design the micro elements of a business when I don't have basic knowledge of their economic culture.
If your browser is hanging it is a bug with the browser and not the framework. Simply put if Java Script, XML or DHTML (the standard components of a client side web framework) crashes a browser it is the fault of the browser. A browser should be able to handle each of these basic elements and their exceptions with no problem and without freezing. That is like blaming a Java app and not the JVM for a memory leak. Sure there are sometimes poor coding standards that can cause such occasion to rear it's head but in the end a managed platform such as a browsers scripting runtime or the JVM should account for said exceptions. In the end the browser provides a scripting runtime and it is the sole responsibility of the browser to ensure that that runtime does not lock the entire process. If it does it is a bug in the browser. That being said many times developers can work around a known bug. Submit your findings to the developers and help them out.
While both cases can certainly be true, your authority over your own opinion is now somewhat dead
Why because I have been doing web apps since CGI/Perl and have worked with almost every web framework under the sun? or because you say so? None of my post support your conclusion. Just because I have recently discovered a framework does not mean that I am not (or am for that matter) an authoritive source on web application development. It merely means that in two months I have deduced that it is the best thing available for Java specific web frameworks. If anything it represents my ability to comprehend the technology at hand in a short timeframe nothing more can be inferred from my posts.
Independant developer. Freshly discoverd NextApp recently though they've been around for a bit. It's a little quick to drink the koolaid and provide them so much attention and props.
So what of it, They have been around for a while and I have already said that I had discovered them a few months ago. They originally developed the Echo Framework which was a standard request response framework Echo2 extends their component model to support AJAX type communication. I like the framework allot and like supporting open source development so if I can give someone credit for developing a good open source product I am going to take every opportunity to do so. I will probably pimp it some more before this thread is through .
Every knows Java servlets suck and you may just be looking to hook responses
What other Java option is there JSP / JSF laughable at best.
see my other post http://developers.slashdot.org/comments.pl?sid=180 799&cid=14959879 it already exits it is called Echo2 it is a open source Java web framework. AJAX is integrated seamlessly into the component model. It is the most comprehensive toolkit I have found. I have been researching them for my new project for several months now and Echo2 is leaps and bounds ahead of the other competing projects.
I concur 100% this has been going on for quite some time someone just put a fuzzy name on what developers have been using for years. Its like LAMP development, what the hell is that? what if I use PostreSQL am I not in the LAMP club? the acronym stuff is getting crazy.
Slashdot Mirror
I would like to see more web frameworks include a mature AJAX framework to facilitate more dynamic interaction. To date the best I have seen so far is Echo2 which incorporate an event driven architecture that allows for seamless integration of client side events transmitted to the server side architecture.
Hotline was ahead of its time. It was doing file sharing, instant messaging et al. back in the dark ages of 9600 modems. It was a great product and was as underground as one could get. It is sad that they had their troubles.
You hit the nail on the head. Many posters are thinking of these desktops in terms of home use in which I agree it is not applicable and will fail. But in the Corporate environment where thousands of desktops and application instances must be managed on a daily basis these technologies can be a god sent. They allow IT departments to manage a client side, platform independent, single install from a single location. Upgrades for 10K users are instantaneous; problems do not arise from different configurations on the client. For corporate application such as accounting systems this is one of the most promising developments in usability and manageability.
Yeah, I know it sounds wacky but I guess you would just have to see the application in action to understand the mitigation to bookmarks it does. My team is pretty well verses in a variety of frameworks. With a lot of experience in ASP / ASP.NET and JSP / Servlets so my guys do have a lot of experience with the options available and the design philosophies, but with the dynamic nature of Ajax it has been extremely easy for out users to implement document retrieval solutions that are more robust than just book-marking. Case in point I had one developer that built an XML file format that could save any applications state and be emailed, IM'ed or stored and then that application and session could be recreated via that document to the T. The user could pick up at any time (a year later) exactly where they left off. We are currently cleaning up the code and are going to submit it as an open library. It's like book-marking on steroids.
Don't worry about it; I have severe dyslexia as you may have gathered from my spelling mistakes. So compared to me you look pretty good. I thank you for the discussion as well.
The landing after login can be accomplished in either a HTTP Authentication or a "roll your own model" and I agree that it is the best design. My point with the authentication page was not that it did not matter that a user need land on the page but to highlight that in certain systems there is more involved in the process then just bookmaking a page for return. After reading my post it may seem that I was drawing the conclusion that it did not matter because the user must log in anyways.
The session expiration is a problem and I don't believe that it is the end all of a role your own system. This is where Ajax and a keep alive are now starting to help in fixing this model as you can issue keep alives without user interaction. By no means is the session based roll your own model the end all be all but it offers far more flexibility than HTTP Authentication.
Security is an ancillary note to this argument, not that it is not important but the fact of the matter is any way you slice it you are going to have to send credentials over the wire I take no issue with that point, The problem is in the design restriction HTTP Authentication presents on a web application. It is fine for restricting access to a single document or set of documents but what happens when you need code level access. What happens when you need to masquerade permissions for the execution of a certain code block. The problem is that HTTP Authentication is not exposing this functionality to the application. In some cases there are libraries but in many cases there are not or they may not exist for your languade of choice. Not to mention restrictions with distribution and scalability. What if you system is compromised with a contained solution there are no worries about a breach of the web-servers permissions system as they are not authenticated on it, or worse the OS's permissions system. An abstracted model allows for this buffer. As well, there is the issue of managing the authentication. With HTTP Authentication the server assumes that a user is authenticated until the browser is closed while this may not be a problem for some application it can present a major problem for say a banking application that may want to terminate specific permissions as soon as a transaction is completed. Security systems such as BOA's site key are virtually impossible to duplicate using a HTTP Authentication model.
The links I provided where merely to highlight the problems that developers are encountering with trying to retrofit a HTTP Authentication model. Nothing more can be inferred from them.
This bit of information would probably do a lot for Echo2's acceptance
c =136&st=0&p=425&#entry425
c =152&st=0&p=477&#entry477
c =300&st=0&p=1031&#entry1031
I agree but I think the problem is that as many of us use Echo2, we find less and less reasons to use book-marking capabilities. I have used it from time to time to show invoices and records but for the most part my developers have moved away from book-marking to other representation of data such as an icon on a user's workspace when they log in and our users love the simplicity of such a model. Anyway, I am rambling the point is your are correct the developers at Nextapp should tout this ability more as for some applications, not being able to bookmark is a show stopper.
Here is more info on the Bookmark pattern.
http://forum.nextapp.com/forum/index.php?showtopi
As well here is some info on the inter application communication. I am a little vague on Echo2's implementation of this as I have not had to cross this bridge with any of my applications, but these problems are being evaluated and addressed to my understanding.
http://forum.nextapp.com/forum/index.php?showtopi
http://forum.nextapp.com/forum/index.php?showtopi
Well, just imagine how damn silly you must look
0 4511.html
Indignation and personal attacks are indicative of a diminished capacity to reson. Lets leave them out of the conversation or it is over. If you have a beef with my information then attach my information as attacking me will show its hollow end.
As for the HTTP Authentication comment you are talking about HTTP authentication vs "role your own" in which I will defer you to this discussion as the problems with HTTP Authentication are so numbered that it would be redundant to spew them all out here
http://ask.metafilter.com/mefi/21446
http://www.imc.org/atom-protocol/mail-archive/msg
No one in the field actually uses Http Authentication. I mean who EBay? Amazon? E-Trade? Yahoo? Microsoft? So I don't see your point. They all roll their own many of them use built in system accounts (which is a whole other argument) and put a front end on it. I mean really no one has used HTTP Authentication in years.
There is a common design pattern that developers using Echo2 use to bookmark internal elements of within the application. It is via a URL string as many other web apps use. One only need grab the string from the servlet context and parse it to return the application to a specific state, say maybe a string added on to the URL such as &invoice_id=7 parsing out this value will allow the developer to retrieve and display the invoice. You can even do this after a log in screen. Currently you have to build your own parser and command interpreter but given the other benefits of Echo2 this is a small piece of software to write and if built correctly fairly reusable among applications.
Where Echo2 fails in my opinion is in inter-application communication you cannot have an application that passes it context to another application. The developers are currently proposing solutions for this problem but in reality it is a small problem as it is rare that a developer needs full context passed between applications. Few frameworks offer this feature but it allows for more robust applications and allows for greater reuse.
I did not move into another environment. I started out building web apps back in the CGI / Perl days when their was no framework and I know all to well the time frame it takes to develop a web app from the ground up when you have to slog through 12 different document, markup, script, and programming languages to get it out the door. I do not differ with the conclusion that sometimes resources need to be immediately accessible via a URL but some times they just don't. Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page. I am not trying to shoehorn an archaic model onto a web model I am trying to develop new models which enable my developers to develop web applications quickly. It may not work for all but it has worked successfully for me. Where it has failed I have opted for other frameworks.
Web applications are not desktop applications that happen to be used through a web
browser.
Ross,
I do not totally agree with your conclusion, different application requires different architectures. This is the very reason that there is a plethora of different frameworks some solve different problems while some tackle the same tasks ad nasium.
Echo2, is aimed at tackling the problem of a thin rich clients over the internet. It is not designed to supplant you standard page based web applications where bookmaking content is necessitated. For a portal type application it is not the right tool for the job. Where it is the right tool for the job is in building a dynamic application that is distributable and maintainable in a single instance. It is very good for enterprise system development of say and accounting system or a admin system in which the user is accomplishing a business process. I am not talking about end user content based sites but applications that have traditionally been the domain of the desktop. The savings on administration alone are astronomical. As I have said it is not the right tool for ever job but to discount it out of hand is to not give it due diligence. In my realm of work Echo2 has liberated me for have to make the choice of either giving up the simplistic distribution of the web or the dynamic nature of the desktop.
The Nextapp devs and marketers say you shouldn't need to tell someone a URL that takes them directly to a particular piece of information
Again, an application designed to input information to store in a DB or to transact a process is where such frameworks shine not in content rich applications such as a shopping site or a documentation project. It depends on the nature of the application. If you are just creating a word document and saving it on a server then there is no need to bookmark said information. A completely different architecture exists for retrieving information in this design, such as opening the saved document from the web application.
Don,
I thank you for the heads up on the possibility of problems with the Ajax components of RoR as of now I am not currently evaluating RoR for any projects so my knowledge of the framework is limited to small test applications to gain personal knowledge of the framework as a whole. I concur with many conclusions that both you and the author of the article you cited draw. Breaking core functionality of a language is neither a good practice nor is it advisable. If I have the chance to evaluate RoR for a project I will keep your notes in mind and test my proof of concepts to test the fabric of the framework to ensure that they will not hinder my design.
As someone who's evaluated various JavaScript frameworks
I do not evaluate JavaScript frameworks as JavaScript is only one portion of a mutli-teir application. I focus my efforts on comprehensive frameworks (such as RoR, Echo2, ASP.NET, JSF, etc.) that incorporate front to back solutions in an effort to reduce the overall development lifecycle of which AJAX is but one small facet (if existent, which was the point of my original post). Having to wire up the back end for AJAX communication does not serve this end that is why pure JavaScript frameworks such as MochiKit or SAJAX are a partial solution and not the solution as a whole, which as an architect is what I have to concern myself with the most. Linux would draw a similar parallel, though the kernel is an important piece of the OS pie, it is in the end, a partial solution you need user land tools, as well as drivers and applications in order to have a complete and useful system. If RoR implemented their AJAX architecture incorrectly (or did not use a proven JavaScript kit) then that is a problem that you must sort with them and not me, as I am neither the designer nor an authority of RoR. As I said in my original post I welcome the incorporation of an AJAX layer into any of the prospective frameworks that I may have to use at some point and as I said from my evaluation the most intuitive and well designed framework that I have used to date is Echo2 as a developer need not concern themselves with any layer of the client communication. Ajax and HTTP communication are seamlessly integrated into the event model. As well HTML is encapsulated in their component model. Therefore a developer only need concern themselves with one language and one technology. Narrowing technological focus directly translates into increased productivity. I let the framework developers concern themselves with their implementation specifics. If it is broken take it up with them as that is exactly what I would do or I would find a new framework.
No I design web-based enterprise systems, I make it my job to evaluate all possible framework options.
It is nice to see them add the AJAX / JavaScript integration. I would like to see more frameworks include a mature AJAX framework to facilitate more dynamic interaction. To date the best I have seen so far is Echo2 which incorporate an event driven architecture that allows for seamless integration of client side events transmitted to the server side architecture. In all good show, I hope more frameworks will follow suit.
I suspect that the Open Invention Network was set up to defend against this very possibility. If Microsoft makes a move the alliance will use their patents to counter. Which the companies involved have a pretty comprehensive portfolio.
Yes the chairs are strictly reserved for WWG wrestling.
Or are you claiming some kind of racial superiority
I don't think I would be so bold to claim a racial superiority, but races do tend to excel at different tasks and view problems and solutions in different ways. What I would claim is a distinct cultural advantage based on location. An offshore individual does not understand the intricacies of American business processes and therefore things as simple currency transfer can seem foreign to them. This creates a source of error and an overall loss of quality. This is where American programmers have a distinct advantage. Developers that understand their business domain are generally more productive than those that do not. This allows a development team to be more agile while decreasing the amount of bodies needed to complete a task. Many savvy managers are now starting to realize that two 70-80K a year guys that know their domain can outpace a team of 10 10-15K a year guys that are just reading specs. As much as we all like the idea of software manufacturing it just does not work that way in the real world. Quality not quantity of personnel effects the feasibility of a project and business acclimate is a quality that affects results. I for one would not take a business software contract for, say a German company as I have no idea about the intricacies of even macro elements like their economics how am I going to design the micro elements of a business when I don't have basic knowledge of their economic culture.
If your browser is hanging it is a bug with the browser and not the framework. Simply put if Java Script, XML or DHTML (the standard components of a client side web framework) crashes a browser it is the fault of the browser. A browser should be able to handle each of these basic elements and their exceptions with no problem and without freezing. That is like blaming a Java app and not the JVM for a memory leak. Sure there are sometimes poor coding standards that can cause such occasion to rear it's head but in the end a managed platform such as a browsers scripting runtime or the JVM should account for said exceptions. In the end the browser provides a scripting runtime and it is the sole responsibility of the browser to ensure that that runtime does not lock the entire process. If it does it is a bug in the browser. That being said many times developers can work around a known bug. Submit your findings to the developers and help them out.
Here is a direct link to the RAD tools http://www.nextapp.com/platform/echo2/echostudio/
While both cases can certainly be true, your authority over your own opinion is now somewhat dead
Why because I have been doing web apps since CGI/Perl and have worked with almost every web framework under the sun? or because you say so? None of my post support your conclusion. Just because I have recently discovered a framework does not mean that I am not (or am for that matter) an authoritive source on web application development. It merely means that in two months I have deduced that it is the best thing available for Java specific web frameworks. If anything it represents my ability to comprehend the technology at hand in a short timeframe nothing more can be inferred from my posts.
Independant developer. Freshly discoverd NextApp recently though they've been around for a bit. It's a little quick to drink the koolaid and provide them so much attention and props.
So what of it, They have been around for a while and I have already said that I had discovered them a few months ago. They originally developed the Echo Framework which was a standard request response framework Echo2 extends their component model to support AJAX type communication. I like the framework allot and like supporting open source development so if I can give someone credit for developing a good open source product I am going to take every opportunity to do so. I will probably pimp it some more before this thread is through .
Every knows Java servlets suck and you may just be looking to hook responses
What other Java option is there JSP / JSF laughable at best.
see my other post http://developers.slashdot.org/comments.pl?sid=180 799&cid=14959879 it already exits it is called Echo2 it is a open source Java web framework. AJAX is integrated seamlessly into the component model. It is the most comprehensive toolkit I have found. I have been researching them for my new project for several months now and Echo2 is leaps and bounds ahead of the other competing projects.
I concur 100% this has been going on for quite some time someone just put a fuzzy name on what developers have been using for years. Its like LAMP development, what the hell is that? what if I use PostreSQL am I not in the LAMP club? the acronym stuff is getting crazy.