Safari kicks ass, again

Sometimes, while at home, I really miss working so I bring work to home . So, this time was the turn of a cross-browser JavaScript madness, the problem manifests like this:

There's a grid, big one, in which each cell has 3 image/buttons, each image has 2 states and they are exclusive, as in Low, Med, Hi, get the picture? Well, when the grid gets big (my HTML file right now has about 20.000 lines) performance goes down a lot, that means that when a user clicks a button the state change takes a noticeable second to happen, in IE 6 and 7.

I didn't code that so I had no idea of what was causing the problem so I asked the guys working in that project to email me a static version of the page so that I had something to fill my evening with .

Besides the JavaScript in that page is painfully awful (I'm sorry guys, I had to say it) I managed to isolate the piece of code that was causing trouble. Many of you geeks might already be blaming some obscure for(;;) over every single element, or a diabolic recursion; well my friends this is not the case, or at least the for(;;) is not where you think it is, read on.

The offending code was merely a dozen of document.getElementById() calls. But wait, think about it, getElementById in 20.000 lines worth of elements, that's something we should handle more efficiently, well yes and no. Yes, you should narrow your element "universe" and work with subsets as much as you can, and also use CSS selectors to get your target. And No because the browser's engine could do us the favor of optimising it, can't it? That seems to be the case for Safari, whose performance is not affected *at all* by this experiment, and remains as snappy as always. Next in the podium is Firefox, whose performance degrades slightly, regarding the button state change, but fails terribly at the very beginning when it almost hangs up while loading the page. At the bottom of the podium (if any) there's IE6 which fails in every single aspect, and degrades much more with a much lesser number of elements.

Very well then, what have we learned with this? You have to code well, don't trust the browser's engine too much, Firefox is really good but it still has some issues and that IE6 sucks at rendering web pages and executing javascript code.

I just wanted to share my findings on this noble area of knowledge. Your comments are more than welcome.

Oh god, I really need a pint right now, make it a brown ale please.

Hack me babe! I implement Hackeable

Recién tuve que escupir un mail tratando de convencer a alguien de que _no use_ EJB, acá va:

Hi guys,

I'd like to take the conversation one step further and give you my opinion on "why I think we should go REST". Exchanging information online among apps is all about exchanging bits over a socket. The ways I've done this before are EJB, some sort of RPC implementation (i.e. spring rpc), WebServices (Axis) and simple custom HTTP calls. With the advent of "Web 2.0" completely different websites (apps) need to communicate with each other, besides screen scraping (for non-cooperative external apps), simple HTTP calls are great. Why should I have to implement a whole set of things just to get simple info from another app? As happens with EJB and WebServices (to a lesser extent), and that what happens with *ClientName* apps most of the time. Also, as we are using Javascript and JSON extensively we can leverage that knowledge to use JSON as a transport and not XML, which is waaaay better for these matters.

For the particular case Sofía mentions, a couple of cooperative servlets in each app would do for now. In the big picture, IHMO we should think in terms of exporting all the functionalities in, say *AppA*, as simple REST services that any other app can use with simple HTTP calls. We've already done this in a way with *AppB*, you can go an talk JSON to it through the Jabsorb bridge.

Well, this is a long email, we can discuss the topic further over the phone if you want.

Cheers,
Juan 

La idea que quiero transmitir en realidad, más allá de si se implementa REST, RPC o whatever, es la de hacer una aplicación hackeable o hacker friendly. Cuando estás codeando esa fina capa de aplicación/servicios está bueno pensar en cómo vas a proveer esos servicios a todo el resto del mundo, que nadie piense siquiera en hacerte screen scraping, un buen ejemplo son los WebServices de Amazon. La sigo en otro post porque ahí viene el próximo entrevistado.

Este JAR te salva la vida... XHTMLRenderer

Hace mucho tiempo estaba perdido y desesperado, ya nada importaba en mi vida, hasta que conocí este proyecto: https://xhtmlrenderer.dev.java.net/

Bueno, en serio, es un motor de rendering de XHMTL + CSS, que anda MUY bien, de hecho mejor que cualquier navegador que tengan a mano. Para qué sirve? Bueno, yo tenía este problema: Una página generada dinámicamente que tenía que mandar a imprimir y/o a PDF. Para hacer esto normalmente uno tendría que romperse la cabeza codeando el PDF hasta que quede igual a lo que se muestra en la página. O bien, usar su motor de rendering amigo y alimentarlo directamente al generador de PDF.

El resultado? simplemente fantástico, a priori no tenía muchas esperanzas, teniendo en cuenta la disparidad de los motores de los navegadores, pero mientras uno respete XHTML y CSS, anda ferpecto.

Que lo disfruten...

PD: No se asusten por el beta. Ah, y está pensado originalmente para embeber contenido html en aplicaciones de escritorio.

!!""==false

Dijo el gran filósofo contemporáneo César D.:

Not not string vacío es una buena forma de castear un string a boolean.

Tiny bit of corporative marketing

I'm not a big fan of corporative marketing and we all know the company I work for is really into it.

That being said, I thought this might me an interesting event, Google and the major social networks are behind this and I'm pretty sure they'll be able to gather interesting people.

So, here's the link: OpenSocial Hackathon

I don't know if I'll be able to go though.

Cheers!