Category Archives for JavaScript

OpenShift

Created an OpenShift account tonight. The application creation is pretty simple, but the cartridges that are available are pretty limited. And the Ruby apps seem wanting at only version 1.8.7. Don’t understand why that’s the case and why not 1.9.2? It seems to me that with RVM the version should be a choice. But who knows, there is likely an architectural nuance that forces their hand to limit it to 1.8.7.

Regardless it’s a rather clean and simple setup. The rhc client is nice and it’s extremely cool that the project starts with a template (at least the Node.js application I created did). The project template has README files documenting available cartridges and hooks for build/deployment cycles (nice touch).

I’m a big fan of Heroku. I have an account there too. Now if I’d only build applications to host on each of them :)

Changing how CSS works: Hitch

One of the most popular technologies in web development today is CSS. It’s a language that controls the presentation of HTML pages to browsers. It’s also one of the most complicated languages to truly master. CSS has a deceivingly easy syntax and rule construction, but is as close to any imperative/declarative language as can be in its execution.

To further complicate things, web browers (Chrome / Firefox / Opera / Internet Explorer) all treat the rules of CSS differently. Even though there are standards written on what should happen for certain features and constructs, they still each have their own nuances. Seemingly simple things like rounded-corners are handled differently by a few of these browsers.

Now you can reverse that paradigm: Hitch

Right now browser vendors (Google / Microsoft / Mozilla / Apple) control how CSS works in the browser you’re using. There are utilities out there that make writing CSS easier and better, while trying to minimize these vendor differences. For example, Sass is a CSS superset in which you can write CSS with certain syntactical features and Sass will re-compile your Sass into standard CSS and specifically for each vendor’s nuances. It does not however change how CSS works, and relies on the browser’s current functionality for CSS features. There is also LESS – very similar to Sass. (These are both wonderful utilities and you should use them.)

Hitch switches the control of the web page from the vendor to the developer. It provides true functional changes via CSS, not just syntactical extensions. The way Hitch does this is through a JavaScript API that hitches onto the execution of CSS, intercept it, change it and then let it continue. Specifically it’s designed to extend the CSS pseudo elements and pseudo classes by making them more like filters.

An Example

Imagine you need to style the links in your web page according to an information architecture where the nested level of the link’s URL path is important. For example the URL path /2012/05 is important because it represents a month and /2012/05/05 is important because it represents a day. The markup for these is very simple:

<a href="/2012">View 2012</a> 
<a href="/2012/05">View May</a> 
<a href="/2012/05/05">View May 5th</a>

With standard CSS there is no way to apply a style based on the path nesting. But with Hitch there is:

/* links with /-- should be black */ 
a:-links-local(0) { 
    color: #000000; 
} 
/* links with /--/-- should be blue */ 
a:-links-local(1) { 
    color: #336699; 
} 
/* links with /--/--/-- should be gray */ 
a:-links-local(2){ 
    color: #333333; 
}

With the Link Pseudo Class filters you can specify a style for any number of nested paths and even base the style on whether the path is local to your web page or external. The CSS rules are subtly different (but still very standard) while the functionality is extremely new and currently not doable without Hitch.

Not only does Hitch come with a few built-in features like filters, widgets and constants – it is also extensible by you. And this is where it breaks the current paradigm:

Now you can control your CSS functionality and not be bound to a vendor.

Note: Hitch is a rather new project. It has amazing potential and also a few things yet to be built. It’s open sourced and available on Github: https://github.com/bkardell/Hitch/. Fork it. Change how CSS works!

Things I’m working on

I’m listing out a few things that I’m going to spend more effort working on in my free time. Some of this I’ve already started. Most of this is entirely new to me and I’m treating as education.

Parsers

There are tons of parsers out there. And frankly the field is quite big. But honestly I’m pretty humble about my expectations. I created a project called Peggy.js and I hope to get some activity in that library. I’d like to be involved in the many web projects out there that require their own grammar/parser. What I’m learning so far is that nearly everything in software development is some form of parsing (more than one might imagine). And it can be very difficult.

Sentiment Analysis

Sentiment analysis is another field that is rather big and actually becoming quite popular (or trendy I suppose). To be honest, I’m not even sure that the field has a name like that. It’s basically the study of emotion/attitude/opinion in content users submit to web applications. At least that’s my definition. Essentially I’m interested in the Front-End perspective. How do web/mobile applications handle sentiment analysis? Is there a way to do so on the Front-End that will add better user experience? Or is it really only suited in the post-content-submission perspective. I’ve started (I use that term very loosely) 2 projects for this. One in Ruby and one in JavaScript: Sentiment.js and Altimeter. I’m really hoping to capitalize these projects as not only learning experiences, but potentially career altering opportunities.

I have a ton to learn. I’m very interested in these things. Hopefully something will come of it.

Next Exciting Thought Exercise

At work and personally my next new shiny thing is the design of a framework for delivering JavaScript applications. It’s more than building modules, listing them in a gallery and then HOWTO documents, rather a top-to-bottom application UX delivery system.

This is more tricky than might be imagined. It’s a gallery of modules. It’s a development environment. It’s a hosting environment. It’s a core library. And not always in this order.

It’s exciting stuff to think about. And it’s really cool to think about doing it with JavaScript (client and server sides). A few things that cause concern are the definitions of things.

  • What is a module?
  • What is a component?
  • Is there a difference?
  • Or are components applications?
  • What does “development environment” mean?
  • Does hosting mean you get what you get or does it mean you can get what you want?

It’s answers to these questions that are critical in designing a system like this.

Fun stuff.

Software Abstractions

Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

chrisjsmith

This was part of a comment left on Hacker News to a post about Coffeekup. Coffeekup is a CoffeeScript abstraction over HTML. Just like HAML. The beauty of the comment is how concise it is to the real problem with abstractions.

Abstractions are key to developing good software libraries. They are shortcuts for what otherwise might be lines and lines of code. The jQuery JavaScript library is a great abstraction over JavaScript. It takes what would be tons of “document.querySelectorAll(‘selector’)” kinds of code and distills it down to “$(‘selector’)”. This is a good abstraction because it’s JavaScript over JavaScript.

And in many cases developers will build libraries of abstractions in the name of “platform”. That is to say that you can create a platform for building software based on a frameworks full of these kinds of abstractions. An example might be to use Google Web Toolkit to build web pages which would allow you to write “everything” in Java, and compile it down to JavaScript.

The quote points out why this is not always the best solution. The reason is simple: It’s Java over JavaScript. Right away the learning curve is 2x the original problem. What you may not be familiar with in JavaScript may only loosely compare in Java due to differences in language. It is much harder to debug – regardless of the debugger provided – because of the native differences in runtime for each language. More importantly, is that it requires more lines of code to achieve the same effect. What is typically a few lines in JavaScript inevitably turns into tens to hundreds of lines of code in Java. The compilation process is so effective that the hundreds of lines of code in Java turns back into those few lines of JavaScript. Which to me argues the benefit. Is there one?