JavaScript compiler: improvement suggestions

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

JavaScript compiler: improvement suggestions

Miller Medeiros
Before starting I have to say: I do believe that you guys are doing an amazing job...

I've been doing a lot of JavaScript lately but sometimes I miss a compiler to check for errors and also a strict language for some specific tasks.. I've stopped following the list a long time ago but today I decided to check the code that haXe is currently generating for JavaScript and I have some feedback...

My first concern about the JS compiler is that it pollutes the global scope without a reason and it doesn't do many simple optimizations...

I think a good start would be to follow Google JavaScript Style Guide when possible: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and some of these recommendations: http://www.alistapart.com/articles/javascript-minification-part-II/  and  http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices

Also trying to validate the code using JSLint: http://www.jslint.com/ (see code conventions: http://javascript.crockford.com/code.html ) and Closure Compiler: http://closure-compiler.appspot.com/ - would be definitely a good reference for possible problems on the code.

I'm not saying that the code should be as clean as if someone coded from scratch using the native language or that it should follow Douglas Crockford's "The Good Parts" strictly (BTW I don't agree with everything), but I do believe that there is a big room for improvements.

Another thing is to add a compiler option to generate the JavaScript including JavaDoc style comments including typecasting and inheritance (see: http://code.google.com/closure/compiler/docs/js-for-compiler.html and  http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it could even be the default option since everyone should use a compressor like closure compiler or YUICompressor ( http://developer.yahoo.com/yui/compressor/ ) before deploying files.

I don't think that there is a need to implement a minifier (or reduce variables/functions names) inside haXe compiler since YUICompressor and Closure Compiler do a good job and they can be run using an Ant task..

I know it is a insane amount of work, but maybe someone want to give it a try...

I hope my comments don't sound too arrogant.

Cheers!

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

tommedema
I can only agree that further improvements to Javascript are always welcome.

I wonder how achieveable it is and if anyone is interested to work on it.

- Tom

2010/7/31 Listas | Miller Medeiros <[hidden email]>
Before starting I have to say: I do believe that you guys are doing an amazing job...

I've been doing a lot of JavaScript lately but sometimes I miss a compiler to check for errors and also a strict language for some specific tasks.. I've stopped following the list a long time ago but today I decided to check the code that haXe is currently generating for JavaScript and I have some feedback...

My first concern about the JS compiler is that it pollutes the global scope without a reason and it doesn't do many simple optimizations...

I think a good start would be to follow Google JavaScript Style Guide when possible: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and some of these recommendations: http://www.alistapart.com/articles/javascript-minification-part-II/  and  http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices

Also trying to validate the code using JSLint: http://www.jslint.com/ (see code conventions: http://javascript.crockford.com/code.html ) and Closure Compiler: http://closure-compiler.appspot.com/ - would be definitely a good reference for possible problems on the code.

I'm not saying that the code should be as clean as if someone coded from scratch using the native language or that it should follow Douglas Crockford's "The Good Parts" strictly (BTW I don't agree with everything), but I do believe that there is a big room for improvements.

Another thing is to add a compiler option to generate the JavaScript including JavaDoc style comments including typecasting and inheritance (see: http://code.google.com/closure/compiler/docs/js-for-compiler.html and  http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it could even be the default option since everyone should use a compressor like closure compiler or YUICompressor ( http://developer.yahoo.com/yui/compressor/ ) before deploying files.

I don't think that there is a need to implement a minifier (or reduce variables/functions names) inside haXe compiler since YUICompressor and Closure Compiler do a good job and they can be run using an Ant task..

I know it is a insane amount of work, but maybe someone want to give it a try...

I hope my comments don't sound too arrogant.

Cheers!

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

blackdog-2
In reply to this post by Miller Medeiros
Hi there,

I believe haxe/javascript is the future of of haxe, and I'm putting all my efforts in the js/node.js platform. Nicolas has given us a great tool for doing large scale javascript, and with some additions, like the one's you mention haxe, has the potential of surging to new popularity. 

  • node.js  haxe type sigs, and a partially implemented haxe std lib
  • dojo type sigs
  • and various js things
also I think the ability to split javascript into separate modules (commonjs) is extremely important, I've done some tiny experiments with the compiler and commonjs modules (see here http://blackdog66.wordpress.com/2010/05/07/commonjs-modules-and-haxe/ ) If haxe generated js can be seamlessly used in js ecosystems haxe will catch fire, and we can all spend our days coding in this great language.

bd  


On Fri, Jul 30, 2010 at 6:57 PM, Listas | Miller Medeiros <[hidden email]> wrote:
Before starting I have to say: I do believe that you guys are doing an amazing job...

I've been doing a lot of JavaScript lately but sometimes I miss a compiler to check for errors and also a strict language for some specific tasks.. I've stopped following the list a long time ago but today I decided to check the code that haXe is currently generating for JavaScript and I have some feedback...

My first concern about the JS compiler is that it pollutes the global scope without a reason and it doesn't do many simple optimizations...

I think a good start would be to follow Google JavaScript Style Guide when possible: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and some of these recommendations: http://www.alistapart.com/articles/javascript-minification-part-II/  and  http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices

Also trying to validate the code using JSLint: http://www.jslint.com/ (see code conventions: http://javascript.crockford.com/code.html ) and Closure Compiler: http://closure-compiler.appspot.com/ - would be definitely a good reference for possible problems on the code.

I'm not saying that the code should be as clean as if someone coded from scratch using the native language or that it should follow Douglas Crockford's "The Good Parts" strictly (BTW I don't agree with everything), but I do believe that there is a big room for improvements.

Another thing is to add a compiler option to generate the JavaScript including JavaDoc style comments including typecasting and inheritance (see: http://code.google.com/closure/compiler/docs/js-for-compiler.html and  http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it could even be the default option since everyone should use a compressor like closure compiler or YUICompressor ( http://developer.yahoo.com/yui/compressor/ ) before deploying files.

I don't think that there is a need to implement a minifier (or reduce variables/functions names) inside haXe compiler since YUICompressor and Closure Compiler do a good job and they can be run using an Ant task..

I know it is a insane amount of work, but maybe someone want to give it a try...

I hope my comments don't sound too arrogant.

Cheers!

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

MarcWeber
In reply to this post by Miller Medeiros
Hi Listas,

You're welcome.

Excerpts from Listas | Miller Medeiros's message of Sat Jul 31 00:57:16 +0200 2010:
> My first concern about the JS compiler is that it pollutes the global scope
Try haxe --help. There is --js-namespace, isn't there?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Andy Li
If using namespace is a better practice, maybe we can set it as default but not an option?

Andy

On Sat, Jul 31, 2010 at 10:55 AM, Marc Weber <[hidden email]> wrote:
Hi Listas,

You're welcome.

Excerpts from Listas | Miller Medeiros's message of Sat Jul 31 00:57:16 +0200 2010:
> My first concern about the JS compiler is that it pollutes the global scope
Try haxe --help. There is --js-namespace, isn't there?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

MarcWeber
Excerpts from Andy Li's message of Sat Jul 31 11:59:05 +0200 2010:
> If using namespace is a better practice, maybe we can set it as default but
> not an option?
I did what I could do now: I adde the option to the wiki so that its
easier to find it:

http://haxe.org/doc/js/ajax?lang=en

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Miller Medeiros
CoffeScript compiler is doing a pretty good job, the output is really clean and follow many of the good practices that I've pointed on my initial e-mail:  http://jashkenas.github.com/coffee-script/

It's open-source and can be used as reference...

cheers.

--
Miller Medeiros  |  www.millermedeiros.com  |  blog.millermedeiros.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

MarcWeber
Excerpts from Miller Medeiros's message of Thu Aug 12 16:53:30 +0200 2010:
> CoffeScript compiler is doing a pretty good job, the output is really clean
> and follow many of the good practices that I've pointed on my initial
> e-mail:  http://jashkenas.github.com/coffee-script/

Pay attention to the lambda style:

  # Functions:
  square = (x) -> x * x

translates to

square = function(x) {
  return x * x;
};

But it doesn't have any static checking, does it?

So it looks being closer to JS that HaXe is.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

John A. De Goes

That's the exact short lambda syntax I suggested for HaXe! These are truly beautiful lambdas, and the language in general is amazingly clean and aesthetically pleasing.

Unfortunately, no static type system.

Regards,

John

On Aug 12, 2010, at 9:45 AM, Marc Weber wrote:

> Excerpts from Miller Medeiros's message of Thu Aug 12 16:53:30 +0200 2010:
>> CoffeScript compiler is doing a pretty good job, the output is really clean
>> and follow many of the good practices that I've pointed on my initial
>> e-mail:  http://jashkenas.github.com/coffee-script/
>
> Pay attention to the lambda style:
>
>  # Functions:
>  square = (x) -> x * x
>
> translates to
>
> square = function(x) {
>  return x * x;
> };
>
> But it doesn't have any static checking, does it?
>
> So it looks being closer to JS that HaXe is.
>
> Marc Weber
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Michiel Crefcoeur
In reply to this post by Miller Medeiros
You might want to take a look at http://code.google.com/p/haxetacy/.
This project contains a haXe javascript postcompiler that splits the output into seperate types, optimizes output (runtime type builder) and does jsMin compression.


2010/7/31 Listas | Miller Medeiros <[hidden email]>
Before starting I have to say: I do believe that you guys are doing an amazing job...

I've been doing a lot of JavaScript lately but sometimes I miss a compiler to check for errors and also a strict language for some specific tasks.. I've stopped following the list a long time ago but today I decided to check the code that haXe is currently generating for JavaScript and I have some feedback...

My first concern about the JS compiler is that it pollutes the global scope without a reason and it doesn't do many simple optimizations...

I think a good start would be to follow Google JavaScript Style Guide when possible: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and some of these recommendations: http://www.alistapart.com/articles/javascript-minification-part-II/  and  http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices

Also trying to validate the code using JSLint: http://www.jslint.com/ (see code conventions: http://javascript.crockford.com/code.html ) and Closure Compiler: http://closure-compiler.appspot.com/ - would be definitely a good reference for possible problems on the code.

I'm not saying that the code should be as clean as if someone coded from scratch using the native language or that it should follow Douglas Crockford's "The Good Parts" strictly (BTW I don't agree with everything), but I do believe that there is a big room for improvements.

Another thing is to add a compiler option to generate the JavaScript including JavaDoc style comments including typecasting and inheritance (see: http://code.google.com/closure/compiler/docs/js-for-compiler.html and  http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it could even be the default option since everyone should use a compressor like closure compiler or YUICompressor ( http://developer.yahoo.com/yui/compressor/ ) before deploying files.

I don't think that there is a need to implement a minifier (or reduce variables/functions names) inside haXe compiler since YUICompressor and Closure Compiler do a good job and they can be run using an Ant task..

I know it is a insane amount of work, but maybe someone want to give it a try...

I hope my comments don't sound too arrogant.

Cheers!

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Michiel Crefcoeur
Oh and makes sure the global scope doesn't get polluted

2010/8/12 Michiel Crefcoeur <[hidden email]>
You might want to take a look at http://code.google.com/p/haxetacy/.
This project contains a haXe javascript postcompiler that splits the output into seperate types, optimizes output (runtime type builder) and does jsMin compression.


2010/7/31 Listas | Miller Medeiros <[hidden email]>
Before starting I have to say: I do believe that you guys are doing an amazing job...

I've been doing a lot of JavaScript lately but sometimes I miss a compiler to check for errors and also a strict language for some specific tasks.. I've stopped following the list a long time ago but today I decided to check the code that haXe is currently generating for JavaScript and I have some feedback...

My first concern about the JS compiler is that it pollutes the global scope without a reason and it doesn't do many simple optimizations...

I think a good start would be to follow Google JavaScript Style Guide when possible: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and some of these recommendations: http://www.alistapart.com/articles/javascript-minification-part-II/  and  http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices

Also trying to validate the code using JSLint: http://www.jslint.com/ (see code conventions: http://javascript.crockford.com/code.html ) and Closure Compiler: http://closure-compiler.appspot.com/ - would be definitely a good reference for possible problems on the code.

I'm not saying that the code should be as clean as if someone coded from scratch using the native language or that it should follow Douglas Crockford's "The Good Parts" strictly (BTW I don't agree with everything), but I do believe that there is a big room for improvements.

Another thing is to add a compiler option to generate the JavaScript including JavaDoc style comments including typecasting and inheritance (see: http://code.google.com/closure/compiler/docs/js-for-compiler.html and  http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it could even be the default option since everyone should use a compressor like closure compiler or YUICompressor ( http://developer.yahoo.com/yui/compressor/ ) before deploying files.

I don't think that there is a need to implement a minifier (or reduce variables/functions names) inside haXe compiler since YUICompressor and Closure Compiler do a good job and they can be run using an Ant task..

I know it is a insane amount of work, but maybe someone want to give it a try...

I hope my comments don't sound too arrogant.

Cheers!

--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Niel Drummond-3
In reply to this post by Michiel Crefcoeur
Nice project, I'm surprised it hasn't been talked about more on the mailing list.

I have a question: the project page states that the postcompiler only works on FlashDevelop - is that by necessity ? Can one make this component more generic that can run outside of an IDE ?

- Niel

On Thu, Aug 12, 2010 at 11:49:11PM +0200, Michiel Crefcoeur wrote:

> You might want to take a look at http://code.google.com/p/haxetacy/.
> This project contains a haXe javascript postcompiler that splits the output
> into seperate types, optimizes output (runtime type builder) and does jsMin
> compression.
>
>
> 2010/7/31 Listas | Miller Medeiros <[hidden email]>
>
> > Before starting I have to say: I do believe that you guys are doing an
> > amazing job...
> >
> > I've been doing a lot of JavaScript lately but sometimes I miss a compiler
> > to check for errors and also a strict language for some specific tasks..
> > I've stopped following the list a long time ago but today I decided to check
> > the code that haXe is currently generating for JavaScript and I have some
> > feedback...
> >
> > My first concern about the JS compiler is that it pollutes the global scope
> > without a reason and it doesn't do many simple optimizations...
> >
> > I think a good start would be to follow Google JavaScript Style Guide when
> > possible:
> > http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and
> > some of these recommendations:
> > http://www.alistapart.com/articles/javascript-minification-part-II/  and
> > http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices
> >
> > Also trying to validate the code using JSLint: http://www.jslint.com/ (see
> > code conventions: http://javascript.crockford.com/code.html ) and Closure
> > Compiler: http://closure-compiler.appspot.com/ - would be definitely a
> > good reference for possible problems on the code.
> >
> > I'm not saying that the code should be as clean as if someone coded from
> > scratch using the native language or that it should follow Douglas
> > Crockford's "The Good Parts" strictly (BTW I don't agree with everything),
> > but I do believe that there is a big room for improvements.
> >
> > Another thing is to add a compiler option to generate the JavaScript
> > including JavaDoc style comments including typecasting and inheritance (see:
> > http://code.google.com/closure/compiler/docs/js-for-compiler.html and
> > http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it
> > could even be the default option since everyone should use a compressor like
> > closure compiler or YUICompressor (
> > http://developer.yahoo.com/yui/compressor/ ) before deploying files.
> >
> > I don't think that there is a need to implement a minifier (or reduce
> > variables/functions names) inside haXe compiler since YUICompressor and
> > Closure Compiler do a good job and they can be run using an Ant task..
> >
> > I know it is a insane amount of work, but maybe someone want to give it a
> > try...
> >
> > I hope my comments don't sound too arrogant.
> >
> > Cheers!
> >
> > --
> > haXe - an open source web programming language
> > http://haxe.org
> >

> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Michiel Crefcoeur
The project has been under development for the past year but because of other priorities at my company progress has been a bit slow on the opensource side. Meanwhile, we've been using it for some time now and it works for what we want to use it for. Although the postcompiler part is functional, there's still a lot of work to be done for the accompanied class library for a stable release which is why it's not talked about more I guess.
As for your question: we use FlashDevelop here so that's why the postcompiler currently only works with FD projects. But the sourcecode is setup in a way that makes it easy to add support for hxml files. If someone on the list would like to give it a try, check out the hxtc.jstypes.CLIPostCompiler class.

2010/8/13 Niel Drummond <[hidden email]>
Nice project, I'm surprised it hasn't been talked about more on the mailing list.

I have a question: the project page states that the postcompiler only works on FlashDevelop - is that by necessity ? Can one make this component more generic that can run outside of an IDE ?

- Niel

On Thu, Aug 12, 2010 at 11:49:11PM +0200, Michiel Crefcoeur wrote:
> You might want to take a look at http://code.google.com/p/haxetacy/.
> This project contains a haXe javascript postcompiler that splits the output
> into seperate types, optimizes output (runtime type builder) and does jsMin
> compression.
>
>
> 2010/7/31 Listas | Miller Medeiros <[hidden email]>
>
> > Before starting I have to say: I do believe that you guys are doing an
> > amazing job...
> >
> > I've been doing a lot of JavaScript lately but sometimes I miss a compiler
> > to check for errors and also a strict language for some specific tasks..
> > I've stopped following the list a long time ago but today I decided to check
> > the code that haXe is currently generating for JavaScript and I have some
> > feedback...
> >
> > My first concern about the JS compiler is that it pollutes the global scope
> > without a reason and it doesn't do many simple optimizations...
> >
> > I think a good start would be to follow Google JavaScript Style Guide when
> > possible:
> > http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml and
> > some of these recommendations:
> > http://www.alistapart.com/articles/javascript-minification-part-II/  and
> > http://wiki.forum.nokia.com/index.php/JavaScript_Performance_Best_Practices
> >
> > Also trying to validate the code using JSLint: http://www.jslint.com/ (see
> > code conventions: http://javascript.crockford.com/code.html ) and Closure
> > Compiler: http://closure-compiler.appspot.com/ - would be definitely a
> > good reference for possible problems on the code.
> >
> > I'm not saying that the code should be as clean as if someone coded from
> > scratch using the native language or that it should follow Douglas
> > Crockford's "The Good Parts" strictly (BTW I don't agree with everything),
> > but I do believe that there is a big room for improvements.
> >
> > Another thing is to add a compiler option to generate the JavaScript
> > including JavaDoc style comments including typecasting and inheritance (see:
> > http://code.google.com/closure/compiler/docs/js-for-compiler.html and
> > http://code.google.com/p/jsdoc-toolkit/wiki/TagReference ) - I think it
> > could even be the default option since everyone should use a compressor like
> > closure compiler or YUICompressor (
> > http://developer.yahoo.com/yui/compressor/ ) before deploying files.
> >
> > I don't think that there is a need to implement a minifier (or reduce
> > variables/functions names) inside haXe compiler since YUICompressor and
> > Closure Compiler do a good job and they can be run using an Ant task..
> >
> > I know it is a insane amount of work, but maybe someone want to give it a
> > try...
> >
> > I hope my comments don't sound too arrogant.
> >
> > Cheers!
> >
> > --
> > haXe - an open source web programming language
> > http://haxe.org
> >

> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Nicolas Cannasse
In reply to this post by tommedema
Tom a écrit :
> I can only agree that further improvements to Javascript are always welcome.
>
> I wonder how achieveable it is and if anyone is interested to work on it.
>

Improving JS output is possible, but it is hard to decide what actually
need to be really improved. Suggestions are welcome, but I tend to
prefer the ones that do bloat generated code.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Michiel Crefcoeur
Currently, the postcompiler needs to call the haXe compiler again because it needs the verbose output to match the __init__ and statics code blocks with the corresponding classes. On top of that, it needs the XML output to determine the right order. If haXe would output the __init__ (and __statics__) functions the same way it writes other static functions and then generates function calls for these, the postcompiler can just use the js file as input and won't have to call the haXe compiler again.

This is probably a minor change that would make postcompiling a lot more efficient.
For more suggestions on improving js output, see the haxetacy postcompiler output and not-so-up-to-date documentation. It would be great if at least some of these features would end up in the haxe compiler by default.


2010/8/13 Nicolas Cannasse <[hidden email]>
Tom a écrit :

I can only agree that further improvements to Javascript are always welcome.

I wonder how achieveable it is and if anyone is interested to work on it.


Improving JS output is possible, but it is hard to decide what actually need to be really improved. Suggestions are welcome, but I tend to prefer the ones that do bloat generated code.

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Justin Donaldson-2
As a side note, It would also be nice to have the postcompiler executable available on the other platforms (OSX).  I'd definitely give it a shot instead of the yui compressor I'm using now on my mac.

-Justin

On Fri, Aug 13, 2010 at 5:25 AM, Michiel Crefcoeur <[hidden email]> wrote:
Currently, the postcompiler needs to call the haXe compiler again because it needs the verbose output to match the __init__ and statics code blocks with the corresponding classes. On top of that, it needs the XML output to determine the right order. If haXe would output the __init__ (and __statics__) functions the same way it writes other static functions and then generates function calls for these, the postcompiler can just use the js file as input and won't have to call the haXe compiler again.

This is probably a minor change that would make postcompiling a lot more efficient.
For more suggestions on improving js output, see the haxetacy postcompiler output and not-so-up-to-date documentation. It would be great if at least some of these features would end up in the haxe compiler by default.


2010/8/13 Nicolas Cannasse <[hidden email]>

Tom a écrit :

I can only agree that further improvements to Javascript are always welcome.

I wonder how achieveable it is and if anyone is interested to work on it.


Improving JS output is possible, but it is hard to decide what actually need to be really improved. Suggestions are welcome, but I tend to prefer the ones that do bloat generated code.

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Michiel Crefcoeur
it's written in haXe and compiles to neko.
you can use "hxtc - Neko.hxproj" to compile.


2010/8/13 Justin Donaldson <[hidden email]>
As a side note, It would also be nice to have the postcompiler executable available on the other platforms (OSX).  I'd definitely give it a shot instead of the yui compressor I'm using now on my mac.

-Justin

On Fri, Aug 13, 2010 at 5:25 AM, Michiel Crefcoeur <[hidden email]> wrote:
Currently, the postcompiler needs to call the haXe compiler again because it needs the verbose output to match the __init__ and statics code blocks with the corresponding classes. On top of that, it needs the XML output to determine the right order. If haXe would output the __init__ (and __statics__) functions the same way it writes other static functions and then generates function calls for these, the postcompiler can just use the js file as input and won't have to call the haXe compiler again.

This is probably a minor change that would make postcompiling a lot more efficient.
For more suggestions on improving js output, see the haxetacy postcompiler output and not-so-up-to-date documentation. It would be great if at least some of these features would end up in the haxe compiler by default.


2010/8/13 Nicolas Cannasse <[hidden email]>

Tom a écrit :

I can only agree that further improvements to Javascript are always welcome.

I wonder how achieveable it is and if anyone is interested to work on it.


Improving JS output is possible, but it is hard to decide what actually need to be really improved. Suggestions are welcome, but I tend to prefer the ones that do bloat generated code.

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript compiler: improvement suggestions

Justin Donaldson-2
thanks!
-Justin

On Sun, Aug 15, 2010 at 5:11 AM, Michiel Crefcoeur <[hidden email]> wrote:
it's written in haXe and compiles to neko.
you can use "hxtc - Neko.hxproj" to compile.


2010/8/13 Justin Donaldson <[hidden email]>
As a side note, It would also be nice to have the postcompiler executable available on the other platforms (OSX).  I'd definitely give it a shot instead of the yui compressor I'm using now on my mac.

-Justin

On Fri, Aug 13, 2010 at 5:25 AM, Michiel Crefcoeur <[hidden email]> wrote:
Currently, the postcompiler needs to call the haXe compiler again because it needs the verbose output to match the __init__ and statics code blocks with the corresponding classes. On top of that, it needs the XML output to determine the right order. If haXe would output the __init__ (and __statics__) functions the same way it writes other static functions and then generates function calls for these, the postcompiler can just use the js file as input and won't have to call the haXe compiler again.

This is probably a minor change that would make postcompiling a lot more efficient.
For more suggestions on improving js output, see the haxetacy postcompiler output and not-so-up-to-date documentation. It would be great if at least some of these features would end up in the haxe compiler by default.


2010/8/13 Nicolas Cannasse <[hidden email]>

Tom a écrit :

I can only agree that further improvements to Javascript are always welcome.

I wonder how achieveable it is and if anyone is interested to work on it.


Improving JS output is possible, but it is hard to decide what actually need to be really improved. Suggestions are welcome, but I tend to prefer the ones that do bloat generated code.

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
haXe - an open source web programming language
http://haxe.org