The MVC vs OOP debate is an important one, but the developing holy grail of “Pure OOP” doesn’t help me be more productive in the near future, and perhaps ever.
I’m ready to be practical.
But being practical means also considering the performance hit, as presented by @bdw429s, from using Lucee with ColdBox vs Lucee on its own. The difference is arguably negligible when they are both compared to other platforms, but when compared to each other, 19.1% is a significant loss. I expect performance loss from any framework compared to bare bones code, but that doesn’t mean I have to accept it.
Practicality also considers the time investment I’d have to make learning MVC (as @bennadel advised not jumping into something before fully understanding it) and then migrating all my websites to it. They’ve been running very well for decades, I’m quite happy with their performance, and the code is easily maintained and improved with new features because I have already separated concerns via OOP.
From necessity, I have a long history of solving issues from scratch instead of waiting for 3rd party solutions that don’t yet exist at the time, so when I first heard about Ruby on Rails long ago, it sounded like it only solved problems that I didn’t have. And I’ve mostly ignored all other MVC platforms since.
SEO-friendly routed urls e.g. site.com/home/about are another example of a feature I don’t need, because I rolled my own custom error404.cfm which handles routing. I can see how MVC would automate some of that, but doesn’t seem worth the pain of conversion.
So the arguments for why I should migrate to MVC better be strong ones and demonstrate advantages I don’t already have!
Everything exists to solve a problem. And, if it doesn’t solve your problem, I wouldn’t worry about it. One of the nice things about a framework is that you get some automated functionality, like dependency-injection and auto view rollup. But, none of that is all that hard to do manually. And, sometimes doing it manually makes the code easier to understand (since it’s more explicit).
ColdBox is a whole ecosystem. So, it becomes a “development target”. That is, people can build things specifically to work with CB, which allows that functionality to - essentially - just be “dropped in” and it “just works”. So, something like CB can be great for a team or for something that uses a lot of use-space functionality.
But, again, if you’re doing mostly solo-work, and you don’t use a lot of 3rd-party stuff, then it may not hold that kind of value-add for you.
At the end of the day, you just gotta get stuff done.
Learning any different kind of ideology is just that, is a method or ideology. I will not convenience you that OOP or MVC is best, as I do not believe that either is “best”. In the end of the day, nobody on the front end cares about how your code is written they only care about result. If your method works for you, and you can support it, go with it.
I do not use MVC and my implementation of OOP is closer to PHP than anything in CFML or java. Does it work for me, Yes, will I try to sell it as its own methodology, nope.
As for SEO concerns, if you design your app full knowing the SEO design in mind, then you can literally have domain/URL/ and every /URL/ can be its own complete application.
Yes, there are several methods in which the application stack hijacks the request and responds with a faked output that resembles /URL/SOMETHING even though its really index.cfm&PARMS that is then rewritten via the applet engine. If you want to get down to it, this has a small, but noticable memory footprint. On low traffic sites its nominal, but on larger sites with large data queries, there are performance gains to be made by making /URL/ be the application you need ran.
That all being said, it doesn’t hurt to know how someone does something and all the methodologies out there. I find that the KISS (Keep it simple stupid) method works best for me. I use the old EDS model for application design. Its top down, everything is commented out for code changes with date and user, and that the code is written to be as close as it can be to use as few files as possible.
So there you go,I can not convince you to join a hokey religion that I do not believe in.
My experience is people who don’t really want to use a framework are the same as the people who don’t really want to use script. They won’t
This is a very valid point. We’ve done tons of performance optimization in ColdBox to streamline its request routing, error handling, etc to be as fast as possible. What I have found is that most robust web apps written in ColdFusion without a framework will eventually amass the same sort of extra features and overhead that a framework has. In the Techempower benchmarks (which FULLY saturate the machine’s CPU with 512 concurrent connections) my “raw” CFML versions have absolutely no overhead and are not indicative of any real app.
I would say the biggest feature of ColdBox MVC specifically are
Code organization that your whole team (even incoming developers can understand)
Standardized ways of doing things such as URL routing, error handling, logging, caching, etc
The existing community of drop-in modules to add functionality
So the first two bullets are of little use to a very small team or a single person who already knows how they do things and likes it. So the remaining bullet CAN be useful, but not if you’ve already built tools to do all those things.
When I spin up a ColdBox app to start a new client project, I don’t need to write any code to get
Dependency injection (core)
AOP (core)
Pluggable Logging (core)
Pluggable Caching (core)
SES routing (core)
REST resources and automatic data serialization (core)
Interceptors (core)
Any one of nearly 400 modules on ForgeBox that you can drop in via the CLI
So basically, if you’ve already written libraries for everything above or don’t think you’ll ever come across the need for any of them, then you probably don’t stand to gain a lot.
This is what it comes down to for me-- if you go to a programming conference whether it’s Java, Ruby, or PHP, you’re likely going to find every serious developer you talk to is minimally using
CLI tools
Frameworks (likely MCV)
Package management
I attend and speak at a lot of conferences-- even non-CF ones and use of tools like these are just basic assumptions you’re going to see on the projector in every session and on every screen in the audience.
In the CFML space, the pinnacle of modern development IMO is
Now, I’m totally biased, that’s for sure. But bullets #1 and #3 literally don’t even have any competition in the CFML space, and the only other framework using ForgeBox/CommandBox to install plugins is CFWheels (and they’re just now starting to do it). FW/1 doesn’t even have a real concept of 3rd party modules you can drop in to add functionality outside of subsystems, which are more for organization of an app.
Anyway, you asked about MVC, not ColdBox, but I think many of the benefits happen at the nexus of the Box products so it’s hard not to talk about the specifics. Here’s an opinion piece I wrote on my personal blog several years ago: It's Time You Looked At ColdBox 4
In the end, you get to decide if the benefits and conventions of a framework are something you want to spend the time learning and if it will really help you get apps out the door any faster. This is much less compelling if you’re just maintaining a legacy app. I’d recommend you just play around and find out for yourself. You can have a ColdBox app running in about 20 seconds with CommandBox.
coldbox create app
server start
It’s pretty much that easy. And if you hate it
server stop --forget
cd ../
rm testproject --recurse --force
I am actually keeping an open mind, as I always do, and I fully embrace change when the long-term benefits outweigh the short-term struggle, which is the very reason why I created this topic.
I don’t even know what most of those ColdBox features are, and the ones that I do know, I have already solved by other means, e.g. Lucee’s own SanitizeHTML(), the stripe-cfml repo on GitHub, Captcheck (no Google!), QRCode.js, etc.
But you have convinced me that I at least need to learn more about all of the other features.
Also, I need to keep myself employable in case of the unlikely event that my wife loses her job, since my own businesses currently don’t generate enough revenues to pay all of our bills. I’m not too worried about it since we fully own our house (no mortgage), and she works in healthcare which has terrific job security, but it’s one of many issues to consider in terms of whether I need to learn more about frameworks to keep myself viable.
Unfortunately, if I decide I do need MVC:
Being principled means it wouldn’t be ColdBox because as I’ve stated elsewhere, I don’t want to be bombarded by nor personally associated with unprofessional religious evangelicism, and I agree with @JenniferHerrera about the importance of that re: Roe v Wade. Freedom from religion is our right just as freedom of religion is theirs, except when that interferes with a woman’s freedom over her own body.
Being practical means I would be moving on to Node and JavaScript frameworks which would make me much more attractive in the eyes of the vast majority of employers.
I wouldn’t agree with that Brad. I’d rather agree that people who don’t like script also wouldn’t like using a framework. That was probably what you was trying to say.
Some devs just like using their own “home grown” framework instead, like Ben Nadel also uses his own web application for his blog.
The core belief was as a consultant (employee, whatever) you adhered to a strict core methodology that was part of the brand.
In coding, at the very top of the file was a bunch of comments, the very top comment was the last person who edited file
#Me date - time format HH:MM: AM / PM #Reason #lines changed
Then on the lines changed.
You would comment out the “old code”.
You would put in your name, initials and the updated code.
You would optionally put in a full description of what the change did.
This predates SVN, but even after SVN was released this methodology still followed.
Re-read what I said-- because we’re saying the same thing I think you also missed a bit of the joke. In the LUCEE NOT DEAD thread, Lionel was talking about how there was no reason to use tags (for business logic) and everyone needed to move to script. I was ribbing him a little by paralleling that to my assertion that everyone needs to start using a framework.
You can’t really say ‘Coldbox costs 19.1% performance versus (other thing)’ unless you’re running the same test with the other thing.
The app exists that is so lightweight or single-purpose that it doesn’t need hand wavey gestures all the framework “stuff” behind it.
Very nearly every app I’ve ever had much to do with in 20 years of writing CFML very quickly grew to the point where we were starting to solve problems that had already been solved by others (like Ortus). If you can set firm boundaries on your project such that you know you’ve only a finite, small number of such instances, your custom-built ‘thing’ may still be faster or better or both than Coldbox, which has to cater to the unwashed masses (while also receiving support from them).
You also need to factor in not just the time it takes to execute your request, but the investment of time it took to get your app to a place where it could execute that request. If you know your app is going to be running for 20 years, for sure it makes more sense to re-invent some wheels so that you’ve got exactly the purpose-built fit you need.
Then you’ve got to factor in extra time for new developers to learn your custom voodoo. For many years, we used a homegrown framework that I wrote that was custom-built for our main app. It was fast and easy to expand. It ‘just worked.’ I’m so glad we stopped using it in 2015 because the learning curve to learn our custom framework was in the same vicinity as the learning curve for Coldbox, and other developers coming in to work on our stuff are going to have a much easier time with a set of tools they’ve run into elsewhere than with whatever I happened to think was a good idea on some Tuesday in 2011.
This is not exactly the same question as ‘do I need MVC’ though – it’s more, once you say ‘yes’ to that question, your choices are not numerous. In CFML land these days all we do is write API endpoints, so we’re just using the M and the C bits with a front end doing the rest. Probably one could imagine a version of Coldbox streamlined such that it knew it would only ever have to serve API requests and not bother with rendering HTML!
If we’re gonna be drawing conclusions from Brad’s performance data, we could just as easily say ‘CFML + Coldbox is way faster than most everything else’ but as always: much depends on what you’re trying to accomplish.
Well, Brad wrote both of those tests, so presumably they are equivalent.
That reminds me of how last year I did a Gatling load test on a $5/mth DigitalOcean nodejs+nginx droplet and it achieved nearly 8,000 concurrent connections!
You’ve both made valid points, but the conclusion is that the Techempower methodology is flawed because it doesn’t represent real-world production performance for any of the tests.
That is a fantastic point, especially when I consider the possibility that some day I might sell my businesses or maybe they’ll grow enough that I’ll need help with the coding.
Unfortunately that’s yet another strike against Lucee. Despite cfscript’s similarity to JavaScript, from the perspective of the vast majority of the global developer pool Lucee for the most part is custom voodoo. And its #1 most popular MVC framework is hampered by the appearance that Ortus doesn’t care about their public perception. I guess they’re satisfied with their ancient Corp/Gov clients and maybe haven’t given enough thought to the probability that some day those slow moving conglomerates will finally enter the 21st century.
These realizations make me sad, because as I’ve said, I do love Lucee, but as I’ve also said, in my quest to improve the viability of my own skills as well as my business platforms, frameworks, etc, I am now being practical.
I mean: take an actual, real-world thing you have to do, start from zero, and measure both the investment required to get to a ‘ship this product’ state and then the performance.
It isn’t trying to. Of course it’s a contrived test scenario, but as contrived test scenarios go, it’s a useful and informative one. My point is merely that one should not be drawing conclusions about MVC frameworks (the original question here) based on a performance test for which ‘does it use an MVC framework’ is merely one ingredient in the soup.
If you’ve never grown a product past the point where anybody other than you has had anything to do with it, it sounds like “being practical” is for you a hypothetical consideration.
We have to hire people to work on our apps. The thing you’re driving at here ain’t nothin’ – it’s part of the reason why we split off front end development into VueJS. It reduces our CFML surface area. But CFML was only ever ‘fine’ at front end stuff anyway; it wasn’t really trying to shine there. Since doing that, when we hire a back end developer, we look for somebody who knows HMVC & OOP concepts, DB architecture, and how to write readable and testable code. I don’t care if they happen to know CFML already. It’s a perk if they do but hardly a requirement.
What a bizarre comment to make about the only private company in the CFML world that hosts a public conference and dedicates the resources of multiple developers to public projects.
I’ll tell you what: inLeague (my shop) doesn’t care about our public perception. We contribute (occasionally) to OSS. We speak (occasionally) at conferences that other people (like Ortus) host. I’m satisfied with our non-ancient, non-profit/public ed. clients who are very much in the 21st century.
I don’t see what any of that has to do with ‘convince me that I need MVC’ though.
You need MVC if you want the experience with your work product by other people to not be horrible.
There are ‘lighter’ MVC frameworks out there, though Coldbox is lighter than it sometimes gets credit for. MVC is just a pattern. FW/1 folks tend to like FW/1 because it “just” does MVC and then gets the heck out of the way. There are fewer moving parts, so if the potential 19.1% performance hit is a concern for you, you could audition FW/1, but even if the performance hit were double what it is, I’ll take the *box ecosystem and our experience optimizing Ortus libraries (or having Ortus optimize them) over any of the other available choices; nothing against FW/1 but it’s not in active development. We auditioned it years ago when it still was and found it worked great but that Coldbox made our lives as a small development shop much easier when we considered the big picture, recruiting other developers, and (especially) modules.
I’ve been using different frameworks throughout my career: Fusebox, FW/1, CFWheels and now ColdBox. I’ve enjoyed them all.
It’s already been said but the biggest benefit of any framework is the organization of the code. It doesn’t matter which flavor of MVC you’re using, you just always know where everything is. You know the data access is going to be in the model, anything rendered to the user is going to be in the view and the controller just ties it all together. It’s just that simple and it’s also why Uncle Bob hates it: He says it’s just too boring and that every app looks the same! He’s exactly right and that’s the whole point.
I’ve always worked in small shops. Most projects I’ve jumped into are brownfield (legacy) projects and I’ve created a few greenfield projects too. I don’t hesitate to use a framework for a greenfield project. It’s just too easy. Now, for a brownfield project, I would never recommend a project that simply converts 100% a non-legacy project to an MVC enabled project. That’s a waste of time and can be dangerous given the scope of the conversion (and project rewrites seldom work anyway). However, if you do want to start to streamline and organize all your projects, I would (and have) create a hybrid where all new functionality goes through the framework. This way, and slowly over time at very little cost, you’re getting every project on the same page.
I also find that I use the same framework tools over and over again to save a lot of time. RESTful routing, error handling, ORM and interceptors are few of my favorites because they really cut down on my development time. I hear you when you say you’ve rolled your own and that it works. And if you truly work by yourself and will continue to do so, that’s just fine. But down the road, if you bring on help or grow your team, that’s when a standard organization shows its real value.
It also helps cut down testing time because, again, you know where everything is and you can re-use test code (and create example for others to follow).
As for performance, personally I really haven’t noticed much difference short of the initial loading time. Sure, it takes a few more seconds to load the app but once it’s loaded it performs just like any other app.
Is there a bit of “drinking the Kool-Aid” involved? Sure. But just like Git, VSCode and Docker, sometimes adding a new tool to your box is worth it.
@dbelanger’s answer is one of the better ones on this thread, but there’s something - and I think it’s the most important thing - that no-one else seems to have mentioned (at least directly).
It’s not always gonna be you maintaining this code. Eventually someone else will be in your seat and needing to deal with whatever you’ve written, and if the code adheres to accepted industry-wide design patterns (and using accepted third-party libs), then they’re gonna go “OK, I know where to start here”.
If they sit down and instead they see SpecialLionelWayOfDoingThingsThatIsJustMadeUpBecauseReasons they are likely to go “WTF is this shit?”. Almost certainly any given web dev is just not going to come up with a better way of doing things than just sticking to the widely-accepted design patterns. You might have had a cool time reinventing a wheel, but the people after you are just gonna roll their eyes and think yer a twerp, and they’re not going to have a cool time maintaining your code.
Now… you might not care that they think yer a twerp, but that doesn’t mean they’re not right, and yer just making their life harder purely because of yer own hubris. Don’t be that twerp.
Design patterns and standard practices are there for a reason. Sure: one should not cargo-cult them, but also one shouldn’t either dismiss them out of hand just to be a unique little snow flake.
Second to that it’s just way easier to get going if one uses a framework - which does most of the boring repetitive shit for you out of the box so you can focus on implementing the code for your USP. So it’s just a better use of your time to not get into the business of wheel-reinvention.
I see quite a lot of “Not Invented Here” going on in the CFML community, and to a lesser extent in the PHP community: “why have you… why have you reinvented logging? (and badly). Monolog / LogBox already does all this. Better. And written and maintained by someone else so we don’t have to worry about it. And it just works”.
To me the premise of this thread is basically an exercise in validating a case of NIH.
