RoR-e

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.

ror_ecommerce vs spree (The best Ruby e-commerce solution) David Henner Dec 20

20 comments Latest by raul

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.


Follow Up:

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.

20 comments so far

Anonymous Coward 21 Dec 10

Thanks for this well-written comparison. Biased or not, I am going to take a serious look at RoR-Commerce. By the way, what about their extensibilities?

Dan Carper 21 Dec 10

I second the anonymous coward!

DRH 22 Dec 10

Check out a response I had about extensibility http://groups.google.com/group/ror_ecommerce/browse_thread/thread/495b2ddc6207248

Anonymous Coward 22 Dec 10

I read the google group thread and it's spot on: exactly the issue I am having with Spree. (Forgot to put my name in the first comment, so I better stay anonymous and cowardly :) )

Josh 22 Dec 10

as noted, found you post to be very biased. please see some disagreements below: Time to market: spree saves more time by allowing you to use existing extensions, instead of forking a project. using ror_commerce means forking the project. Plus using spree means you are using a system that is battle tested. 100s of commiters have put time into spree and it is being used in production on thousands of sites. Performance: spree does not do any excessive querying. it queries the minimal data set required to display a page. Accounting: The goal of an ecommerce solution is not accounting. You could easily export spree data to QuickBooks and use a solution that is specialized for that field. Cart: not sure what you meant about not having historical data. All spree carts are saved and visible to the admin. In Spree the cart is an order "In Progress" i dont see this as a problem. Purchase Orders: Same as accounting, not the strong suit of an ecommerce solution. It would be better to use orthis systems instead. Otherwise you need to handle a full accounting system (i.e. A/P A/R G/L accounts etc..) Security: Spree follows all security best practices. Though you can store the CC number in the db, by default spree does NOT store credit card numbers in the db. Never seen that option used Cloning Data: Imagine you have 3 orders pointing to the same address, then you change the address for the last order.. you will lose the historical data about where the order was shipped. The data size is tiny, and any company selling products will have no problem paying what it costs to store an extra 80kb of address data per order (if it even is 80kb)

Josh 22 Dec 10

correction meant 80 bytes not 80 kilobytes

DRH 22 Dec 10

WOW Josh. I like the fact that you like spree. =) Time to market: I didn't say spree doesn't save time to market. But if you get an experienced rails developer they will bring ror_ecommerce to market faster IMO. I agree spree has a big community. I think resource_controller & class eval & hooks everywhere & complex solutions to simple problems & breaking MVC all hurt time to market. Performance: I have spent the last 100 days optimizing a site that uses spree. Trust me there are many more queries than needed. This wont hurt you will less the a 100K users but have a site with more than a million and you lose. I can give you log files and N+1 queries all over the place. Accounting: Try going public without this. I need to upgrade a spree project right now to take this into account. If we had used ror_ecommerce this would just work. I agree it's overkill for mom and pop shops but it doesn't hurt mom and pop. The goal of this account piece is to export to an enterprise accounting system. Spree doesn't have accounts receivable / accounts payable / expenses / .... Cart: Spree does NOT have a cart. They have an Order and this order is created before the order is placed. Do me a favor. Go into spree admin start an order and then leave that order. You now have an orphan order / line items/ address/ ..... in your database killing SEE ABOVE Performance. AND dont dare delete the order or you risk ophan objects and bad associations. Purchase Orders: Same as above see accounting. LOL. but seriously you need to track inventory and no ror_ecommerce does not replace an enterprise level purchase order system but it certainly compliments it better. (read the spree google group, spree is looking to copy my code, I hope they do. The point is for both projects to be better and help the community.) Security: I didn't say CC.number is by default in the DB. but it is one bug away from being in the DB. Also Spree does not by default give you a config file that is outside of GIT itself. Secure data should not be accessible to all developers with git privileges. Make good practice easy and bad dev's might follow good practices. Cloning Data: You need to look at my implementation. I NEVER edit address or CC EVER. When you edit an address you inactivate and create a new record. This all has tests in the test suite so you never change an order's address/CC if you edit it. Old orders keep the old address that was inactivated. So ror-e has all the upside and none of the downside. HUGE WIN At the end of the day, resource_controller and breaking MVC are deal breakers for spree and me. (sounds like a movie LOL) At the end of the day, the community gets stronger with competition. HUGE WIN for everyone. Lets keep the debate going. This could be healthy to improve code for both projects.

Mo 22 Dec 10

Good indication of performance is in a test suite. My work has a spree app with 100 tests that take 6 minutes to run. ror_ecommerce has 700 tests that take less than 20 seconds to run. WOW

Sean Schofield 22 Dec 10

Readers should be clear that this is just your opinion. I have a different opinion which I will outline below. Most importantly I'd like to clear up some errors of omission as well as things that are being represented as fact which are just opinion. "I feel spree is great solution for small sized businesses that want to get an e-commerce website up fast." Glad we agree. It also happens to be good for large e-commerce sites as well. The website you work on during your day job is in fact a huge Spree site. Don't you think you should have mentioned that? "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)" This implies Spree is not just like a Rails app. It is like a Rails app. You might not like the use of certain gems or plugins but you shouldn't imply its somehow different than a typical Rails app. "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)" I'm familiar with the project you're working on (since we worked on it as well.) Many of those queries were introduced by your company's customization. You're also using a very old version of Spree at this point. I agree that Spree still has too many queries but the reason why we haven't done much about it yet is that real world experience on high volume sites shows that this doesn't affect performance when used with proper caching. Having fewer queries is not the "clear advantage" that you claim and we're certainly open to patches that would improve this if you thought it was an issue. "If you are planning on going public with your site one day you better have an accounting piece in your application." IMO Spree is actually pretty strong with accounting. We're careful to record things "the right way", etc. Ultimately a business needs a strong accounting system that is independent of their website. The website just needs to feed the correct numbers to your accounting system which Spree can certainly handle. Again, not necessarily with the version of Spree you're using or how your company has chosen to customize it. Your solution may have a better approach (I haven't looked) but I doubt it would take "months of development" to add whatever you've done in your solution. "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." Spree actually has the same philosophy as you. It is intentionally plain (but perhaps more polished than your solution.) Its assumed you will heavily customize and extend it. In fact, its not a big deal to replace the whole front end and just keep the admin. Spree is trying to be more than just a series of models and controllers - its supposed to be a starting point for building a more polished application. There's always room to improve but the thousands of stores out there seem to suggest this is not a big problem for Spree. "Spree starts with an order. This means spree can't have appropriate validations at the model level. ... In addition there are many abandoned records in spree, thus bloating the orders table. (HUGE WINNER RORe)" The first part about validations is simply not true. You should also not suggest that Spree does not have a "cart." Customers see a shopping cart like any other website even if there's no cart.rb Ralis model. It seems like you are having a hard time grasping this but an in-progress order in Spree is equivalent to what you're calling a cart. The Spree order model simply progresses through various states during the checkout (address, payment, etc.) The abandoned order critique is ridiculous. Just use a cron job to delete them (like you would if you called it a cart and the user abandoned it in the same manner.) "Order_item (list_item in spree) prices are broken down individually in ror_ecommerce. This allows you to process returns without complexity. Also ror_ecommerce never deletes line_item 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)" I don't even know what you're talking about here but I would just like to say for the record that this is not an accurate description of how Spree works. "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. [sic]" Spree is intentionally modular and lightweight so that you only get the functionality that you need. It would take 2-3 days to write a purchase order extension for Spree. You could add any random feature to your project and say its not in Spree but that doesn't mean people shouldn't use Spree. I'm not against purchase orders but you shouldn't imply that purchase orders would be difficult to achieve or "prevent you from going public." No e-commerce solution is going to be exactly right for everyone. It will always have too many or too little features. Spree has a reasonable set of default features but its designed to make it easy to remove the ones you don't like and too add the ones you want. "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. " Spree has rock solid security. Its been subjected to several security audits and all reported issues are fixed immediately. Credit card numbers were never stored in the database ... EVER. The database field you were referring to was there so that developers could opt to store the number with PGP encryption. Even this was considered too risky so the field was dropped from Spree a while ago. Configuration information does not need to be stored in the database. It can be stored in a file in the same manner you are suggesting (although why you think files are more secure than databases I can't explain.) "Spree clones credit cards and address[sic] for every order. This bloats these tables and give[sic] no advantage." Its certainly possible to have a single credit card profile for a user. Since users are not giving explicit permission to create a secure credit card profile we decided to store the token information on a per order basis. This was only so that refunds could be done more easily. Its not perfect but not a reason to use an untested framework IMO. We're also certainly open to making improvements. "Finally coding style in ror_ecommerce uses[sic] many namespaces to allow every action to have one responsibility." This is the first time I've heard someone complain about coding style in Spree. Perhaps your standards are different. I will point out that there over 100 contributors to the Spree code and it is often cited on Rails forums as an excellent example of a sophisticated Rails app. "Resource_controller does to[sic] 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)." I'm sorry that resource_controller confuses you and seems like "magic." You probably would not like the newer gem called inherited_resources either. That was created by Rails core member Jose Valim and its been downloaded 60,000 times in less than a year. It relies on similar "magic" to greatly reduce the lines of code in your application. We've always been open to removing resource_controller but the alternatives never seem to be more appealing. N+1 queries are no more or less likely with using resource_controller than any other approach - you need to know what you're doing to avoid them. I think its pointless for us to argue about which framework is better. I just wanted to set the record straight about Spree. I think it would be a shame if your unusually strong feelings about purchase orders and resource_controller discouraged someone from looking at Spree which has been serving the Rails community for over two years now. Ultimately the best way to evaluate a technology is to actually use it. So I think that users should evaluate both solutions and pick the one that works best for them. It sounds like Spree just rubs you the wrong way for whatever reason. No hard feelings on this end but I would prefer if we both just focused on making our software better instead of critiquing each others efforts.

DRH 22 Dec 10

OK. I'm going to just say I stand by what I have said. I feel I have stated facts and I agree with much of your post. resource_controller does rub me the wrong way. It gives a complex solution to a simple problem. Hooks / business logic in the controller does rub me the wrong way. I wouldn't have started this project if Spree did rub me the right way. Just like Yahuda wouldn't have started MERB had rails rubbed him the right way. I would like to find someone completely new to ror-e and Spree to do an independent evaluation. It would be great for both projects. Code reviews will only help everyone out. As for inherited resources(IR)... It's not bad, especially for simple controllers. I'm not a fan of any complex solutions for both RC and IR. Spree removed RC from the orders and checkout controller for this exact reason. Great decision! At the end of the day Spree helped ror-e more than I could ever express. Had I started this project without using spree first, I would have an average solution at best. I studied Zen cart / spree / Java solutions / ... in order to take what I felt was best practices. I studied the amazon's cart. Wow they have a great cart!!! Their checkout has so many steps yet is very simple. I can't express my thanks enough to the whole open source community. At the end of the day I want Spree to succeed. When you make improvements I get ideas!!! Thank you.

apneadiving 23 Dec 10

Hi, Thanks for your work, it's always very appreciated people gives time for the open source community. I'd simply want to say I won't use RoR-ecommerce because it's not engine based and then not easily upgradable. Say you improve your platform with great features, I'd be disappointed having to redo all my work to integrate your add-ons. What's your point of view about that? Ben PS: seems you fixed your comments ;)

DRH 23 Dec 10

There is an easy solution. Just use it as an engine if you want to. Clone the repo... create an engine. Now if you see improvements clone the repo again, create a new engine... replace the old engine. I personally have had the engine route not work for me so I'm not releasing something that doesn't fit what I would use. Feel free to clone/fork the repo and use it as you like. I've also seen difficulties upgrading projects like this. When it comes time to upgrade you have enough customization that it is impossible to upgrade. Not sure if throwing months of work away is a good choice. Isn't it better to save months of work and forget about the one extra feature that saves to a couple weeks? I understand your desire to upgrade. I dont see the lack of desire to save months of work. Also.... most upgrades will start appearing as RACK apps. The base app will hopefully be stable. Just my opinion.

Independent tester here! 16 Feb 11

I've used spree on a successful client site, and I've had my fair share of headaches. BUT, I am 100% certain that any solution would have given me a headache, just in a different way. I'm very interested in trying out RoR-e, and I will. I'll let you and Sean know how it goes.

David Cobbs 28 Oct 11

I think this is the greatest post ever made and I will find out more at google.

Another Fairly Biased Tester 15 Nov 11

I've just used Spree on a project, and it is pretty easy to start off, but here is on major headache, while google group is great, IT IS A MAJOR HEADACHE to go there with every more or less complicated questions: while basic documentation is available, it mostly lacks once you start customizing. I literally spent 40% of the time trying to figure out, what's where in spree, trying to find blogs, or reading old or contradicting documentation, ending up just reading code. Documentation for a lot of features is either lacking, or seriously outdated. I may be unfair, but I just got so frustrated at times. I'm going to check our RoR e commerece right now.

Jorge Ruby 25 Nov 11

I preffer 1000000 times ror_e instead spree, why? because I dont like the engines, they are a pain in the ass to maintain, I dont care about engines upgradeability, I can code myself and fix bugs, Spree took part of my day to figure out how the fuck it works, ror_e only took 10 minutes to setup, I've ported my existing photoshop/html template into it and works great!

DRH 01 Dec 11

Jorge Ruby (and everyone else that has a URL) I'd love to see your ror_ecommerce site. Send me the URL. If you want I can link to the site from my homepage.

Saurabh Bhatia 29 Dec 11

I agree totally with David. Most of the extensions in Spree are outdated. Even working on simple functionality in spree like static pages I had to struggle to make extensions work with the latest versions. On top of it, the community is not ready to support older versions either. They are plain arrogant. Good to see ror-ecom effort, I have started my project on similar lines too. It is still in early stages of development but I hope to release something worthwhile by mid jan 2012 https://github.com/storedragon/storedragon-base

Jerry 16 Sep 12

I have been working on a spree project trying to get it up and running for about 2 weeks. Every time I get it to a certain level, it crashes on me. I never had that trouble with ROR. nfl-pro-fan.com was built on ROR in about a week and I am a novice programmer.

raul 05 Oct 12

hello people, surfing the web i´ve found these excellent discussion about two excellent tools. They should be changed a lot since the first entry two years ago. My team is very pleased working with Spree, we have tied it up with OpenERP, what extend the solution and the potentialities. Right now we are adopting OpenTravelAliance(OTA) and OpenERP to get a complete e-commerce solution oriented to the tourist sector. When we finish our work, we will publish some useful gems. hugs

Comments are closed