[Proposal for how access Flash specific APIs]
Having access to the raw Flash API is really a must-have to create the best
applications possible, so this proposal is very much welcomed. We are
already reliying on the #pragma hack, so an "official" way to do this would
be great - especially since the #pragma hack is fragile: if it is not
followed by some dead code, it seems that instructions might be "optimised"
away. The proposal itself looks fine as long as it is open-ended and allows
access to the full underlying API.
However, I'd like to ask for even more (or some else): The ability to
include inline flash assembly. The performance of the Flash engine is so
poor that the loss in performance due to translation from JavaScript to the
flash bytecodes is costing too much: Especially the difficult choice of
whether to put a variable in a register or use the top stack element as
"register" costs a great deal of performance. For maximum performance, you
really need to decide this yourself, so flash assembly is the way to go.
So some mechanism to include assembly would very much be welcomed, whether
it is based on flasm, or in the worst case, maybe even just hex-codes.
(Neoswiff supports inline assembly, and flasm allows ActionScript to
contain assembly as well.)
Another thing is documenting the ABI so that interoperability with other
Flash technologies becomes possible. There are lots of different Flash
technologies these days: Flex, Neoswiff, Xamlon, Mtasc, haXe, flasm, and so
on. And for each of these, there are lots of libraries: actionstep, flex
components, and what not. If it was technically possible to mix & match
different technologies, that would really open the door for making nice
stuff quickly. This shouldn't be technically hard, since the Flash canvas &
runtime is the common building block, but it does require the ABI to be
documented to allow bridging conventions: The ability to access variables
and functions, and interact with the "GUI" loop.
Laszlo is great for dynamic user interfaces that are quickly put together,
and to some extend XML based stuff. However, it is not so great for user
interfaces with lots and lots of dynamic visual elements or performance
critical data processing - the overhead is simply bringing things to a
crawl, making it unworkable for really complex stuff.
The other main problem I see with Laszlo is programming in the large:
Without static type checking, it is difficult to manage a large project
with many different programmers. Simple refactoring is difficult, because
you get no help from the compiler to make sure all instances are caught.
Regards,
Asger Ottar Alstrup
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
