Explaining My Problem with Frameworks
I have tried time and time again to find an elegant way to describe what it is about Fusebox and frameworks in general that I don't like. I think that my trouble orating these issues is a contributing factor to all of the dialogue.
This weekend I was up in New York having lunch with Shlomy Gantz, and while talking about his beef with FB, was able to perfectly summarize my feelings in a single sentence. "My problem with Fusebox is that it solves a bunch of problems that I don't have"
Yup, that just about says it all. Thanks, Shlomy. You'd think that being an instructor and author I'd have touched on this simple explanation myself years ago.
This weekend I was up in New York having lunch with Shlomy Gantz, and while talking about his beef with FB, was able to perfectly summarize my feelings in a single sentence. "My problem with Fusebox is that it solves a bunch of problems that I don't have"
Yup, that just about says it all. Thanks, Shlomy. You'd think that being an instructor and author I'd have touched on this simple explanation myself years ago.
I look at it as the ability to implement certain design patterns. That may be a bad choice of wording... But everything I build, even applications that have no similarities, are designed in similar ways. The framework just allows you to design a certain way. That's not to say that it restricts you in anyway, for other fellow fuseboxers may take a completely different approach to certain situations, and yet they use the same framework. And even then, we'd still both pick up each others approaches in a matter of no time.
So it really has nothing to do with whether a framework is used or not... that's completely irrelevant. You have your own methods of designing software, as I do. The difference is that my method is aided by "helper files". You may have helper files as well. Maybe you like to use CFC's? Do your applications require CFC's in order to work? Many times not. But CFC's do help many people design software in ways they like. And those people may use CFC's as objects or simply as collections of udf's. How's that any different with using frameworks? Application.cfc and cflogin are just helper frameworks just like fusebox, do you dislike those as well? The same concepts are occur there as well.
So when you dislike frameworks like FB, you're also saying you dislike how FB sites are designed and built, yet you really have no idea how any of my sites, or the sites of other fuseboxers are designed in built.
"XML was a great solution looking for a problem"
tie that in with
"when you have a hammer, everything looks like a nail..."
just my 2c worth...
I've never been restricted when using Fusebox. So could you elaborate on that?
Brian, this is reason I was never sold on the fusebox approach:
Everything goes (submits?) back to the index.cfm (the fusebox) and different actions (the fuses) execute depending on the value of the FuseAction URL variable. Is my understanding accurate?
This approach reminds me of a "Main Routine" approach (it may have another more official name that I do not remember). Basically, when an [traditional / non-web based] application starts the main routine is executed. This main routine doesn't do anything other than calling other routines.
I do not have a problem with that approach for traditional apps. After all you are only running a single program and everything is self-contained. However, in terms of web development I find it easier (and better) to view each page as a separate program, especially since they all execute in isolation of each other. The "main routine" approach that fusebox uses does lend itself well to this type of thinking.
It might be interesting to note that ASP.NET uses a fusebox-reminiscent style with Web forms. The Postback and Viewstate variables define the page's state and decide what code to execute based on their values (similar to how the Fusebox decides what to execute based on the FuseActio). The purpose of this was to make it transparent to move from windows development to web development; and that is something it does relatively well.
The "main routine" approach that fusebox uses does *NOT* lend itself well to this type of thinking.
To me, the fusebox framework (im not speaking of other frameworks which I have not had a chance to try yet) is great for developers that are trying to just get started and get something churned out quickly that other developers can work on with them. But if you have time to plan (which in a perfect world we all would) a methodology would be just as easy to maintain and a lot less code to write. I have used fusebox for about four projects now and in each of them I ended up writing more code and spending more time than I would using my general methodology. So thats how I feel that fusebox restricts me.
Sorry, just couldn't help fueling the debate ;)
All this being said, I am glad to have learned it so if I go to a consulting position that uses fb already Ill be up to speed, but any project I work on where my opinion is required, I will always suggest not using it. my two cents...
Ryan said "It oftentimes gives me errors that are less than helpful which is something im just not used to when working with coldfusion. A simple xml error like not closing a self closing tag can be quite hard to track down and fusebox just tells me which page its on. (a good ide can help this, true, but to me it should be able to tell me exactly where in the error message)." XML errors of any kind are difficult to determine in CF. But it is very easy to use an XML editor that autopopulates and validates the tags/attributes from the DTDs.
Ryan said "Everyone keeps telling me that the circuits are great because you can look at them and tell about the flow of the entire application. I don't see that at all." Not sure what to say here because when done correctly, the circuits *are* an excellent roadmap of what is happening.
Regardless of why the xml errors are a problem, the fact is they are a problem for me. I don't have trouble writing code, but when I make a small mistake like missing a /, it shouldn't be so difficult to tell me where that is. Maybe thats a problem with working with xml, but regardless, xml is what I have to work with.
I dont want an xml circuit telling me the roadmap. Thats what documentation is for. And regardless, I don't see any possible way that you could write your fuseactions in your circuit that could make it easy for me to glance at and read. I would love to see how you do it though, that may help me in my progress with the fusebox apps we do have.
Heres the main point for me though. I have to learn fusebox. I have to learn syntax, I have to learn fusebox best practices, I have to learn fusebox architechture, all this, just to build a simple application. Im not learning coldfusion, Im not learning patterns or object orientation, or anything else that I can apply to things besides the fusebox framework. At the end of the day, I *am* writing more code, and I *am* doing more work to get the same thing done. Methodologies don't require you to learn new syntax and things that you shouldn't already be learning for other reasons. Things like how to work with objects effectively and actual language best practices. These things are general programming techniques, things that I can describe to someone writing php, asp, java or anything else and were on the same page.
So, if you can't agree with me that the things I have mentioned about fusebox that I don't like are restrictions, surely you do agree that having to learn a framework like this to use it is extra requirements. And in my opinion, the extra requirements are too expensive for the few benefits.
Simon makes an interesting point that his methodology "requires developers to have stronger application development skills" (he says this of methodologies vs frameworks). If your development skills are strong enough, you can write good code with any framework.
So we seem to have some consensus that a framework helps less skilled developers build maintainable code (although it isn't a silver bullet) and that highly skilled developers can use frameworks too.
Which means that if you have a team of mixed skills, especially a large team, perhaps geographically spread, using a framework should provide a set of common reference points without requiring that every member of the team have "stronger application development skills". That seems like an easy win to me: a little compromise by the lead developers to assist all of the junior developers. Isn't that what teamwork is all about?
Anything outside of these two points is "cream" in ones coffee.
Frameworks in many shape or forms are simply code templates to extend outward on, and aren't there to solve all developers problems in one hit. The FuseBox frameworks origins stemmed from how to separate a procedural code solution into something that hints at "abstraction".
Somehow over the years it's mutated and adjusted to the new additions Coldfusion has thrown at it.
If you are a solo developer and are currently using a framework, it will most definitely feel like you are jumping through countless hoops to solve virtual problems resulting in an overall bad experience with the chosen framework. Yet, the moment you suddenly find a problem with your laid out architecture, you are also now able to communicate your problem without asking your listeners to play pre-lude catch-up. Furthermore you can seek advice on how to re-arrange code-base in a more efficient manner. Then there is the fact that if you get hit by a bus, someone can come along and go "ahah, Mach-II, I know what to do here".
To me, there are a number of deciding factors that are at play when I develop a team or project, the main aspect is Communication.
When you write an application and have to sit in the world of "debug queues" you kind of need a way to communicate your "pain points" in a manner that doesn't require extra translation. If you utilize a common framework, you can do this quite easily, as it's a manner of keeping your listeners focus on the context of the problem and not everything else surrounding it.
It also has to do with "scalability", if you need to swap components in and out, how do you cater for that? If all your co-developers have their own disparate way of implementing various portions of logic and you need to somehow dislodge a component or inject one, how will your architecture cope in this regard?
Frameworks exist for a tone of reasons and each solve various problems, some even overlap but the point is this: They are there for a reason, not because a coder got bored one evening and decided he/she would add to the overwhelming mass of already existing frameworks.
It's a matter of first understanding what problems are solved before using a framework, too many people pickup OO Patterns and Frameworks simply because "All the other kids are doing it, so why not me".
I feel into that category and now have the luxury of reflection, and thanks to my peers and their patience I've come to that conclusion, choose because you find it solves not because it simply exists.
The irony of all is that Coldfusion in its current state is actually a grouping of existing J2EE frameworks (i.e. Jasper anyone?) all being "glued" together via common backbone, entitled CFML.
- Hopefully i'll be at MAX this month, and would love to catchup with any who wish to cry about frameworks into a beer or two hehehe..
When I was writing my books the publisher decided the number of CF Developers was half a million (500,000). I doubt the number of CF Developers has more than doubled over the past 3-4 years.
I thought that this was the number being thrown around when MM acquired Allaire (However, I have also heard 300,000 as the number).
Perhaps this is a minor point, but... does anyone have any current estimates as to how many CF Developers their are?
I have no idea how many CF developers there are in the world, but my point doesn't change with the numbers. Here's an abstraction so that my sentence is more portable: "Oodles of developers out there use this framework, so it is very easy for someone to take my well documented code and quickly jump in and maintain it in my absence."
However, I do think frameworks can be a valuable tool for people that want to use them. I'm just not one of those people.
I agree with both of the former assertions (but not the latter, obviously).
I think I got confused. My statement was intended to be framework-independent.
I believe I meant the second. It's easy with code documented and structured, as opposed to difficult to work w/ undocumented / unstructured code.
Any [competant] developer should be able to work with structured / documented code regardless of whether it was built using a framework or not.
If they have trouble working with structured / documented code, then that would trigger incompetance flags in my mind.
Did that clarify for you?
Though I do agree Simon that if you're going to post about it in a negative way you have to be prepared for the response! You said "I was just feeling a little bit like a one man army under siege from attacking foes." and it's funny when I get into debates like this on CF-Talk or elsewhere I often feel the same way but on the other side. Anyway good luck with your talk.
Try to learn & use coldfusion perfectly rather than debating about various Frameworks. If you know 90% of the built-in fuctions and tags, you can write better quality code than what u can accomplish with less knowledge and using frameworks.
So guys, better learn Coldfusion deeply..
Frameworks are tools that many experienced coders use to organise their application code. Typically, framework users have turned to frameworks after several years of 'traditional' development. Frameworks are not an alternative to knowing CFML (or any other language) and their adoption or eschewal has nothing to do with how many CFML functions and tags you know.
(I suspected that he was our old friend, the 'ColdFusion Purist' writing under a pseudonym!)
Last night I watched the CF 10 year birthday party video, the party that was held this last July in Newton (I think). I found it very interesting listening to all of the original CF coders talk about priorities and motivations behind CF (including Tim Buntel). They kept comparing CF to 'pure' languages like Java and C++ ('they' being the Allaire bros. and 2-3 of the original employees). One discussion really got me thinking. Tim Buntel asked the guys what kind of things led them to the java rewrite, and what challenges they faced. All of them talked about the decision to leave CF an easy, but not 'pure' language, and how they feel they made the right choice. So I ask this:
A lot of low level languages have these rules:
1. Case sensitive variables, functions, etc.
2. Strict scoping
3. Strict variable typing
I'm sure there are other things that I can't think of, but when I look at all of the activity surrounding the framework community, I am reminded of these 'pure' languages. I'd love to hear some of your comments on why CF isn't a 'pure' language, and if it should be, and how this relates to the frameworks.
Technically, ColdFusion is an application server, encompassing much more than just the language. CFML is the language.
Speaking in terms of CFML, I'm not sure why it would not be called a programming language. I'm not sure what makes up a programming language "pure" or not.
With the introduction of CFCs, I'd say that CF is now on par w/ other languages I have worked with in terms of encapsulation features of the language.
I never worked with a case sensitive programming language before Java Is C / C++ Case sensitive? I thought not, but I could be wrong.
I'd like to see ColdFusion offer stricter (?different?) variable scoping rules. For example, if I create a variable inside a function, why can't it be "local to the function" by default. Why must I specify it as local using the var keyword?
CFML is clearly a programming language. A lot of people like to complain that CF is not pure enough, in that it doesn't do the 3 things mentioned in my previous comment, and other things. I am not one of those people.
"Java Is...Case sensitive?"
I was once told by a Java programmer, "Java is VERY case sensitive, as all programming languages should be".
"Why must I specify (a local function variable) as local using the var keyword?"
I'm sure the CF engineers know what they are doing, and I'm sure they'd have an answer for you. Similar questions one could ask: Why isn't CF case sensitive? Why aren't CF variables strictly typed? Etc, etc. Listening to the ColdFusion founders in that birthday party video, I'd say the answer is that CF is supposed to be easy, yet powerful. The Allaire brothers kept referring to CF as magic, because of its ease/power combination. Do we really want to take away the magic by making CF a 'pure' language? What about frameworks, then?
I've heard of complaints about CF as a programming language, but never that it was not pure.
Since very few languages are case sensitive, I'm not sure why that is a point against CF.