From here

[Nicolas Cannasse]

Hi,

In the past week, we've been discussing several things.

I think we came to agree that Haxe definition could be :

"target any platform natively"

Based on this, we can build up a strategy :

- split the different target audiences into several sub groups (NME, JS,
WebDev, Decision Makers, etc.)

- address each group separately in terms of communication (explaining
how Haxe is great for this particular usage), but also tutorials and
"getting started" support

Do we clearly agree on these things now ?

If yes, then please list the different groups that you think we should
focus on, then for each group :

- the MOST important things we need to do for these specific groups to
achieve our strategy

- the way we can make these needed things happen : do we need to find
people, money, time, or something else ?

Based on these results we will try to see what is most important, what
can be done immediately, and what is needed for us to make Haxe a huge
success.

Looking forward to your contributions ;)

Best,
Nicolas

[Joshua Granick]

I think list you gave is pretty accurate:


- Management / Business

- Game Developers

- JavaScript Developers

- Server-side Web Developers



1.) Management / Business


Rather than creating a section of a website devoted to management, or the
business side, I think they would be drawn to sections like "About",
"FAQ", "Testimonials" and other types of "What is Haxe?" material.

They need to see that other companies are using the language. They
probably do not want to feel like pioneers. They also want to see that it
is mature, supported, and will continue to remain stable.



2.) Game Developers


We should not assume that every game developer would want NME, but it
should be provided as a choice, along with Haxe/Flash development and
Haxe/JavaScript development.

If they are interested in mobile development, especially, they should know
that NME is designed to get them running. We can introduce them to the
possibilities of the Haxe C++, Flash, JS, Java and C# targets (if Java and
C# are ready), and possibly highlight other libraries (like EaselJS,
Flixel, etc) which have been adapted for use with Haxe.



3.) JavaScript Developers


We have discussed this use-case a bit in previous threads. I won't go into
the ideas of how to reach and help this community right now, especially
because I don't feel like I am really a part of this community. The things
that tend to get the community going (backbone.js, CoffeeScript, et al) do
not make me feel excited. I've never wanted a cloud-based IDE, and I don't
even like the Chrome browser. I'm not the target audience ;)



4.) Server-side Web Developers


PHP, Neko, Node.js, performance, databases, scalability... all the stuff
server-side guys are interested in :)




I don't think this list is comprehensive. Whether or not we divide the
website into separate categories (or create derivative sites devoted to
each community), I think these are at least four of the demographics we
need to consider.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Peter Halacsy]

Guys,
We stop java, php because they are not native?

I'm just challenging the vision/strategy.

Hp

[Nicolas Cannasse]

Le 17/05/2012 09:10, Peter Halacsy a �crit :

> Guys,
> We stop java, php because they are not native?
>
> I'm just challenging the vision/strategy.

Fair :)

My answer : since when did java or php allow to target any platform ?
Both have been designed to run on their own platform.

Best,
Nicolas

[Peter Halacsy]

On Thu, May 17, 2012 at 9:31 AM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 17/05/2012 09:10, Peter Halacsy a écrit :

Guys,
We stop java, php because they are not native?

I'm just challenging the vision/strategy.

Fair :)

My answer : since when did java or php allow to target any platform ? Both have been designed to run on their own platform.

Best,
Nicolas

i mean if and only if the strategy  "target any platform natively" then Java could not have high priority.

for me personally target any platform natively is not sexy but I might be out of target scope.

What would be exciting for me (and I don't tell that haxe should go to this direction)? When I can have a platform which makes easy to use/reuse code/knowledge in different situations. I don't want Haxe to target platforms. I want haxe to be a platform.

If I'm a java developer, I can use the same components/techniques/methods to build websites (with GWT), bigdata applications (hadoop), multicluster environments, servers etc.

If I'm a .net developer, I can use my same tools to build everything.

If I'm a haxe developer, I can use my tool to create iphone, android, front-end, flash apps, but I need to use python/java/php to build website (php output is not enough), I can't use for bigdata.

Here is an example: at prezi we use objectiveC, haxe, flash, python and some java. The majority of our website is in django/python. I would love to use the same dependency injection on the client side and backup side. I would love to teach everyone in the company the type inference.

I don't care native performance on the server side.

So I would like to have a safe and productive tool for full stack web development. This would make me excited. Maybe this is java, or javascript, I don't know. To be a successful platform you need to show the diversity of possible applications (i would love to see haxe-java with hadoop, haxe-c with eventd high performance network programming), work on best practices (http://haxe.org/forum/thread/3395#nabble-td5320774) etc.

does it make sense?

hp

[Cauê Waneck]

Here is an example: at prezi we use objectiveC, haxe, flash, python and some java. The majority of our website is in django/python. I would love to use the same dependency injection on the client side and backup side. I would love to teach everyone in the company the type inference.

I don't care native performance on the server side.

So I would like to have a safe and productive tool for full stack web development. This would make me excited. Maybe this is java, or javascript, I don't know. To be a successful platform you need to show the diversity of possible applications (i would love to see haxe-java with hadoop, haxe-c with eventd high performance network programming), work on best practices (http://haxe.org/forum/thread/3395#nabble-td5320774) etc.

does it make sense?

Totally. But what holds you back from doing server-side with Haxe at prezi? IMHO Haxe's webserver capabilities aren't bad, specially if you are working with SQL (vs nosql). We could extend the support for NoSql, I actually started a project some time ago that would use the same macro-based query engine for both SQL and NoSQL backends. I also plan to make a Web framework that allows us to target any web server platform we can (from PHP and Neko to Java+Google App Engine, and maybe even NodeJS). Would that be enough for a more solid webserver support?

Thanks

Cauê

[Peter Halacsy]

Totally. But what holds you back from doing server-side with Haxe at prezi? 

it's not meant for that. No tools, no framework, no best practice, no knowledge

 

[Nicolas Cannasse]

Le 17/05/2012 15:09, Peter Halacsy a �crit :

I agree : all the tools are here, but they are not tied together by a
framework. Haxe is a toolbox, not a framework. So far.

Should it be ?

Best,
Nicolas

[Peter Halacsy]

On Thu, May 17, 2012 at 4:39 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 17/05/2012 15:09, Peter Halacsy a écrit :

   Totally. But what holds you back from doing server-side with Haxe at
   prezi?


it's not meant for that. No tools, no framework, no best practice, no
knowledge

I agree : all the tools are here, but they are not tied together by a framework. Haxe is a toolbox, not a framework. So far.

Should it be ?

I don't know what is the difference between toolbox and framework. What I know: writing a webapp in python takes 15 min based on the documentation, in haxe I don't know. I can generate php code but I donno how to do a webapp.

how can I read config files in haxe? for example

[Philippe Elsass]

Totally agree with Peter here.

As I said already, if you want to "sell" haxe you have to make opinionated decisions and say "here's the framework and this is how things should be done to do X".

Remember, RoR's "hello world" was a 5-10 minutes video to create a "complete blog". I think RoR vs Ruby is a good example: one well defined framework (among others) which became popular and which later drove Ruby popularity in general. 

And this doesn't mean you can't just pick in the toolbox, write everything from scratch as you like and make your own framework.

In some respect NME has a free ride because people can figure the basics out thanks to the Flash API, but it isn't that simple: there are many secrets and mysteries in the engine, and even smart people miss the batching features wich are the key to mobile performance.

On Thu, May 17, 2012 at 4:39 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 17/05/2012 15:09, Peter Halacsy a écrit :

   Totally. But what holds you back from doing server-side with Haxe at
   prezi?


it's not meant for that. No tools, no framework, no best practice, no
knowledge

I agree : all the tools are here, but they are not tied together by a framework. Haxe is a toolbox, not a framework. So far.

Should it be ?

Best,
Nicolas

--
Philippe

[Joshua Granick]

I agree with Philippe, "opinionated" frameworks (which provide an end-to-end solution) do help drive adoption.

For example, you won't often find books on sewing machines. You'll find books on quilts, clothing, and other types of "opinionated" "development" that causes users to buy, use, and perhaps love their sewing machine.

I do feel, however, that Peter's argument regarding "native" was splitting hairs.

If much of the Android runtime is using Java, and you write Java classes using the Haxe programming language, the result is going to be "native" to the runtime, not foreign. How else might you describe that Haxe is adapting itself to run "as a native citizen" to every place you might need to drive code? This is not the idea of processing Lua over the top of the target language, for example. 

[Peter Halacsy]

If much of the Android runtime is using Java, and you write Java classes using the Haxe programming language, the result is going to be "native" to the runtime, not foreign. How else might you describe that Haxe is adapting itself to run "as a native citizen" to every place you might need to drive code? This is not the idea of processing Lua over the top of the target language, for example. 

what is the difference between native java and native C on android?

anyway, I feel that the currently the best definition of haxe is that the native version of phonegap. Which I think is interesting enough (not one what makes me excited but never mind that)

 

[Joshua Granick]

I think that Haxe and PhoneGap are different in this case.

PhoneGap is used to provide a wrapper for platforms, so you can write the
same code and still access native APIs.

I know this sounds similar, until you recognize that there is a clear
"wall" between your application code and the actual platform. In order to
extend the function of PhoneGap, you will still need to write C++,
Objective-C or Java code.

Where Haxe is unique is that, unlike a runtime, there is no barrier
between your code and the rest of the application. You are not writing in
Lua, communicating with C++. You are not writing in Javascript,
communicating to Objective-C. The reason why I think that "native" is a
fair assertion is that you're writing Javascript in a Javascript
environment, or Java in a Java environment. There isn't really a runtime
or language barrier.

Accessing native code form the Haxe C++ target is more difficult, due to
the nature of C++, but for other languages/targets, accessing something
native is as simple as an untyped call, a typedef or an extern. That's
very different from the PhoneGap or Titanium style of development.

I suppose the benefits of Haxe depend on the platform.

A developer may choose Haxe because they prefer it over Javascript, as it
offers strong types and many more features. I enjoy Neko for command-line
tools, because it is fun to write and is easy to use and multiple
platforms.

Combined with NME, Haxe is a compelling solution for games and
applications, especially on mobile platforms. Apart from the benefits of
adapting a single application to multiple platforms and even target
languages (C++, SWF bytecode, Javascript), the command-line tools abstract
a lot of the complexity that's involved in supporting each target.

Somehow, it may make sense to communicate that Haxe is adaptive. Rather
than forcing each platform to work "the Haxe way," it adapts itself to be
a good citizen on each platform and in each language. Rather than
excluding features, Haxe was designed (as a language) to allow for
cross-platform code without compromise. Instead of using its own runtime,
it converts to use whichever environment you prefer -- native compiled
C++, SWF bytecode, Javascript, etc.

[JLM]

I think Mobile development can be games but is not just games, I see many media agencies look at offering a cross solutions where website, and phone all tie in together for the same project, so flash, js and nme may all play a part in an ad campaign and often social media so that is php, neko with flash, js to target stuff like facebook. 

So you can target types of developers separately or you can target types of clients separately... ad agency, gaming company, educational, etc..

If haxe is adopted by large blue chips as one of the inhouse prefered languages then this would be really good, so you can for instance look at how haxe could work with a company that currently uses a lot of dot net and then another use case a company that uses lots of java, and see how haxe can fit add to these users, and a company that does a lot of flash/js how they can start using haxe to build more robust backends.  Anyway just thoughts thrown into the mix.