Thomas Fuchs
Hi, I'm Thomas Fuchs. I'm the author of Zepto.js, of, and I'm a Ruby on Rails core alumnus. With Amy Hoy I'm building cheerful software, like Freckle Time Tracking and Every Time Zone and write books like
   Want me to speak at your conference? Contact me!

What do you need to make a successful web app?

April 13th, 2014

Here’s some things you need to make a successful web app:

  • A plan to make an application that helps real people to make their lives easier, solving a well-researched problem
  • Understand human psychology
  • Know how to design, both in terms of UX flow and visual design
  • A marketing plan, to tell potential customers that your app solves their problem
  • A text editor
  • A web server
  • Probably some sort of database
  • A payment processor of sorts
  • Good security (including well-tested backups) from the start
  • A (at least basic) understanding of tax laws in your country
  • A healthy dose of perseverance

And here’s some things you don’t need:

  • The latest alpha of hype.js
  • CSS frameworks
  • Boilerplates
  • reset.css
  • JavaScript loaders
  • The newest NoNoNoSQL database
  • Distributed anything
  • That cool new jQuery plugin
  • A custom-designed font
  • Multiple load-balanced “webscale” servers

All these things create the illusion of making things easier when in reality they create very complex dependencies and will be very hard to remove later if they don’t turn out to be the silver bullets they promise to be. This doesn’t mean these things are bad or evil. You may want some of them later, when your app grows.

Remember, keep it simple and don’t over-engineer. Solve the problems at hand, and don’t anticipate “potential” problems.

You need to wear many hats when setting out to make a successful web application: entrepreneur, psychologist, designer, programmer, marketer, accountant—but you’re not a fortune teller.

Heartbleed exploit tl;dr

April 8th, 2014

OpenSSL had a bug for several years which allowed attackers to untraceably read all your SSL traffic and some server memory.

If you’re like me and have better things to do than reinvent the fix-wheel and you’re all like “WTFBBQ TL;DR” here’s the absolute minimum what anyone who runs a web server with SSL must do.


  • Update OpenSSL to 1.0.1g. This is required before you do anything else.
  • Recompile anything that’s statically linked against OpenSSL. In many instances, web server software like Nginx is statically linked and must be recompiled. For example, if your Ruby is statically linked to OpenSSL, it’s recompile time!
  • Reboot the server. This must be done before issuing new certificates.
  • Create a new private key and CSR and get a new SSL certificate. You will need to revoke the old SSL certificate. (If you’re on Godaddy, use their “rekey” function. The old cert will be revoked automatically after 72 hours). Don’t forget to install your new cert.
  • Change any server passwords. These may have been read by an attacker as they are in server memory. It’s not a bad idea to issue new server SSH hostkeys as well.
  • Change any and all passwords and tokens of APIs you use. As server memory may have been compromised, an attacker could access the APIs as if they where you. Not good.
  • If you’re using cookie-based sessions in Rails (or similar environments) you must switch to a new encryption secret. Your current secret may have been compromised, allowing attackers to log in as anyone to your service. Unfortunately this means all your users will have to log in again.
  • Ask your users to change their passwords. As this security issue means that server memory may have been compromised as well as past traffic could be decrypted, passwords should be considered to be compromised.


There’s an optional step, which I highly recommend while you’re at it—get your SSL configuration into shape and enable PFS and HSTS (and test it!). It just takes a minute if you’re on Nginx.

If you have anything to add, please email me directly and I’ll update this post.

How to get an A+ on the Qualsys SSL Labs test

April 4th, 2014

Recently we upgraded our server infrastructure for Freckle Time Tracking and in the process wanted to improve how we serve SSL.

If you don’t know much about this, it’s fine—there’s a few simple steps you can take to make your website more secure and faster loading in the process. _Important: of course, there’s no absolute security, and I make no claim that what I describe here is secure and will work for you. Use it at your own risk._

Long story short, you’ll want to get an A+ rating on the Qualsys SSL Labs test.

For that you’ll need to do the following:

  • Don’t support older protocols. A lot of servers support really old and obsolete protocols. If you run a web app, your users will very likely not need support for these.
  • Don’t support flawed SSL ciphers. There’s a bunch of these and you can avoid using them. Browsers support multiple different ciphers, so this is not a problem.
  • Cache SSL sessions. This will improve performance.
  • Turn on HTTP Strict Transport Security (HSTS). This is a special header that will tell browsers to never connect to the server via normal HTTP.

And that’s it. In order so you don’t need to research the proper settings, here’s how this looks like in form of an nginx configuration:

server {
  # deferred allows for faster connections if there's
  # no other servers on port 443 defined
  listen 443 ssl spdy deferred;

  ssl on;
  ssl_certificate /etc/nginx/your-certificate.crt;
  ssl_certificate_key /etc/nginx/your-private-key.key;

  ssl_prefer_server_ciphers on;
  ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_stapling on;

  # tell any upstream things like unicorns that we're on https
  proxy_set_header X-Forwarded-Proto 'https';
  underscores_in_headers on;

  location / {
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
    # ...

  # ...

And that’s it. Have fun with your new A+ rating on the SSL labs test.

Our Internet

March 30th, 2014

Our Internet isn’t big corporations doing whatever they want. Our Internet is not DRM, is not SOPA and not PIPA and not the spying on us (and everyone else). Our Internet isn’t bigots taking away human rights from people. Our Internet isn’t hiding behind PR releases.

Our Internet isn’t greed, narcissism, fear and blind hate.

Our Internet is people helping each other be excellent. It’s sharing, caring and being proud of what we humans can do if we only put our will to it. It’s about helping the unprivileged when governments fail. Our Internet is about standing up to your mistakes.

Our Internet is about love and empathy.

The only thing we have is each other.

That is all.

Scrolling DOM elements to the top, a Zepto plugin

January 19th, 2014

There’s bunches of plugins, extensions and techniques to smoothly scroll page elements, but most of them are convoluted messes and probably do more than you need. I like “small and works well”, and it’s a good exercise for those JavaScript and DOM muscles to write a small plugin from time to time.

My goal was to have an animated “scroll to top” for the mobile version of Freckle—normally the browser would take care of that (tap status bar to scroll to top), but in a more complex layout the built-in mechanisms for this quickly fail and you’ll have to implement some of the interactions users expect (like tap status bar to scroll to top) yourself. Specifically, this is for the native app wrapper (Cordova) I use for Freckle’s upcoming mobile app. It’s hooked up so that taps on the statusbar invoke a JavaScript method.

During development of this I needed the same thing for arbitrary scroll positions as well, so “scrolltotop” is a bit of a misnomer now. Anyway, here’s the annotated code:

Often, writing your own specialized plug-in is faster than trying to understand and configure existing code. If you do, share it! :)

Let it snow with Zepto—again!

December 24th, 2013

Updated with the latest and greatest Zepto.js… Let it snow!

If you’re interested how this works, grab the source. Except for Zepto.js (built with detect & fx support) there’s no external dependencies (not counting the Twitter and analytics).

Happy Holidays!

P.S. Because it was so popular, I’ve started another flash sale of my ebook Retinafy your web sites and app—use coupon “hiresholidays” for 15% off, but only on December 24th and 25th!

Happy High-Resolution Holidays!

December 6th, 2013

This holiday season, delight your users with pixel-perfect deliciously retinafied web sites and apps—my book Retinafy your web sites and apps is ON SALE, but just this weekend (December 6 through 8).


Use coupon code highresholidays on checkout for $15 off the regular price! :)

Get it for yourself or a beloved designer or developer!

Zepto 1.1: Moar performance, IE 10+, Deferreds

December 5th, 2013

Mislav and I just released Zepto 1.1, which brings updates across the board. Even if you don’t need to new features, upgrading is worth it for “free” IE 10 support (which makes mobile sites work great on Windows Phone 8) as well as the huge performance speedups for common operations (benchmarks).

Screen Shot 2013-12-05 at 10.09.35 AM

Notable changes

  • IE10+ support
  • Huge speed optimizations for simple CSS selectors (classname, ID) and DOM element creation
  • Provide $.Callbacks and $.Deferred in optional modules
  • Removed fx and detect modules from default build


  • New supported $.ajax() options:
    • xhrFields
    • mimeType
    • jsonpCallback
    • username & password
  • Promise interface supported when loading the optional “callbacks” and “deferred” modules:
    • xhr.done(function(data, status, xhr){ ... })
    •, errorType, error){ ... })
    • xhr.always(function(){ ... })
  • Enable mutating Ajax settings in the beforeSend callback
  • Fix JSONP callbacks for errored responses on Android
  • Ensure consistent Accept request HTTP header across browsers
  • Fix $.param() for jQuery compatibility when handling complex nested objects
  • Support IIS JavaScript MIME type
  • Pass “abort” and “timeout” status to global ajaxError event handlers


  • Provide isDefaultPrevented(), stopImmediatePropagation(), and related methods for all events
  • Support the data argument in .bind(), .on(), and .one()
  • Support CSS selector argument in .one() for event delegation
  • Support .on('ready') as an alias for .ready()
  • Enable event handlers on plain old JS objects
  • Many fixes related to event delegation


  • Cleanup .data() values on DOM element removal with .remove/empty()
  • .data() now assumes that numbers that begin with zeroes are strings
  • .removeData() (no argument) now removes all data on the element
  • Enable reading data-* attributes that have underscores in the name

Other updates

  • Support simple DOM property names in .prop(name) such as for, class, readonly
  • Implement the .scrollLeft([value]) method
  • Support setting .scrollTop(value)
  • Fix $(document).width/height()
  • Support fetching multiple CSS values via array in .css(['prop1', 'prop2', ...])
  • Support setting CSS transition delay via delay option for .animate()
  • Ensure that .animate() callback always fires

All in all, our most bestest release yet. A big thank-you to all our contributors for making this awesome! :)

10 reasons why it’s good for you not to be a dick in open source projects

December 3rd, 2013

1. You’re more likely to get what you want.
2. You’re more likely to get what you want.
3. You’re more likely to get what you want.
4. You’re more likely to get what you want.
5. You’re more likely to get what you want.
6. You’re more likely to get what you want.
7. You’re more likely to get what you want.
8. You’re more likely to get what you want.
9. You’re more likely to get what you want.
10. You’re more likely to get what you want.

5 things I’ve learned in 5 years of running a SaaS

November 27th, 2013


Photo Credit: Will Clayton cc

Freckle Time Tracking is turning five on December 1. In 5 years of being a co-founder of Freckle I’ve learned a lot of things, but here are 5 important takeaways. Maybe it helps you on your path to product nirvana:

1. You’re not a “tech company”—you’re a “make customers awesome” company
People don’t pay you because you have amazing programming skills and can write nginx configurations blindfolded. People pay you money because the product you sell to them saves them time, money, effort and nerves. It’s your job to make your customer more awesome. Every decision you make for your product and business should revolve around that.

2. Never promise dates for a feature launch
Just don’t promise launch dates for a feature. Ever. Trust me on this. People will ask you all the time when “feature X” is ready. A good way to answer that question is (if you plan on doing it), “We’re considering this feature for a future version. I can’t give you a date on when it will be ready.”. Just be honest to your customers—you don’t know yourself if and when a feature will really be ready.

3. Spend money on things that help you stay productive
This includes obvious stuff like a laptop that doesn’t suck (upgrade often), a good working chair and desk, and less obvious things like software that allows you to concentrate on developing your application’s features rather than configuring servers.

4. Do not work too much
Overworking yourself is the first step to failure in business. You can’t do your best if you’re permanently stressed out. Don’t check email in the evenings. If you’re only 1 or 2 people, don’t provide 24/7 support. It’s ok. Customers understand. It helps to not have a mission-critical product (if Time Tracking goes down it’s annoying but people can take a note on paper).

You didn’t start a company to die of exhaustion. Your health, family and social life is more important than 5 minute support response times and a 100% uptime guarantee.

By the way, one way to keep on top of this is to keep track on how you spend your time.

5. Don’t believe the hype
People are good at getting excited. And people are good at believing the hype™ about new technologies, frameworks, programming languages and ways to deploy. People will tell you what to do and what to plan for. That you need to scale to millions of users, and you’re doomed if you don’t plan for that. That generating HTML on the server is so 1994. That node.js will cure cancer.

The fact is that you need to be pragmatic—your goal is to run a business. Use technology that is proven (to you), and that you know how to work with. My “litmus test” for technology is if the people that provide it are in a similar situation as you are: having to rely on it to run their own business (this quickly weeds out cool-but-academic-only stuff). You need to optimize for shipping. That includes writing less code, having broad test coverage, and concentrate on getting things out in order of long-term profitability for your business.

Good luck with your business! :)