Flex/Flash Builder vs. IntelliJ IDEA
The first article was about a favorite of mine, IntelliJ IDEA. I've been an IDEA user (some may say fanatic) for a long time, and while I've used Eclipse based editors when necessary, I always feel more at home with IDEA. The article is an overview of the Flex/ActionScript support available in IDEA 9. My conclusion is: while the depth of support is impressive (refactoring, code analysis), it does suffer from what I think of as 'not my primary function' issues. Jesse's (the author) complaints are mostly around speed, and non-intuitive configuration issues. I'm also not sure how it stacks up against some of the code generation and BlazeDS/LCDS integration features of Flash Builder 4 (which is still in beta).
The 'not my primary function' issue is one of my strongest frustrations with Eclipse. I've always found IDEA more intuitive to use because the basic functions feel 'more built in' and less like a set of cobbled together plug-ins. In fact, one of my concerns with IDEA becoming a platform like eclipse (part of their new Open Source strategy) is the erosion of this advantage. I think these types of issues will crop up more and more as IDEA supports a wider set of platforms.
LCDS vs. GraniteDS
The second article was about Granite DS, an alternative to Adobe's commercial LCDS. The article is actually a 'response' to a pair of articles about the new features in LCDS 3 by fellow Gorilla Justin Shacklette. The article covered quite a bit of ground, so I'll touch on a few areas of interest.
Code Generation
Justin discusses the ability for LCDS to generate server functionality based on your Flex code.
"In LCDS 3, you write the UI and the model, and LCDS does everything else. Yep, LCDS handles everything below the UI using just the model. Not only that, but LCDS is constructs a performant, enterprise-class backend using just the model. No boilerplate code, no plumbing code, no serialization/deserialization, no Hibernate config, just a point-and-click Modeler and your UI code. Game changing."If this works, I mean REALLY WORKS, it can be game changing. But we've all seen 'push this button for magic' before. More importantly, even if it works, is it 'how work gets done'. I think the SOFEA concept is more reasonable. In this concept Flex could be just one of many possible rich clients sharing a single set of services with other clients that could include iPhone, Android, Silverlight, JavaFX, GWT, JavaScript/Ajax, etc. clients. Obviously no application would use all of these, but having a Flex client an HTML/JavaScript/AJAX client and an iPhone client can be reasonable, especially in today's world of mobile optimized apps. And if this is the case, do you want your service layer generated by LCDS based on your Flex code?
GraniteDS takes the approach that your server code is the foundation of your application, and GraniteDS helps expose and integrate that into a Flex application. All of your modeling and service layer is written in traditional Java code, and then GraniteDS can expose the methods (via annotation) and generate ActionScript classes to map your model objects.
In reality, I think these approaches are targeted for different uses, and different audiences. Java shops that want to build a rich client will be attracted to the GraniteDS approach, while Flex applications that need small amounts of server data storage and persistence can benefit from the LCDS approach. As a long time Java developer, you can guess where I'll feel more comfortable.
Asynchronous Processing
One of the 'joys' of working with Flex is the interaction between its single application thread and asynchronous I/O. LCDS and GraniteDS approach these in separate ways. I won't rehash the comparison as I think the GraniteDS article does a good job. My view is that the LCDS way feels more like Flex, and the GraniteDS way feels more like Java. It isn't surprising giving the origination of the two projects. Both get the job done and are using the same underlying protocol, so it just boils down to a different API.
BlazeDS
Where does BlazeDS fit into all of this? As Adobe's Open Source alternative to LCDS, you might assume there was no point in the GraniteDS project. For simple RPC and messaging, BlazeDS will handle all your basic needs. With the latest release (3.2.0) well over a year old, it isn't a rapidly evolving project. However, it still provides a solid bridge between Java and Flex, so it doesn't necessarily need regular releases either.
In the end, GraniteDS is an alternative to LCDS, not BlazeDS. All three bring different feature sets to the table, so you will need to evaluate them in light of your specific needs.
What this means for Adobe
So what does this mean for Adobe? I think it is a classic good news/bad news situation. As far as I can tell, Adobe is a packages software vendor. While they have been making efforts to gain traction in the enterprise software space (ie LCDS) they are still very focused on selling packaged software: Flash Builder, Photoshop, Lightroom, Premier, etc. And in the Flex space, that means Flash Builder and LCDS licenses. If these licenses don't offset their efforts on the open source Flex SDK, why should they continue to champion the platform. (Well, there are other reasons, but the point remains).
Having strong competitors in the market for both products shows both a growing maturity and adoption of the Flex platform. It also means more competition for revenue. I think these CAN both be positive if they result in Adobe raising the bar on its efforts.
