Slashdot Mirror

It's an attempt to make Javascript more Java-like. To be honest, I've only scanned the docs and haven't used it yet, but plan to.

If anyone has some real-world experience they'd like to share, I'd love to hear about it.

http://echo.nextapp.com/site/corejs

Echo is similar, but written in Java. It uses widgets and everything runs on the server side. The client side is just a Javascript program that draws the web app components. Very fast to develop in. I'm hoping that we will see some nice work coming out of Broadway - the HTML5 backend for GTK. Native apps, written in whatever language you want, straight to the web. There's a lot of advantage to keeping all the logic server-side in one persistent (I'm tempted to say "proper") application, and relegating HTML+Javascript to function only as a client-side display layer.

When I first got my EVO i bought into this. Then I downloaded SystemPanel:
http://android.nextapp.com/site/systempanel

At the time all the features of the pay version were in the unlocked version. So I got to play around with the profiling features. I have since paid for the app.

This is what I discovered. The Sprint apps don't do jack if you never use them. The only app that actually runs despite me having no need for it is the voicemail app because I don't use Sprint's voicemail.

What people don't understand is that Android loads applications into memory on the idea that you might use them. Which applications it thinks you might use is based on what you actually use. So when you first get the phone and it doesn't have any history and not many applications loaded on it. There's a very good chance that the Sprint apps are going to be the ones getting cached. The cached apps use no CPU time. They're just in memory in case you decide to run them.

I've stopped using a task killer, my battery time hasn't gotten worse. Nothing about my phone has really changed.

In short, yeah it sucks you can't remove those apps and they're taking up space, but they're not hurting performance. They're not even running unless you run them.

See also this explanation from the developer of the SystemPanel app as to why automated task killing is a bad idea:
http://android.nextapp.com/site/systempanel/doc/autokill

When I first got my EVO i bought into this. Then I downloaded SystemPanel:
http://android.nextapp.com/site/systempanel

At the time all the features of the pay version were in the unlocked version. So I got to play around with the profiling features. I have since paid for the app.

This is what I discovered. The Sprint apps don't do jack if you never use them. The only app that actually runs despite me having no need for it is the voicemail app because I don't use Sprint's voicemail.

What people don't understand is that Android loads applications into memory on the idea that you might use them. Which applications it thinks you might use is based on what you actually use. So when you first get the phone and it doesn't have any history and not many applications loaded on it. There's a very good chance that the Sprint apps are going to be the ones getting cached. The cached apps use no CPU time. They're just in memory in case you decide to run them.

I've stopped using a task killer, my battery time hasn't gotten worse. Nothing about my phone has really changed.

In short, yeah it sucks you can't remove those apps and they're taking up space, but they're not hurting performance. They're not even running unless you run them.

See also this explanation from the developer of the SystemPanel app as to why automated task killing is a bad idea:
http://android.nextapp.com/site/systempanel/doc/autokill

Love the new UI, and really appreciate the option of another well done browser. But they still refuse to fix a trivial CSS bug which has horrible consequences for AJAX apps.

Just go to this page, and resize your browser with the vertical (not horizontal) handle.
http://echo.nextapp.com/content/test/operacss/

(This is very hard/impossible to do on a mac, as they don't really have one).

Unfortunately the bug is not limited to resizing with the vertical handle...it manifests itself in other ways. It seems the browser is incorrectly measuring/reporting the vertical size of elements, and sometimes uses this data internally (as in the case of this test).

Full thread is here:
http://my.opera.com/community/forums/topic.dml?id=250572

And one of the Ajax apps that experiences more serious failures as a result: http://demo.nextapp.com/

Love the new UI, and really appreciate the option of another well done browser. But they still refuse to fix a trivial CSS bug which has horrible consequences for AJAX apps.

Just go to this page, and resize your browser with the vertical (not horizontal) handle.
http://echo.nextapp.com/content/test/operacss/

(This is very hard/impossible to do on a mac, as they don't really have one).

Unfortunately the bug is not limited to resizing with the vertical handle...it manifests itself in other ways. It seems the browser is incorrectly measuring/reporting the vertical size of elements, and sometimes uses this data internally (as in the case of this test).

Full thread is here:
http://my.opera.com/community/forums/topic.dml?id=250572

And one of the Ajax apps that experiences more serious failures as a result: http://demo.nextapp.com/

- latest 'as of today'
- performance is fine, other than the jumpy bits
- slashdot is not the issue ( though slashdot HAS issues. I certainly wouldn't use Slashdot as a field test to check whether browsers display the same :D ). See the demo page from the GP post:
post: http://slashdot.org/comments.pl?sid=1354247&cid=29272487
demo page: http://echo.nextapp.com/content/test/operacss/

My example: http://echo.nextapp.com/content/test/operacss/

The consequences get a bit more catastrophic with applications with larger quantities of nested DIVs. Things really start to break when you start measuring using Element.offsetHeight.

Apologies for posting it here...again...but I'm tired of replying to users who ask "why does component X not render properly in Opera, it passes Acid3 thus something must be wrong with the component."

It may be ACID3 compliant, but it still can't correctly render two nested DIVs:

http://my.opera.com/community/forums/topic.dml?id=250572

To see it fail, just go to this page in Opera 10: http://echo.nextapp.com/content/test/operacss/ , and resize your browser vertically (but NOT horizontally). It's been reported in the bugtracker, forums, forum PMs to developers, etc..

So please, when you file that bug report today that "Opera 10 doesn't render things correctly" to whatever your AJAX framework of choice happens to be, don't make a big deal out of the fact that it's "Acid3 compliant" and thus the AJAX framework developers must be in the wrong.

As a developer of an AJAX-based web framework, I'm upset to see IE8 being thrown out the door so quickly. RC1 was nothing short of a disaster: it had a performance bug where nesting absolute-positioned DIVs would result in exponential performance decreases.

Test case here: http://echo.nextapp.com/content/test/ie8/

The 25-nested DIV test would require killing the browser. Nesting absolutely positioned DIVs is somewhat fundamental to delivering application-style user interface layouts in a web browser.

I reported this bug everywhere I could, and Microsoft actually did a great job in responding to it. They say they've found it and fixed it. But there is no way for us to test this. We must simply take their word for it and wait. They're going from RC1 to final, and begging and pleading for an interim build didn't warrant much of a response.

From reading forums (e.g. Ajaxian: http://ajaxian.com/archives/push-back-digital-tv-or-ie-8), my IE8 experience is not uncommon with other web frameworks as well. The average developer's opinion there suggests RC1 is nowhere near ready for a final release. Every build of IE8 (beta1, beta2, win 7's "beta2+", and the RC) have each had major unique problems not found in other releases.

I have developers asking me if their software will work in IE8 on day 1 and the only honest answer is "I have absolutely no idea." Anyone (without a final build) who tells you otherwise, even offerring a rough estimate, is a liar, IMHO.

I don't understand the point of putting out a "release candidate" and then not using feedback to determine whether the next release is a "candidate" or a "final". Our bug alone means that IE8 RC1 has never been publicly tested with many complex web-based applications.

Just tried it out, and of course it passes ACID3 as advertised. I still can't recommend this browser on the grounds that it can't correctly render absolutely positioned CSS elements, as demonstrated by the following code:

<!DOCTYPE html
          PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Resize your browser with the vertical handle!</title>
  </head>
  <body>
  <div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:lime;">
  <div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:red;">
  </div>
  </div>
  </body>
</html>

Hosted version of the above:
http://echo.nextapp.com/content/test/operacss/

Opera 9.50, 9.60, and now 10.0alpha will not render the above properly if the browser is resized vertically. (9.27 and prior work perfectly) On the initial render, 9.5/9.6 and 10 do fine, but the moment one resizes the browser vertically (and NOT horizontally as well), things go awry. I reported this to their bug tracker six months ago, and posted a thread on their forums 2.5 months ago: http://my.opera.com/community/forums/topic.dml?id=250572 Have also mentioned it in their 9.6-about-to-be-released-post-non-working-sites thread.

This bug has additional consequences for AJAX applications that make use of on-screen measuring using offsetWidth/offsetHeight information. In such cases, even the initial rendering can be seriously flawed as offsetHeight returns incorrect values. (Note: offsetXXX properties are not part of a proper W3c standard, but are universally supported).

Apologize for the quasi-rant, but I just don't want to see another bug report about how our applications don't look right in a supposedly ACID3 compliant browser, thus indicating that the problem "MUST" be our fault. Please realize that passing ACID3, while a neat accomplishment and generally good thing, is far from a guarantee of standards compliance.

Maybe offtopic, but does anyone know what the new hotness is, java/jsp/j2ee wise, wrt ajax frameworks? I've forked around with echo2 but I'm not totally sold.

I can google all I want, but I'd love some opinions.

Go check it out, then come back and tell me that Campfire is a feature-for-feature clone:

    http://demo.nextapp.com/ChatClient/app

This is just chat, and chat's been done hundreds of times. Campfire is so much more.

Before last month, my first chance to try out Actionscript 3, I would have thought that big, feature rich, complex apps would be impossible (or rather, run like ass) due to speed limitations of Actionscript. This benchmark very accurately mirrors what I've seen with AS3: its overall performance whips the pants off of Javascript and previous versions of Actionscript, and in many cases hugs Java pretty closely or even beats it (by a small amount). This is after how many years of JVM optimizations and improvements? Not bad.

Think what all has been done with Javascript without getting too slow. Now make the language a lot faster, and add some pretty advanced bitmap and vector graphics support that runs native, and the use of "shared objects" (local storage of arbitrary data). I see possibilities.

Never heard of zk before, but their demos are very uninspiring.

Now this is an impressive ajax framework demo.

Why don't you learn to use a framework? For example, Echo2 has an API similar to Swing and builds desktop-like applications. Try the demos. It also handles the browser computability issues for you.

Developing with it simply rocks.

Something I'm more impressed with is Echo2, which is dual licensed under the LGPL and MPL. Try out the demos. It's possible to do some really cool stuff with it. I started learning it a few days ago, so far it seems really nice.

If the Java plugin didn't freeze the browser while downloading and run at glacier-speed, it would be decent for a browser. Java is a nice language, especially with frameworks like Echo2 (try the demos, it rocks). What hurts Java is that Swing and the plugin suck rather hard.

If you enjoy using FireBug, it is likely you are not really productive...

Don't get me wrong, I think the tool is excellent, but do you really want to go bug chasing at this low level of abstraction ? You can easily waste hours debugging like this, figuring out what exactly happened (or didn't happen) ...

I think you are better off using a high level AJAX toolkit like echo2 or Wt instead, blame their developers for any JavaScript or other unexpected trouble, and let developers of these toolkits enjoy FireBug in ironing out these bugs.

Try Echo2 from NextApp. It's open source and has a nice little community. Requires a server-side Servlet container so it's not a translator like GWT but it's got a lot more widgets. http://www.nextapp.com/platform/echo2/echo/

http://www.nextapp.com/Echo2is awesome. Use it. love it. K. Bye.

If this guy had even bothered to look online at what AJAX is today, he'd realize that there are frameworks such as Echo2 http://www.nextapp.com/platform/echo2/echo/ that make writing AJAX applications no more complicated than writing Swing apps.

AJAX is happening because there's nobody willing to take the lead in Web 2.0.

Echo2 is a dream to develop with (forget html, form backing objects etc. Think swing api)

The cross browser compatibility is excellent, the performance impressive and writing your own custom components (not that you'll often need to) is not too bad either.

Give it a go and you'll see what I mean.

Have a look at the demo app to see what it can do: http://demo.nextapp.com/Demo/app

(and always forgotten in those roundups):
http://www.nextapp.com/platform/echo2/echo/
If the future of webapps is based on a combination of ugly hacks such as the xmlhttprequest and other technologies which aren't meant to be used as some kind of thin client protocol, why not just let the framework do all that stuff, allowing you to concentrate on the business logic? Writing an echo2 app is like writing a normal, standalone gui app.

the echo2 library is an Ajax library which makes web application development as easy as desktop application development; it is an all-Java framework with no need to write even one line of XML/HTML/JSP/other. You can find it here:

http://www.nextapp.com/platform/echo2/echo/

once again, echo is missing...

Echo http://nextapp.com/ is quite nice IMO

What about Echo2 http://www.nextapp.com/platform/echo2/echo/ ?

That's pretty cool. Here's their demo. After clicking through this, I have to say: for all the mockery of "Web 2.0" around here, there is a HUGE change from 10 years ago (writing static pages in html) to this demo (writing what appear to be fairly normal applications in Java, where supposedly the developer avoids the grab-bag of "web technologies" altogether). I realize the exact choice of when to use a new major version number is somewhat arbitrary, but things really have changed. Too bad it's almost impossible to write a fully functional web browser from scratch anymore, but could it be that real, general-purpose hosted office apps are finally becoming a reality?

1. Download Echo2 http://nextapp.com/platform/echo2/echo/
2. Write AJAX applications like you would a Swing app, never touching HTML or Javascript.
3. Go outside and play.

'nuff said.

The team I used to work for 3 years ago wanted a web gui layer framework similar to this back then.. and i remember Echo 1.x was one of the first ones we prototyped. Then there also was millstone http://www.millstone.org/ And i think echo was also featured on slashdot http://developers.slashdot.org/article.pl?sid=03/0 9/09/2337216
Echo 2.x seems to have now added support for ajax.. a demo is available here: http://demo.nextapp.com/Demo/app ..and it runs smoother than the ajax controls found on flickr atleast. In the end it seemed that the world wasnt ready for this... and higher management didnt like the risk associated with trying something completely new.

This seems like a useful article. At work we were just discussing the possibilities of using the GWT. Currently we use NextApp's Echo1 and are also pondering upgrading to Echo2. The demo app for Echo2 is actually mighty impressive; I'd say moreso than GWT's. Though I wonder how much of it is just more time spent on fancy graphics as opposed to a better quality framework.

Hadn't heard of that one yet. And I realized later that I had forgotten Echo, so things just keep getting better and better.

I will see your ICallbackEventHandler and raise you a ActionListener It existed long before Atlas. I do both .NET and Java web work, I like ASP.NET and I have found Echo2 to be the closest to ASP.NET as far as productivity, and speed of development. While the implementations are different the basic idea (component / sub-component page hierarchy) are the same.

Coding your UI in java and having it translated into javascript and html without having to worry about cross browser compatibility?

Sounds familiar. It's rather like the echo framework

The big differences I see are:

1) Google toolkit advantages:
- No load on the server to render the UI. All ui code runs on the browser, so this may help server scalability.

2) Echo advantages:
- Fully open source.
- Richer set of ui components (IMO - see the demo at http://demo.nextapp.com/Demo/app )

Coding your UI in java and having it translated into javascript and html without having to worry about cross browser compatibility?

Sounds familiar. It's rather like the echo framework

The big differences I see are:

1) Google toolkit advantages:
- No load on the server to render the UI. All ui code runs on the browser, so this may help server scalability.

2) Echo advantages:
- Fully open source.
- Richer set of ui components (IMO - see the demo at http://demo.nextapp.com/Demo/app )

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.

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.

Here is more info on the Bookmark pattern.
http://forum.nextapp.com/forum/index.php?showtopic =136&st=0&p=425&#entry425

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?showtopic =152&st=0&p=477&#entry477
http://forum.nextapp.com/forum/index.php?showtopic =300&st=0&p=1031&#entry1031

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.

Here is more info on the Bookmark pattern.
http://forum.nextapp.com/forum/index.php?showtopic =136&st=0&p=425&#entry425

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?showtopic =152&st=0&p=477&#entry477
http://forum.nextapp.com/forum/index.php?showtopic =300&st=0&p=1031&#entry1031

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.

Here is more info on the Bookmark pattern.
http://forum.nextapp.com/forum/index.php?showtopic =136&st=0&p=425&#entry425

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?showtopic =152&st=0&p=477&#entry477
http://forum.nextapp.com/forum/index.php?showtopic =300&st=0&p=1031&#entry1031

First let me say that I'm the lead developer of Echo2, which absolutely requires JavaScript in order to function, so please take that into account as a bias if you desire.

I disagree with the statement "JavaScript is insecure". Implementations may be insecure, but the specification itself has no such problem. There have certainly been security holes discovered in JavaScript implementations. There have been equally dangerous security holes discovered in other aspects of the browser.

My other question to the "disable JavaScript" camp is, "what do you propose as an alternative?" Flash, client-side Java or any similar technology has the same security concerns as client-side JavaScript. The answer of "just use plain HTML" is not a solution. JavaScript and this "AJAX" stuff is not just about adding bling to applications--it's about eroding the barrier between remote and desktop applications.

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.

Try http://www.nextapp.com/platform/echo2/echo/
It fits everything together well, and you don't have to write a single line of HTML or javascript.
If you can write a swing application, you can write an echo2 application.

Also, XMLHTTPRequest is just that, a request. What gets sent back is up to the server.
The difference is that it doesn't cause an entire page refresh in the browser itself.

Here is a direct link to the RAD tools http://www.nextapp.com/platform/echo2/echostudio/

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.

Well, the AJAX wars have started, and M$ maybe just got off the first shot.

Microsoft did not fire the first shot Next App has had a mature Open Source Java Servlet / AJAX framework called echo2 and eclipse plugin for quite some time now.

While I agree that JavaScript is not the ideal candidate for developing any system, much less a web app it is what we are limited to. Java Applets et. al. are DOA, unsupported or don't fit within the model of web application development. For better or worse those are the breaks.

I differ with you on the presumption that AJAX is irrelevant, as recently as a few months ago I would have concurred with this notion and would have agreed that it was a new spin on some simple technologies. That was until I found the Echo2 framework, it is an Open Source Java framework built on top of the servlet API it is the first comprehensive Ajax framework that I have found and the component model is both flexible and intuitive. It is the first framework where I have not felt the restrictions of the web metaphor creeping into design decisions. It has changed my idea of what Ajax web apps are capable of in terms of usability, speed, code reuse and overall system design.

http://www.nextapp.com/platform/echo2/echo/

If you want a proper application that handles user and error conditions gracefully, it helps to use a tool that aids good design.

Echo2 lets you build AJAX applications as if you were writing a swing app.
No messy html/javascript. You don't even need to know that XMLHttpRequest exists.

I'm currently in the process of building an AJAX app for a large financial institution and all I can say is thank god I don't have to mess about in javascript to make a nice application.

I think it is less about the language and more about the framework. JSP / JSF et. al., are just too bloated with configuration and XML files that leave the new developers scratching their head. If you look at other frameworks such as Echo2 , you can have a developer developing in no time given a familiarity with Java. Frameworks such as Echo have very little configuration to get up and running and provide a very code centric way to deploy web applications they allow a programmer to stay in their domain of expertise and allow for faster production. Lighter frameworks are the key not new languages.

Hello, If you're interested in an alternative bug tracking tool that is open source, you should check out TrackIt. Not only does it manage bugs, but it also supports features, requirements, test cases, and much more, in addition to any user defined item types. It integrates with Subversion and CVS, as well as preliminary integration with Eclipse. Other features include a Timeline view that is also viewable via RSS, a Listing driven by HQL, Reports driven by SQL, fully customizable lookup lists, project news, a high level summary view, nightly build integration, and user customizable RSS feeds.

Under the hood, it's implemented using Hibernate 3 and the fully AJAX enabled Java web toolkit, Echo2