The best framework == no framework To be clear, I have no issue with anyone who chooses to use frameworks and/or third party dependencies, this is just my opinion. Here is my story. Not long after I joined this slack channel, I was told I was misinformed (by an influential person here). From his perspective, for me to gain anything here would require I understood the prevailing tools and frameworks used by those in the community. Then, not long afterwards, I was turned down from a gig partially because of my "inexperience" of using one of those prevailing frameworks. This made me take a few steps back to see where I was wrong. So after hours of study, I still have the same opinion. Frameworks are not worth it. Not just CFML, but for any language such as NodeJS, Go, Python, Ruby and most especially Javascript. Writing clean code specific to your app is not as hard as you think. If you think any code without a framework is "spaghetti", then who is misinformed? If you have a job that demands it, cool. Go with what the boss wants. But if you have a choice, consider going outside the comfort zone, and build something great without a framework. It might be a breath of fresh air.

I agree but disagree. All of the below - comes with the following caveat. "As long as you are using it, as it was designed to be used". A framework provides a consistent "way" to develop your application. By virtue of "enforcing" it's rules upon the developer. Want to run "A" - "B" - "C" in that order when you press the LOGIN button - a framework spells out "its" method for letting you do that. Want to run "1" - "3" - "7" in that order when you press the GENERATE REPORT button - a framework spells out the same method - that you used in the LOGIN form, for you to process the GENERATE REPORT button. Irrespective of the button you click - the framework ensures that the shape of your code is the same for all "buttons". • That the "config" for "actions" - are always "here". • The code for a individual action is always "here" • etc. For a team - it means that "John" and "Bill" and "Me" - (pretty much) code the same way, for all things - because I HAVE TO - because of using the framework. It also means (well it is supposed to mean) that when you need to "step outside" the framework - that code becomes obvious. I would argue - that even if you're not using "xxx-Box" / FW1 / Mach-II / FuseBox... If you're doing a "professional" job - your aim is to ensure that the "shape" of all your code looks the same no matter what. Subsequently - I would argue that you ARE using a framework... It is just that you are using YOUR framework. Subsequently, the day will come that an software developer is the cause for killing someone - and "professionalism" will be forced upon us. (IMHO) you will have to prove that your code is using what is considered "best-practices" - whatever that looks like for Software Development - that will most likely be set by some over-seeing "Software Engineering Board of Ethics", SEBE. Much like we have "The Bar" for lawyers / "Certified Practicing Accountants" / etc.

It seems like the distinction is around sharing more than anything else. Which tracks with my view of libraries (of which frameworks are one) being force-multipliers more than anything else. I don't think it has much to do with conformity, per se, and I dread the day when you cannot freely share code. I know a lot of people who fear AI (or more aptly ASI) fear the open sharing of information, and therefore fear open-source software, but I am relatively sure their fears are unfounded— and indeed, a form of "category mistake" — as the problem ever was, and perhaps ever will be, how you use it. I might be missing something, but I don't see any way in which having "professionalism" forced on software development leaves room for open source software, and from there maybe it's speech that needs to be regulated, as it were. (Code is generally considered protected speech.) All that said, "provenance" is going to continue to get more important, and we do need to pay attention to the force-multipliers we use (and the force-multipliers the force-multipliers use (JavaScript I'm looking at you)), as it's turtles all the way down so to speak.

Hey Gavin and Denny, thanks for the great points. With best practices, let's hope that software development remains an art, not an AI contrived assembly line. Although I'm not concerned that will ever happen. Force-multipliers are like having a hammer, and everything looks like a nail. Oh, let's build a single page website... We have to use React with SSR cause it will make us look cool and give us job security. And besides, that is how xyz company does their site. As ridiculous as it sounds, that kind of thinking happens every day.

I would hope that when software development is forced to become a "professional" endeavour - that the implementation it is never stipulated. But I could see something like; • Must use "A" version control tool. • Must use "A" deployment tool. • Must have a coding standard and prove it is enforced. • Must use a "system" for application design. For the last one I am thinking along the lines of you would argue in an "Audit" that your system is XXX, YYY XXX is a design pattern that has been published / peer-reviewed / proven. YYY is an implementation of a design pattern ZZZ YYY is peer-reviewed ZZZ is a pattern used to solve 1, 2 and 3. The "system" - is specific to your domain. The tools / libraries / frameworks / etc - help YOUR SYSTEM.. The "system" is domain specific - and includes THIS and THIS and THIS, because of A,B,C. The tools / libraries / frameworks are an implementation detail - not a directive. The "Audit" process is about do you have a system? Are you enforcing the system Is the system reviewed? Is the system fit-for-purpose?

Force-multipliers are like having a hammer, and everything looks like a nail. Oh, let's build a single page website... We have to use React with SSR cause it will make us look cool and give us job security. And besides, that is how xyz company does their site.

"Mens rea" is pretty important! For what it's worth, I don't think that "to get a job" is a bad reason to learn a skill (which I think drives a lot of the "less practical" stuff), and speaking of less practical stuff, not even "to keep up with the Joneses" is a bad reason, per se (we are tribal (and hopefully always will be, because variety is the spice of life (tho hopefully better at working together as tribes as well))— so we'll always have things we do just for looks, kinda)… but like all things, some moderation is needed. The reason I like React (note I like most all frameworks/libraries, this is for example) is because I liked the Dojo Toolkit, and React felt like the spiritual successor, so to speak. Accessibility was high on their list of requirements, which is Just Plain Good™, and they were using modules, and had a decent handle on state (which is always kinda hard), etc. There are tons of great tools that all do the same sorts of things, and while I don't think you need all the things all the time, I think to some extent stuff like accessibility should be baked into everything. Standards are also a form of force-multiplier, and often arise first in libraries before making it into their respective cores. Instead of "library" or "framework" or "force-multiplier" or "standards", it can also be seen as _"teamwork"_— which as we all know "makes the dream work" 😃

Cue: Monty Python sketch entitled "What have frameworks ever done for us" (ref: )

I used to work for a major company working on software for airplanes. Needless to say, bad software there could kill people. Lots of them. So there were very strict standards for the development process, how the code was written and tested, etc. However, there weren't any frameworks that I recall. Just seriously professional software engineering. Having programmed for many years now, I can say that was the only time I really was a software engineer. I still try to always do professional work, but building an informational website doesn't require nearly the same level of detail that an embedded computer on a aircraft does. Framework or not, do good work.

Use the right tool for the right job (thats the engineering bit, knowing what the problem is and being aware of appropriate solutions), frameworks / libraries are just another abstraction on top of high level languages which build on all the work that has gone before and the lessons learnt. By all means re-invent the wheel because yours is the best wheel ever, but good luck re-inventing that nuclear reactor.

which build on all the work that has gone before and the lessons learnt. By all means re-invent the wheel because yours is the best wheel ever

This sums up the situation well. Only a fairly... adolescent-level developer would think they know better than everyone else in the same situation who went before them. This in itself is reason to stick with established frameworks. But sadly these are the very devs who "just don't get it". And there's plenty of other reasons to not flout industry standard approaches to things just cos one thinks one knows better. But it's a self-correcting environment as demonstrated here:

I was turned down from a gig partially because of my "inexperience" of using one of those prevailing frameworks.

Well. Quite. Ppl don't wanna hire ppl who don't have industry experience and think re-inventing the wheel is a thing one ought to be engaging in in 2024. But, obviously... you do you.

I suspect the "influential person" who said you were "misinformed" was either Adam or myself... Why use frameworks (or even libraries)? • They save you writing a bunch of code -- plumbing and/or boilerplate -- so you can focus on the application's business logic instead • They have been battle-tested by hundreds/thousands of other users -- unlike your own code • They provide a consistent architecture for your applications -- so any developer who knows the framework can jump in and be productive, instead of wasting time figuring our your custom flows

I was turned down from a gig partially because of my "inexperience" of using one of those prevailing frameworks.

...and what were the other reasons? Reasons I have turned candidates down, when hiring, include: • Lack of experience with basic OOP concepts (for CFML) • Lack of experience with automated testing (and I'm not even talking about TDD) • Lack of experience with version control (sad, but true) • Lack of experience with bug tracking systems (also sad, but true) • Lack of even basic comprehension of automated build & deployment pipelines (CI/CD) If all you're building are basic HTML CRUD apps, sure, you can hand craft those but that is a very tedious and inefficient way to work when you have the option to reach for something like Rails (or ColdBox or whatever -- nearly every server-side language has tooling to write this boilerplate for you). If you're building anything more complex -- especially if you're building an interactive frontend app in JS -- you just won't be able to compete with someone using a framework.

If you have a job that demands it, cool. Go with what the boss wants.

Most jobs demand it these days -- and developers without that experience (and especially developers who appear to be anti-framework/library) are not going to get any of those jobs. It's 2024, not 1994 🙂

I misread part of that as

... you can hand cruft those...

Seems fitting, that said.

Hey Sean, no it was not you, it was Nolan. And I totally agree on using frameworks on complex applications. Totally makes sense. But most apps are not complex, and don't require more complexity with a framework. And Adam, this is just my opinion mate. You don't need to be a curmudgeon. Oye.

But most apps are not complex

I guess it depends where you work. I haven't encountered a "not complex" app for about thirty years at this point, except for toy/demo apps...

And Adam, this is just my opinion mate. You don't need to be a curmudgeon. Oye.

You posted your opinion in a public discussion forum. Clearly soliciting feedback. I mean like otherwise why bother?

curmudgeon

Play the ball not the player mate. If you have a case to make... make the case. Don't resort to ad hominem. Like I don't take offence, but it's a pretty weak response.

Adam, I do have respect for you, but I am not the first to call you a curmudgeon :) Everyone is free to have their opinions, you certainly have yours. If you and Nolan really think I "just don't get it" I don't take offense either. I voiced an opinion, you are free to say I'm full of it if you like. But through it all, I still have the same opinion, I have not been convinced otherwise.

I strongly agree with Adam, Sean, and Nolan. You're not going to change your opinion, so I won't bother with the long response I had typed up. But you'll find yourself having more and more difficulty in any job hunt. No matter the language.

Yeah, I'm obviously a lone wolf. Thanks Mark!

I'm starting a lone wolf club, gonna call it "Lone Wolf and Club" 😃 There are pros and cons to everything, but we're never not standing on the shoulders of giants— for good or ill. I believe that as more and more security issues arise over time, you'll see some push-back around using popular libraries, just as a matter of course. It's sort of like life's failover— diversity If everyone is using the same library, that is a single point of failure, and single points of failure are not good— as we just saw demonstrated again with Microsoft So from that standpoint I'm with you Bill, but since it is "giant's shoulders, all the way down", it's hard to get on the "best framework is no framework" train— they are unavoidable… and maybe if we're being good citizens (or whatever), we're sharing our work for others to stand on as well. For what it's worth, I love that I'm in a country where starting your own business is relatively easy, and where there are tons of people that need better (or even any) applications, and basically room for everyone (which I think is really most of the world but USA USA USA lol) For all my fierce independence, teamwork does make the dreams work, and that's why I like open-source… you don't have to call it a framework, or a library, or even an app, but whatever you call it, sharing is caring. 😃 Thanks for sharing your opinions Bill, and everyone else— it was an interesting thread! 🍿

You just made my day Denny, thanks! And for what it is worth, I know full well I don't know everything, but like you I admit my independence. There are some brilliant people on this channel for sure... And I do listen to what they say. Cheers, Bill

But most apps are not complex

Sure, day one it is not complex, but the chances are that you're going to need to evolve that application so it will become complex over time, so why not just use a framework before it becomes too complex to retrofit a framework?

@Bill Nourse Interested to understand why you feel frameworks aren’t for you; Initial setup a hassle, pattern doesn’t fit problem, learning curve, 3rd party dependancy or just general “reasons”?

I've in fact been slowed down by using a Framework (FW/1 in my case). But that may be largely in part that I was implementing ORM, which became tedious to setup and make adjustments, not to mention needing to reinitialize the app for chnages to the table objects. The only feature that would tempt me to use it again on a future project is the routing and dependancy injection features. I personally am not convinced of the MVC pattern and think find keeping logic seperate from presentation markup(html) is sufficient.

@brendan I would say perhaps your real problem there was using an ORM 🙂 I've used a lot of ORM implementations over the decades and I consider them all terrible for anything but the most basic CRUD features. MVC is a really solid pattern, ORM often messes up your architecture.

I never posted a long thing I was going to do on the deployment thread, but if you do it right, ORM is more good than bad imho. Here is an excerpt: … first is

localdev

(this is local development env.) due to massive amounts of data, you basically never have the full set locally, so instead you have a tool that grabs what you need— think like a "shallow" git clone of a massive repo, but for data, with some simple stuff to grab either the last few days of data, or some targeted range. You do your local development here. You've got your schema versioned, and you can safely turn on things like Hibernate's auto-schema feature (or else run some other model syncing tools) which you never run anywhere else. If the schema changes, either automatically or due to SQL you create yourself, you know it (this check is automated), and so you take that change and create a "migration" form it. Usually this is just copying the generated SQL into a numbered SQL file in a "migration" directory. …

Hey @dougcain, thanks for asking. As Denny aptly pointed out, everything we do with code is by standing on the shoulders of giants. In other words, the language and tools we use have been provided and shared by others... Who I admit are a lot smarter than me. Knowing that, I don't have an issue with frameworks or the people who build them. I have an issue with unnecessary complications. Frameworks come with a cost... sometimes justified, sometimes not. Consider these... 1. They inhibit flexibility... conventions are predefined (I admit it is justified on a complex app) 2. They increase dependencies and vendor lock in 3. They reduce performance and increase weight (even Ortus will admit that) If I was tasked to build a complex application using a team of developers, I would choose an established framework. As this provides a predefined set of rules right from the start, which is good. But if I was tasked to build an API as a service, I would not use a framework, you really don't need one... Even if it means (as Mark says) I won't get the job 🙂

@Bill Nourse, at least one of your recommendations has some merit. Particularly, your opening declaration, "The best framework == no framework". I had to give it a second read. I then realized that, in a way, that is deep sh*t, The recommendation has a long tradition. It evokes a design-system recommendation that goes back 2600 years. For example, Confucius emphasized the importance of virtue and propriety over the use of laws and regulations. A second example is Wu wei ("zero action"), one of the founding principles of Dao philosophy (600 BCE - 200 BCE). As third example, Shuhari. Shu, Ha and Ri reflect ancient methods of mastery that have been part of Japanese culture for centuries. All three states Shu, Ha and Ri are important. The initial states, Shu and Ri, are analogous to using a framework. But the mastery state, Ri, transcends beyond form, design and system to create a new approach. There has been a long "no framework" tradition in the West, too. From Aristotle's Posterior Analytics ("... the best is that which needs no premises and the better that which needs the fewer...") to Occam's Razor (design parsimony) to the software principle closest to Occam's Razor, KISS ("Keep It Simple, Stupid"). In conclusion, "no framework" can be a viable solution in some cases. In fact, history shows that it may even be the optimal solution.

Hey bkbk, thank you for your comments 🙂 One thing for sure, there are several great thinkers in this channel, just amazing. From your angle I suppose you could include Adam Smith and his invisible hand theory versus governmental regulations. Not being political, his philosophy suggests less guidelines lead to optimal outcomes.

Frameworks are just libraries of code, if it fits, then use it. Probably some errors to be avoided just because someone solved the problem for you already, no need to fall into trap again. But yes, this also means adding more code to project (adding 1000 functions to project when using only 10) eg. node_modules jokes are all around. I personally don't like 'heavy opinionated', 'all and kitchen sink' frameworks, but I do like and use structural frameworks like fw/1 or flask in python. There is room for homegrown frameworks too - I worked with rather nice Coldfusion code which was just structurally well organized, didn't used any of framework, but files were cleverly separated so they not stick into one huge Carbonara :)

Mmmmmm carbonara...

Surely if your Carbonara is "stuck" together - it's just a bad a bowl of pasta!

One person's bad bowl of pasta is another's life-saving meal… so as in all things, the only sure-fire rule-of-thumb or advice is: "it's all relative" (long-form of "it depends!"😃)

y'all making a man hungry over here lol

Erratum for my last post: please read,

"The initial states, Shu and Ha, are analogous to using a framework."

in place of

"The initial states, Shu and Ri, are analogous to using a framework."