Saturday, October 29, 2005
LazyWeb Request: JavaScript 2.0 Preprocessor
I'd like to see a preprocessor that can take JavaScript 2.0 code and turn it into JavaScript 1.5 code, so that you can get it's advantages for development, such as true OOP syntax, but deploy it to existing clients. This is actually what Flash does; it takes ActionScript 2.0 code (which is basicly JavaScript 2.0) and preproceses it down to the old, core ActionScript bytecodes. The one downside to this is that you can't run eval() on the JavaScript 2.0 code, but being able to have real object oriented notation instead of the ghetto prototype system makes it worth it for programming in the large, which most AJAX systems are starting to need to be manageable.
It would be cool to have this for E4X as well, so that we can start using it it in Internet Explorer by preprocessing it into JavaScript 1.5 code.
Having this would really jumpstart large AJAX apps.
Any skillful language hackers want to use the Java Rhino engine to do this?
It would be cool to have this for E4X as well, so that we can start using it it in Internet Explorer by preprocessing it into JavaScript 1.5 code.
Having this would really jumpstart large AJAX apps.
Any skillful language hackers want to use the Java Rhino engine to do this?
How would you integrate Ruby and the Really Simple History framework?
Quick question: How would you integrate Ruby on Rails and the Really Simple History frameworks and AMASS? RSH provides bookmarking and back button support for AJAX applications, while AMASS is an alpha framework that provides large amounts of persistent storage. I'm still learning the Ruby Way, so I don't know the most natural way one would integrate these into Ruby to make them more transparent. I'd love to know people's thoughts.
Also, are you interested in doing this kind of integration? It would be very cool.
Also, are you interested in doing this kind of integration? It would be very cool.
Freeze!
Over on Randomize there is a great idea on how to bake in native history support in browsers for AJAX apps:
"I was just reading some documentation for a framework designed to make it possible to add "back-button compatability" to AJAX applications and was struck by the complexity required.
Instead, I'd like to see browser support for a new method. Immediately before executing a DHTML action that might be considered analogous to "navigation," a web app could call the method (if supported). This would create a clone of the current document as it exists and "freeze" it in the browser history, making the old version available in the Back/Forward button queue. A "restore point," if you will--not in terms of a true undo/redo, but at least a bread-crumb trail back to previous "screens."
This would be ridiculously easy to implement, would degrade gracefully (test for support, older browsers just don't get the history navigation capability), and would go a long way toward improving usability of sites with heavy in-page interactivity.
Going further, users of tabbed browsers should be able to do the same thing ad-hoc. Currently, if a user opens a hyperlink in a new tab and the href is a JavaScript action, they get a blank page. A better response would be for the browser to clone the DOM to a new tab and execute the action on the cloned tab (but not on the source tab). This would, for instance, allow a GMail user to open a message in a new tab just as they would with a non-AJAX application."
The blog poster has some good ideas on how to reduce the complexity in my original proposal for native browser DHTML history support, which I agree is too complex.
"I was just reading some documentation for a framework designed to make it possible to add "back-button compatability" to AJAX applications and was struck by the complexity required.
Instead, I'd like to see browser support for a new method. Immediately before executing a DHTML action that might be considered analogous to "navigation," a web app could call the method (if supported). This would create a clone of the current document as it exists and "freeze" it in the browser history, making the old version available in the Back/Forward button queue. A "restore point," if you will--not in terms of a true undo/redo, but at least a bread-crumb trail back to previous "screens."
This would be ridiculously easy to implement, would degrade gracefully (test for support, older browsers just don't get the history navigation capability), and would go a long way toward improving usability of sites with heavy in-page interactivity.
Going further, users of tabbed browsers should be able to do the same thing ad-hoc. Currently, if a user opens a hyperlink in a new tab and the href is a JavaScript action, they get a blank page. A better response would be for the browser to clone the DOM to a new tab and execute the action on the cloned tab (but not on the source tab). This would, for instance, allow a GMail user to open a message in a new tab just as they would with a non-AJAX application."
The blog poster has some good ideas on how to reduce the complexity in my original proposal for native browser DHTML history support, which I agree is too complex.
Subscribe to Posts [Atom]
