Ufront visibility

[delahee]

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]

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:

• https://www.reddit.com/r/webdev
• https://www.reddit.com/r/programming
• https://www.reddit.com/r/technology
• https://www.reddit.com/r/frontend
• HackerNews
• Slashdot

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]

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]

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]

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

[nadako]

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]

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]

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
#30 (comment)
.

[jasononeil]

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:

• ufront-mvc
• ufront-orm
• ufront-easyauth - Possibly could be considered optional
• ufront-ufadmin - Can be made optional
• ufront-uftasks - Can be made optional

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:

• Used throughout:
  • tink_core
  • tink_macro
  • minject
• Small utilities that are helpful, and I don't want to remove
  • compiletime - A simple library (2 classes) with some macro powered utilities that we use in several places and encourage people to use when setting up their configuration etc.
  • random - A stupidly simple library (1 class) that we use to generate UUIDs for sessions and password-hashing salts.
• Only required by ufront-easyauth, which could be made optional.
  • PBKDF2 - for password hashing. 1 class only.
• Only required by ufront-uftasks, which will be made optional
  • mcli - for making CLI task runners.
• Only required by ufront-ufadmin, which will be made optional
  • hscript for letting you edit serialized objects using Haxe syntax.
• No longer required
  • thx.core - Dependency removed in latest git.
  • cleversort - Only used for syntax sugar, I can get rid of it.

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]

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]

+1 to Nicolas :)

[delahee]

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

[delahee]

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