An Uphill Battle
by Tom Dale
Where is the web’s Loren Brichter?1 Why does it take big teams, big budgets, and long timelines to deliver web apps that have functionality and UI that approaches that of an iPhone app put together by one or two people?
If you’re a developer who is obsessive about building a quality user experience, you are most likely to create an iOS application. One reason is that Cocoa is able to operate at a higher level of abstraction than raw web primitives. It means that iOS developers can think more about how their UI or features should work, instead of how they should be implemented. The human brain is like a buffer: at a certain point, every new concept pushes something else off the other end. For web developers, buffer overflow is common as they grapple with cross-browser bugs or APIs that are openly design-by-committee.
The web needs better abstractions. There are, however, only a limited number of abstractions you can implement in under 5k of code. I’m sensitive to cultivating an attitude in the community that the only valuable problems worth solving are those that can be done under 5k (or 10k, or 20k, or…). I will take my share of the blame, and admit that many frameworks that tried to take on large problems ended up out-of-touch and crufty.
The web won’t have a singular answer, and that’s fine. But we have to avoid fostering a culture where people are afraid to tackle hard problems because they’ll be seen as architecture astronauts. We shouldn’t let the mistakes of the past make us timid about learning and moving forward.
***
Yesterday on Twitter, I posted:
Just wanted to point out that Backbone is still listed on microjs.com, even though it’s >5k if you count dependencies.
Which is fine; let’s just be upfront about the fact that microjs.com is more akin to the cool kids table than a useful directory.
In retrospect, this came off crankier than I intended. Several people contacted me privately (and publicly!) and weren’t sure why I was making a stink over something that, to them, seemed trivial. And while in the scheme of things it is trivial, I think this arbitrary line in the sand we as a community have drawn is harmful to the future of the web.
I want the web to win. Everywhere.
So I want people to be aware of the abstractions we’re giving up to hit our 5k target. If some things get included that are over 5k, and other things get rejected that are under the 5k limit, it sends a very mixed message to new developers about what is possible. If we’re going to emphasize small codebases, let’s be honest about the limitations that entails.
If we don’t get our act together soon, proprietary platforms are going to become entrenched. Every new device that comes out is an opportunity that is ours to lose. The community has to figure out how we educate and recruit developers into the web fold. People will disagree with me about the best way to accomplish the task, and that’s great. But I’d like to compete on things like developer productivity and finished products, not insinuation that anything over a certain size is inherently unsuitable for the web.
It’s human nature that once we start assigning labels to things, we think about which side of the label we’re on. I think that positioning microlibraries as a separate “thing” is a bad idea. There are just tools that fall on different sides of the size spectrum.
Writing efficient code is important. But when we decide that certain web abstractions are a bridge too far, we’re actively discouraging precisely the developers that we need the most. When the next Loren Brichter comes along, I want to be able to say he or she is a web developer.
Thanks to Majd Taby and Yehuda Katz for reviewing this post. I tweet as @tomdale if you’d like more timely updates.
- Loren Brichter’s company, atebits, created both Tweetie for Mac and Tweetie for iOS, which were acquired by Twitter. [↩]
First of all: the basis of your argument is that writing iOS apps is more efficient than web apps? I beg to differ. If on average iOS apps are created by fewer people than web apps, I suspect that this has more to do with the scope of the apps than anything else. But this is just guesswork, and your claim (if I’m reading you right) should be substantiated. The fact that many popular iOS apps were written by few people says very little about the situation.
I also think that both you and Yehuda are making way to much out of the microjs site. Come on, it’s a list of small libraries for people who like that sort of stuff. I have yet to see people start fleeing away from e.g. jQuery because of it, and it’s certainly not an assault on SproutCore. It’s an alternative for programmers who are discontent with the “all you need bundle”.
Also, I have not seen anyone arguing that “certain web abstractions are a bridge too far”. The way I see this is that not everyone enjoy big frameworks that take control over many aspects of development, and want finer grained control over their apps. These people created tools that suit them better, again, as an alternative. Judging by the amount of people cheering for this work, I’d say they’re providing a much sought after alternative.
Providing tools that aren’t largish “all in one” frameworks is not making the web “loose” to native. I also do not agree that it is the size of the framework/libraries that decide whether or not a small team can be successful in creating applications. To counter your “Loren Brichter argument”; many popular services on the web today were initially created by small teams; Twitter, Facebook, YouTube are three examples. Hell, even Google started out small.
Let me clarify one thing. Sure, people have argued that “certain web abstractions are a bridge too far”. What I meant was that I have not seen anyone state this as a universal truth that should apply to everybody. People who make this argument – as far as I have seen – make it for themselves.
Hey Christian,
Thanks for your comments. Certainly everyone is welcome to choose the tools that work best for them; I wouldn’t have it any other way.
I have noticed (and granted, it may just be my perception!) that there has been a vocal movement towards using solely micro-libraries. As I stated above, I don’t think the distinction is a good one to make; but more importantly, I wanted to be a voice of dissent, saying it’s okay if larger libraries work better for you. Again, it’s not about right or wrong; it’s about saying it’s okay to pick the right tool for the job.
Thanks again for the feedback!