apuntes

Lately I have been trying to encapsulate some functions that I use in my day to day development.

Today I will introduce HelmJS, a Curry based DOM Factory for vanilla Javascript and jQuery.

Maybe the name is even more complicated that what it does. Basically I made a wrapper that follows this rule:

$('<div>') === $div()

$('<div>') is the fastest way to create an HTML element in jQuery.

You then can chain some other functions as follow:

$('<div>').attr( "class":"fitter happier" ).text( "more productive" ).appendTo( $container );

It will create a DIV element, with two classes: fitter happier, with the text "more productive" and append it to an already declared $container. Also you can bind events like on click, etc. ( That jQuery object is awesome! )

So far this seems really convenient. BUT, reading the jQuery source I found out that any string passed to $() is evaluated as if it is an HTML string representation ( $('<div>') ) or a Sizzle Selector ( $('div.some-class') ). 

So, I don't know if this is completely ok, it works I know, but what happens when you write $('div') ( notice the lack of <> ) with that expression you are selecting ALL DIVs in your DOM and not creating any. Kind of an easy bug right there huh?

I have created some Perfs to test which is the fastest way to create HTML elements using jQuery.

Then I asked my self, what if we use the native javascript way to create HTML elements, which is document.createElement() and wrap it up with a $() Object, this way jQuery won't need to test if it is a selector or not : 

$( document.createElement('div') );

Its Perf Test shows a better performance for this more native solution.

Next, I found that with the use of curries we can specify custom functions for each HTML Element available. ( How to set up curry functions )

Ending up with these custom functions:

div() or a() as encapsulated forms of $(document.createElement('div')) or $(document.createElement('a'))

But since these Curries need to live in a very global scope I decided to use the *hungarian notation(?)* of $ to specify that they return jQuery objects and also to prevent problems with variables named a or the famous i etc.

And that is how HelmJS was born.

I've curried all the HTML elements in this MDN list. This also prevents you to select all DIVs by mistake as explained earlier since you only have one way to create a DIV.

There is also included a Vanilla Version that works with document.createDocumentFragment(). See the example in the github repo.

I don't necessary recommend to use HelmJS in a production or a very serious project, it needs more testing. Also it is most likely that you will be using some MVC Framework or Template Engine to build your HTML elements. But if you are planning to do so at least you were informed ( and please let me know ).

Even though the title seems kind of pretentious, truth is I stopped using Facebook as a consumer sometime a year ago. And I say as a consumer because as a developer I have been using it with test accounts and so.

Thats why in this exercise I am going to post some ideas that could make me think of coming back to Facebook. But..

I am very sure that Facebook will never implement anything posted here nor something similar, It is very clear that Facebook new clients are their stakeholders and developing for consumers is not their priority.

With that said, lets begin day dreaming:

What if, Facebook implements a way to share configurations among users. I mean, one of the hardest part of using Facebook is the amount of time you need to invest tweaking your privacy configuration to feel safe to share.

Of course most of people don't give a damn about this, they use Facebook with default settings and they are happy with that, until they get tagged going out on a friday night with someone else that is not your girlfriend (woops!).

Another problem of not caring about default settings is that Facebook can change those every time they want but still normal consumers will not care. It is really inconvenient to read those mails and to understand those changes so lets trust Facebook, yeah right!

But, there are Facebook Power Users that care about this Privacy Settings and they use Facebook in a "Pro Way".

What if, we let those Power Users share their Configurations, maybe as files or any data abstraction Facebook can think of.

If the idea catches up we could get popular Configurations like:

 - Friendly Configuration (Get all your friends of friends to know me).

 - Path like Configuration (as the Path app, even with 250 friends cap).

 - Protect your children Configuration (All private except for their friends under 20 years old)

 - Anything normal but only this people can tag me: add List of people.

Of course this idea will work better with a Configuration API, so you can build other ideas on top. But, ..

"When it comes down to smart, talented, capable people, what is often the reason that they will fail at something is that, in order for them to be successful, they have to perform behaviors they regard as actively stupid."