Ideas for Haxe JS community

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

Ideas for Haxe JS community

singmajesty
Hi again,

I have been thinking for a while that I have wanted to help build  
community around Haxe's Javascript target -- nice, clean code samples of  
Javascript and Haxe, illustrating how incredibly similar it is in core  
syntax, but then expanding to show how you can get compiler inferred type  
completion, code completion, compiler time error checking, classes, enums  
and all kinds of other things that potentially make Haxe a "better kind of  
Javascript"

Also, it makes sense to surround community, tutorials and samples around  
specific use-cases, like Node.js, Enyo, Sencha Touch, or "plain vanilla"  
Javascript development, and so on. A website could really help this.

Since this is in the early stages, I'd love to hear your feedback, your  
ideas, your hopes, dreams, concerns, wishes... anything regarding Haxe JS.

Thank you, and have a great day!

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

Re: Ideas for Haxe JS community

Michael Cann
Hi Joshua,

Thats a great idea mate, I definitely think it would be a good idea to highlight the remoting ability within the same language and perhaps show off the type-safe SPOD stuff too.

What were you thinking? Some sexy website like NME's?

I always thought this was a pretty cool way to learn a new language: http://www.codecademy.com/

Mike

On 10 October 2011 16:59, Joshua Granick <[hidden email]> wrote:
Hi again,

I have been thinking for a while that I have wanted to help build community around Haxe's Javascript target -- nice, clean code samples of Javascript and Haxe, illustrating how incredibly similar it is in core syntax, but then expanding to show how you can get compiler inferred type completion, code completion, compiler time error checking, classes, enums and all kinds of other things that potentially make Haxe a "better kind of Javascript"

Also, it makes sense to surround community, tutorials and samples around specific use-cases, like Node.js, Enyo, Sencha Touch, or "plain vanilla" Javascript development, and so on. A website could really help this.

Since this is in the early stages, I'd love to hear your feedback, your ideas, your hopes, dreams, concerns, wishes... anything regarding Haxe JS.

Thank you, and have a great day!

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



--
Mike Cann
http://www.mikecann.co.uk/


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

Re: Ideas for Haxe JS community

Bruno Garcia-2
In reply to this post by singmajesty
On 10/10/2011 08:59 AM, Joshua Granick wrote:
> Since this is in the early stages, I'd love to hear your feedback,
> your ideas, your hopes, dreams, concerns, wishes... anything regarding
> Haxe JS.

Here are my two cents:

- Built in support for Node.js in the standard library. Being able to
build the backend and client from the same code base is a major draw for
social game/app developers, and I think we should heavily promote this.
- Change JS's trace() to use console.log rather than <div
id="haxe:trace"> by default. Console support is widespread now, and the
defacto standard way to do logging in JS. It's kind of a drag to tell
new developers to use Firebug.redirectTraces().
- Some tweaks to the JS generator to not pollute the global namespace. I
realize we can write a custom generator to do this, but it should be the
default.
- Minor: There are other areas where the JS generator can be improved,
but that will take care of itself once interest in the JS target grows :)

Thanks for leading the haXe JS charge! With the interest in HTML5 apps
and Node, I can see the JS target becoming a source of lots of new haXers.

Bruno

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

Re: Ideas for Haxe JS community

blackdog
On 10/12/2011 10:54 PM, Bruno Garcia wrote:

> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>> Since this is in the early stages, I'd love to hear your feedback,
>> your ideas, your hopes, dreams, concerns, wishes... anything
>> regarding Haxe JS.
>
> Here are my two cents:
>
> - Built in support for Node.js in the standard library. Being able to
> build the backend and client from the same code base is a major draw
> for social game/app developers, and I think we should heavily promote
> this.
> - Change JS's trace() to use console.log rather than <div
> id="haxe:trace"> by default. Console support is widespread now, and
> the defacto standard way to do logging in JS. It's kind of a drag to
> tell new developers to use Firebug.redirectTraces().
> - Some tweaks to the JS generator to not pollute the global namespace.
> I realize we can write a custom generator to do this, but it should be
> the default.
> - Minor: There are other areas where the JS generator can be improved,
> but that will take care of itself once interest in the JS target grows :)
>
> Thanks for leading the haXe JS charge! With the interest in HTML5 apps
> and Node, I can see the JS target becoming a source of lots of new
> haXers.
>
> Bruno
>

+1

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci


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

Re: Ideas for Haxe JS community

Dion Whitehead Amago
+1

On Wed, Oct 12, 2011 at 9:30 PM, blackdog <[hidden email]> wrote:
On 10/12/2011 10:54 PM, Bruno Garcia wrote:
> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>> Since this is in the early stages, I'd love to hear your feedback,
>> your ideas, your hopes, dreams, concerns, wishes... anything
>> regarding Haxe JS.
>
> Here are my two cents:
>
> - Built in support for Node.js in the standard library. Being able to
> build the backend and client from the same code base is a major draw
> for social game/app developers, and I think we should heavily promote
> this.
> - Change JS's trace() to use console.log rather than <div
> id="haxe:trace"> by default. Console support is widespread now, and
> the defacto standard way to do logging in JS. It's kind of a drag to
> tell new developers to use Firebug.redirectTraces().
> - Some tweaks to the JS generator to not pollute the global namespace.
> I realize we can write a custom generator to do this, but it should be
> the default.
> - Minor: There are other areas where the JS generator can be improved,
> but that will take care of itself once interest in the JS target grows :)
>
> Thanks for leading the haXe JS charge! With the interest in HTML5 apps
> and Node, I can see the JS target becoming a source of lots of new
> haXers.
>
> Bruno
>

+1

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci


--
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: Ideas for Haxe JS community

Lee Sylvester
In reply to this post by Bruno Garcia-2
+1

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Bruno Garcia
Sent: 13 October 2011 02:55
To: [hidden email]
Subject: Re: [haXe] Ideas for Haxe JS community

On 10/10/2011 08:59 AM, Joshua Granick wrote:
> Since this is in the early stages, I'd love to hear your feedback,
> your ideas, your hopes, dreams, concerns, wishes... anything regarding
> Haxe JS.

Here are my two cents:

- Built in support for Node.js in the standard library. Being able to build
the backend and client from the same code base is a major draw for social
game/app developers, and I think we should heavily promote this.
- Change JS's trace() to use console.log rather than <div id="haxe:trace">
by default. Console support is widespread now, and the defacto standard way
to do logging in JS. It's kind of a drag to tell new developers to use
Firebug.redirectTraces().
- Some tweaks to the JS generator to not pollute the global namespace. I
realize we can write a custom generator to do this, but it should be the
default.
- Minor: There are other areas where the JS generator can be improved, but
that will take care of itself once interest in the JS target grows :)

Thanks for leading the haXe JS charge! With the interest in HTML5 apps and
Node, I can see the JS target becoming a source of lots of new haXers.

Bruno

--
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: Ideas for Haxe JS community

Nicolas Cannasse
In reply to this post by Bruno Garcia-2
Le 13/10/2011 03:54, Bruno Garcia a écrit :

> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>> Since this is in the early stages, I'd love to hear your feedback,
>> your ideas, your hopes, dreams, concerns, wishes... anything regarding
>> Haxe JS.
>
> Here are my two cents:
>
> - Built in support for Node.js in the standard library. Being able to
> build the backend and client from the same code base is a major draw for
> social game/app developers, and I think we should heavily promote this.

 From what I've seen it seems that NodeJS API is evolving faster than
haXe releases. It was then proposed to modify a little bit the haXe
standard library to allow non-browser JS compilation, and keep NodeJS
externs in a haxelib library (that could be promoted on haxejs.org)

> - Change JS's trace() to use console.log rather than <div
> id="haxe:trace"> by default. Console support is widespread now, and the
> defacto standard way to do logging in JS. It's kind of a drag to tell
> new developers to use Firebug.redirectTraces().

Indeed.

I have updated js.Boot.__trace : it will use <div haxe:trace> but then
fallback on console.log if available before printing the alert.

> - Some tweaks to the JS generator to not pollute the global namespace. I
> realize we can write a custom generator to do this, but it should be the
> default.

If it means adding "var" in front of package/toplevel classes
definitions then it's planned (see Philippe proposed patch).

If it means that haXe classes will not be accessible directly from the
JS window then it's not a possible change since it will break backward
compatibility.

> - Minor: There are other areas where the JS generator can be improved,
> but that will take care of itself once interest in the JS target grows :)

Yes, there's still some (function($this) {....})(this) tricks going on
in some corner cases. I'm planning to eliminate them - it will actually
also benefit other source-based haXe outputs such as PHP or CPP.

Best,
Nicolas

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

Re: Ideas for Haxe JS community

singmajesty
Is the updated js.Boot.__trace in haxe 2.08, or was that change made after  
the release?



On Thu, 13 Oct 2011 01:17:30 -0700, Nicolas Cannasse  
<[hidden email]> wrote:

> Le 13/10/2011 03:54, Bruno Garcia a écrit :
>> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>>> Since this is in the early stages, I'd love to hear your feedback,
>>> your ideas, your hopes, dreams, concerns, wishes... anything regarding
>>> Haxe JS.
>>
>> Here are my two cents:
>>
>> - Built in support for Node.js in the standard library. Being able to
>> build the backend and client from the same code base is a major draw for
>> social game/app developers, and I think we should heavily promote this.
>
>  From what I've seen it seems that NodeJS API is evolving faster than  
> haXe releases. It was then proposed to modify a little bit the haXe  
> standard library to allow non-browser JS compilation, and keep NodeJS  
> externs in a haxelib library (that could be promoted on haxejs.org)
>
>> - Change JS's trace() to use console.log rather than <div
>> id="haxe:trace"> by default. Console support is widespread now, and the
>> defacto standard way to do logging in JS. It's kind of a drag to tell
>> new developers to use Firebug.redirectTraces().
>
> Indeed.
>
> I have updated js.Boot.__trace : it will use <div haxe:trace> but then  
> fallback on console.log if available before printing the alert.
>
>> - Some tweaks to the JS generator to not pollute the global namespace. I
>> realize we can write a custom generator to do this, but it should be the
>> default.
>
> If it means adding "var" in front of package/toplevel classes  
> definitions then it's planned (see Philippe proposed patch).
>
> If it means that haXe classes will not be accessible directly from the  
> JS window then it's not a possible change since it will break backward  
> compatibility.
>
>> - Minor: There are other areas where the JS generator can be improved,
>> but that will take care of itself once interest in the JS target grows  
>> :)
>
> Yes, there's still some (function($this) {....})(this) tricks going on  
> in some corner cases. I'm planning to eliminate them - it will actually  
> also benefit other source-based haXe outputs such as PHP or CPP.
>
> Best,
> Nicolas

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

Re: Ideas for Haxe JS community

Nicolas Cannasse

Joshua Granick <[hidden email]> a écrit :

>Is the updated js.Boot.__trace in haxe 2.08, or was that change made
>after
>the release?
>
>
>
>On Thu, 13 Oct 2011 01:17:30 -0700, Nicolas Cannasse
><[hidden email]> wrote:
>
>> Le 13/10/2011 03:54, Bruno Garcia a écrit :
>>> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>>>> Since this is in the early stages, I'd love to hear your feedback,
>>>> your ideas, your hopes, dreams, concerns, wishes... anything
>regarding
>>>> Haxe JS.
>>>
>>> Here are my two cents:
>>>
>>> - Built in support for Node.js in the standard library. Being able
>to
>>> build the backend and client from the same code base is a major draw
>for
>>> social game/app developers, and I think we should heavily promote
>this.
>>
>>  From what I've seen it seems that NodeJS API is evolving faster than
>
>> haXe releases. It was then proposed to modify a little bit the haXe
>> standard library to allow non-browser JS compilation, and keep NodeJS
>
>> externs in a haxelib library (that could be promoted on haxejs.org)
>>
>>> - Change JS's trace() to use console.log rather than <div
>>> id="haxe:trace"> by default. Console support is widespread now, and
>the
>>> defacto standard way to do logging in JS. It's kind of a drag to
>tell
>>> new developers to use Firebug.redirectTraces().
>>
>> Indeed.
>>
>> I have updated js.Boot.__trace : it will use <div haxe:trace> but
>then
>> fallback on console.log if available before printing the alert.
>>
>>> - Some tweaks to the JS generator to not pollute the global
>namespace. I
>>> realize we can write a custom generator to do this, but it should be
>the
>>> default.
>>
>> If it means adding "var" in front of package/toplevel classes
>> definitions then it's planned (see Philippe proposed patch).
>>
>> If it means that haXe classes will not be accessible directly from
>the
>> JS window then it's not a possible change since it will break
>backward
>> compatibility.
>>
>>> - Minor: There are other areas where the JS generator can be
>improved,
>>> but that will take care of itself once interest in the JS target
>grows
>>> :)
>>
>> Yes, there's still some (function($this) {....})(this) tricks going
>on
>> in some corner cases. I'm planning to eliminate them - it will
>actually
>> also benefit other source-based haXe outputs such as PHP or CPP.
>>
>> Best,
>> Nicolas
>
>--
>haXe - an open source web programming language
>http://haxe.org

Changed today !

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

Re: Ideas for Haxe JS community

singmajesty
"Changed today !"


I love it :)

So fun to be in a community where things are better today than they were  
yesterday ;)



On Thu, 13 Oct 2011 11:49:21 -0700, Nicolas Cannasse  
<[hidden email]> wrote:

>
> Joshua Granick <[hidden email]> a écrit :
>
>> Is the updated js.Boot.__trace in haxe 2.08, or was that change made
>> after
>> the release?
>>
>>
>>
>> On Thu, 13 Oct 2011 01:17:30 -0700, Nicolas Cannasse
>> <[hidden email]> wrote:
>>
>>> Le 13/10/2011 03:54, Bruno Garcia a écrit :
>>>> On 10/10/2011 08:59 AM, Joshua Granick wrote:
>>>>> Since this is in the early stages, I'd love to hear your feedback,
>>>>> your ideas, your hopes, dreams, concerns, wishes... anything
>> regarding
>>>>> Haxe JS.
>>>>
>>>> Here are my two cents:
>>>>
>>>> - Built in support for Node.js in the standard library. Being able
>> to
>>>> build the backend and client from the same code base is a major draw
>> for
>>>> social game/app developers, and I think we should heavily promote
>> this.
>>>
>>>  From what I've seen it seems that NodeJS API is evolving faster than
>>
>>> haXe releases. It was then proposed to modify a little bit the haXe
>>> standard library to allow non-browser JS compilation, and keep NodeJS
>>
>>> externs in a haxelib library (that could be promoted on haxejs.org)
>>>
>>>> - Change JS's trace() to use console.log rather than <div
>>>> id="haxe:trace"> by default. Console support is widespread now, and
>> the
>>>> defacto standard way to do logging in JS. It's kind of a drag to
>> tell
>>>> new developers to use Firebug.redirectTraces().
>>>
>>> Indeed.
>>>
>>> I have updated js.Boot.__trace : it will use <div haxe:trace> but
>> then
>>> fallback on console.log if available before printing the alert.
>>>
>>>> - Some tweaks to the JS generator to not pollute the global
>> namespace. I
>>>> realize we can write a custom generator to do this, but it should be
>> the
>>>> default.
>>>
>>> If it means adding "var" in front of package/toplevel classes
>>> definitions then it's planned (see Philippe proposed patch).
>>>
>>> If it means that haXe classes will not be accessible directly from
>> the
>>> JS window then it's not a possible change since it will break
>> backward
>>> compatibility.
>>>
>>>> - Minor: There are other areas where the JS generator can be
>> improved,
>>>> but that will take care of itself once interest in the JS target
>> grows
>>>> :)
>>>
>>> Yes, there's still some (function($this) {....})(this) tricks going
>> on
>>> in some corner cases. I'm planning to eliminate them - it will
>> actually
>>> also benefit other source-based haXe outputs such as PHP or CPP.
>>>
>>> Best,
>>> Nicolas
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> Changed today !
>
> --
> 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: Ideas for Haxe JS community

Bruno Garcia-2
In reply to this post by Nicolas Cannasse
On 10/13/2011 01:17 AM, Nicolas Cannasse wrote:
> From what I've seen it seems that NodeJS API is evolving faster than
> haXe releases. It was then proposed to modify a little bit the haXe
> standard library to allow non-browser JS compilation, and keep NodeJS
> externs in a haxelib library (that could be promoted on haxejs.org)

Sounds great to me.

> I have updated js.Boot.__trace : it will use <div haxe:trace> but then
> fallback on console.log if available before printing the alert.

Cool!

>> - Some tweaks to the JS generator to not pollute the global namespace. I
>> realize we can write a custom generator to do this, but it should be the
>> default.
>
> If it means adding "var" in front of package/toplevel classes
> definitions then it's planned (see Philippe proposed patch).
>
> If it means that haXe classes will not be accessible directly from the
> JS window then it's not a possible change since it will break backward
> compatibility.

Would it be possible to opt-in to the latter with a compiler flag?
Perhaps combined with an @:export metadata that you can use to tag
individual classes that you want to write to the global namespace.

> Yes, there's still some (function($this) {....})(this) tricks going on
> in some corner cases. I'm planning to eliminate them - it will
> actually also benefit other source-based haXe outputs such as PHP or CPP.

Awesome! Speaking of details, there are also spots in the stdlib that
use eval (like reflection) which wreaks havoc with minifiers and I just
realized is a major security issue. For example, clients can send a
node.js remoting server a crafted string to run arbitrary code.

Bruno

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