CFWheels Scaffold?

Hi Guys! I am trying to decide between PHP/Laravel and Lucee/CFWheels for an upcoming project.

I was wondering if anyone is still using CFWheels in 2025? Are there any Github repos with scaffolding/starter kits setup already? Login, etc.

I like PHP, but man CFML in Lucee is king and I miss it :-). However, I have not done any CFML projects since Coldfusion 4.5 or 5, I think - years ago.

I am just trying to make a list of convincing reasons for the business to justify it over the PHP solution. Thanks!

Just found GitHub - cfwheels/cfwheels-example-app: A CFWheels 2.x App with user management, role based permissions and password resets . Bit dated but I will look into it.

@til, as you await hearing from others on their use (or observed rate of use) of CFWheels, I do want to at least point out that the project has been evolving recently, especially with the injected enthusiasm the past couple of years of Peter Amiri (@bpamiri) and others. Indeed, I’d thought he may have replied by now. :slight_smile:

While you may have found these already, I’ll point out first news of recent active development:

FWIW, the current 2.5 major release had come out Nov 2023, with 2.4 in 2022 and so on.

As for scaffolding, the getting started guide shows how simple it is to get an initial app up via a single command in Commandbox:

I realize you may be seeking more “scaffolding” than that alone. That’s the first page of AMPLE documentation, available via the left nav bar. There are also wheels plugins at forgebox, though only one is updated since 2020.

Finally, you can of course find recent discussions (and news) at cfwheels/cfwheels · Discussions · GitHub along wiith more on the framework generally (including their blog) at https://cfwheels.org/… which is being renamed to https://wheels.dev/, as discussed a few weeks ago in a post at Celebrating 20 Years of CFWheels: A Look Back and a Step Forward as Wheels.dev | CFWheels Blog

Sorry if anyone feels I’m “doing what anyone could do on their own”. Again, my main point is to stress that it’s alive and well as a cfml framework. I don’t use it (or any, as I don’t do professional development any longer), but as an observer of the community it just seems news worth celebrating, along with other vigorous cfml frameworks, since the question was raised. :slight_smile:

4 Likes

Thanks @carehart, appreciate the info.

If you haven’t been around cf for a while, get to know commandbox as @carehart mentioned, it’s a real time saver.

Sorry to be late in responding. Til I use CFWheels every day at work. We have a major B2B ecommerce site built on the 2.x version. We are kicking off a new major project and we are basing it on the upcoming 3.0 version. (Basically dog fooding our the project). I would definitely recomment a CFML platform vs. a PHP platform. At the core of it, PHP is single threaded and that can lead to long request times on PHP systems that get more complex.

Commandbox had modernized the CFML developer work flow. Here is a work flow of how to scafold an entity with the 3.0 codebase. This set of commands creates a new Wheels app, scafolds a User entity, adds a few properties to the entity. This will create all the crud based operations and pages.

wheels new

This goes through a wizard to create a new Wheels application.

wheels scaffold

This starts a wizard to create a User resource.

wheels g property user firstname
wheels g property user lastname
wheels g property user email

These add additional properties on the User resource.

As you can see CFML has come a long way and is on par with other modern tech stacks. I’m obviously partial to Wheels but I can reasure you that the framework is being actively worked on and extended.

Let me know if you have any other questions I can answer for you.

@til, I for one question why the business you’re working for has narrowed it down to only those two options and particularly why a Ruby on Rails style framework is apparently a definite requirement.

I remember some decades ago when the company I was working for at the time decided to migrate from ColdFusion to Ruby on Rails. While I recognized the benefits of scaffolding, MVC, and ORM, it also seemed I was the only member of the team who was more concerned about its many drawbacks.

At first I thought maybe I was just being a stick in the mud because they didn’t involve me in the decision and I’d never even heard of RoR, plus they relegated my role to solely DBA tasks with no app dev, thus my lack of RoR experience became a Catch-22. They barely even needed me at all since the scaffolding did so much for them … or so it seemed initially. Well actually I don’t know how it turned out for them long term because that’s when I decided to focus on my own entrepreneurship projects … and I’ve been a sole proprietor ever since. So yeah … thanks Ruby on Rails!!! :joy:

With the benefit of hindsight I now realize I was more spot on than I knew back then. While scaffolding is highly effective for rapid prototyping, simple CRUD applications, and enforcing architectural consistency, its usefulness diminishes for more complex or performance-critical applications where greater customization and control are required. The value of scaffolding depends on the trade-off between development speed and long-term maintainability, and its questionable just how much the development speed benefit really is (see below).

From an SQL and DBA perspective, scaffolding and ORM introduce significant limitations in terms of query efficiency, schema design, and performance tuning. Those features tend to abstract away critical aspects of database optimization and control, leading to long-term performance and maintainability issues.

They often produce code that requires significant modification to meet real-world performance and design standards, effectively negating its initial speed advantage. My philosophy has been that if I’m going to have to tweak, fine tune, and refactor all of that scaffolded code eventually, might as well not scaffold at all and do it the right away from the start!

Furthermore, modern IDEs and AI-assisted tools (e.g. Windsurf) now provide intelligent autocompletion, boilerplate generation, and context-aware suggestions, reducing the need for scaffolding while allowing greater control over the codebase from the outset.

I’ve had a similar critical reaction to MVC, preferring to separate concerns manually with .cfm scripts (controllers) in the main web root folder, templates (views) in an include folder outside of the web root, and database queries in a folder of .cfc files (model) also outside of the web root.

The benefits of scaffolding and ORM are further negated by a proper Git deployment process that incorporates .sql scripted database changes. With a well-structured Git workflow, developers can track and manage code changes in version control, ensuring that every modification—whether to the application code or database schema—is transparent, repeatable, and easily reverted if necessary. Instead of relying on auto-generated migrations or scaffolded database structures, scripted SQL changes allow developers to have full control over database optimizations, indexing, and schema design.

By integrating version-controlled database scripts into the deployment process, the need for scaffolding is diminished, as database modifications are clear, explicit, and optimized for the specific needs of the application. Additionally, this approach ensures that all changes to the database are consistent across development, staging, and production environments, reducing the risks of discrepancies or poorly optimized auto-generated queries.

Ultimately, combining a disciplined Git workflow with manual, optimized database scripts not only removes the reliance on the framework, but also promotes better scalability, performance, and maintainability over time.

Well, I don’t expect anyone’s preferences to change based on what I’ve said here, nor am I likely to change based on any replies that might be forthcoming. :wink: I just wanted to share my own thoughts as obviously I have a very different perspective!

That’s my cue. :slight_smile: I really have nothing to contribute to this potential debate. Hope what follows is edifying for all concerned.