Announcing AceSeller.com

It's been some time now that I've been working on solving an interesting problem, and I think it's time to start talking about it.

AceSeller.com is a cloud-hosted service that aims to make it real easy for businesses to start selling products on their websites. It is targeted at small and mid-sized businesses that want to start selling online, but don't know how to. It is, from what we've seen, already the simplest to use and cleanest application that does this.

I'm doing this together with Sandeep Shetty and Jinesh Mehta. Between the three of us, we've got a great deal of experience with almost every aspect of running ecommerce sites. We are good friends, have tremendous respect for each other, and share a common passion for technology, simplicity, great user experiences and online businesses. This passion has already started reflecting in AceSeller.

We're working very closely with some businesses who have agreed to use our platform for launching their web-stores, and we are very excited about the great feedback we've been getting. One of these stores has already gone live on the AceSeller platform and is already processing orders, while several more are in the pipeline.

AceSeller is currently not open for sign-ups. We are working fervently on getting the little details right. However, if you want early access to AceSeller, please leave your email address with us, and we'll get back to you as soon as possible.

Our plans with AceSeller are huge. We've barely scratched the surface of what we want to offer, and this post doesn't do justice to even that little bit that we've already accomplished.

The amount of things we've learnt over the last couple of weeks alone is tremendous; I can't wait to start sharing that knowledge. There's so much to talk about - everything from the challenges we've faced in getting businesses online, to the user experience we want to provide, to how our technology choices came about and how we managed to race ahead to get AceSeller live. I'll keep churning out more details as frequently as possible. Stay tuned.

Thoughts On Taking the Entrepreneurship Plunge

tldr; Jump to the bottom ↓

I found myself at a time in my career when I had to look back and reflect, and decide what I want to do next. Remain an employee? Or leave it all and become an entrepreneur. It's hard to make purely logical decisions about these things, in part because your life and well-being might be affected, but mostly because you need to make projections into the future and the future presents itself as a hazy picture at best. A lot of this decision is based on gut feel. This post outlines my thoughts.

Financial aspects

This was obviously the most important thing that I was thinking about. Salaried jobs give you a decent amount of financial stability. This is in sharp contrast to starting up, which has near-zero financial security, at least at the outset.

However, financial growth in a salaried job is not in your control at all. Your salary increments depend on a lot of factors: What is the industry standard paycheck being given out, what's the salary of your peers and bosses, what's the revenue of the company, what's the funding status of the company, etc. Yes, your performance does matter, but even with excellent performance you have an abysmal salary increase every year. What's worse, no boss will ever tell you that your performance has constantly exceeded all set expectations. They'll always find some cop-out; things like: "Your performance has been good, but you should take on more responsibility."

That's an awfully bad deal — the factors that affect my financial growth are not in my control, good performance pays very little, and there are text-book methods to even reduce the payout for excellent performance! I've tried fighting this at all my past jobs, and I've always lost. It's a system designed to make you lose every time.

It's very easy to take this negatively. When you realize that your performance doesn't matter anymore, the quality of your work suffers. You start going to work simply because you are obliged to. You start hating Mondays, and look forward to Fridays.

I am not like that though. More than anything else, I have a strong primal urge to create stuff. I never let my obviously slow and completely-out-of-my-control financial growth affect my quality of work. Fortunately, this kept me in the good books of my bosses and my employers at all times. That makes everything fine, right? It does, except when you stop to think: Where is all this going?, and discover that you don't really know. You realize that if you could instead use your zeal, energy and passion elsewhere where the promise of financial growth is higher, you could maybe make a lot more money for the stuff you are doing.

May be, I should start up.

Of course, the promise of financial growth is just that — a promise. There's a huge possibility that it will not work at all, and I will have failed. But then I realized that if I fail, it'll be of my own doing. It will be my mistake that stalls (or negatively impacts) my financial growth. That's a lot more control than I've been used to! I only need to be able to learn from my mistakes and change what I'm doing wrong quickly enough. I should be very cognizant about what might be mistakes, and reduce possible risks from those mistakes. Easier said than done of course, but at least I would be in control.

Creating something

Let's now talk about that primal urge to create that I mentioned above. It's one of the reasons I work with technology — it's very easy to create things seemingly out of thin air, with very little effort at nearly no cost. It's an awesome feeling when you build something and watch the world use it. This, I now understand, is why programming is argued to be an art — you are always creating. I have that creative urge in me, and I intend to never let go of it. It's the single most important character trait that I will treasure and nurture.

So, how do you create stuff when you are an employee? Turns out, it's nearly impossible. Firstly, there are the business goals of the company, and you have to align personal goals with business goals. For most people, personal goals just means making money. But that's not the case when your biggest passion is to create things. What it means then is that you have to compromise. You end up doing things that might not be fun to do, because the business requires it. Like most other people, this is what I have been doing.

Secondly, on those occasions when you do get to create, you are not in control of the decisions taken. There are several stakeholders in practically anything you do. Their opinions have to be factored in as well. By itself, the idea rocks — creating stuff is a form of collaborative art in some sense. However, in practice it never ends up that way; people's egos, unclear vision, different motivations, etc. get in the way of the quality of the product. You end up creating something that is not as good as it could be.

So, creativity at work practically doesn't exist. As a creative person, how do you deal with this? What I used to do was wait to get back home, and then I'd work on my own little side projects. Most of these projects have never seen the light of day. There have been all kinds of projects I've worked on on the side over the last couple of years: creating protocols, implementing protocol clients, writing some funky server-modules, and building stuff on the bleeding-edge of web tech. These products were meant to be given out for free, and I could've built a business model around it in the future if I wanted to. Actually, it didn't even matter that I didn't get these live; I was happy enough to have satisfied my urge to create. On some days, I have found myself working on my side projects till the wee hours of the morning, getting very little sleep, spending time at work because I had to, only to come back home and continue having fun on my side projects till the morning. It was exhausting, but I enjoyed it because I could finally create.

Starting up

If I could channelize this energy, focus on something that can actually see the light of day, and get it to generate enough revenue for me, I could maybe survive on this. I'll be working just as hard, and will have more fun doing it.

It's an unsettling thought process that's been eating into me for several months now, and I've been meaning to act upon it. I've been discussing this with several people, and there's a lot I've learnt. There are several factors to be considered and risks involved. It hasn't been an easy decision. I would be leaving my cushy job to take on what would be my biggest risk ever. And then I realized something.

Starting up is not a risk at all.

What is the worst that will happen? Even if I fail, I'm only losing my financial security. That's a reasonably easy problem to fix. I could always take loans from friends and family. Or I could secure investment to buy me more time. I'd have to have a revenue model that will start generating money from get-go, and that in itself will reduce the risk significantly. There are several solutions, but the fact remains that it's an easy problem to fix. If all else fails, I'll still be at least as employable as I am right now. I'd end up doing a salaried job like I have been doing, as much as I wouldn't like it.

The worst that will happen is that I'll end up where I am right now. That's hardly a risk!

Last Friday was my last day as an employee. I've never been more anxious and excited. I've finally taken the first steps towards doing what I wanted to always: fully control my financial growth, create what I want the way I want to, and do this at minimal risk of my financial security. At the risk of sounding overly dramatic: last Friday was the first day of the rest of my life.

Watch this space for more announcements coming soon!

The Impact of HTML5^H: Feature Detection

Ian Hickson posted a day or two ago that the WhatWG has decided to drop the version number from HTML. On the face of it, it seems like a knee jerk reaction to fight an old rival that just announced the HTML5 logo, but it's a lot more than that. In Hixie's words:

The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.

What does this mean for us developers? It means that the spec will never be finished — the living standard bit — so there's no point waiting for an announcement saying that HTML5 is ready or anything to that effect. But that's just on the surface.

For front-end developers it means one more very important thing. It means that feature detection is more important than ever before. It'll be the only reliable way for us to determine browser support for features. Of course, we always knew that but rarely did we ever practice it. You think you might have, but the libraries you have been using didn't actually do this. Until very recently that is. jQuery removed all browser sniffing in jQuery 1.3 and the guys from Dojo have launched a project called has.js meant for library authors to incorporate feature detection. Of course, Modernizr has been around for a long time now, and its list of detectable features keeps growing.

But detecting features alone isn't enough. You need a way to work around them. This is where polyfills come in the picture. As Remy Sharp describes it,

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.

That way, feature detection happens at a lower level than the developer, and the developer can continue coding to the WhatWG/W3C specs. If this works as well as it says on the can, I think we can all move forward, and not worry about little pains like IE6.

What are the factors to be considered when creating a way to download a polyfill? The first is that there has to be a way to declare a dependency on a browser feature. Depending on browser feature detection, one or more polyfills might be downloaded for that browser. Secondly, the download of the polyfill will necessarily be asynchronous and the coding paradigm will have to take that into account. Thirdly, ideally the download of the polyfill itself shouldn't slow down the experience. This is impossible to do, but at least we should employ whatever techniques we have to reduce the impact of the download.

How would such an API look? CommonJS has been doing some great work with the Asynchronous Module Definition spec to help solve the general problem of dependencies in JavaScript. Maybe we can look at their API for help. To define a module, you'd generally write code that looks like the following (from their own example):

define("alpha", ["require", "exports", "beta"], function (require, exports, beta) {
    exports.verb = function() {
        return beta.verb();
    }
});

That looks simple enough. The first parameter of define is the name of the module, the second is a list of external dependencies that the module has, and finally it's the declaration of the module itself. Using RequireJS, the way to use such a module would be, (again, from their own examples)

require(["helper/util"], function() {
    //This function is called when scripts/helper/util.js is loaded.
});

That's a simple enough API. Unfortunately, we can't use this directly for our polyfills, since we'll need to only download the dependencies if the browser doesn't already support them. So, maybe for our purposes, we'll need to have an API that looks like this:

require(["our/polyfill/helper"], function() {
    requirePolyfills(["localStorage", "geolocation"], function() {
        // Polyfills have been downloaded and applied now if necessary.
        // We can code straight to the WhatWG/W3C APIs without worrying about browser differences.
    });
})

The requirePolyfills function is responsible for downloading the polyfills necessary depending on browser support in an async manner, and then calling the function passed in to hand over control to the developer. The developer then doesn't have to worry about browser differences and can write simple code completely devoid of browser specific hacks. It gets me excited just to think of how awesome it will be to program once we've got browser differences out of the way.

Taking this a level further, this could be done by library authors itself, to ensure that the footprint of the library is as small as possible. This way Chrome users will have an excellent experience since there's no polyfill to be downloaded, while IE6 users will have the worst experience since many polyfills will have to be downloaded. If you think that's worse than the state of affairs today, consider that Chrome users currently have to download all the browser hacks for dealing with IE6 that exist in the library, and then the code-path never hits them. Wasted download, and the worst possible experience for all users thanks to IE6.

Libraries are slowly migrating towards the CommonJS AMD spec. Dojo just announced partial support for it in their latest version. The landscape is bound to get better. If polyfills were to be part of the library itself, it would be awesome. That way, we ensure that the library has the smallest footprint possible.

That leaves us with two more problems. First: we need to develop a public repo of polyfills that are very well tested. The quality of polyfills is not something that library developers should be fighting over. Also, there's no reason for a polyfill to be tied into a library's APIs. And there's no reason why one shouldn't be able to use a polyfill without a library. The second problem is slightly more tricky. The problem is that of network latency. You wouldn't want to download a bunch of polyfills over slow network connections. Ideally, it should be just one file containing all the polyfills required for that browser. This might necessitate a change the API I've mentioned above. Feature detection obviously happens on the client, but then the client issues only one request for the polyfills file. The request could look something like: http://example.com/polyfills?include=localStorage,geolocation. The server basically just concats the polyfills the client has requested, and sends them down in one file. Awesome.

Unfortunately here I've added a server component which suddenly makes this far less appealing to library authors, and for good reason. I don't know of a clean way to fix this, except saying that there should be publicly maintained servers that do this for everyone. Something like Google's CDN. This solution isn't ideal for several reasons, but it might be a good stop gap. Of course, there's also the possibility that open source implementations of such polyfill servers can be developed for several languages, maybe even just web servers — I'm thinking mod_polyfill or something similar.

The best solution is not clear yet, but we have an idea of what it might look like. We'll have to see how things evolve in the coming few months to get clarity on this. Meanwhile, what do you think about this? Do you think there might be a better way to solve this problem?