My personal preference is to prioritize runtime performance over startup
times, though keeping in mind that startup time can be an issue,
especially for mobile. We don't want this thing to start up horrendously
slowly (I don't think that'll be the case here though). The best way to
measure will
I wonder if you could use the second argument of Object.create to reduce
the number of times Object.defineProperties appears in the source (and
if it would matter at all).
// Example where we create an object with a couple of sample properties.
// (Note that the second parameter maps keys to *p
I understood Frank's approach as vanilla-js (ES5) - eg, no dependencies.
JS is JS though - you can write Backbone.j models in Typescript, wrap
jQuery based views in coffee script, and lay everything out using
mustache with some Jangaroo games mixed in just for giggles. At the end
of the day it
On 12/6/12 1:57 PM, Frank Wienberg wrote:
I like that idea. But still not all polyfills simulate the intended
semantics 100%. The question remains that when we know certain semantics
can't be done in a certain browser (like get / set on non-DOM-objects in
IE8), should we refrain from using it and
evin N.
On 12/6/12 10:49 AM, Kevin Newman wrote:
Maybe it's worth looking at a polyfill for defineProperties in IE8:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/defineProperties
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global
te that is though. Does it emulate get/set? or
would that require all AS3 classes are based off DOM elements (is that
even viable)?
Kevin N.
On 12/6/12 7:32 AM, Frank Wienberg wrote:
On Wed, Dec 5, 2012 at 11:39 PM, Kevin Newman wrote:
Object.create has other useful features too (tha
That's almost exactly the polyfill for Object.create (except with some
extra book keeping):
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create
|if| |(!Object.create) {|
|||Object.create = ||function| |(o) {|
|||if| |(arguments.length > 1) {|
|||throw| |new
For that matter you could just load and parse the ABC right in
Javascript at runtime:
https://github.com/mozilla/shumway
Kevin N.
On 12/3/2012 3:49 PM, Gordon Smith wrote:
The possibility of transcoding ABC -> JS (rather than AS -> JS, MXML -> JS, CSS ->
JS, and .properties -> JS) has come u
DOM mode.
Single-canvas-mode is activated by setting cacheAsBitmap on the stage!
On Thu, Nov 29, 2012 at 4:47 PM, Kevin Newman wrote:
Oh, I thought Jangaroo switched to a single Canvas a while back. I may
have introduced that incorrect information. Sorry about that.
Oh, I thought Jangaroo switched to a single Canvas a while back. I may
have introduced that incorrect information. Sorry about that.
Kevin N.
On 11/29/12 6:31 AM, Frank Wienberg wrote:
Primarily, I also map DOs to DOM elements!
I believe that's Frank's blog. :)
Kevin N.
On 11/28/2012 7:28 PM, Daniel Wasilewski wrote:
But I know what the community is capable of, and seeing stuff like
jangaroo (I went trough Kevin's blog already, very good read) and many
initiatives I remember from the past, like make AS3 evaluators,
On 11/28/12 4:42 PM, Alex Harui wrote:
I don't know enough to have an reason not to go the classic route. But
someone else will have to step up to do the work.
Classic is the fastest for me (often by a lot) - at least in Firefox.
Maybe I'm missing some reason to go with the others?
That said
It looks like adobe.js is using the constructor method as a kind of
marker function, and compiling the actual constructor into the 'init'
method (which is weird IMHO, since you can inherit from the parent
constructor, and protect the prototype chain without calling the
constructor via other mea
What's required for the legal ok? Is that like a full copyright/patent
audit? Or is it more of checking the license requirements, or getting
signoff from the current copyright holder? Or both? Or something else? :-)
It's already licensed under Apache 2.0, so that's a good start.
Anyway, a lot
Here are theAS3 -> JS externs that Jangaroo's AS3 Flash API is built on:
https://github.com/CoreMedia/jangaroo-libs/tree/master/jangaroo-browser/src/main/joo/js
Kevin N.
On 11/28/12 11:04 AM, Kevin Newman wrote:
Could always use (easiest) or port Jangaroo's implementation (it'
Could always use (easiest) or port Jangaroo's implementation (it's
written in AS3 - might even be able to port it to compile under FalconJS).
https://github.com/CoreMedia/jangaroo-libs/tree/master/jooflash/src/main/joo
Kevin N.
On 11/28/12 12:29 AM, Alex Harui wrote:
There is no flash API em
On 11/27/12 5:56 PM, Daniel Wasilewski wrote:
However, when comes to FalconJS the task is to use strict proper OOP
language like AS3 to translate into JS. In my humble opinion, this is
what is all about, to protect us and give us more robust development
environment and target the platform we
On 11/27/12 2:11 PM, Daniel Wasilewski wrote:
On 11/27/2012 6:36 PM, Kevin Newman wrote:
definitions be outside the testing loop
Very good point :)
Just modified this test up there
http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/5
And will prepare the one, that has
Shouldn't the Function (class) definitions be outside the testing loop?
Kevin N.
To be blunt, if Flex doesn't measure up against those other frameworks,
it has no future - regardless of the language it's built on.
Kevin N.
On 11/21/2012 7:18 PM, Alex Harui wrote:
Because if I offer a solution that doesn't require porting your existing
code you might be willing to accept o
So in that case it'd either be using (or completing then using)
FalconJS, or Jangaroo (pulling it into Apache maybe - it's already under
Apache 2.0 license).
That doesn't sound terrible. That could even allow Apache to move AS3
(ApacheScript!) in a different direction over time from what Adobe
For that matter, Adobe Flash is not Apache either.
Just to add one more bullet point - existing AS3 code bases can still be
used if Flex is done in Haxe, as long as you target AVM2.
Kevin N.
On 11/21/12 4:59 PM, Carlos Rovira wrote:
Your point of "Haxe is not in Apache" is not a point for m
On 11/21/12 1:22 PM, Alex Harui wrote:
And, what isn't clear is how well AIR will run on that device,
if at all. There are so many devices it will be hard for AIR to keep
running well (in captive runtime of course) on all of them.
The exact same thing was true for desktop/laptops with Flash. I o
JavaScript is evolving with ECMAScript harmony 6, it's just incredibly
slow to standardize on the new stuff, and even slower before you can
really use most of it in practice.
But there are at least two attempts to build ES6 compilers that work
today. There's TypeScript (Microsoft), which adds
From what I see, the HTML5 everything push is ending - mostly because
of performance issues on the native app side. HTML5 is still taking over
for flash in the desktop/laptop web space for most things, though even
there, folks are starting to loudly express dissatisfaction with
platform fragmen
Mark Zuckerberg also said very publicly that Facebook "burned" (his
word) 2 years of development with HTML5, "We burned two years. That's
really painful. Probably we will look back saying that is one of the
*biggest mistakes* if not *the biggest strategic mistake* that we made."
It was less of
The main problem is bigger than that. Adobe through it's marketing has
told everyone that Flash is for Games. They have been actively working
against the idea that Flash is about ubiquity (they could pick that up
again, AIR fills the gap, but I don't see any signs they will).
That story is bas
HaXe really is more similar to AS3 than many here seem to think (it's
more of a superset than a subset - though there are some missing
features like namespace). Would Flex really need to start from scratch
when porting to HaXe? Could some level of automation be utilized
(there's an unfinished t
There are two different Flash related LLVM products at Adobe, afaik.
They have an LLVM frontend which takes ABC code and turns that into ARM
code for packing on iPhone. Then there's the Alchemy stuff, which is an
LLVM backend, for generating ABC bytecode from other front ends like C
and C++. T
Just some notes on Starling:
* Starling is written in AS3, so that'd need to be ported to HaXe along
with everything else (unless you just use it for the Flash target).
* Native Apps: Starling uses Stage3D, which NME doesn't (yet) support
(afaik, and I did just look somewhat recently). I supp
I don't know much about compilers, or about how much work it'll be, but
that's my question.
How much work would writing an AS3 front end for LLVM be? I imagine it's
a lot of work.
Adobe did it with ABC bytecode, so it seems it should be theoretically
possible (if a lot of work). There are ba
Darn good point.
Kevin N.
On 11/15/12 2:50 PM, Alex Harui wrote:
IMO, Flex is AS3. My assumption is that there are large bodies of AS
business logic that folks are not wanting to port to something else. Of
course, that assumption could be incorrect.
If considering a move to a new language and platform, shouldn't
preference be given to something open source?
How about HaXe? It has compile support for all the current Flash/AIR
targets, and then some, including Flash (AVM2), JavaScript and
C/C++/Native mobile apps through NME (an open source
There are a couple of Flash API on JS engines already (Jangaroo,
EaselJS, Shumway, more...).
Porting to another language, I'd suggest a JS compiler like Traceur or
TypeScript. You might even be able to use Jangaroo's AS3->JS compiler to
bootstrap the conversion in the short term (it'd still be
There are still some features of AS3 that aren't supported in Jangaroo
(I think namespaces are a big missing feature), but they did manage to
get most things working. If you look at the compiled code for Jangaroo,
they didn't do as much of a 1:1 mapping to JS as other compilers try to
do, they
On 10/18/12 7:28 PM, Gordon Smith wrote:
Yes, the community has to figure out what the essence of Flex really is. To me,
it's an rapid-development application framework, the combination of a
procedural language with a declarative language, and a widely-deployed runtime
that can support RIAs. T
On 10/18/12 6:46 PM, Gordon Smith wrote:
the internationalization APIs in the Flash VM were never finished
Isn't some level of internationalization required even for games?
Kevin N.
So an open source Apache Flex that requires a closed source Adobe
AVMNext compiler?
That seems incorrect.
Kevin N.
On 10/18/12 7:31 PM, Thibault Imbert wrote:
I was just giving examples of how a very lightweight Flex could work on
this new runtime.
38 matches
Mail list logo
