RoR-e

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?

I second the anonymous coward!

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 :) )

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)

correction meant 80 bytes not 80 kilobytes

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

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.

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 ;)

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.

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

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.

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!

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

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.

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