Showing posts with label Flex. Show all posts
Showing posts with label Flex. Show all posts

Wednesday, April 2, 2008

7 Reasons Not To Use Flex

Thomas Hansen of Gaia has an entertaining anti-Flex rant here (with even more entertaining comments featuring an array of Adobe Flex stooges all commenting as Anonymous).

I'm not sure I agree with all his points (see my State of the RIA market post or Really Idiotic Approches to RIA), but sometimes it's just fun to stir the pot. Here are his top 7 reasons not to use Flex:
  1. Adobe Flex effectively don't care about any of the web standards we have spent the last 4 decades building
  2. Adobe Flex is a BINARY RIA Framework
  3. Adobe Flex will effectively render your website invisible to Search Engines
  4. You don't know the technology needed to use Adobe Flex
  5. You don't know who'll win
  6. Adobe Flex is immature technology
  7. Adobe Flex is lock-in technology

As the commenters very ably point out, however, Flex is beautiful, cross-browser and works today. Us Ajax folks have got some catchin' up to do!

Friday, March 28, 2008

Saving Ourselves From the Unweb

[This article is based on a talk by Alex Russell, the co-founder of Dojo (and Director of R&D at Sitepen), that he gave at the Visual Ajax User Group, with added editorializing and pontification by Chris Keene, CEO of WaveMaker. You can safely assume that anything insightful and true came from Alex's talk and anything smarmy and argumentative is part of Chris' "value add"]

The original use case for the web - researchers working with static documents - doesn't bear much resemblance to the multi-media, consumer-oriented web we have today. The HTML web browser infrastructure that got us this far won't get us the rest of the way.

The web has always been about the worst platform for any particular task (unless your task is to display a poorly formatted doctoral thesis). Ubiquity, searchability and combinability have always made up for the web's many weaknesses.

We are reaching a fork in the road, however, where the web's traditional strengths may be dramatically eroded by a "hollowing out" of the HTML semantics. There are basically two responses to this challenge of evolving the web. They are:
  1. Evolve HTML = Better Semantics, Smarter Clients. Evolve the existing web by pushing browser vendors to add semantic HTML capabilities that support next generation web apps. This allows for the web to remain a collaborative community that preserves the advantages which the web has traditionally enjoyed even sa it transitions to handle new tasks.
  2. Hollow out HTML = the "Un-web". Abandon HTML and replace it with a powerful but proprietary alternative like Adobe Flex or Microsoft Silverlight. Let's call this the Un-web, as it carves out walled gardens which will curtail the web's traditional openness.
The web needs to evolve to support building the Rich Internet Applications that people want to use. At the same time, web tools need to evolve to be able to handle the increasing complexity of building these apps.

Example of Semantic HTML - The Dojo Grid

Web development and customer expectations have far outstripped the table management capabilities of HTML. Why do we expect so little from HTML? Is it too much to ask for capabilities like locked columns and subcolumn formatting? Is the only solution to improve the grid to break HTML by going to a proprietary solution like Silverlight?

A great example of how to evolve the web through semantic HTML is the Dojo grid, which was contributed to the Dojo project by WaveMaker engineers Scott Miles and Steve Orvell.

Here is a screenshot of a Dojo Grid:
















With Dojo 1.1, we can use HTML that has additional semantics "layered on" to create a grid like this. Note that it looks a lot like normal HTML beefed up with extra attributes to encode the semantics that allow us to "say what we mean":

<SPAN DOJOTYPE=" dojox.data.CsvStore"
JSID=" csvStore" URL=" names.csv" >
</SPAN>

<TABLE DOJOTYPE=" dojox.grid.Grid"
STORE=" csvStore" QUERY=" { Title: '*' }" CLIENTSORT=" true"
STYLE=" width: 800px; height: 300px;" >
<THEAD>
<TR>
<TH WIDTH=" 300px" FIELD=" lastName" > Last</TH>
<TH FIELD=" firstName" > First</TH>
</TR>
</THEAD>
</TABLE>

The Dojo grid also showcases a core strength of Dojo - it's disciplined architectural approach. The Dojo architecture focuses on extending HTML semantics in an layered way that still give us room for HTML to evolve to meet usage like this half-way in the future (e.g., with the HTML 5 tag). Note that we use a non-semantic tag (a span) to denote something that exposes a fundamentally new capability (data stores), but extend existing HTML semantics for grid configuration.

The result is a very clean layering of Dojo semantics on top of vanilla HTML and css. For example, even with Javascript turned off in the browser, you can still tell what the Dojo grid is supposed to be doing. We can even supply the data via an HTML table in order to get full downward-compatibility.

Replacing HTML with Javascript is enticing but dangerous. Dojo uses Javascript to extend HTML semantically rather than throwing it away. Adding semantics to HTML gives HTML the carrying capacity to support next generation of web design.

Hollowing Out HTML - The Un-Web

While parts of the web evolve, there are also web constraints that don't change, such as the latency of communication and the static application deployment environment (aka browser + plugins). There are huge restrictions in not being able to send down an execution binary along with each web app, but huge deployment efficiencies as well.

One way to overcome the limitations of HTML is to replace HTML with proprietary web technologies like Flex and Silverlight. These technologies pose the risk is that the searchable, collaborative HTML web that we know and love gets hollowed out from the inside. This effectively carves out areas of the web that are not searchable or combinable with anything that has gone before.

Save The Web - One Browser At A Time

It is up to the Ajax and open source communities to "liberate" the HTML web from the Unweb. For example, "liberating" the Dojo grid is an on-going community effort involving large amounts of goodwill, time and cash.

Rapid evolution of the HTML browser can get us to the future, but only if we get a lot more demanding of the web browser manufacturers. What we can't afford is another 6 year drought like what we got when Netscape abandoned the browser wars and Microsoft IE had the world all to itself.

The key to the web's future is real competition between the browser vendors that will force them to evolve the browser quickly. These features include:
  • Auto update capabilities
  • 3-d rendering
  • Support for new semantics in HTML
  • In short, give us native ability within the browser to do what we otherwise have to do in Javascript libraries
What we know is that we have never gotten good browser enhancements and tools from the market leader. So now you know what you need to do to save the web - download and use the underdog web browser and give it all the love you can ;-)

Monday, March 3, 2008

More hot AIR

Tim Anderson's blog has a good, "fair and balanced" ;-) entry entitled Adobe AIR 10 reasons to love it, 10 reasons to hate it.

To summarize, he lists
  • Reasons to Love AIR: strong visuals, cross platform, fast
  • Reasons to Hate AIR: limited extensibility, limited database access, security
Ron Schmelzer, a Zapthink analyst, also wrote about AIR security holes in Infoworld, with more security folks weighing in here. There is also a fairly curmudgeonly rant from I'm Mike on the proprietary nature of the Flash platform, which, BTW, can't be wished away by open sourcing the tool while keeping the underlying platform locked up.

By the way, this is not to say that Flash/Flex is bad per se, or that it is any worse than other proprietary platforms like Microsoft Silverlight. In fact there are many good reasons for Ajax developers to use Flex when needed to add graphic/audiovisual capabilities not yet present in Ajax toolkits like Dojo (O'Reilly has a good article about Dojo and Adobe).

It is more to get a sense of urgency in the Ajax community that we gotta lotta work to do around robust look/feel, as well as some blocking and tackling work to do around the FUD that platforms like Flex/AIR have the database, security and data handling capabilities needed to work inside the corporate firewall.

Thursday, February 14, 2008

Getting Started


This is the first posting for the Visual Ajax blog. I look forward to inviting various Ajax thought leaders to present at our monthly user group meetings in San Francisco as well as post to this blog!

The goal of this blog is to promote the use of AJAX tools to build rich internet applications (RIA). We are looking for ways to make AJAX programming as easy (and as ubiquitous) as VB programming.

If you want to know more about me, check out my "day blog" at www.keeneview.com or my "day job" at www.wavemaker.com.

Some other resources to check out include:
 
ss_blog_claim=3447bca5887ddff6d0ca4a390cd980a4