12 6 / 2013

q42nl:

image

3 weken geleden heb ik een update gedaan van mijn Pxxl.js library, een libje waarmee je tekst kan ‘renderen’ naar pixel coördinaten om vervolgens leuke effecten mee te creëren. Het was niet eens een echte code update maar slechts een nieuwe githubpagina met uitleg en voorbeelden. Het…

20 2 / 2013

TypeScript Definitions Package Manager

When working with TypeScript you need type definition files for the libraries  you use. Already there was the invaluable DefinitelyTyped repo which hosts definitions files for many popular libraries like jQuery, Knockout, Backbone etc.

Now it becomes even easier to find and download those definition files with tsd, the TypeScript Definitions package manager. For instance, to install the definitions for Knockout, you would enter this on the command-line:

tsd install knockout

It then creates the following path:

d.ts\DefinitelyTyped\knockout

and within that folder you’ll find knockout.d.ts.

Looks familiar? Indeed, installing the actual library works analagous using bower.

What’s more, tsd’s website is a search engine for definition files, currently with DefinitelyTyped as its (only) source.  

image

 To top it off, when you click on a library name in the search results, it will present you with the actual command needed to download the definition files.

image

Note: you will need Node.js to install and run tsd.

reference

20 9 / 2012

Selecting by data-* attributes vs. performance

Just after writing about selecting elements by data- attributes, I discovered Roy’s post about this subject and his (positive!) performance measurements. Although I honesly thought it would be slower but he concludes that selecting by data attributes is actually not significantly slower than selecting by classname (<10% difference most of the time). The only exception is IE being 50-70% slower.

So that’s good news!

And I understand Roy’s motivation for coming up with the numbers: a lot of folks seems to reject the idea because they think that:

  1. their DOM queries will be much slower
  2. slower DOM queries will make their website/application slower.

So while Roy has mostly debunked #1, let me show you #2 doesn’t hold up either, if you follow these principles (and you should!).

Cache your queries

All methods to find elements in the DOM take time. A lot of time compared to just executing a single javascript statement. So always cache the elements you’ve already selected and re-use them! In fact this is my dearest rule about programming with jQuery because not only does it increase performance, it also keeps the code DRY and helps you catch typos earlier.

Scope your queries

Secondly, scanning the whole document if you don’t have to is a waste. If you have something like a dialog then first select the dialog’s root element and then, when selecting anything inside the dialog, like a button, use a scoped query, like this:

var $dialog = $("[data-role='dialog']");
var $button = $dialog.find("[data-role='button-ok']");

Don’t use script to apply style

Lastly, script is mostly dormant after the initial loading of the page. It normally takes user interaction for script to become alive. This means nobody is noticing a 25ms delay before the event handlers are attached! But, if you use script to apply styling of a component at page load then not even selecting by id will prevent a FOUC. Therefore, always serve out the html with the correct styling initially.

No more excuses!

Stick to these principles and selector performance will mostly be a non-issue. Chances are you were doing it already to keep your code clean and DRY. So what’s the excuse? Go ahead and use data attributes for selecting elements! You might like it ;-)

This is a follow-up to my post classnames for styling, data attributes for behavior

Discuss on reddit/r/javascript

18 9 / 2012

classnames for styling, data attributes for behavior

a.k.a. “classy behavior with data attributes”

For a while I’ve been using a rule-of-thumb that I’d like to share with you. Basically, when attaching behavior to html elements, in the form of event handlers and such, I use data-attributes to identify elements rather than classnames.

Example

Say we have a button that will display an alert:

.action-button {
  font-size: 120%;
  border-radius: 5px;
  background-color: red;
}

<button data-role='show-alert' class="action-button">
  click me
</button>

<script>
    $("[data-role='show-alert']")
        .click(function() { alert('you clicked me!'); });
</script>

Here, style is applied to the classname .action-button, while the behavior is applied to every element with the attribute/value pair [data-role='show-alert'].

Separation of concerns

What this demonstrates is that the style and behavior of the button are applied independently: You can change classnames without affecting the behavior and you can change the data-roles without affecting the styling. This can be quite an advantage, especially in larger teams.

Use any data-* attribute

The example uses the custom data-role attribute, which is what we use in our team. This was somewhat inspired by the jQuery Mobile framework. You can pick a different attribute, if you like, but whatever you do don’t use any pre-defined ones like role. These attributes have their own specific semantics and are not for you to use freely. Rather, make use of the data attributes as defined by html5 which are yours to embed custom data with.

For more information about the role attribute, see the WAI-ARAI specs.

jQuery plugin

I wrote dataroles.js (a jQuery plugin) that adds some extra functions like $.findByRole(role) to make all this a little easier. It assumes the data-role attribute. Check the repo for the features.

Other libraries based on this principle

  • role.js
    extends css selector syntax, can be used w/o jQuery, uses the role attr.
  • please let me know if you know any others

13 9 / 2012

Designing A Pirate Themed Card Game

q42games:

Every year during my summer holiday my mind wonders off to games not yet created. I love scratching down thoughts on paper and from time to time I come up with a new game concept that can either be played with dice, pen and paper or in this case… cards.

Read More

That’s right! We’re moving into the brick & mortar world. Or, I should say, the pen & paper world :D

(Source: q42games)

05 6 / 2012

Emulate Touch Events In Chrome

mrtnkl:

Hey mobile web developers. You can use Chrome to behave as an iPad or iPhone by overriding the User Agent and emulating touch events, and it’s just a click away.

In Chrome press F12 to open the Developer Tools. On the bottom right is a little settings gear. Press it, and voila:

Happy coding :D

20 8 / 2011

Demo launched: Fractyl Tree

The final result of our 1-day hackathon / demoparty is finally here! Targeted at Chrome specifically, the demo runs 1.5 minutes and shows a bouncing fractal tree. We gotta go, as it’s getting late but you can enjoy the demo here.

cheers,

Fractyl 3

p.s. yes that’s our brand new group name! ;-)

20 8 / 2011

Ferry composing phat beatz.

Ferry composing phat beatz.

20 8 / 2011

Sjoerd coding like a madman.

Sjoerd coding like a madman.

20 8 / 2011

Today is demo day!

In the spirit of the demoscene of yore we’ve assembled a crew, 2 coders and a musician, to create a html5 / music demo in a single day. Not unlike hackathons like Q42's w00tcamp, we limit ourselves to single idea and attempt to work it out within a time contraint.

After having some trouble getting a network up in the morning, we’ve decided upon a theme, based some preliminary work by Sjoerd, and got going. The core idea is that of a tree, but I won’t tell you more at this point :-)

And while Sjoerd is coding like mad to make his tree do funky stuff and make it all perform in the browser, Ferry is currently turning the knobs, spilling electrified beats and cranking up the volume to almost eardrum shattering levels! I myself am working on the opening scene currently and writing this blog post ;-)

Well, I gotta get coding again but stay tuned for more updates while we continue our journey through mad beats & bytes!