Twitter launches a new web app

Targeted at those with low spec phones, Twitter today launched Twitter Lite, a product build on a modern suite of technologies that should be ring a bell with most front-enders today.

The new Twitter frontend is built using React (nb. made by Facebook), Redux, Normalizr, Globalize, Babel, Webpack, Jest, WebdriverIO, and Yarn (they have written about how they built it.

It is a good thing to see a large company not giving up on the open web. I’ve added the new Twitter Lite app to my phone (running iOS) and see if it can replace the native app (as I did with Facebook before). My first impression is pretty good. Most importantly, as promised: it loads faster, even without support for ServiceWorkers (while iOS 1.0 only allowed for web apps, its level of support is kind of bleak when compared to the efforts made by Google and Firefox). It could use some animation …

Must do speed optimalizations on nginx

Nginx's default configuration needs a bit of extra configuration (at least on Debian systems) to enable gzip and client side caching. Two very quick wins for better performing web-apps.

Enabling gzip for more content types

Compression makes files smaller. By default only HTML is gzipped, but it it makes sense for quite a list of other file types too. This, however, excludes(!) images, which have their own methods of compression: compression over compression delivers you nothing, and costs you and your end-user a few more CPU cycles.

So find the gzip on; line in /etc/nginx/nginx.conf file (make sure it is not turned off or commented), and either uncomment the gzip_types-line or use this, more complete, line (including svg):

gzip_types image/svg+xml text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Client side caching

Every browser has a cache of its own, …

Learning from failures: off-line support in a rails-app

As a web-developer you typically assume that your users are always using your app on-line. When asked a year ago to start developing an app for the art-consulting firm QKunst I was, however, specifically asked for a tool that had to work in bunkers. Bunkers where having a solid internet connection was typically the exception. No problem, I read about HTML5 and offline app-cache: I thought I could fix that. More about that soon.

How I face a challenge

When faced a (technical) challenge I typically search for the easiest way out: what would be the slightest change I’d have to make to my battle tested set-up to accommodate for the new challenging feature. In my case this battle tested set-up starts of with the Ruby on Rails stack, which builds on techniques that align well with how I believe the web should work too. RESTful (proper HTTP-messaging and URLs), semantic, CURL-able. And all graceful…

Ruby on Rails is fast

Of course, this title is obviously too blunt. Still, when I see applications being developed on supposedly fast languages such as Java that perform terribly slow it makes me wonder.

Today I had to fix an issue with the slowness of an overview page inside a product I wrote using Rails. I don't like pagination (it's a workaround), but I wasn't expecting pages with over 700 items. The page with items stored in a traditional database was performing somewhat slow: it took about 6 seconds to load. The fix however took me less than half an hour (including searching the docs) from idea to execution and deployment on production (writing this post took me longer):

  old view code to render the item

Passing the item itself to the cache ensures that the cache gets invalidated when the item is updated. The page load it is still kinda heavy, with 500ms of load time, but this is acceptable for its size.

Features like this make Rails not only a super fast way to realise…

Still waiting for pipe-lining to become mainstream

Sometimes I get a bit upset about a state a project I get to work on is in. Recently I came across a project which frontend served over 30 files that could be reduced easily to about 10. I got upset because to me it is like one of the basic things you have to be aware of as a web developer. I told the others working on the project that is a problem that should be fixed, to optimize speed. But later that day, in bed, I started wondering because the pages were served using HTTPS: was I actually correctin stating it as a problem? Well, currently still yes.

I started wondering because I remembered something about 'pipe-lining'. A year ago I turned on the experimental SPDY protocol a year ago, which supports asynchronous pipe-lining. Pipe-lining allows browsers to request all files in one request, which diminishes the reason why a developer should try to reduce the numbers of file…

Geen bug maar een foutje

Deze week probeerde ik een bug (een foutje) uit te leggen aan een van mijn klanten:

> “Het probleem is opgelost. Omdat ik weet dat je het op prijs stelt om te weten hoe het zit zal ik het uitleggen: > Om de gegevensuitvraag te versnellen hebben we 2 verschillende caches, dit zo gegroeid, een tijdelijke en een langdurige. De fout zat ‘m in het feit dat de langdurige cache niet werd bijgewerkt omdat de tijdelijke cache aangaf dat er niets veranderd was, terwijl in het echt wel iets veranderd was. De langdurige cache, waarvan we gebruik maken tijdens het sorteren werd dus niet bijgewerkt. Aangezien de kortdurende cache eigenlijk overbodig is geworden toen we de langdurige hebben gebouwd, heb ik deze er tussenuitgehaald.”

‘Verrassend’ genoeg kwam dat niet over. Toen hetzelfde verhaaltje opnieuw getypt, maar dan met net iets andere acteurs:

> “Het probleem is opgelost. Omdat ik weet dat je het op prijs stelt om te weten hoe het zit zal ik het uitleggen. > Omdat Jan nogal tra…