Aptana Cloud plugs right into your IDE to provide instant deployment, smart synchronization, and seamless migration as you scale. Aptana Cloud is ideal for developers who use scripting languages to create Ajax, Facebook, mySpace and all other sorts of Web applications.
The key is that this isn’t a infrastructure play, which they clearly point out:
Aptana Cloud is architected to complement Cloud infrastructure providers like Amazon, Google, Joyent and others. To get started we’ve selected Joyent who serves up some of the largest of all Facebook apps.
This shows that their platform is designed to go meta, allowing you to deploy to various clouds in the future.
I think that the number one meme from Web 2.0 Expo last week was the “cloud”, coming off of the excitement of Google App Engine. With Aptana Cloud we will see sophisticated tools to make us productive in the cloud. I am very excited to see that it won’t be too long until developers will be able to build an application, hit DEPLOY, and be done. This is a huge win.
For developers:
IDE plug-in integrates Cloud development, deployment and management life-cycles right into Aptana Studio in either its standalone or Eclipse based editions
Instant deployment of projects to Cloud
One click sync your project to the Cloud, or provide fine grained sync control too
Integrated service management consoles
Configure desired memory size and disk size
Develop and instantly preview remote files right inside your Studio desktop environment
Subversion source control.
As Ajax developers, the vision of Jaxer in the cloud is very interesting too. The entire application using JavaScript, and deployed up into the cloud, all through the nice IDE.
I was also pleased to read that not only Ruby on Rails, but Python is on the docket. After developing Django applications and playing with Google App Engine, I would love to be able to use Studio for Python code too. Not that Emacs (X or GNU) isn’t great, Steve!
Darryl Taft wrote:
Aptana adds extra value via IDE integration, deployment automation and active monitoring and notification services, Hakman said. “It’s like the ease and simplicity between iTunes on your desktop and its connectivity to services on the Web,” he said.
For developers, the IDE plug-in integrates cloud development, deployment and management lifecycles right into Aptana Studio in either its standalone or Eclipse-based editions, Hakman said. “The ability to deploy stuff to the cloud from Eclipse is part of this as well.”
Other developer features include instant deployment of projects to the cloud; one click can sync your project to the cloud or provide fine-grained sync control; the technology features integrated cloud services management, enables users to provision their cloud right from Aptana Studio, configure desired memory size and disk size, develop and instantly preview remote files right inside the Studio desktop environment, and includes Subversion Source Control.
Dealing with file uploads can be a test of a Web framework. I personally long for the input type="file" to be improved with items such as multiple="true" for multiselection, let alone showing the status of the upload (20% complete).
The Jaxer folks have posted on Easy File Uploading using Aptana Jaxer which shows how you can tinker in JavaScript to get everything you need in a very simple way:
To receive the data from the form when submitted we put some Jaxer code into the page the form will be submitted to. The code below should be in script block with a runat = 'server' attribute, which makes the code run serverside and doesn't present it to the client so you don't expose any serverside filenames or folder structures.
Aptana took over the RadRails open source project a few months back, and now have fully integrated it with Aptana Studio with the RadRails 1.0 release.
RadRails 1.0 runs as a plug-in to Aptana Studio. So in addition to all the Ruby on Rails IDE goodies and the integrated Rails shell command-line console, developers get the great HTML, CSS, DOM, JavaScript and Ajax features in Aptana Studio, which can run stand alone or within Eclipse to that all your other Eclipse tools can be right there as well.
The new version has a slew of new and enhanced functionality such as:
Rails 2.0 support
JRuby support
Bundled auto-installing gems for rails development
A Ruby profiler for Pro users
An RDoc preview view
Extended RHTML/ERb color preferences
Code completion for ActiveRecord model fields and finders
Code completion suggesting method call arguments
Significant expansion of code warnings and analysis, including syntax changes from Ruby 1.8 to 1.9
Once this is done, Dojo should load in Jaxer, and you can utilize the library capabilities of the Dojo Toolkit on the server side. In particular, you can now use the DTL renderer as you would on the browser. The DTL renderer can take templates written using Django template language and render the templates based upon JSON data. If you are running Jaxer, you can view a demonstration of DTL rendering on the server by loading /dojox/dtl/demos/demo_Templated_Jaxer.html (make sure the Dojo Toolkit base URL is correct).
By using Jaxer’s capability to allow scripts to execute on both the client and server, we can utilize our Dojo Toolkit in both environments. On the server we can utilize many of the Dojo Toolkit’s features such as functional language features, math libraries, cryptography, dates, encoding, and more to improve development speed and code quality. We can use the same powerful features and idioms in both the browser and the server. An example of a practical way to use the Dojo Toolkit in both environments is to utilize the DTL renderer as described above to generate HTML on the server, and then use the Dojo Toolkit’s Ajax capabilities to dynamically update the page once it’s on the browser. For example: we could use the DTL renderer to display the comments in a blog, dynamically add any new comment the user makes at the end of the list of comments, and then send the comment to the server using Ajax.
It is important to note that Jaxer is not capable of transferring the programatically set event handlers for widgets—it can only send the static HTML to the browser. This means you can use DTL as a templating engine to create HTML on the server, but the Dojo Toolkit client side widgets are still necessary if you want to use interactive widgets on the browser.
When we posted the last podcast on Aptana Jaxer, someone commented on the fact that Kevin Hakman was there, and "Doesn’t Kevin Hakman work for Tibco? What does he have to do with Aptana?".
We are excited to announce that Kevin Hakman has joined Aptana to head up marketing and developer community programs. Kevin is a recognized leader in the Ajax community. Long before the term "Ajax" was coined, Kevin was pioneering single page web application concepts via the company he co-founded, General Interface Corp., one of the first enterprise Ajax libraries and visual development tools companies. General Interface Corp. went on to be acquired by TIBCO Software in 2004 as a compliment the company's service-oriented architecture (SOA) products. Today TIBCO General Interface is used by many Fortune-scale companies for rapid Web application development and deployment atop their XML and SOAP data sources.
In addition to his historic role on the steering committee of the OpenAjax Alliance, Kevin currently chairs the organization's integrated development environment working group. The OpenAjax Alliance IDE Working Group which includes Adobe, Aptana, the Eclipse Foundation, IBM, Microsoft, Sun, TIBCO and others is now close to delivering a draft specification for a uniform way to describe Ajax libraries and controls and thus streamline the ability to use Ajax libraries within your development tools of choice. Kevin is a frequent speaker at Ajax industry events and is an author to many published articles on Ajax in the enterprise.
I asked Kevin a couple of questions about his move, comparisons between the companies, and the industry in general.
What similarities / differences do you see between pioneering heavy JavaScript on the client w/ GI and JavaScript on the server with Aptana
GI and Aptana's primary application models are different to serve different purposes similar to the way that Java has multiple presentation tier architectures for differents kinds of apps: Swing, SWT, AWT for application GUIs and JSP, JSF for generating web pages. With GI, the concept in 2001 when we deployed some of the first "Ajax" apps pretty much evolved from a need to migrate software-style GUIs to the Web and a technical approach summarized as "we like Java Swing, but not the JRE dependency, so let's do something Swing-like in JavaScript with a JavaScript VM of sorts and get data as XML / SOAP via the XML HTTP Request Object -- an oh yeah, make it Visual Basic-like easy to visually develop too". That led to what I call a "Client-Services" architecture where you have a full fledged JavaScript application running in a web page talking to back-end data services plus the WYSIWYG rapid development tools for which GI has been recognized as best in class in enterprise IT journals. With GI, you never really interact with the HTML page or its DOM. Instead there's a higher abstraction of application concepts and a model of the GUI, called "dual DOM" by some. The result is that the JavaScript applications are deployed into a webpage more like an applet, (except it's all in the same JavaScript memory space and there's no JRE dependency of course). This "Client-Services" architecture has been a great fit for many enterprises pursuing service-oriented architecture strategies.
Aptana Studio is clearly among the best-in class for the predominant model of Ajax development called "single DOM" where you work directly in the HTML DOM to describe elements within a page, then apply Ajax and CSS concepts to bring that page to life with interactive features. Aptana Studio meets the needs of Ajax developers working in this model extremely well. Whereas tools for web page development have historically focused on layout, image placement, styling, and JavaScript for roll-over and simple navigational assists, Aptana saw that with Ajax and the popularity of all the single-DOM model Ajax libraries like dojo, Ext, prototype, MooTools, and jQuery, the page was becoming increasingly programmatic in the client and needed tooling optimized for the programmatic page.
What excites you about Aptana
Aptana Jaxer is a very cool concept for all the JavaScript developers out there because they can now go boldly where no JavaScript developer has gone before--to the server-side. Sure Netscape had LiveWire back in the day, but remember there was no real DOM, no real CSS and certainly no XHR object at that time. Aptana Jaxer's genius is that is takes the same Mozilla engine we know and love in the browser, and puts it inside a server along with a bunch of handy Jaxer methods and properties to do server-side things like interact with databases, web services, session concepts, sockets and more. I personally love the ability to write a script that runs on the server, but call it from the client as if it were running on the client. In this case Jaxer handles all the sync or async communications for you transparently, and soon will provide end-to-end debug capabilities as well. We're also now working with Joe Walker of the DWR project to extend this kind of capability to remote Java objects as well through Jaxer. We're also investigating how to best interoperate with Microsoft’s .NET platform.
To some, JavaScript is not a preferred language and that's where things like GWT and DWR come in real handy. At the same time there's millions of developers who like the ease and mutability of JavaScript. Aptana Studio, with its JavaScript debug and type inference capabilities, and Aptana Jaxer with its server-side power enable all JavaScript developers to do much more, more quickly in the language we love to work with -- JavaScript! Thinking beyond the solid JavaScript programming tools in Aptana Studio today, things like visual WYSIWYG GUI composition and data-binding are clearly natural extensions. Not many people know that the Aptana team contributed to much of the Eclipse Monkey code which enables JavaScript to run within and communicate with Eclipse's APIs. This means that Aptana is extraordinarily well positioned to execute a first-class solution for WYSIWYG editing -- and further streamline the creation of Ajax web pages and full-featured Ajax applications.
Now you have been around JavaScript for awhile, what are you likes and dislikes, and do you have any thoughts on JavaScript 2?
Having been part of Ajax projects where we had single HTML pages running for 9 hours sessions with over 180 separate application modules you could load/unload during that time (and that was in 2001), the GI core team (Luke Birdeau, Michel Peachey, Jessee Costello Good, and myself) has had loads of experience in what it means to make highly scalable, full featured apps in JavaScript. Much of what we had to invent and implement in JS1.5 for the TIBCO GI Framework, things like object orientation for example and better memory management, is on the horizon for future releases of JavaScript. The primary pain of JS though, until recently, has been lack of great debugging, type inference, and code assist capabilities. What few people realize about Aptana Studio is that it not only code assists on the Ajax libraries you've loaded, it assist with the Ajax objects, classes, packages, functions and properties that you create too -- again a concept borrowed from the Java community, but with less programmatic overhead since its JavaScript.
I had the opportunity to sit down with three fine gents from Aptana to discuss their recent launch of Jaxer, the "server side Ajax framework".
Paul Colton, Uri Sarid, and Kevin Hakman all sat with me to chat about things. I have already played with Jaxer, and created the Google Gears wrapper which can be used seemlessly for use cases such as "If the user doesn't have Gears installed, just do it on the server".
We discussed a lot in the twenty odd minutes including:
Where the idea for Jaxer came from
The difference between a server side JavaScript framework and Jaxer (since there are many of them!)
How Jaxer works (think of a headless Mozilla browser)
Side effects of going this direction
How developers are using it
How does your architecture change if you are using Jaxer?
How can you talk to code in Java and other languages?
How JavaScript 2 fits into the picture
What about deployment?
A lot of good stuff. Thanks to the crew for taking the time to chat with me. What other questions do you have for them?
getDB().execute('insert into Demo values (?, ?)', [phrase, currTime]);
}
addPhrase.proxy = true;
This now allows me to run the addPhrase code from the browser, and it will be proxied up to the server to actually execute that INSERT statement.
This forced me to separate the server side code from the client side code, which is a better practice anyway, but it does make you think about what goes where. In a pure Gears solution I can put everything in one place since it all runs on the client.
Create the new gears_init.js
A new gears_init.js acts as the shim itself. Instead of doing the typical Gears logic, it implements the Gears database contract. This wasn't that tough, although there are differences between the Gears way, and the Jaxer.DB way. The main difference is to do with the ResultSet implementation, where Gears goes for a rs.next()/rs.field(1) type model versus the Jaxer.DB rs.rows[x] model.
I actually much prefer Gears DBLib as it hides all of that, and just gives the programmer what he wants... the rows to work on.
oncallback magic
In the current Jaxer beta, I ran into an issue where I wanted the Gears library to just "be there" for any proxy requests.
This is less than idea, and Aptana is playing with nice scoping which would enable you to just say "hey, load this library once and keep it around for the lifetime of the server | application | session | page". That will be very nice indeed.
You can do a little bit of this by opening up your jaxer_prefs file and adding the resource for your file:
This is just the beginning. As I mentioned at the beginning, I am interested to see where you can take this to handle clients who do not support JavaScript, and also to deal with synchronization with minimal code (sync from local to remote with exactly the same SQL API).
Aptana has been known for its Eclipse based Ajax IDE Aptana Studio. Paul Colton, CEO, has impressed us at The Ajax Experience as he has shown of Studio, and how Aptana is fast to adapt and come out with support for iPhone development, Adobe AIR, and more.
But today Aptana is breaking out of the IDE world, and joining the server market with the release of Jaxer, which they are calling an "Ajax Server". Jaxer brings JavaScript, the DOM, HTML, CSS, to the server as it tries to unify the development model for developers.
You can think of the server as a Mozilla version of Tomcat. It plugs nicely into Apache (and more in the future), and handles the web application requests for you.
An example: validation
One solid way to understand Jaxer is to look at an example such as validation (screencast). Wouldn't it be nice to be able to reuse your validation logic on the client and the server? This example shows you how you do just that:
Part 1: Server Proxy
This code shows you how to use runat="server-proxy" to wrap that code in a way that the client can call it, but it gets seamlessly ran on the server:
If you don't like context switching between the Web world of HTML/CSS/JS/DOM (Ajax) and the server side language of your choice, then this could be the programming model for you.
Unobtrusive Ajax
There are some interesting benefits, such as the ability to do a good job with certain accessibility without much work. If the browser doesn't have JavaScript turned on, the server can run the code and produce the HTML for you. Obviously, the HTML interface that is returned would be less dynamic.
The execution flow looks like this:
Prototype/jQuery/Dojo/... on the server
You can use your client-side library of choice on the server (e.g. Prototype, Dojo, jQuery, etc). My screencast below in fact does just that. The aim isn't to create a totally new programming model, but to rather be part of the Web. That being said, they had to add a set of libraries to allow you to do things on the server that you can't on the client. For example, the file reading in the example above: Jaxer.File.read("name.txt").
Databases
To build server side Web applications you normally need to persist data. Database access is provided via Jaxer.DB.*, and SQLite is built in. As soon as I saw this, I pictured a wrapper for Jaxer that would bridge the Google Gears database API. There is the ability to build some simple syncing, and have the framework do the right thing depending on if you are offline or online, and shifting data between the local and remote SQLite database. Very promising.
Cross domain XHR
Since you can have XHR calls which are really coming from the server, you can talk to any domain. Again, in my example, I proxy through to Twitter, which allows me to do a Greasemonkey type solution that works in all browsers.
JavaScript 1.8
Since the latest Spidermonkey is available on the server, you can write JavaScript 1.8 using new features such as expression closures, generators, and more. You have to be careful here and remember that this will only work for code ONLY running on the server. For all other code, you have to do the usual thing and test it with the various browsers that matter to you.
Rails for JavaScript?
I hope that we do not see a lot of huge pages with runat="server" all over the shop. We did that in the ASP/PHP/JSP of old. I am sure that frameworks will pop up to do MVC nicely with Jaxer. One option would be having Jaxer work nicely with projects such as Trimpath Junction and the project that Steve Yegge often talks about.... which is Rails-like but for JavaScript (using Rhino). Integration will also be an issue for a certain class of applications. I can imagine there being a particularly strong connection for something like Java.
IDE independence
Although Aptana Studio has top notch support for Jaxer (it better!), the product does not depend on any IDE and you are free to use it with anything. To show this, I use the stand alone Jaxer server and write my code using vi.
In fact, let's check out the video that builds a Twitter proxy in a few lines of code, showing how the beast works.
(I recommend watching the video at Vimeo to make a larger window to see the type).
We are very proud to have released Aptana Studio 1.0 (formerly Aptana IDE). After over two years of non-stop development and close to a million downloads, we have finally reached "1.0". Along with the release of 1.0, we have also created two editions of the product: Community and Professional. The Community Edition is the keystone of the Studio product, where all core features and capabilities are developed. The Professional Edition brings additional features and services beyond the free Community edition.
The newly renamed Aptana Studio 1.0 Community Edition will continue to be feature-rich but in looking at the product comparison page, a robust Internet Explorer JavaScript debugger alone would be reason enough to consider purchasing a copy of the Professional edition.
Internet Explorer® Debugging
The Internet Explorer Debugging extension enables full breakpoint debugging for your Web applications directly from within Aptana Studio. Like the already integrated Firefox debugging capabilities of Studio, you can now watch variables, set conditional breakpoints, and seamlessly step through your code in Internet Explorer 6 or 7 on Windows XP or Windows Vista.
Aptana Studio 1.0 continues to provide strong support for the most popular JavaScript libraries including:
, Aptana
