In my case, I'm not interested in SWF output and will not working with that
output in closest time. But I think is great to have that output a side and
that we dedicate time some time in the future. I'm debugging with
source-maps with Josh NextGen Extension and Chrome/Firefox.
The key point is that right now this is a race, and now that things start
to be "contributable", we need to get to a 1.0 point soon or we will lost
vs other tech that are already there and positioned (Angular2, React,...)
2016-10-15 2:12 GMT+02:00 Josh Tynjala <joshtynj...@gmail.com>:
> Don't these languages transpile their features down to ES5, where they
> aren't supported natively either? Why can't we do the same for SWF output?
> I think Alex was trying to suggest this, rather than dismissing you, but
> maybe it wasn't clear enough.
> Looking ahead, I personally see the Flash runtimes becoming less and less
> important for FlexJS. For many developers, I don't see them building SWFs
> ever, even for debugging (sorry Alex, but I don't think many will bother to
> do that...). Most people will probably be deploying only the JS version to
> production, and if we allow them to output modern JS, these features can
> even be fully native.
> Try not to feel too held back by Flash, Jason. We can either polyfill for
> SWF or even make certain new language features JS-only.
> - Josh
> On Oct 14, 2016 4:50 PM, "Jason Taylor" <ja...@dedoose.com> wrote:
> > "TypeScript and Dart for JS all run on top of JS, so my understanding is
> > that any new language constructs they offer can be implemented on top of
> > Flash as well, although you might give up runtime type-checking for those
> > new language features."
> > How would you implement async / await and parallel programming features
> > top of flash when the flash runtime in no way supports those types of
> > constructs. Again Alex you continue to dismiss these features, while
> > of us that program in these features daily will dismiss FlexJS in time if
> > the future roadmap dosen't include this. It's way way way more important
> > than you seem to believe.
> > ~ JT
> > -----Original Message-----
> > From: Alex Harui [mailto:aha...@adobe.com]
> > Sent: Thursday, October 13, 2016 3:37 PM
> > To: firstname.lastname@example.org
> > Subject: Re: [Discuss] What's keeping the others from participating?
> > On 10/13/16, 3:20 PM, "Jason Taylor" <ja...@dedoose.com> wrote:
> > >Hi Harbs, I honestly don't see how the language can move forward when
> > >the goal of FlexJS is to be able to compile to swf. As long as we are
> > >stuck with that baggage implementing async / await and other parallel
> > >processing operations won't be possible without breaking the swf
> > >compatibility and fracturing FlexJS. That's where the crux of my
> > >disagreement with the team is. I don't believe compiling to swf is
> > >important in the long term, and by binding ourselves to that we are
> > >limiting out future drastically. In a few years I don't think an
> > >application developer will be willing to switch framework platform
> > >without async / await, generics, or lamda's. I am excited about
> > >FlexJS, but honestly I hope it's ported over to a better language system
> > like
> > >typescript or dart. The world needs a great rapid application
> > >development framework with a declarative UI language, but the world
> > >dosen't need SWF's in the future.
> > >
> > Compiling to SWF isn't a requirement for FlexJS. I still think it is a
> > good thing so all our current SWCs can run as SWF. Having runtime
> > type-checking is important as applications grow in complexity and are
> > developed by remote development teams.
> > But even if it was a requirement, TypeScript and Dart for JS all run on
> > top of JS, so my understanding is that any new language constructs they
> > offer can be implemented on top of Flash as well, although you might give
> > up runtime type-checking for those new language features.
> > And there is nothing stopping anyone from building a version of the
> > compiler that handles TS or Dart instead of AS. Its all open-source.
> > Thanks,
> > -Alex
M: +34 607 22 60 05
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación