Disclaimer you will probably ignore:

I'm a software architect not a product manager, which means I write code and not marketing messages. My responses shouldn't be taken as any sort of official word from Macromedia. I'm just talking engineer-to-engineer here, rambling over a couple of virtual beers on Artima rather than offering official word from macromedia.com.

Regarding DHTML and Flex:

I agree that DHTML can be used to great effect, and over the years we've spent a good deal of time supporting and simplifying it in products like DreamWeaver. While Flex initially publishes only to the Flash VM, it's really about providing an app development model with the right service and data orientation for developers of server pages and templates to write, test, deploy and manage rich apps today. In my opinion, it's about getting the model and services right and not about pushing Flash itself (or any other client platform) as the be-all end-all.

That said, I do believe that Flash provides the only ubiquitous lightweight cross-platform client VM that can support the sorts of web clients we're wanting immediately -- not just for its rich vector graphic visuals and audio/video, but for sophisticated offline storage and push applications as well. That says nothing about what Flex may eventually target as a result of customer requests and requirements, though, nor does it speak to what the Flash VM itself may evolve into.

Regarding XUL:

My own opinion is that we wouldn't be doing justice to the XUL community if we called our syntax by that name, because even aside from the runtime container differences it differs so significantly in its service, component, and data models. But...

If you think only about the syntax and not the rendering and compositing, though, and eliminate data binding and tag-based custom component creation, I think the base Flex UI syntax is very similar to that of XUL. This is a good thing because I personally like that portion of XUL, and I'd certainly be interested in figuring out how we could give back to the XUL community, or if despite the other differences a lot of folks really do view this as a version of XUL and want that name applied in some extended form. For some years I managed an open source project on sourceforge (something called PoolMan) and have contributed to many others, and I certainly believe everyone wins when folks give back where appropriate and where welcomed. It's not always possible seeing as how I work for a commercial software business, but I am willing to fight the fight where necessary and if it's really justified.

Regarding use of SVG:

SVG is supported in MXML, and at the very least in version 1.0 you'll be able to reference external SVG files. Inline SVG, however, is not guaranteed to be available. We can support multiple namespaces for MXML and SVG in the same document, but it posed language usability issues, so for the current beta this has been disabled.

Peter Farland, who worked with me on creating the Flash Remoting product (my first foray into Flash product development after developing the JRun 4 J2EE 1.3 server) is the engineer handling the SVG features. Pete was basically asked to implement a specific subset of SVG, but he found that distasteful so he pretty much implemented everything. It's great to be in an engineer-driven place, particularly when the engineers are so talented. Anyway, I wandered down the hall and asked for his response to the question. Here's Pete's word on the subject (imagine this spoken in an Australian accent): "The inline SVG feature has been disabled until language specific usability issues are sorted out. This is not guaranteed to be ready in 1.0. You can reference external SVG files for any Property attributed with [ImportResource], such as Image's src property."

Regarding use of Flash MX:

If you or your collaborators do use the Flash authoring environment you can still do so and export components you create into Flex. We also have a new DreamWeaver-like tool for visual Flex authoring. And you can continue using your ActionScript, both in Flex and in our classic tools. Flex gives you a simpler, smarter way to use MX components in an enterprise application. It's easier to link them to web services, easier to bind data to them, easier to create navigational flows through them, easier to unit test them, easier to share them through source control, easier to dynamically generate them, etc.

Flex makes it easier to quickly build robust rich apps without requiring a good deal of time and designer skill, and without requiring knowledge of the proprietary APIs Macromedia has previously released. It's standards-based and familiar to folks who've used server page or template frameworks in the web tier, and in the hands of wise web developers it produces behaviors that can be pretty incredible.

Regarding JavaServer Faces:

This past summer I spoke at a conference where I demo'd JavaServer Faces with a Flash JSF renderkit rendering a Flash-based rich datagrid in a page that was otherwise rendered with HTML form widgets. All were produced from a single JSF page using JSF tags. The Flash datagrid and the other widgets shared the same JavaBean data model -- the same server-side instance of the bean, actually. Flash can work with JSF. But Flex is not JSF, and they don't aim to address exactly the same goals.

JSF seems to be mostly about simplifying Model 2 MVC development for JSP applications. There's nothing specifically about web service bindings and the like but more importantly -- there's not much about smart clients. At best there is a delegated rendering model that might be exploited to supply client-side storage and client-side logic. But mostly the classic JSP model is assumed and simplified. I don't think this is an oversight by JSF, I think it's evidence that we're going after slightly different goals.

More deserves to be said of JSF, but this will have to suffice for now. As always, interested in feedback: If you're a JSF fan, please give me a yell.