search

HaxeFoundation / Project-Management

Project management and communication
20 stars 4 forks source link

Ufront visibility #30

Closed delahee closed 8 years ago

delahee commented 9 years ago

I don't know but... Since ufront is now a strategic asset, we should enforce our relation to it and leverage SEO and such with them.

For example : google "ufront" is not giving meaningful results to me...

@Merelleya Am I pertinent here ?

larsiusprime commented 9 years ago

Ufront especially represents something Haxe is not as well known for as it should be -- WEB STUFF. And it's got a great sell -- a web framework where you can use the same language on the client AND the server.

We should really be hitting this up in the various hangouts for this sort of thing:

And so forth. The key is to have a really good introductory article / landing page for it that explains exactly what it is and gives a solid pitch for it. Does the current Ufront page do that well enough or could we improve a little before we try to give it proper attention?

Simn commented 9 years ago

I just can't shake off that feeling that ufront is really "heavy". Maybe that's just because building haxe.org requires like 20 different haxelibs.

Merelleya commented 9 years ago

I will put this on mine and @jasononeil s list. However, as far as I know, the Ufront site is quite new. It takes a while for a site to be properly ranked. Especially if there is not much content on it. There are some small technical things one can do, but other than that, it all boils down to the content, recency and to a certain degree back-links, although getting a link profile artificially is not recommended.

What you and also Lars are looking for and recommending is online-marketing rather than SEO.

I will have a chat with Jason when there is time to see if there is anything on the technical side that we can do. Other than that, I could do a showcase on it at some future date or we can blog about it, once we have the blog and so on.

delahee commented 9 years ago

Ok fine as long as the topic is on your radar :)

nadako commented 9 years ago

I'm with @Simn about heaviness feel because of ton of libs, maybe it makes sense to review whether all of them are really required.

dpeek commented 9 years ago

I don't understand this fear of dependencies. Heaven forbid a Haxe developer used some existing code rather than reinventing all their wheels!

It's not like Rails is monolithic: actionmailer, actionpack, actionview, activejob, activemodel, activerecord, activesupport, bundler, railties, sprockets-rails

hughsando commented 9 years ago

I think dependencies are fine (good, in fact) as long as they are properly decoupled. So if ufront requires some of Lib A, and some of Lib A requires Lib B it does not necessarily follow that ufront requires Lib B, depending on which parts of Lib A are involved. And if you avoid dependency hell, where you need older versions of any of the libs for any reason, there should not be a problem with many libs. I also think it is much easier with source-code libs (ones without binaries) since practical download issues are generally not a problem. I have a problem with the flixel-demos when I want to test them on nme, since it pulls in 100MB of lime/openfl, which is not actually required. So I think it is worth ensuring that the whole framework can be downloaded in a reasonable time (reasonable being relative to the fact that it is actually doing quite a bit of stuff) and if this means making some parts optional or something, then it might be worth it.

On Tue, Jun 9, 2015 at 5:50 AM, David Peek notifications@github.com wrote:

I don't understand this fear of dependencies. Heaven forbid a Haxe developer used some existing code rather than reinventing all their wheels!

It's not like Rails is monolithic: actionmailer, actionpack, actionview, activejob, activemodel, activerecord, activesupport, bundler, railties, sprockets-rails

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/Project-Management/issues/30#issuecomment-110152292 .

jasononeil commented 9 years ago

Hey all, sorry for the late reply to this... it has taken me a while to recover after wwx.

Visibility

I am waiting till I have a stable haxelib release (v2). To achieve that, I need to work with David on a haxelib release of minject v2 (@dpeek I'll try leave my comments on that soon).

Once that haxelib is up, the tutorials will be significantly easier to try out, and THEN it's worth doing the content marketing stuff ... thanks for the list @larsiusprime - I'm not a redditor so the list of subreddits is helpful. I'm not sure if it is of general interest to slashdot. Hacker News will hopefully pick it up, though it can be pretty hit and miss with them.

The SEO will sort itself out once I upload the tutorials and have more content. I've named all the tutorials with SEO friendly titles, such as "How to send email in Ufront" or "Handling file uploads in Ufront". Once the site has more content populated we can link to it from the haxe.org website, the lib.haxe.org website, Github etc which should help with SEO also.

Dependencies

I admit that the dependency situation is needlessly complex, and since WWX I have taken some time to audit these (as @nadako has suggested) and got rid of the thx.core dependency (as @dpeek suggested).

The ufront haxelib is a "mothership" repo that includes a bunch of different libraries, most of which can be used independently. I could consider making some of these optional so they are not included by default:

The ufadmin and uftasks libraries I will make optional, which will reduce the weight if you are not using them. The easyauth one I am not sure about - it is kind of needed if I am to claim "batteries included".

In terms of the other dependencies in the project:

Conclusion: Yes it has been more complicated than it needs to, and I'll try clean it up. At the same time I'll try document which dependencies I have used, and why. I hope this helps and I'm always open to feedback.

ncannasse commented 9 years ago

When it's a small 1/2-class library that is not exposed to the end user but used internally, maybe you could simply include it in library.

I'm in favor of "batteries included" approach, and I think that having one big library is often better than having several split ones, even if they have no direct dependencies between them, but when they are part of the same "framework". It also prevent "library hell" when an upgrade to one of the library will make other break.

ConfidantCommunications commented 9 years ago

+1 to Nicolas :)

delahee commented 9 years ago

@jasononeil awesome work. Could you highlight / hotlink the samples from within the github reame somehow ?

delahee commented 8 years ago

I'll close for inactivity and bugger our friend on their github :D