Erik Osterman

On Hacker News today there was a mention of how LinkedIn is using the Dust.js templating system. Dust.js is doing what XSLT always promised to do but never delivered on.

In the post, they make a pretty compelling argument for why to use client-side templating. Their problems are all similar to the ones I’ve seen countless times — anywhere a services based architecture is employed like at TV.com.

At LinkedIn they have a services based architecture with applications written in a slew of frameworks across multiple languages. Because of this, it’s hard to re-use visual components. Requiring that all components be written in the same language reduces productivity of developers and hinders their ability to rapidly prototype new features, but having the templates reimplemented in each language makes maintenance a chore. What LinkedIn settled on doing was to only require applications to produce JSON responses (light weight and efficient to render) and rely on client-side (browser) rendering to transform the layout templates with JavaScript. This puts the expensive cost of rendering on the browser (totally scalable), and allows for LinkedIn to cache the layout on CDNs to accelerate their delivery (in addition to the CSS, Images, JS, etc.)

Some might argue that well written HTML+CSS is essentially the same thing. It’s not. First, HTML is verbose; the amount of data needed to even express a simple document far exceeds that of JSON because it includes layout information. Then generating the HTML is an expensive operation on the server involving parsing some source templates in (ERB, JSP, Jinja, Smarty, etc) and assembling them in a string object with lots of concatenation. Lastly, no matter how “light” you make the HTML, you’re still mixing layout with data so you can’t statically cache the layout on a CDN without using ESI (fancy XSLT).

Compare this to simply requiring apps to produce JSON responses. JSON is lightweight and efficient to generate. Most scripted languages have native bindings to libjson so that rendering is done in C.

Lastly, if the thought of templating done entirely in the browser is not appealing (perhaps for SEO reasons), there’s always Node.js which can sit in between; however, this negates the CDN-effect for template caching and puts the computational onus back into your datacenter / cloud.

I’m not a “frontend” guy, so maybe that’s why this immediately appeals to me. I’m curious what frontend developers think about this approach?

I forgot what it’s like when packages just don’t install. Remember, the days of RH6, where you’d have to spend a day tracking down all the dependencies only to discover that some tiny POS package prevented the whole install. That’s kind’a how Fedora is today. In fact, I don’t notice any improvements over the old Redhat package management system. Yum runs about the same speed as it did on my 486; quite a remarkable task given that the processing power on my new system is equivalent to a small server farm of 486 units. How can they make something so slow? Having used Debian for the last few years, I feel entirely spoiled.

I’ve been an avid Thunderbird user for sometime. One of the biggest draws was its Bayesian JMC. It works for the most part, but hasn’t stood its ground against the constantly evolving spammers. Stock/Image spam being the most effective at escaping detection. I’d say about 5% of spam get’s through. If you take that as a part of the 1000 daily spam emails I get, it’s significant. 50 spams is like what we used to get in ’97 without filters… and that was annoying!

Thus, I’ve decided that I can’t be bothered any more by the constant email notifications of new spam! This whole class of problems has virtually disappeared for me by creating a simple filter that checks if the sender is in one of my address books. I keep one for automated emails (like those from eBay or mailing lists) and one for personal contacts. Any mail that’s not in one of these lists and isn’t already flagged as spam get’s shoved into a “Unknown Senders” folder that I can check periodically. Since most of my good email comes from known sources, this wins out over the Bayesian filtering.

This is nothing new. The solution has been around for about as long as spam has been. And I still love the JMC in TB. I didn’t disable them; infact, I still keep training them with those emails that end up in “Unknown Senders”. The benefit is now I it’s just easier to flag them as spam and I can do it once a week instead of once an hour.

Beware: Visibility works on a per class basis and does not prevent instances of the same class from accessing each others protected/private properties/members! I consider this a real cop out from an OO perspective and doesn’t offer me any level comfort.

In the Highway section of the LA Times today, there was a nice expose of the new Porsche Turbo. The author had some nice smack talk to laydown on regarding Lambos.

“Look, I’m not saying the Gallardo doesn’t have its uses. If I were a teenage millionaire and I needed a smooth surface from which to blow rails, the Gallardo’s hood is first choice”

http://www.latimes.com/classified/automotive/highway1/la-hy-neil16aug16,0,327997.story?coll=la-home-headlines