Why We’re Building Reaction Commerce on Meteor

We got on the Meteor train early; it’s not even at 1.0 release yet. Why’d we choose it to build our entire business upon when it’s not even a finished framework? It’s a simple answer, really.

We want to be cutting edge. We want to have fun. And we have a need for speed. (Not necessarily in that order.)

According to their own description, Meteor is an ultra-simple environment for building modern websites. What once took weeks, even with the best tools, now takes hours with Meteor.

A couple weeks ago, Meteor made an exciting announcement: they were overhauling their rendering system with a live page updating engine. In layman’s terms it means that when a user changes data or new data arrives, it’s updated on everyone’s screen automatically. What it means to developers is that they don’t need to hack together a bunch of interfaces. Automatic means it comes with Meteor. Automatically. You don’t have to provision server resources or deploy API endpoints in the cloud or manage a database or wrangle an ORM layer or swap back and forth between JavaScript and Ruby or broadcast data invalidations to clients. Meteor isn’t just simpler for everyone; it’s a lot more fun, too.

So what’s the big deal about live page updating, you ask?

According to a study in 2012 of the top 2,000 ecommerce websites by Strangeloop Networks, the average load times by users ranged from 7 to 10 seconds depending on their browser. The top 100 websites did even worse. And when you consider that load times the year before averaged about 6 seconds, that’s a whopping 22% SLOWER! Radware summed up what this means to the bottom line for businesses:

“Slow speed can cost retailers up to 9 percent of their traffic and as much as 13 percent of sales.”

If usability experts suggest a 2-second load time, why are we moving backward? Because web pages are getting bigger, more complex and more dynamic with multiple scripts and resources pulled from multiple servers and locations. And internet access speeds can’t keep up.

Typically, here’s what happens. When the client changes something, it sends a message to the server requesting the change. The server checks the proposed change against a set of allow/deny rules, and only accepts the change if all the rules pass. If the server accepts the change, it applies the change to the database. If not, the update fails, the server's database remains untouched, and no other client sees the update.

The revolution of Meteor means there are real-time updates.

With Meteor, all that information isn’t being sent back and forth between servers and resources like it typically was. Instead, when a client issues a write to the server, it also updates its local cache immediately without waiting for the server's response. This means the screen will redraw right away. Not 10 seconds. Not 6 seconds. Right now. Bam shazam! That’s called real-time reactive, and on another ecommerce platform it’ll cost you the salaries of a bunch of dev people and a whole lot of time to implement. But because Reaction Commerce is built on Meteor, well, that’s where we start.

Reaction Commerce. Change the way you think about commerce.

comments powered by Disqus