About JavaScript apply arguments limit

Just a quick one from ECMAScript ml ... it is true that browsers may have a limited number of arguments per function. This may be actually a problem, specially when we use apply to invoke a generic function that accepts arbitrary number of arguments.

String.fromCharCode

This is a classic example that could fail with truly big collection of char codes and here my suggestion to avoid such limit:

var fromCharCode = (function ($fromCharCode, MAX_LENGTH) {
    // (C) WebReflection - DO THE FUCK YOU WANT LICENSE
    return function fromCharCode(code) {
        typeof code == "number" && (code = [code]);
        for (var
            result = [],
            i = 0,
            length = code.length;
            i < length; i += MAX_LENGTH
        ) {
            result.push($fromCharCode.apply(null, code.slice(i, i + MAX_LENGTH)));
        }
        return result.join("");
    };
}(String.fromCharCode, 2048));

// example
alert(fromCharCode(80)); // P
alert(fromCharCode([80, 81, 82, 83, 84])); // PQRST

The revisited version accepts directly an array and performs the call ceil(codes.length / MAX_LENGTH) times.
Performances impact will be irrelevant while bigger Arrays will be parsed, hopefully, without problems.
If we still have problems we should never forget that userAgents may have a limited amount of available RAM so ... split the task or the operation or stream it.

As Summary

It's not that difficult to apply same concept with whatever function may suffer the apply and number of arguments limits: just define a maximum amount of arguments, in this case 2048, so that the task will be distributed without problems.

because shit happens

When you spend half week of holidays recovering because of a dislocated shoulder, when you come back and spend 1 month recovering after a shoulder surgery, or for any other smaller or bigger shitty situation life could offer us, there is now a customisable way to express our anger: fuckn.es !

100% Embedded HTML5 Application

One project that always fascinated me is py2exe, an utility able to convert whole python applications into a single executable file.
This concept is similar in OS X Applications, where everything is transparently contained in a single file.
I have tried to reproduce a similar concept with this stand alone web page application where the manifest is hilariously the only external dependency, totally superfluous but necessary for mobile devices.
In any case, fuckn.es is a portable, "copy and paste source ready to go", cross platform tiny app, where rather than #! /bin/sh at first line, the user should simply double click it and run within a (modern) browser.
All images, sounds, and obviously CSS, HTML, and JavaScript are included. This surely avoid advantage of self updated web apps but nobody could stop me to implement a simple JSONP call to the website to compare versions:

// current version
var current = "0.0.1";

// update notification example
JSONP("http://fuckn.es/?v=" + current + "&fn", function(latest) {
    if (latest != current) {
        if (confirm(
            "New version " + latest + " available.\nWant to update?"
        )) {
            location.herf = "http://fuckn.es";
        }
    }
});

Mobile Oriented Navigation

While the app works in both Desktop and Mobile browsers, latter are surely more friendly with the implemented navigation / interaction.
The whole app can be managed with touches and gestures:

• touch the body to see the anger in action (one up to three seconds)


• tap one of the top buttons to access internal sections


• swipe sections to change them or tap other sections for faster tab scrolling


• scroll sections if these do not fit on the device screen


• interact with fields by selecting them, no need to explicitly apply changes


• tap again the current opened section to close it and eventually see changes applied

All of this is surely experimental but it was fun to create such mobile friendly interface that is usable through mouse and trackpad as well .... you know, specially on Mac we are getting used to act via gestures and I am pretty sure this website won't be the first one that interact more like an iPad app on bigger screens.

Current and future HTML5 capabilities

fuckn.es tiny app is based on many HTML5 concepts such File API, Audio, more related to the audio element, CSS3, and soon coming Web Storage to make changes persistent. I did not bother myself to make a fully cross browser app since one of these days all major browsers should support these features, including the input with capture microphone, right now usable to customise the audio providing a valid source.

JSONP Based Setup

The whole logic is based in a single fucknes function call, passing an object such:

fucknes({
    color: "#F00",
    background: "#333",
    text: "OMG",
    audio: [
        "base64encodedSource1",
        "base64encodedSource2",
        "base64encodedSourceN"
    ],
    image: {
        "00": "base64encodedImage00",
        "10": "base64encodedImage10",
        "11": "base64encodedImage11",
        "30": "base64encodedImage30",
        "31": "base64encodedImage31",
        "60": "base64encodedImage60",
        "61": "base64encodedImage61"
    }
});

The same concept is used to restore a previous or custom state file via record section and soon I will put an extra input able to JSONP online a custom configuration. Of course this app makes sense if people will start customise and distribute angers all over the net :)

Inline Download

As soon as W3C committed the link download property I have thought: how cool is that, I can create a base64 version of a text or whatever it is and set the filename into the download property ... and this is what I have done. There are no browsers yet compatible with the download property so right now if we create a snapshot of the current configuration we need to "right click" and save as, the result will be a text/plain file directly decoded for us by our browser.
This is the first time I see such technique to avoid big post or redirect to the server in order to download something for the client and as solution it seems pretty damn cool, isn't it?

No Server Code Involved At All

The last cool part is that the whole app can be used within the html file itself, there is no need of the server side and once these apps will be able to run in a trusted mode, same as native apps do, through the FileReader API, the Web SQL Storage or similar, and all next generation JS features, we can truly, and eventually, think of creating native like applications using exactly what we know already: no 3rd parts frameworks or application involved ( phonegap, Qt, appcelerator, etc )

As Summary

This little website has been one of the most stupid and futuristic personal projects I have ever made. It was simply fun from the beginning till the end, the silly represent your anger idea and the everything in one place with no server needed implementation.
It took a little while during my spare time and even this post has been prepared in different moments but eventually I have been able to activate my german PayPal account and the host finally worked as expected after DNS changes ( my fault here, I did it wrong ).
I hope you can at least appreciate the idea and why, have a little laugh or contribute with some customisation.
What's next? It could be face recognition to put anger through our camera snapshots or who knows what else ... stay tuned, and have fun ;)

Random Rant On CSS3 Transitions

Update
Thanks to @gregersrygg for his link and hints, this is a hackish way to solve the problem apparently cross browser and trustable ... still a hack!

// this save one char, how cool is that!
!function(document){
    
    // (C) WebReflection (As It Is) - Mit Style
    
    // we all love function declarations
    function redraw() {
        
        // clientHeight returns 0 if not present in the DOM
        // e.g. document.removeChild(document.documentElement);
        // also some crazy guy may swap runtime the whole HTML element
        // this is why the documentElement should be always discovered
        // and if present, it should be a node of the document
        // In all these cases the returned value is true
        // otherwise what is there cannot really be considered as painted
        
        return !!(document.documentElement || 0).clientHeight;
    }
    
    // ideally an Object.defineProperty
    // unfortunately some engine will complain
    // if used against DOM objects
    document.redraw = redraw;
    
}(document);
// tested with Opera, Firefox, Chrome, WebKit

... at the end of the day, nothing changed about this post because the summary is still that we do not have an official/standard way to do things properly and we need to use hacks to simplify our daily tasks.

---

so here the summary: there is no fucking way to use CSS3 transitions properly!

The Problem

We put everything on the DOM and we let nodes come in and out all the time or we are screwed!
CSS3 transitions are freaking cool and freaking painful at the same time.
The classic scenario is to pollute the whole DOM once or many times with our random appended/inserted HTMLElements.
The goal is to keep the DOM as clean as possible still being able to let things land on the DOM in our desired way.

setImmediate bullshit

Rather than improve the single setTimeout(callback, 0) classic case, the classic hack that supposes to make things work as expected and at the same time the classic timeout rarely stored as integer to clearTimeout later does not scale.
This is the reason vendors/HTML5 people/whoever decided to add another unshimmable function: setImmediate, which supposes to be used the same way "setTimeout with zero delay" is commonly used.
If vendors screw a bit up the same way FireFox did, where somebody pushed in some release a requestAnimationFrame without thinking about the counterpart clearRequestAnimationFrame, setImmediate becomes useless as well as setTimeout 0 is if nobody takes care of clearTimeout or clearImmediate function.

The Problem, Once Again

We appendChild a node with margin-left: -100px, a transition property equal to margin, and we add the className that supposes to put the margin-left: 0.
To solve this we need to appendChild the node then abstractly wait for the browser to paint and after, eventually, set the new class.

var div = document.body.appendChild(
    document.createElement("div")
);
div.style.marginLeft = "-1000px";
// now we want the transition to marginLeft = 0 ... HOW?????

If by CSS3 above div has transition margin monitored, the only way to trigger the transition is to set a random timeout expecting that the browser renders in the meanwhile ... caus if it does not happen, we won't simply see it.

Why It Is So Hard

Unfortunately is most likely Web Developers fault, in the meaning that browsers are doing everything possible to optimize callbacks.
What we think is synchronous is just a matter of asynchronous, impossible to control, redraw actions behind the scene, where of course if we change 3 times classes to the same node browsers just consider last status and that's what they draw.

The Missing API

The more we have illusion of powerful features the more we screw up our architectures and layouts .... there's not much to do here except a bloody synchronous document.redraw() method, something that supposes to tell the engine: hey, I wanna you to consider the current layout so that after I can change it and you can consider these changes.

Will it be too hard for the CPU/GPU? Who cares, I mean, with all uncontrolled and theoretically optimized redraws/repaint operations we have every N milliseconds, how can a developer choice hurt so much?

mozAfterPaint

About Events, the cool part is that we can create them on JavaScript side and dispatch them whenever we want. Now, this paragraph notification is something we cannot fire in a meaningful way but it supposes to tell us ... exactly what? No idea, because the problem is that I do not want to control the status of the DOM via unpredictable setTimeout behavior, I wanna be able to tell the browser that status is OK now, would be so kind to draw the whole fucking thing for me, please?

As Summary

I hate lack of power under the HTML5 is for developers flag, I see setImmediate as a joke that I will be forced to use at some point for who knows which reason, but I still miss the possibility to properly control all these CSS3 transitions power via JavaScript, and once again, messing up between the view, and the controller.

Told'ya it was a rant!

Online Base 64 Converter

Update apparently I am more than late since datauri.com does similar stuff ... oh well, better two options than nothing, right? Thanks @mathias for the update.

---

Right, you may think this is the most useless thing ever but actually embedded content is freaking cool and this is the reason I have created a truly simple page in 3site.eu/base64.

What The Hack Is That

Nothing truly special, you choose a file, you get its representation in base64 compatible with inline data url.

Best Available Option

... is converting data accordingly with your browser: who better than a browser can know how to understand inline data? Chrome or any other HTML5 Enabled Browser should work offline without problems, but if you are masochist and stubborn, it may fallback into server side encoding. Latter case may be dropped as soon as my cheap space in my cheap website will suffer too many requests so ... did I say already use a decent browser?
And that's all folks :)