Re: [FalconJx] New JavaScript runtime format prototype

Hehe, is not your bit I am worry about, And well, OK I will stop posting for a moment, because looks like interrupting people at work. Will back to discussion when will be able to help physically, for now just talking during my breaks, because busy working on something that pay my bills. By

Re: [FalconJx] New JavaScript runtime format prototype

Frank, I never said that. Everyone cares that's why we having this discussion going. But different people different ideas how we should do care :) And I do agree with Alex too, he was the one who started with very early prototype and kick-started this thread. I see Alex as a guy of lets-do-it

Re: [FalconJx] New JavaScript runtime format prototype

This is funny, it took me less then 2 weeks to rewrite the cross compiler for alternate output formats and we are talking about not competeing. A team is only as strong as it's weakest link. That link is not going to be me. I have a feeling Daniel this will get ironed out. Once Erik, Al

Re: [FalconJx] New JavaScript runtime format prototype

On Sat, Dec 22, 2012 at 12:19 AM, Daniel Wasilewski wrote: > With all respect, all the talks on this subject just convinced me more to > continue my work on BixBite project, because I can't see flex to compete in > near future. Dan, what exactly in this discussion made you think that we don't ca

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 6:29 PM, Alex Harui wrote: > I saw a brief overview of Require and it seemed way more difficult than > goog.require, but I could be wrong about that. > Hi Alex, using RequireJS may (only) become difficult if you use its advanced features (e.g. path mappings), but my prot

Re: [FalconJx] New JavaScript runtime format prototype

I was trying hard to get the best performing framework in AS3 ever. Pushing platform to its limits. And I made it happen. I made it the faster AS3 framework ever. Maybe broken few rules, maybe is not pure MVC, However, Let this picture speak for itself. http://bixbite.org/bixbite.jpg With a r

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 5:43 PM, Kevin Newman wrote: > BTW, what do you mean by startup times - do you mean the actual parsing, > loading and setting up of the classes (I think this)? Or is there an speed > issue with class instantiation as well (it seems like no)? I'm not actually > familiar eno

Re: [FalconJx] New JavaScript runtime format prototype

Startup Time must meet a certain threshold of acceptability before enough folks will use your app and worry about runtime performance. IMO, startup time has several metrics: -First visual indicator: a progress bar or splash screen, enough to tell you that something is running -first screen: enough

Re: [FalconJx] New JavaScript runtime format prototype

Referring to the require() discussion above, a colleague just pointed me to this nice article about JavaScript modules by OSGi Guru Peter Kriens, worth a read: http://softwaresimplexity.blogspot.fr/2012/06/modules-in-javascript.html Among other things, it explains some history of CommonJS modules v

Re: [FalconJx] New JavaScript runtime format prototype

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

RE: [FalconJx] New JavaScript runtime format prototype

Awesome lol -Original Message- From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of Om Sent: Friday, December 21, 2012 3:30 To: flex-dev@incubator.apache.org Subject: Re: [FalconJx] New JavaScript runtime format prototype Obligatory xkcd reference ;-) http://xkcd.com/386

Re: [FalconJx] New JavaScript runtime format prototype

Good morning, I just followed your advice and simplified defineClass.js a bit (pushed to GitHub repo and GitHub pages, so you should see the update, maybe after cleaning your browser cache). Another thing: Because defineInterface.js is really so small I thought about uniting both define*.js into

Re: [FalconJx] New JavaScript runtime format prototype

:-) Om, Frank and I are on GMT +1, so it wasn't really that bad... you, on the other hand are missing out on some well deserved sleep time; make sure to catch some, but only after you've fixed the internet, of course ;-) EdB On Fri, Dec 21, 2012 at 9:33 AM, Frank Wienberg wrote: > lol, yes, th

Re: [FalconJx] New JavaScript runtime format prototype

lol, yes, that's how it was like yesterday (or rather: today), but now it's 9:30 am here. On Fri, Dec 21, 2012 at 9:30 AM, Om wrote: > Obligatory xkcd reference ;-) > > http://xkcd.com/386/ > On Dec 21, 2012 12:26 AM, "Erik de Bruin" wrote: > > > Frank, > > > > I was writing a very long and de

Re: [FalconJx] New JavaScript runtime format prototype

Obligatory xkcd reference ;-) http://xkcd.com/386/ On Dec 21, 2012 12:26 AM, "Erik de Bruin" wrote: > Frank, > > I was writing a very long and detailed reply to your very long and > detailed reply to my ... (ad infinitum, it seems), debunking or > countering most of your claims, when I realised

Re: [FalconJx] New JavaScript runtime format prototype

Frank, I was writing a very long and detailed reply to your very long and detailed reply to my ... (ad infinitum, it seems), debunking or countering most of your claims, when I realised that I don't want to spend my time that way. I call for a truce while we investigate the merits and pitfalls of

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 1:29 AM, Chema Balsas wrote: > Another thing, is that one can use r.js to pipe the require minification > process into the closure compiler so you're supposed to get the best of > both worlds... > Exactly, that's what I'm trying to get across. Since we produce VanillaJS,

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 12:20 AM, Erik de Bruin wrote: > > This the overall impression I have with the GCC approach: it introduced > > complexity only to optimize it later on. > > I think we better avoid complexity in the first place! > > Well, it introduces "complexity" in order to facilitate BE

Re: [FalconJx] New JavaScript runtime format prototype

> > For implementing the actual resource bundle loading, RequireJS also offers > a mechanism . You're right! I totally forgot! Another thing, is that one can use r.js to pipe the require minification process into the closure compiler so you're supposed to

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 12:53 AM, Kevin Newman wrote: > 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

Re: [FalconJx] New JavaScript runtime format prototype

On Fri, Dec 21, 2012 at 12:29 AM, Chema Balsas wrote: > One thing I'm not sure has been mentioned here is localization support. > It's not a requirement for the pure AS->JS translation, but I have the > sense it's quite important for Flex. > > I think the Closure Compiler offers Templates and som

Re: [FalconJx] New JavaScript runtime format prototype

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

Re: [FalconJx] New JavaScript runtime format prototype

One thing I'm not sure has been mentioned here is localization support. It's not a requirement for the pure AS->JS translation, but I have the sense it's quite important for Flex. I think the Closure Compiler offers Templates and some kind of internationalization automation, which could come in ha

Re: [FalconJx] New JavaScript runtime format prototype

> This the overall impression I have with the GCC approach: it introduced > complexity only to optimize it later on. > I think we better avoid complexity in the first place! Well, it introduces "complexity" in order to facilitate BETTER optimisation later on. So, by avoiding that "complexity" - si

Re: [FalconJx] New JavaScript runtime format prototype

On Thu, Dec 20, 2012 at 11:34 PM, Daniel Wasilewski wrote: > I don't know why but it looks like it iss adding extra stars: > > http://fwienber.github.**com/**as-js-runtime-prototype/ //fwienber.github.com/as-js-**runtime-prototype/ > > I obvious

Re: [FalconJx] New JavaScript runtime format prototype

On Thu, Dec 20, 2012 at 11:12 PM, Daniel Wasilewski wrote: > You keep saying, for debugging reasons, your goal is to mimic as3 vs JS > output into even exact line of code. > Only in the debuggable compiler output. The optimized production code might look like machine code. > We are about to get

Re: [FalconJx] New JavaScript runtime format prototype

On Thu, Dec 20, 2012 at 11:23 PM, Daniel Wasilewski wrote: > http://jsperf.com/global-**namespace-chain-vs-string-** > based-local-modules/12 > > This is what worries me the most. If I understand this test correctly, it m

Re: [FalconJx] New JavaScript runtime format prototype

I don't know why but it looks like it iss adding extra stars: http://fwienber.github.**com/as-js-runtime-prototype/

Re: [FalconJx] New JavaScript runtime format prototype

Oops? Can you give me a pointer which link does not work? I can't reproduce. Maybe the new subdomain created by GitHub pages (fwienber.github.com) is not "spread around the world" yet? On Thu, Dec 20, 2012 at 11:18 PM, Daniel Wasilewski wrote: > Btw, yes I have checked your links, but stuff on gi

Re: [FalconJx] New JavaScript runtime format prototype

On Thu, Dec 20, 2012 at 10:54 PM, Erik de Bruin wrote: > Excellent points! I see that we are closer in our goals and methods, > but there is still 'some' misunderstanding about the tools we are > proposing. I'll address your points and add my opinion/understanding > where I think some clarificati

Re: [FalconJx] New JavaScript runtime format prototype

http://jsperf.com/global-namespace-chain-vs-string-based-local-modules/12 This is what worries me the most. On 12/20/2012 9:55 PM, Frank Wienberg wrote: Er... I hope I already did. Did you read by previous post in this thread? On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski wrote: Please

Re: [FalconJx] New JavaScript runtime format prototype

Btw, yes I have checked your links, but stuff on github is 404. On 12/20/2012 9:55 PM, Frank Wienberg wrote: Er... I hope I already did. Did you read by previous post in this thread? On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski wrote: Please enlight us on why you think goog is not a go

Re: [FalconJx] New JavaScript runtime format prototype

Don't get me wrong, I am asking about how 'goog' or vanilla and your approach solition performs on various browsers. You keep saying, for debugging reasons, your goal is to mimic as3 vs JS output into even exact line of code. We are about to get compiler that can optimise everything before it

Re: [FalconJx] New JavaScript runtime format prototype

On 12/20/2012 9:54 PM, Erik de Bruin wrote: *tool/vendor dependency:* The Google Closure Tools are Open Source, available under the Apache License 2.0. *separation of concerns:* 1) a matter of choice and convenience, I'm not married to "goog" here, but I haven't seen a good reason NOT to use it,

Re: [FalconJx] New JavaScript runtime format prototype

Er... I hope I already did. Did you read by previous post in this thread? On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski wrote: > Please enlight us on why you think goog is not a good solution.

Re: [FalconJx] New JavaScript runtime format prototype

Frank, Excellent points! I see that we are closer in our goals and methods, but there is still 'some' misunderstanding about the tools we are proposing. I'll address your points and add my opinion/understanding where I think some clarification is needed. - *waste:* In one short scentence: the Clo

Re: [FalconJx] New JavaScript runtime format prototype

Dan, did you check out the "linked" version? It just loads require.js for bootstrap, then hello-world-all.js that contains the whole application. The list of scripts that you mentioned is only generated dynamically in RequireJS's debug mode. Until we have JS source map support in all major browsers

Re: [FalconJx] New JavaScript runtime format prototype

Ah, one thing I forgot, a short overview of the prototype's directory structure and files. The root directory contains - the HTML files *index.html* and those that load the three application variants (*app-*.html*) - the linked (minimized) generated JavaScript application files * hell

Re: [FalconJx] New JavaScript runtime format prototype

Please enlight us on why you think goog is not a good solution. On 12/20/2012 9:06 PM, Frank Wienberg wrote: Hi Alex, thanks for your prompt reply anyway! I don't think this is very urgent, I only felt the need to provide a concrete alternative to the "goog" approach before everybody runs off i

Re: [FalconJx] New JavaScript runtime format prototype

Well, some says JS is just JS and I disagree with that statement because it is al about how you write JS. JQuery is popular this days but limited developers by slowing down runtime over 100x times. Impossible to make mobile web application with acceptable performance level when mobile platform

Re: [FalconJx] New JavaScript runtime format prototype

Hi Alex, thanks for your prompt reply anyway! I don't think this is very urgent, I only felt the need to provide a concrete alternative to the "goog" approach before everybody runs off in that direction... ;-) I'd appreciate your opinion on the topic and look forward to your response. Best, -Frank

Re: [FalconJx] New JavaScript runtime format prototype

Hi Erik, my proposal is not at all about UI frameworks, so I'll try to answer the part about (not) using "goog" / Google Closure Compiler. I agree on the strengths of GCC as being "not only a JS optimiser, it's an actual compiler" when you want to write class-oriented JavaScript code manually and

Re: [FalconJx] New JavaScript runtime format prototype

Hi Mike, On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle wrote: > I'm probably in the position of, "Show me what you want to generate based > on the semantics involved and I will generate it" mode. that was exactly what my proposal was aiming at! It sounded like once you are done with generat

Re: [FalconJx] New JavaScript runtime format prototype

Hi Frank, I will try to take a look, but right now my priorities are post-graduation tasks, the 4.9 release and getting the current FalconJS code to spit out the Base.js format for both MXML and AS. Also, I'm theoretically off duty next week, so I won't be poking at this stuff full-time. Hopeful

Re: [FalconJx] New JavaScript runtime format prototype

Hi, To complete the party, a few brief comments: - at the moment, I'm not sure what approach to the eventual UI frameworks (AS and JS side) will take. FlexJS is one but it doesn't (yet) have the feel of something that meets the standards that Flex users have come to expect. - I'm sure that Googl

Re: [FalconJx] New JavaScript runtime format prototype

Quoting Frank Wienberg : Hi folks, as mentioned in another thread, I have been working on a new JavaScript "runtime", which is what I call the way the generated JavaScript code looks and works like. While this thread's title has [FalconJx] in it, there is no reason the proposal could not be us