Branding/Marketing website

fullofcaffeine commented 8 years ago

I think this is one of the best libraries out there for web and general js development with Haxe, because let's be honest, UFront is a niche framework currently and is not really under active development.

I suggest we brand this over and create a slick marketing site. The name could changed maybe, but I think haxe-js-kit is fine.

Food for though! What do you guys think?

clemos commented 8 years ago

That would be great :) @matthijskamstra's tutorials are already a pretty solid starting point: http://matthijskamstra.github.io/haxenode/index.html I've been thinking about at least moving Haxe/JS related stuff to a dedicated Github organisation. I'll move haxe-js-kit there, probably split it to different projects. There is also this npm-haxe package that I've been working on: https://github.com/clemos/npm-haxe (allows to install haxe and haxelib via npm).

MatthijsKamstra commented 8 years ago

I have no problem moving my tutorials to a dedicated Haxe Javascript organisation. Probably need to do some rewriting (I think I wrote it from my personal perspective)

If needed I will help with the "slick marketing site"

fullofcaffeine commented 8 years ago

That's cool. Would love to contribute.

My main point is that it's quite confusing to navigate the Haxe js ecosystem as of now. I think haxe-js-kit should be the point of entry, the "killer app".

On Mon, Jan 25, 2016 at 2:16 PM, Matthijs Kamstra notifications@github.com wrote:

I have no problem moving my tutorials to a dedicated Haxe Javascript organisation. Probably need to do some rewriting (I think I wrote it from my personal perspective)

If needed I will help with the "slick marketing site"

— Reply to this email directly or view it on GitHub https://github.com/clemos/haxe-js-kit/issues/108#issuecomment-174648254.

MatthijsKamstra commented 8 years ago

I agree, one point would make it easier!

kevinresol commented 8 years ago

+1

fullofcaffeine commented 8 years ago

I can't help but compare with the Rails approach. Starting with Rails is, to this day, extremely simple and straightofward (this article provides some updated perspective on that http://bit.ly/1HZJ4S5).

If we can somehow sell the haxe-js-kit as an improved way of doing Javascript, then we'll be good. People will often fallback to Javascript/ES6 unless they have a very good reason to use Haxe, and I think the Haxe machinery can provide a Rails-like experience (with generators, DSLs, simple package management -- even if only an abstraction over existing solutions, etc).

I also think the static typing to be an advantage there.

Productivity still rules. Who wants to be debugging something in a friday night when you can go out and have some beers? :)

fullofcaffeine commented 8 years ago

I think we should invite @ciscoheat to the conversation, since he has been quite active in the Haxe web sphere, too!

fullofcaffeine commented 8 years ago

Oh sorry Clément, I meant @ciscoheat :)

ciscoheat commented 8 years ago

Thanks @fullofcaffeine ! I had hoped for more interest in merging the top node libs for Haxe, but when that wasn't very interesting I took the back seat. I'm using haxe-js-kit and sends PR when I add something, but not much more until there is more consensus about haxe/node in general. Anything changed in this area lately?

fullofcaffeine commented 8 years ago

@ciscoheat But it's been merged no?

gamedevsam commented 8 years ago

+1 for this, I'm fairly new to web dev, but been using haxe for a few years. Would be great to have a sort of boilerplate template for web apps built with Haxe. I recently made an electron app (not with Haxe sadly), and the electron-boilerplate was essential in getting that running quickly.

fantoine commented 8 years ago

Just to give my 2 cents here.

I think this library provides lot of useful externs but the whole thing maybe restructured to provide a more organized externs marketplace.

Let's imagine a full dedicated github organization which provides externs, not only for js target, but for all haxe supported targets. It could become THE place to go to get an haxe extern, just like DefinitelyTyped is the reference for TypeScript.

Moreover, I think splitting each module to several repositories could give some advantages:

You can easily use a branch for a module without breaking other ones.
You can integrate tests or documentation specific to a given module.
You can load only the modules you need.

With this organization I can easily imagine a lot of things which could make it easy to use externs (a cli tool to haxelib git a given extern repo, a website to list search available externs,...).

It could also be easier to merge stuff from other libs.

Anyway, I'd be glad to help in this way if other people are also interested.

fullofcaffeine commented 8 years ago

I've been thinking about it and, before any website, I think what we need next is a tool -- A generator for the most common projects.

Adding more externs and abstracting more stuff with macros is a good way to sell haxe-js-kit-- @ciscoheat is adding new externs everyday for example, and that's great :)

However, the main challenge is bootstrapping.I spent quite a bit of time figuring out how to use webpack with my haxe-js-kit based project, for example. It uses Angular on the front and rails in the back. Next time I need something similar, I want to be able to quickly generate a usable skeleton, maybe even with deployment facilities built-in (so it's quick to get from prototype -> production).

I think we can use yoeman (?) for that purpose and provide some tasks that can be used to create a new project based on templates (blog, cms, or maybe lower level like express+angular, or with/without components like with authentication, permissions, etc). I'm not very familiar with yoeman though.

Let me know what you guys think.

clemos commented 8 years ago

@fullofcaffeine Well I gave a shot at Haxe/JS + Yeoman here : https://github.com/clemos/generator-haxe-webapp Honestly, I've never really used it, because I finally found Yeoman pretty useless. But you're right, bootstrapping would be nice.

My bigger plan, currently, is to release a clean NPM package containing just the Haxe compiler + Haxelib, properly configured: https://github.com/clemos/npm-haxe IMHO, it's a very important thing to have to compete with Typescript, because currently, installing Haxe is already a huge show stopper. The NPM I've been working on does require Neko, which is already a plus. (About neko dependency, see: https://twitter.com/andy_li/status/702894357104427008)

Having a clean Haxe NPM package opens the door to creating any kind of dev tool (bootstrapping, build tools, dependency management, etc...) in Haxe, all delivered via npm (I've seen @back2dos do crazy things with haxelib + macros, some of which should definitely be released somehow).

I've also recently started to work on Visual Studio Code support, focusing on Haxe/JS. First, because it looks like a great editor (superior to Sublime Text and free/open source), but also to compete with Typescript (VSC has integrated Typescript building, debugging...)

clemos commented 8 years ago

neko is not required :p

clemos commented 8 years ago

BTW, it seems @fantoine started something ;) https://twitter.com/ExternKit

fantoine commented 8 years ago

Well, indeed :) It's available here.

What I started is just an other way to organize externs, it's not about quickly bootstrapping an Haxe app or competing with haxe-js-kit. ;)

The goal of ExternKit is to give tools to quickly find, load and add dependencies to given externs.

There is still a lot of work to do:

Adding all the externs I use but are not public yet;
Adding a search engine to find externs (already have some ideas);
Adding some design/branding (not so much ideas for this yet...);
Creating a tool which would extends haxelib to load externs (something like tsd for DefinitelyTyped)
Hoping more people will want to put their externs there ;)

I also want to find the best way to manage dependencies between libraries since they are not published yet on haxelib. And the way haxelib handle only-zips submits is a bit restrictive when you want to depend on non-submitted libraries. I saw hmm to be quite promising, by providing local project dependencies and git/hg dependencies support.

Also, ExternKit won't provide tools to bootstrap haxe projects. It's only a way to connect Haxe with its targeted languages libraries. I think a kind of HaxeKit would also be a better starting point for new Haxe developers. I imagine it providing front/back/game/whatever projects bootstraps as examples but also some abstracted cross-platform frameworks to start with each kind project.

Anyway, this is just an idea. :)

fullofcaffeine commented 8 years ago

This is turning into a very interesting discussion. Thank you all for shouting out your ideas.

@clemos I saw your npm-haxe initiative. Very interesting indeed. Looking forward to using it in my projects. Let me know if you need help with that.

(I've seen @back2dos do crazy things with haxelib + macros, some of which should definitely be released somehow).

@back2dos Juraj, we summon you! Could you share a bit about your experience with haxelib and macros? That sounds interesting. I'd be interested to hear about the problems solved.

@fantoine I'm not sure I got what externkit is about... could you elaborate? Is it an extern indexer?

I also want to find the best way to manage dependencies between libraries since they are not published yet on haxelib.

What kind of libraries? I think if it's a stable Haxe library, it should be on Haxelib, no?

Regarding hmm, I had no idea it even existed! Thanks for pointing that out.

See, that's one of the problems with Haxe (as well as one of its advantages, maybe) -- there are too many options available and there's this homebrew culture where everyone is constantly reinventing the wheel. It's hard to concentrate efforts, for some reason.

While I like this hack mindset of hacking my way into my own solution, business-wise it doesn't make much sense. It should be the exception, not the rule. It's easier to just use what works well already, in this case, people will often gravitate towards more popular stacks.

I imagine it providing front/back/game/whatever projects bootstraps as examples but also some >abstracted cross-platform frameworks to start with each kind project.

I sympathize with this idea, what I'm focusing here in the web eco-system. Haxe has a lot going on for game dev. There are bootstrap tools for game development already (I think) -- OpenFL has a suite of tools to help with that, so does Snow.

For the web, the closest we have is haxe-js-kit.

Any newbie coming to Haxe for web dev right now has a terrible time getting started. It's way easier to go the ES6 or TypeScript route.

The question to ask, as well, is: Why would I even use Haxe for web dev? For me, I like the language, and I know that with macros and the right target (javascript?) we can do something as powerful and productivity as Ruby/Rails did at its peak time, while avoiding the pitfalls of Javascript. Not everyone would agree to that because the barrier to entry for web dev with Haxe is quite high currently.

back2dos commented 8 years ago

(I've seen @back2dos do crazy things with haxelib + macros, some of which should definitely be released somehow).

@back2dos Juraj, we summon you! Could you share a bit about your experience with haxelib and macros? That sounds interesting. I'd be interested to hear about the problems solved.

I must admit I don't really know what @clemos is referring to, so I too would be interested to hear more about it :D

See, that's one of the problems with Haxe (as well as one of its advantages, maybe) -- there are too many options available and there's this homebrew culture where everyone is constantly reinventing the wheel. It's hard to concentrate efforts, for some reason.

While I like this hack mindset of hacking my way into my own solution, business-wise it doesn't make much sense. It should be the exception, not the rule. It's easier to just use what works well already, in this case, people will often gravitate towards more popular stacks.

Compared to actual engineering, in line with the metaphor of wheels, this is where we are at:

Wheels

I say this is a very bad moment to stop reinventing wheels. Especially from a business perspective ;)

kevinresol commented 8 years ago

Is this (https://github.com/HaxeFoundation/hxnodelibs/issues/1) even related?

Btw, in the picture out of the six men I suspect only 2 are actually putting effort. lol

clemos commented 8 years ago

I just think haxelib is pretty underrated. For instance, I wasn't so interested until @back2dos showed me some tricks. Maybe it was just inspiration rather than actual tricks.

As for these 6 people, at least they go in the same direction :)

fantoine commented 8 years ago

@fullofcaffeine Yes ExternKit goal is to be a kind of externs index, for every Haxe supported languages.

It's actually something like HaxeFoundation/hxnodelibs, but honestly I didn't know about it before. The bad point I can see about this one is that it will only focus on node libraries. While I didn't want to be restrictive about only-back or only-front libraries since some of them can be used in both sides.

If this kind of project can be supported by the Haxe Foundation, it's even better. But from what I can see, nothing changed on the hxnodelibs repo since last september.

Moreover, Haxe is multi-languages, so by principle I think every kind of externs should be available from the same place... By putting node externs in one place, browser externs on an other one, and then for all other languages,... I think it breaks this power of haxe.

What kind of libraries? I think if it's a stable Haxe library, it should be on Haxelib, no?

Yes indeed, maybe I could put them on haxelib. But since most of hxnodejs related libs move quickly, I prefer to work with the latest git version of them.

I sympathize with this idea, what I'm focusing here in the web eco-system. Haxe has a lot going on for game dev. There are bootstrap tools for game development already (I think) -- OpenFL has a suite of tools to help with that, so does Snow.

As I said, it was just an idea. :) Especially since I also think that the game making aspect of haxe is already known and easily accessible. It's just that I felt that you were mainly talking about bootstrapping serverside/node applications, and not about browser applications. Maybe I just misinterpreted it.

kevinresol commented 8 years ago

I have created 2 hxnodejs library externs

Will it be a good idea to add links to the README here, or create an organisation to hold them?

fantoine commented 8 years ago

or create an organisation to hold them?

@kevinresol It was this kind of idea for https://github.com/ExternKit. :) I'll be glad to give access to more people on this organisation.

kevinresol commented 8 years ago

@fantoine the repos look nice! What should I do to put libs there? But the point is that it seems to get diverged, haxe-js-kit vs externkit. I think some efforts should be put to centralize things....

fantoine commented 8 years ago

@kevinresol Thanks. Sadly, I didn't wrote any documentation right now. I need to add a readme about lots of things.

I know it can be disappointing but the goal of ExternKit is not to compete with js-kit. I want it to provide only externs and maybe for more targets than javascript, while js-kit focuses only on js and provides more tools.

I'd be glad to merge libs from js-kit to ExternKit but I don't want to steal them from js-kit. If @clemos and others contributors of js-kit agree, we should try to work together.

clemos commented 8 years ago

The problem is really with the dependency system, because all haxe-js-kit externs use it, and thus depend on the npm.Package modules. The reason is haxe-js-kit started as a rather small project, with ease of use in mind, at a time when Haxe didn't support @:jsRequire. So I had to find a way to support JS require() easily, which I implemented together with a macro that would export the dependencies to package.json.

Now we have @:jsRequire and people write externs that "just work", haxe-js-kit's npm.* package should be rewritten in a way that doesn't require implemeting interfaces, but just the official @:jsRequire, together with an optional @:npmVersion("^2.1.0") or whatever. This would make this npm.Package module just a build tool, and not anymore a dependency. I also think it would be better for this tool to just run npm install xxx --save if needed rather than editing package.json itself...

Then we could just drop the npm.Package.Require interface completely, and why not split the extern collection to different packages and/or move them to another organization / repo. Hence, for the record, I have absolutely no problem with people taking externs from haxe-js-kit, dropping the npm.* dependency, and moving them to, say, ExternKit ;)

kevinresol commented 8 years ago

unless @:npmVersion is officially supported by Haxe, otherwise we still need some "dependency" to process the meta, isn't it? I think npm.Package does the job well and I would vote keeping it for node externs.

clemos commented 8 years ago

@kevinresol Thank you for your support :) But I believe npm.Package has no reason to be mandatory now we have @:jsRequire. Then if it becomes just a tool to handle NPM dependencies, it could just be a macro that crawls all classes and gathers @:jsRequire values. As for @:npmVersion: if this tool promotes the use of it, and allows third party to tag their externs to add free support for this haxe-js-kit feature, then I guess it might become a de-facto standard, if not further integrated to the compiler.

kevinresol commented 8 years ago

@clemos Good points :+1:

@fantoine I can see that in ExternKit there is a repo called externs-js that basically holds all the js externs in a single place. I am not sure but will that lead to management problems? (Imagine one day we have, say, 300+ externs there). I have an idea that ExternKit maybe able to provide a small tool to search for these externs:

haxelib run extern-kit search mime
haxelib run extern-kit install mime

clemos commented 8 years ago

-1000 for using haxelib run because IMHO it's broken. Something cool would be to use npm for distribution, with a common prefix like haxe-extern-mime The package would simply depend on mime, and we could provide a helper tool to automatically install it as a dev haxelib for use with -lib npm-mime

kevinresol commented 8 years ago

wow, I never knew haxelib run is broken. Could you elaborate a little bit on that?

Well, distributing with npm isn't bad, if it is a node extern. But what if it is python, or php, etc?

clemos commented 8 years ago

@kevinresol "haxelib run" depends on neko for historical reasons. Now that haxe has macros / --interp, "haxelib run" should use it to avoid neko dep

fantoine commented 8 years ago

@clemos Thanks for sharing your externs. :)

@kevinresol I also want to create a kind of search engine / externs installer. It was one of the main idea behind moving to a separated organisation. I think a lot of things can be done there.

About the @:jsRequire/@npmVersion question: in ExternKit I also use a js.extern.Extern interface which can handle multiple require modes : global, window and require. So it can be used on node projects but also on browser ones. I already made some node+browser compatible externs (like yamljs extern) with stuff like using a different name depending on the platform (eg: require('yamljs') on node, but window.YAML on browser).

I also want to be able to support multiple versions of libraries (like in validator extern) by letting the developper specifying the one he wants to use.

Maybe all this macro-related stuff could be handled differently like @clemos said. Maybe it could be handled in a descriptive json file for each extern repo...

And about the main big repository which references all js externs. In fact I created it after to simplify the management of all the current repos, but I'm not sure to keep it for the reason you mentioned @kevinresol. Anyway, it works with subtrees from all repos so it can be easily deleted without any side effects...

kevinresol commented 8 years ago

@kevinresol "haxelib run" depends on neko for historical reasons. Now that haxe has macros / --interp, "haxelib run" should use it to avoid neko dep

There is a main field in haxelib.json which allows you to run your program in interp mode. Neko is no longer a must-have dependency. Example: https://github.com/back2dos/travix/blob/master/haxelib.json#L2

clemos / haxe-js-kit

Branding/Marketing website #108