Randori framework [was Re: What to expect from FalconJS]

[Michael Schmalle <ap...@teotigraphix.com>]

I watched the slides to, he mentioned C#. I saw something on Mike's  
Twitter that said he would be getting something in GITHub next week

Joan, I agree his presentation made sense. What you are saying makes  
sense to with the view mediator approach, you are completely dumbing  
down the view using mediator injection.

What I don't get is, Mike said all these other companies that had  
compiler engineers are not here, meaning they are somewhere else. So  
Mike has put his time working with C# and a cross compiler /JS  
framework.

Mike Does this have anything to do with this project? Or are you  
planning on heading in your own direction with the Randori framework?

BTW Mike, I really do agree with how you summarized the problems that  
are occurring today with Javascript and the View layer.

Mike


Quoting Joan Llenas Masó <jo...@garnetworks.com>:

> I think I'm able to get your point after watching these slides and mixing
> it together with what you mentioned earlier on in another thread.
> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> translation we just concentrate our efforts in the business logic code
> translation AS3->{MyOutputTargetOfChioce}.
> The views on the other hand are implemented natively in the language of
> choice, being it AS3, JS or whatever.
> Finally MXML comes to rescue giving us the power of componetization and
> view declaration.
> This way we can implement same set of components for different output
> targets but declare them in the same way.
> FalconJS will take care of the rest.
>
> Am I right? or did I make my own movie...
>
> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
> the essence of Flex taken to the next level :)
> Well, I see Haxe fitting here as well. Actually we could plug many
> packaging tools in the FlaconJS "output port".
>
> Can't wait to see more!
>
> Cheers!
>
>
> On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> >
>> >>  In the meantime, make sure you look at the slide deck from Michael
>> >> Labriola¹s 360Min presentation on how he is developing apps for HTML.
>>  I¹m
>> >> sure he¹ll reply with the link
>> >
>> > Is the slidedeck already pulished somewhere?
>> >
>>
>> http://www.slideshare.net/michael.labriola/randori-design-goals-and-justific
>> ation
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: Randori framework [was Re: What to expect from FalconJS]

[Alain Ekambi <ja...@gmail.com>]

What is the difference between this new Framework and something like GWT or
SharpKit ?


2012/11/19 Michael A. Labriola <la...@digitalprimates.net>

> >* You say this could be C#/Java/AS and so on... I think you start in C#
> because you already have that js cross-compiler. You thoughts are about
> making the same in different platform versions in the end?.
>
> That is the goal.
>
> >* I understand that the final goal is that you end programming in your
> platform and don't touch JS...all will be in C# (or Java, or AS, orHaxe,...)
>
> Not true. There will be some JS because there are some things that should
> be JS. The goal is to make the logic of your program in a language that is
> more appropriate but still use JS libraries or create JS where it makes
> sense.
>
> >* For me the browsers VM is a real problem. Each one is diferent and
> fragmentation is a nightmare. In the end for me, in the past, all
> technologies wich is final product was HTML/JS where off consideration
> since the final technology was bad. (i.e: Java Server Faces, JSP, ...)
>
> I think you need to re-evaluate as I believe you are wrong. The VM in the
> browsers is very consistent and in many cases much faster than Flash. In
> many cases, it is much better. There is some (minimal) fragmentation on the
> JavaScript virtual machine. There is A LOT of fragmentation on how the
> browsers render HTML and CSS. All of these other technologies fail, IMO, as
> they try to encapsulate the view and logic in one programming model. To me,
> the view logic needs to be crafted for the browsers you care to use, but
> the logic should remain 100% consistent across all of them.
>
> * This approach seems to only take into account HTML/JS, and I think that
> it should have SWF, and other output possibilities.
> >You can certainly do so. I personally don't care about the SWF format.
>
> For me HTML/JS would be powerful to be ok with people demanding HTML5, but
> having the "advanced" solution to target Flash, mobile, etc...
> > Again, you are free to do so. IMO, this is not the direction the world
> is moving.
>
> * This is too new for me, but I'm learning how Haxe works and I see that
> they generates complete native projects. So you develop in Haxe and the
> output is native ios, android, flash, HTML...and so on. I think that your
> framework could fit very well in that space, what do you think?
>
> >I hope so. I originally wrote the prototype of this framework in Haxe. I
> went to C# honestly because I was targeting enterprises and the Microsoft
> tooling appealed to enterprises much more than the tooling available for
> Haxe.
>
> Mike
>
>

RE: Randori framework [was Re: What to expect from FalconJS]

["Michael A. Labriola" <la...@digitalprimates.net>]

>* You say this could be C#/Java/AS and so on... I think you start in C# because you already have that js cross-compiler. You thoughts are about making the same in different platform versions in the end?.

That is the goal.

>* I understand that the final goal is that you end programming in your platform and don't touch JS...all will be in C# (or Java, or AS, orHaxe,...)

Not true. There will be some JS because there are some things that should be JS. The goal is to make the logic of your program in a language that is more appropriate but still use JS libraries or create JS where it makes sense.

>* For me the browsers VM is a real problem. Each one is diferent and fragmentation is a nightmare. In the end for me, in the past, all technologies wich is final product was HTML/JS where off consideration since the final technology was bad. (i.e: Java Server Faces, JSP, ...)

I think you need to re-evaluate as I believe you are wrong. The VM in the browsers is very consistent and in many cases much faster than Flash. In many cases, it is much better. There is some (minimal) fragmentation on the JavaScript virtual machine. There is A LOT of fragmentation on how the browsers render HTML and CSS. All of these other technologies fail, IMO, as they try to encapsulate the view and logic in one programming model. To me, the view logic needs to be crafted for the browsers you care to use, but the logic should remain 100% consistent across all of them.

* This approach seems to only take into account HTML/JS, and I think that it should have SWF, and other output possibilities. 
>You can certainly do so. I personally don't care about the SWF format. 

For me HTML/JS would be powerful to be ok with people demanding HTML5, but having the "advanced" solution to target Flash, mobile, etc...
> Again, you are free to do so. IMO, this is not the direction the world is moving.

* This is too new for me, but I'm learning how Haxe works and I see that they generates complete native projects. So you develop in Haxe and the output is native ios, android, flash, HTML...and so on. I think that your framework could fit very well in that space, what do you think?

>I hope so. I originally wrote the prototype of this framework in Haxe. I went to C# honestly because I was targeting enterprises and the Microsoft tooling appealed to enterprises much more than the tooling available for Haxe.

Mike

Re: Randori framework [was Re: What to expect from FalconJS]

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Mike,

I just saw the slides and it's very interesting. Thanks for sharing.
Various thoughts/questions here:

* You say this could be C#/Java/AS and so on... I think you start in C#
because you already have that js cross-compiler. You thoughts are about
making the same in different platform versions in the end?.

* I understand that the final goal is that you end programming in your
platform and don't touch JS...all will be in C# (or Java, or AS, or
Haxe,...)

* For me the browsers VM is a real problem. Each one is diferent and
fragmentation is a nightmare. In the end for me, in the past, all
technologies wich is final product was HTML/JS where off consideration
since the final technology was bad. (i.e: Java Server Faces, JSP, ...)

* This approach seems to only take into account HTML/JS, and I think that
it should have SWF, and other output possibilities. For me HTML/JS would be
powerful to be ok with people demanding HTML5, but having the "advanced"
solution to target Flash, mobile, etc...

* This is too new for me, but I'm learning how Haxe works and I see that
they generates complete native projects. So you develop in Haxe and the
output is native ios, android, flash, HTML...and so on. I think that your
framework could fit very well in that space, what do you think?

Again, thanks for share your vision. Very inspiring one.

Best,

Carlos



2012/11/17 Michael A. Labriola <la...@digitalprimates.net>

> >What I don't get is, Mike said all these other companies that had
> compiler engineers are not here, meaning they are somewhere else. So Mike
> has put his time working with C# and a cross compiler /JS framework.
>
> Actually, I found a really good cross-compiler from C# to JS that was
> extensible. So, instead of inventing the wheel to do a POC, I used
> something off the shelf. If FalconJS was here and extensible, I would have
> built it on top of that first.
>
> >Mike Does this have anything to do with this project? Or are you planning
> on heading in your own direction with the Randori framework?
>
> I think there are some borders and it will really depend on this group and
> what we all want to do. Randori isn’t really just about C#, it's more of an
> idea that we could do with Java/C#/AS/Whatever. I could see Flex being a
> component framework that follows a strategy and exists in the space to all
> a familiar development paradigm. I just don’t want to make the same
> mistakes that I think we have with Flex now.
>
> >BTW Mike, I really do agree with how you summarized the problems that are
> occurring today with Javascript and the View layer.
>
> Thanks,
>
> Mike
>
> Quoting Joan Llenas Masó <jo...@garnetworks.com>:
>
> > I think I'm able to get your point after watching these slides and
> > mixing it together with what you mentioned earlier on in another thread.
> > So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> > translation we just concentrate our efforts in the business logic code
> > translation AS3->{MyOutputTargetOfChioce}.
> > The views on the other hand are implemented natively in the language
> > of choice, being it AS3, JS or whatever.
> > Finally MXML comes to rescue giving us the power of componetization
> > and view declaration.
> > This way we can implement same set of components for different output
> > targets but declare them in the same way.
> > FalconJS will take care of the rest.
> >
> > Am I right? or did I make my own movie...
> >
> > Anyway, I see maaaaany advantages here. Wow, I love it. This is
> > actually the essence of Flex taken to the next level :) Well, I see
> > Haxe fitting here as well. Actually we could plug many packaging tools
> > in the FlaconJS "output port".
> >
> > Can't wait to see more!
> >
> > Cheers!
> >
> >
> > On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> >
> >> >>  In the meantime, make sure you look at the slide deck from
> >> >> Michael Labriola¹s 360Min presentation on how he is developing apps
> for HTML.
> >>  I¹m
> >> >> sure he¹ll reply with the link
> >> >
> >> > Is the slidedeck already pulished somewhere?
> >> >
> >>
> >> http://www.slideshare.net/michael.labriola/randori-design-goals-and-j
> >> ustific
> >> ation
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
> >
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

RE: Randori framework [was Re: What to expect from FalconJS]

["Michael A. Labriola" <la...@digitalprimates.net>]

>What I don't get is, Mike said all these other companies that had compiler engineers are not here, meaning they are somewhere else. So Mike has put his time working with C# and a cross compiler /JS framework.

Actually, I found a really good cross-compiler from C# to JS that was extensible. So, instead of inventing the wheel to do a POC, I used something off the shelf. If FalconJS was here and extensible, I would have built it on top of that first.

>Mike Does this have anything to do with this project? Or are you planning on heading in your own direction with the Randori framework?

I think there are some borders and it will really depend on this group and what we all want to do. Randori isn’t really just about C#, it's more of an idea that we could do with Java/C#/AS/Whatever. I could see Flex being a component framework that follows a strategy and exists in the space to all a familiar development paradigm. I just don’t want to make the same mistakes that I think we have with Flex now.

>BTW Mike, I really do agree with how you summarized the problems that are occurring today with Javascript and the View layer.

Thanks,

Mike

Quoting Joan Llenas Masó <jo...@garnetworks.com>:

> I think I'm able to get your point after watching these slides and 
> mixing it together with what you mentioned earlier on in another thread.
> So instead of going through direct UI AS3->{MyOutputTargetOfChioce} 
> translation we just concentrate our efforts in the business logic code 
> translation AS3->{MyOutputTargetOfChioce}.
> The views on the other hand are implemented natively in the language 
> of choice, being it AS3, JS or whatever.
> Finally MXML comes to rescue giving us the power of componetization 
> and view declaration.
> This way we can implement same set of components for different output 
> targets but declare them in the same way.
> FalconJS will take care of the rest.
>
> Am I right? or did I make my own movie...
>
> Anyway, I see maaaaany advantages here. Wow, I love it. This is 
> actually the essence of Flex taken to the next level :) Well, I see 
> Haxe fitting here as well. Actually we could plug many packaging tools 
> in the FlaconJS "output port".
>
> Can't wait to see more!
>
> Cheers!
>
>
> On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> >
>> >>  In the meantime, make sure you look at the slide deck from 
>> >> Michael Labriola¹s 360Min presentation on how he is developing apps for HTML.
>>  I¹m
>> >> sure he¹ll reply with the link
>> >
>> > Is the slidedeck already pulished somewhere?
>> >
>>
>> http://www.slideshare.net/michael.labriola/randori-design-goals-and-j
>> ustific
>> ation
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>

--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com