Pet Market app in Pure ColdFusion MX

I missed this one, but Christian Cantrell just posted that we have released a ColdFusion only version of the Pet Market application.

You can find more information and download the code here.

Looking over the article, the entire app was created with just 1,500 lines of CF code, compared to 3,500 in .NET and 14,000(!!!) in Java.

It should be pretty interesting to check out the code and interface and compare it to the Flash based Pet Market application.

14 Responses to Pet Market app in Pure ColdFusion MX

  1. Todd says:

    Having downloaded the source already, I’m sure that MM could trim that 1,500 lines even more if they went back through and deleted their comments and commented out code. Do you know if that was counted as well or was comments excluded? Just curious.~Todd

  2. Probably worth pointing out that LOC isn’t a great metric by anyone’s standards….this has been discussed to death in the .NET versus JAVA wars. Not to mention, that the J2EE PetStore was never intended as a performant application, but an example of all the different J2EE technologies in context.So – I wouldn’t read too much into Line Of Code (LOC) metric……..

  3. Harry says:

    Yea I would agree with Steven, doesn’t matter how many lines of code there is, if it’s ColdFusion I’m almost absolutely sure its going to run way slower than both the J2EE and .Net counterpart. Or if Macromedia is arguing that the pure ColdFusion petstore is faster than those two I as I’m sure many in the development community would be interested to see that study.

  4. mike chambers says:

    >Yea I would agree with Steven, doesn’t matter how many lines of code there is, if it’s ColdFusion I’m almost absolutely sure its going to run way slower than both the J2EE and .Net counterpart.hmmm…. thats an odd assertion since CFMX is essentially jsut a j2ee applicaiton.how are you so “sure”?mike chambersmesh@macromedia.com

  5. mike chambers says:

    i think the point behind the line numbers was more towards ease of development verses any performance metrics.mike chambersmesh@macromedia.com

  6. Patrick Whittingham says:

    The LOC metric is used because of the bugs/1000 Lines is a maintenance problem. It adds to the cost of ownership of the product and lack of user confidence of your product. This doesn’t matter if it is a intranet or internet web site. Just my 2 cents.

  7. Phillip Kerman says:

    I find it very surprising the all HTML version isn’t online! What’s up with that? How am I supposed to demo it to people… bring my computer? What a drag. It really needs to be live… online. Like… the world wide web man.

  8. I also disagree that CFMX version would be slower, since now it’s essentially a J2EE webapp, running on a J2EE framework (CFMX runtime) using a JSP tag library (CFMX tags). So no reason why there should necessarily be performance issues. I also note that the CFMX app is intended to be a showcase of development techniques (as was the J2EE app) so running performance tests would be pointless anyway.What *is* worth pointing out however, is that to make a fair line of code comparison between J2EE and CFMX, one should add in the number of lines of code in the CFMX server itself .. which will essentially be thousands of lines of Java code that provides the architecture and services. The “CF code” is the business logic only.Similarly, with the J2EE petstore, a great deal of the lines of the code represent architecture and services, and the actual amount of code to perform the business logic (the same functionality represented by the ‘smaller’ number of LOC of CF) will be much less.It’s also worth pointing out that J2EE is replete with application frameworks, and with tools that actually generate much of the code that is required. So, home, remote, local home, local interfaces, EJB Bean implementations and deployment descriptors are all automatically code generated from a simple description of entities. Session facades, business delegates, value objects — these are all code generated, leaving only the implementation of the business logic left to “hand turn”- *exactly* the same as with CF development.With the code autogenerated like this, the argument with respect to “the more lines of code, the more likelihood of error” is a fallacy as well. As software becomes more complex, quality isn’t assured by writing that software with less lines of code, but by writing it with attention to methodology – things like unit testing, regression testing, continuous integration, separating content from code, demarcation of roles in the development team, etc, etc, etc. Which would arguably put the J2EE platform ahead of CF in terms of writing more complex applications….sorry :)Let’s not forget that CF is a tool aimed at webapp developers. J2EE is an architecture aimed at tool providers, system integrators, as well as server-side developers and web developers (among others).The upshot – the comparison is apples with oranges, and lines of code, performance, quality, etc, aren’t metrics that are worthy of comparison between the 2 technologies.ColdFusion PetMarket seems like a good showcase for the CFMX community to pickup some best practices on putting a mid-sized CF app together … exactly the same purpose the PetStore app served the J2EE community.Let’s leave it at that, and not try and draw inference any further…Steven

  9. > I find it very surprising the all HTML version isn’t online! What’s up with that? How am I supposed to demo it to people… bring my computer? What a drag. It really needs to be live… online. Like… the world wide web man.Yes, I supposed it to be on-line too…

  10. dwym says:

    hola!! felicitaciones por su trabajo, esta muy bueno