Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Archive for the ‘Personal’ Category

“The Bar for Success in Our Industry” — A Quibble

I read The bar for success in our industry is too low with interest. I generally like and agree with the argument that as an entrepreneur, people should build businesses around sustainable practices that involve actually making money in the short-term. The fact that the advice comes from a successful business like 37 Signals, which has actually made sustainable, long-term money, makes it further credible.

I also agree that the analysis of Evernote as a “success” on the basis of projected income earned incrementally (a month at a time) over a year from now is a pretty bizarre way to define present success.

That said, I think their success blinds them to alternative, more risky ways of being successful with technology. In Jason’s post, he analogizes web businesses to stores:

If there was an airline that flew more passengers than anyone else, but lost money on each one, would we call it a success? If there was a restaurant that served more people than anyone else, but lost money on each meal served, would we call it a success? If there was a store that sold more product than anyone else, but took a loss on each one, would we call it a success? Would the business press hold these companies up as business model successes? Would anyone? Interesting, maybe. Promising, sure. But successful? Then what the hell is going on with the coverage of our industry?

There are, however, an entirely different mode of doing business that is well-represented in the traditional sphere. While it is certainly more risky, large companies often sink millions or billions of dollars into research, hoping it will pay off by providing them a sellable product. Microsoft, for instance, spent more than 9 billion dollars on research in FY 2008, almost double what it spent on income tax. Around one in six dollars that comes in to Microsoft in revenue are spent on research.

By Jason’s argument, Microsoft Research is not “successful”, and if someone says it is, they are using an unacceptably low bar for success. It would be more appropriate to think of Microsoft as aggregating significant amounts of risky propositions into a single department, on the gamble that enough of those propositions will be successful to make the expenditure worth it, even if it takes a while for those propositions to pay off.

In effect, venture capitalists are making the exact same gamble. The underlying business model is still the same: plunk down a bunch of cash on research projects that, if successful, will result in significant payoff. The difference is that Internet businesses are very amenable to a more distributed model, where individual folks with ideas do the research, shouldering some of the risk of failure and some of the reward for success.

In other words, these sorts of businesses are simply accumulating value–in followers, users, or even eyeballs. They will be successful when they can sell that value (usually, all at once), just as Microsoft will be successful when they can ship products based on years of research (usually, all at once). According to Jason’s analysis, Twitter is not a success. That is a fundamentally flawed analysis as they have built enough value at this point to be converted into a lump-sum payoff, even if they have not yet cashed in.

However, none of this is to say that as an entrepreneur, you should build your business around the hope of such a payoff. It’s a highly risky way to build a business, and is subsidizing venture capitalists, who don’t actually share in the risk (like Microsoft, they are aggregating risk into a larger research pool). But if taking big risks is your thing, taking on a long-term research project is a perfectly reasonable way to build a business.

Rails and Merb Merge

Today is a fairly momentous day in the history of Ruby web frameworks. You will probably find the news I’m about to share with you fairly shocking, but I will attempt to explain the situation.

Before talking tech, and even going into the details of the announcement, I want to assure everyone that the incredible members of the thriving Merb community are top priority, and that this could not have been possible without every one of them.

Merb is an open, ever-changing project, and some its best ideas have come from not-core regular-Joe community members. It’s gotten where it has because of the community, and the community will get us even further in the future. Your ideas, feedback and even complaints will be 100% welcome in the future, just as they have been in the past. I believe in the tremendous value an open community and just generally open attitude bring to the table, and am counting on those things to continue ushering in the future of Ruby.

On to the news: beginning today, the Merb team will be working with the Rails core team on a joint project. The plan is to merge in the things that made Merb different. This will make it possible to use Rails 3 for the same sorts of use-cases that were compelling for Merb users. Effectively, Merb 2 is Rails 3.

What does that mean exactly?

  • Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. We will focus on reducing coupling across Rails, and making it possible to replace parts of Rails without disturbing other parts. This is exactly what Merb means when it touts “modularity”.
  • We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins. This project will also include the creation of one or more benchmarking applications, so we can more clearly see what optimizations have real-world impact.
  • As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release.
  • Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
  • Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. While ActiveRecord will ship as the default ORM, the plan is to make it drop-dead easy to drop in other ORMs without feature degradation (to the extent possible, of course).
  • Rails will continue their recent embrace of Rack, which is a really exciting development in the Ruby community that Merb got in on early and which we believe will improve the state of modular, sharable logic between applications.
  • In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

How will we do this?

The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.

In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.

To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.

If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.


As you have probably gathered from the above, there aren’t any clear points that the Merb and Rails team disagree on anymore. Merb has been around for roughly two years now, and we’ve proved out our ideas by use in real-world applications (like Yellow Pages, SproutCore, Powerset, Defensio, etc.). Given this philosophical convergence, it just didn’t seem like there was much to gain by continuing to duplicate effort and spend time and energy fighting each other.

I think it’s important to acknowledge the Merb community for building something super-awesome. I really hope that we’ll all stay in this together, help each other in the coming months and in the transition to Rails 3.

Rails will be putting together a new evangelism team, which will include Matt Aimonetti (Merb core team member and evangelist) and a few other people doing Rails evangelism work. This group will be responsible for, among other things, helping the community get where we’re going. Their job will be to listen to you.

This seems crazy! Has this ever happened before?

Interestingly, yes. A very similar situation confronted the Struts developers several years back. They had built a very popular framework in Struts, but a very active group of developers were really advancing the same ideas in interesting ways in a framework called Webwork. The Webwork developers saw their project as “Struts done right”, just as we believe we’ve improved on the implementation of Rails.

Eventually, the Struts guys and the Webwork guys came to the conclusion that they would be stronger together then apart, and merged the projects. What became Struts 2 was effectively also Webwork 2, but the two communities got together to build something better.

I believe that this merger will get the ideas that gave Merb momentum into the hands of many more people, and that really serves us all. I’m looking forward to the future.


  • One of the most personally gratifying parts of working on Merb has been working with alternative Ruby implementations to make Merb run well on them. Fairly early, Merb was running faster on JRuby than MRI, and I’m looking forward to bringing a lot of that insight to Rails, and helping to make Rails to be solidly competitive on the performance front with frameworks in “faster” languages.
  • The Merb Training is very much still on! We’ve spoken with the majority of the attendees, as well as with our partners at Integrum Technologies and they’re all really excited about the merger. That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. There are still a few seats open, so sign up now if you’d like to join us!

jQuery Selector Refcardz

Bear Bibeault (my co-author on jQuery in Action) and I have put together a neat reference card for jQuery selectors that you can get from DZone.

Here’s a blurb they provided:

This reference card puts the power of jQuery selectors at your very fingertips. Written by Bear Bibeault and Yehuda Katz, co-authors of jQuery in Action (Manning Publications), jQuery selectors are one of the most important aspects of the jQuery library. These selectors use familiar CSS syntax to allow page authors to quickly and easily identify any set of page elements to operate upon with the jQuery library methods. Understanding jQuery selectors is the key to using the jQuery library most effectively.

jQuery in Action (w00t)

Some of you might know that I’m writing a jQuery book for Manning called jQuery in Action. It’s pretty awesome, and includes a bunch of labs and exercises that are unique to it. My coauthor is Bear Bibeault (pronounced Bee-Bo), who coauthored Ajax in Practice (and hilariously enough, Prototype and Scriptaculous in Action).

It’s intended for people who already know some JavaScript, but still have questions about jQuery. It’s thorough, while going beyond the typical API runthrough (there are excellent examples; in later chapters, especially Ajax, the examples run through the entire chapter and show you how to complete a fairly detailed, yet typical project using jQuery).

Anyhow, check it out. If you buy now, you get the early-access chapters, which is the equivalent of the PragProgs’ beta book stuff. We’ve already released betas of chapters 1-8 (of 9), so there’s a lot there.