Adobe open-sources Flex under the MPL — a good second step. Congratulations to all the people who made it happen.
My browser-war battle-heightened senses tell me you’ll see more open-sourcing, and no small amount of “openness” hype, from several big players in the coming days. As we mozilla.organs learned the hard way, getting the license right and hosting the code in a public repository are not enough (no pixie dust).
Successful open source projects combine meritocratic leadership, “doing” more than “talking”, and breadth through well-scoped extension mechanisms. It’s not enough to do great work by oneself: each committer who has the stamina and remains engaged must spend time listening to users and developers, grooming helpers and successors, and refactoring or even redesigning to support what becomes, module by module, a platform.
Platforms are for applications to stand upon, for building higher tiers of platform, and ultimately (in my view) for enabling user innovation. Mozilla’s platform has at least three tiers: Web, XUL, Gecko-embedded. Firefox has addons as a tier distinct from those.
Of course, closed-source platforms exist, but the successful ones hold up so much code that they end up de-facto standards, and often go open-source just to reduce costs born by the proprietor (there are better reasons than that, don’t get me wrong).
One way of evaluating Adobe’s success in open-sourcing Flex will be to look for more than just added components and widgets, and discern higher-level as well as different platform tiers. For instance, would patches to add a web-targeted compiler back end, in addition to the Flash Player SWF-targeted back end that’s there now, be accepted if they were developed?
Or how about harmonizing XUL and MXML, making changes to underlying layout and widget models on both sides in order to converge the two, so that (with trivial XML vocabulary translation) MXML could be interpreted by browsers that support XUL, as well as compiled into a SWF bound for the Flash Player?
For many observers and fans, an open-source Flash Player is the holy grail. If that is coming, it will probably take a while. But there’s a small and (I think) rising chance that “openness” competition among big players will speed up the trend at Adobe.
Then what? Obviously, forked and fragmented Player variants are not helpful, and the main distribution will be the contested ground. A better Flash Player via open-source development would be fine: good not great.
Blending Flash code into multiple browser rendering pipelines, with seamless text input (including focus) and output, an integrated DOM, full and fast scripting, and unified CSS processing would be even better. Add high-quality, unencumbered <video>, and web-friendly 3D (including an LOD-capable scene-graph model, rather than a bulky, eagerly created DOM), and you’re close to my idea of the promised land.
Adobe is moving in the right direction. That’s good enough for me today.
Agreed that it’s the right direction and good enough for today. Thanks for the reflections.
Once the source for the ActionScript compiler is available (and/or when one at the ES4 level is supported by a Mozilla compiler), it will be fun to make it target a JVM back end. Especially nice if the AS3 compiler is in Java (which I think it is?). Then you get Java, Flash, Firefox, and maybe more with one (meant to be portable so small standard API) language.
Then given IKVM and Reflect.Emit, maybe .NET wouldn’t be far behind. Hmm.
Hmm. It would be nice if the compiler were written in ES4 directly. While top notch performance isn’t the main ES4 goal, AS3 doesn’t do any cheating to get its performance, does it?
A self-hosted ES4 compiler is intended to be built as part of Tamarin. See
https://lxr.mozilla.org/mozilla/source/js/tamarin/esc/
This is a working AS3-ish self-hosted compiler, so it will need to be fleshed out to match ES4, and a few parts changed incompatibly (since AS3 is not a proper subset of ES4/JS2).
There’s no cheating for performance in AS3, meaning unsafe optimizations. It does better if you annotate types for every variable; it does better if you use the nominal type system. We’ll be optimizing dynamic code in Tamarin for Mozilla 2 to match the Web workload, so don’t worry about a rewrite tax required to get a performance rebate.
/be
Dear Brendan,
I have raised the question of MPL/LGPL/GPL tri-licensing (see link). It sounds like it may be a possibility.
Ian M
Thanks much for the ES4/AS3/JS2 information. That does seem very promising.
What are the incompatibilities between current ES4 and AS3?
Ian: looks like Dave McAllister responded for Adobe.
Taras: see https://developer.mozilla.org/es4/clarification/adobe_as3.html
/be
What about IDE? I have been pushing to develop an application with xulrunner, but after many tries I was turned down. I wanted xulrunner + .Net, but the lack of IDE turned off the developers, in spite of liking the idea of working with Gecko. Need an IDE/Debugging environment to make ES4 successful, and that needs to be there now, not 6 years from now.
An open source flash player would indeed be a huge thing. Many people (read geeks) don’t install flash because of the many problems with it, but an open source player could fix all the issues with it. And we could perhaps get a move towards a better flash. Nightmare for web designers in the beginning, but a good thing in the long run.
I was thinking about this topic, and it seems like an MXML -> XUL converter/interpreter wouldn’t be all that hard to do. I don’t have deep experience in either, though, so maybe I’m wrong. But if Firefox fulfills on the plans to implement Tamarin, JS2 (ES4), hardware-accelerated graphics, and multimedia, then we might not need an open source Flash player so much. You could develop MXML/ES4 apps in Firefox (quick refresh time) then also compile with Flex to SWF for use on IE and elsewhere. Could be tempting. (Right now, I think OpenLaszlo isn’t compelling. It’s too huge and the disparity in runtimes is too great. That’s why my story includes the assumption of Firefox getting a more serious core.) Of course, if we could embed “Firefox applets” in IE, then there’d be no need for Flash there, either, and we could just stick to simpler XUL/HTML.
Um, or like you said in the middle of your original post. I guess I didn’t reread before posting my latest comment. Main difference is that technically it doesn’t require cooperation from Adobe, although that would be best. (And I still like the idea of a Gecko applet player.)
While a load-on-demand 3D scene graph sounds nice, I’m glad that the current Canvas 3D plans call for low-level 3D. With a high-performance VM and low-level graphics, people can build their own LOD-capable scene graphs. Not to say there should be a standard eventually, but I still like low level first, and then high level on top of it.
Or rather, not to say there _shouldn’t_ be a standard eventually. (Having high level tools like HTML is nice with a proper foundation. Same would be for a good 3D standard, whatever a successful system might look like. I just said it backwards in my prior statement.)
Jose: have you checked out Aptana (https://www.aptana.com/)?
Leif: exactly, and it might not even be a nightmare for web designers if the open source Flash Player remains healthy (no major forks).
Tom @ 3:31pm: precisely — my aim is very-high performance VM and low level text and graphics APIs, so the rest can be built up by a broad, deep ecosystem using memory safe languages. See my XTech 2006 slides.
/be
Thanks for the several replies.
Hey B – can you connect with me?