> I like Flex because it has a simple configuration model (mxml) the > configuration model is up until now one of the best I have seen (specially > comparing it to other ones in the Java world). Binding, styling and State > handling are also nice things. Internationalization and modularization are > also awesome. All those things are NOT depending runtime. 99% of it is raw > code. Very few is actually Flash Player specific - conceptually: Just when > it comes to UserInterface things get tricky. Everything "not in the > userinterface" can now be used "just fine" using redtamarin on linux and its > like Nicolas says: 80% of a language can easily be implemented in a new > compiler. Big parts of the code - many concepts.
So here's a crazy idea: target HTML5/JS by offering a strictly headless Flex, and then fashion a new head out of native HTML/JS. Then write a cross-compiler that will take non-rendering ActionScript code and transform it into JS. At first glance that's preposterous: Flex is a GUI framework. But there's also a ton of formatting and parsing functions, i18n, data binding, RPC mechanisms, et cetera. Can we reuse these, even if it's in a different front-end? Also, when I look at my company's Flex codebase, there's a fair amount of UI code, sure, but the majority is intricate business logic. It's the thought of rewriting this business logic that scares me--not of rewriting the views (maybe having a decent architecture based on RobotLegs and dependency injection helps here). If we can find a reasonable way to expose the ActionScript guts to a native HTML5/JS front-end, I think that would be the most sensible solution for us. Of course, if we talk about dumping all Flex display code, maybe this is no longer a Flex framework project but an independent ActionScript-to-JS cross-compiler (which may or may not support some subset of the Flex framework). Still, it seems like it could be a reasonable solution to a class of Flex applications. Any thoughts?
