If you haven't seen The 15 minute E-Commerce Site CLICK HERE
I'm currently looking for Contract jobs, Contact Me if you are interested. Dave.
All the time people ask me...
'How does ror_ecommerce compare with spree?'
To be honest I am probably a bit biased. Assuming everyone knows that I will be biased I will try to be as open minded as possible.
I feel spree is great solution for small sized businesses that wants to get an e-commerce website up fast. It's documentation is pretty good and will definitely save you time to market.
Ror_ecommerce will also save you time to market. What ror_ecommerce lacks in documentation it gains in coding style. After all it looks and feels like a normal Rails app. There isn't a learning curve for developers because things behave as most developers would expect. (winner RORe)
The next difference is performance. ror_ecommerce doesn't have many queries compared to spree. The version of spree I am familiar with had hundred's of queries on many pages. If you plan on scaling large, this can kill performance. (winner RORe)
If you are planning on going public with your site one day you better have an accounting piece in your application. ror_ecommerce has a double entry accounting system built in out of the box. This could potentially save you months of development if you want to go public one day. (winner RORe)
Spree's front end is potentially ready for production on day one. Again for small shops this is an advantage for spree. ror_ecommerce does not try to add much front end work at this time. This is a disadvantage for a small shop that just wants to get something out the door. For a shop that wants to scale large ror_ecommerce this is exactly what you want. Let me explain...
Lets say ror_ecommerce had a bunch of CSS and html in your way from the beginning. There is a good chance you will not remove the CSS, instead you will re-write parts of the CSS and some will stay around even after it should have been deleted. Thus very slightly hurting performance and cluttering up your code. That being said, I see advantages to having a completed front end. (winner Spree)
The Cart is one of the best features in ror_ecommerce. If a user puts something in their cart and removes it. There is just a flag set for that item. So now a marketing team has access to all the information people are putting into their cart. Also a user can save items for later and have items in their cart that are "wish list" items. In spree there isn't a cart at all. Spree starts with an order. This means spree can't have appropriate validations at the model level. Spree had to introduce validations at the controller / programmers discretion. Not only is this buggy but it breaks MVC. In addition there are many abandoned records in spree, thus bloating the orders table. (HUGE WINNER RORe)
Order_item (list_item in spree) prices are broken down individually in rorecommerce. This allows you to process returns without complexity. Also ror_ecommerce never deletes lineitem records. Deleting items on exchanges in spree means you lose history. Thus it is impossible to complete returns accurately 100% of the time. (winner RORe)
Purchase Orders are in ror_ecommerce out of the box. This may be a bit overkill for small shops it is still a great thing to have. Spree does not have purchase orders. (winner RORe)
Internationalization is currently being built out in ror_ecommerce. Spree's Internationalization is pretty good. (winner Spree)
Security, ror_ecommerce out of the box gives you a config file for all secure data and ignores the config file in git. This follows best practices. Spree holds much of the configuration information in the database and also has a column in the DB for credit_card.number. Although, they don't recommend using the number field it's only one bug from a lawsuit. (winner RORe)
Spree clones credit cards and address for every order. This bloats these tables and give no advantage. Instead ror_ecommerce adds new records only when you add a record. When you edit one of these records in ror_ecommerce it inactivates the old record and creates a new record. This improves performance for ror_ecommerce. (winner RORe)
Finally coding style in ror_ecommerce uses many namespaces to allow every action to have one responsibility. This allows easy navigation and clean code. Spree creates many non-CRUD actions and uses resource controller. Resource_controller does to much automatically for you out of the box. This is not a good thing. It hurts performance. (eg. queries for an object without an include thus creating N+1 conditions) It makes the code much less readable. (sometimes you don't see and code it's all magic and when you do over-ride resource controller the code gets very confusing very quickly). ror_ecommerce on the other hand uses standard RESTful controllers. It's very readable and most of the logic is in the models. (WINNER RORe)
You can make a judgement for yourself. You know my opinion.
RoR ecommerce now has documented over 95% of the methods in the models. With the added YARDocs ror_ecommerce has one more big benefit.
Follow Up 2 (one year later):
After talking with many developers I have found that Spree might have a lot of documentation but figuring out what is out-dated and what works for what version of spree is an impossible task. I don't know how spree can fix this. They did hire Ryan Biggs full time for helping and he is great but he might just have an impossible task.