Can anyone expound on disadvantages, if there are any, to using a ColdFusion development framework? I'm developing an application traditionally, and I'm tempted to use a framework having seen how simple some things can be done.
I'm new to ColdFusion and frameworks in general. I want to understand the implications of using a framework, including advantages and disadvantages.
Disadvantages:
learning curve (pick a lean framework to reduce this)
front controller makes ugly URL, often needs URL rewrite on web server layer
risk of framework being discontinued (no support, hard to maintain, break on new CF ver)
framework bugs (pick a popular framework with good & fast support)
harder to debug sometimes, since actions are generally not a .cfm anymore. Tip: make use of cfdump and cfabort to see the dump in the controller layer
some frameworks takes longer to reinit. Since most frameworks will cache the configurations and controller layer for performance, during the development phase, you'll need to reinit all the time. CF9 eases this problem 'cause it is much faster.
lastly, sometimes you'll be using framework's API, an abstraction from CFML, and missed out on the native ColdFusion way of solving the same problem.
Performance generally is a non issue. Don't worry.
Henry's already given a good answer, but I would just like to pick up on this part of your question:
But does it not come with a performance tax?
The performance overhead of a framework is negligible.
In fact, you may even get better performance from frameworks such as ColdBox, which have built-in caching.
Remember, most frameworks are mature codebases used by lots of people - most likely, your newly written untested code is going to be the culprit, not the framework.
However, as a general rule (not specific to frameworks) performance is not a problem unless you've got measurable results that say it is.
i.e. don't just think "I'm going to do X instead of Y because I think it'll be faster" - go with the simplest option that meets user's needs, and only change it if you can prove that it has a performance problem and that your proposed solution is better.
It depends the nature of project you are into. I think its always advisable to use a frameowrk for better code organization, scalability, conventions and other. If you are supposed to start with a enterprise level application then coldbox is the best framework as far as my expriece goes. It has a bigger learning curve but its worth learning. If its simple start up project then FW1 is good. You can find a list here
http://www.riaxe.com/blog/top-coldfusion-frameworks/
Related
I hope this question be worth of answering and well asked! I have a couple of projects using Ktor. I have studied about Quasar and I know it has Comsat for web backends. As you know, Ktor uses fiber and NIO! With this notice, does rewriting the projects with Quasar (Comsat) makes them perform much (noticeably) better than Ktor?
It is hard to answer this without knowing the details and requirements of your project.
You could start by making a feature table of both using the feature you need or might need. If there are a significant amount of features missing or that would require too much time to adapt, it might not be worth changing platform.
To compare performance the absolute best would be to write a minimal Quasar app with the features you want to test so you can directly measure the perfomance based on your needs and use-case.
I'm asking the question after reading this article
http://stevehanov.ca/blog/index.php?id=95
Also isn't it a penalty to use cgi instead of fastcgi ?
Update: why some people do pretend like in answer "that you get 20-30% performance improvement" ? Is it pure guess or is this number coming from solid benchmark ? I have looked at HipHop performance is more in the scale of 10 times.
I've done webdev in a few languages and frameworks, including python, php, and perl. I host them myself and my biggest sites get around 20k hits a day.
Any language and framework that has reasonable speed can be scaled up to take 20k hits a day just by throwing resources at it. Some take more resources than others. (Plone, Joomla. I'm looking at you).
My Witty sites (none in production yet) take a lot more (from memory around 5000% more) pounding (using seige) than for example my python sites. Ie. When I hit them as hard as I can with seige, the witty sites serve a lot more pages per second.
I know it's not a true general test though.
Other speed advantages that witty gives you:
Multi threading
If you deploy with the built in websrever (behind ha-proxy for example) and have your app be multi-threaded .. it'll load a lot less memory than say a perl or php app.
Generally with php and perl apps, you'll have Apache fire up a process for each incoming connection, and each process loads the whole php interpreter, all the code and variables and objects and what not. With heavy frameworks like Joomla and Wordpress (depending on the number of plugins), each process can get pretyy humungous on memory consumption.
With the Wt app, each session loads a WApplication instance (a C++ object) and it's whole tree of widgets and stuff. But the memory the code uses stays the same, no matter how many connections.
The inbuilt Web2.0 ness
Generally with traditional apps, they're still built around the old 'http request comes in' .. 'we serve a page' .. 'done' style of things. I know they are adding more and more AJAXy kind of thigns all the time.
With Wt, it defaults to using WebSockets where possible, to only update the part of the page that needs updating. It falls back to standard AJAX, then if that's not supported http requests. With the AJAX and WebSockets enabled clients, the same WApplication C++ object is continually used .. so no speed is lost in setting up a new session and all that.
In response to the 'C++ is too hard for webdev'
C++ does have a bit of a learning curve. In the mid nineties we did websites in Java j2ee. That was considered commercially viable back then, and was a super duper pain to develop in, but it did have a good advantage of encouraging good documentation and coding practices.
With scripting websites, it's easy to take shortcuts and not realize they're there. For example one 8 year old perl site I worked on had some code duplicated and nobody noticed. Each time it showed a list of products, it was running the same SQL query twice.
With a C++ site, I think it'd have less chance because, in the perl site, there wasn't that much programming structure (like functions), it was just perl and embedded html. In C++ you'd likely have methods with names and end up with a name clash.
Types
One time, there was a method that took an int identifier, later on we changed it to a uuid string. The Python code was great, we didn't think we needed to change it; it ran fine. However there was little line buried deep down that had a different effect when you passed it a string. Very hard to track down bug, corrupted the database. (Luckily only on dev and test machines).
C++ would have certainly complained a lot, and forced us to re-write the functions involved and not be lazy buggers.
With C++ and Java, the compiler errors and warns a lot of those sorts of mistakes for you.
I find unit testing is generally not as completely necessary with C++ apps (don't shoot me), compared to scripting language apps. This is due to the language enforcing a lot of stuff that you'd normally put in a unit test for say a python app.
Summary
From my experience so far .. Wt does take longer to develop stuff in than existing frameworks .. mainly because the existing frameworks have a lot more out of the box stuff there. However it is easier to make extremely customized apps in Wt than say Wordpress imho.
From people I've spoken with who've moved from PHP to Wt (a C++ web framework) reported significant improvements. From the small applications I've created using Wt to learn it, I've seen it run faster than the same PHP type applications I created. Take the information for what you will, but I'm sold.
This reminds me how 20-30 years ago people were putting Assembly vs C, and then 10-20 years ago C vs C++. Of course C++ will be faster than PHP/Rails but it'll take 5x more effort to build maintainable and scalable application.
The point is that you get 20-30% performance improvement while sacrificing your development resources. Would you rather have you app work 30% faster or have 1/2 of the features implemented?
Most web applications are network-bound instead of processor-bound. Writing your application in C++ instead of a higher-level language doesn't make much sense unless you're doing really heavy computation. Also, writing correct C++ programs is difficult. It will take longer to write the application and it is more likely that the program will fail in spectacular ways due to misused pointers, memory errors, undefined behavior, etc. In general, I would say it is not worth it.
Whenever you eliminate a layer of interpretive or OS abstraction, you are bound to get some performance gain. That being said, the language or technology itself does not automatically mean all your problems are solved. I've fixed C++ code that took many hours to process a relatively simple set of records. The problem was in the implementation, and the fix was not related to the language's features or limitations.
Assuming things are all implemented correctly, you're sure to get better performance. The problem will be in finding the bugs. One of the problems with C++ is that many developers are currently "trained" or accustomed to having a lot of details related to memory management behind objects. This eliminates the need to consider things like, "What can happen if I pass this pointer around to several threads?" Sometimes it works well, but not always. You still have some subtleties of the language that you need to consider regardless of how the objects hide the nasty details.
In my experience, you'll need several seasoned C++ developers watching over the code to be able to keep the bugs and memory leaks from getting out of hand.
I'm certainly not sold on this. If you want a performance gain over PHP why not use a Java (or better yet Scala) framework? These are much better for web development, have nice, relatively easy to use frameworks and avoid a lot of the headaches of C++. I've always seen one of the main pluses of web-development (and most modern non-scientific/high performance applications) as being able to avoid the headaches that come along with C/C++ development.
We have a medium sized ColdFusion code base for our Intranet and Website. For most of the history of the code we have used hard coded links in the cfm's for where to go and for what 'save' code to tun.
In the last few years we've began using cfc's to handle more of the "navigational" code as well as more automated save code (implicitly calling the save process for a given cfc on init)
Assuming that it makes sense to begin using a framework, is it better to begin using it for newer projects or attempt a full scale conversion?
EDIT
To avoid confusion, I'm sensing that by moving to more cfc based code we are going down the path of accidentally creating our own framework. It seems to me that taking a proactive step toward using a proper framework and allowing the cfc's to process data is probably a wiser choice.
I'd only put the effort into a conversion if you were spending more than 10-20% of your time maintaining the project. (Your threshold my be lower or higher.) Other than that, use it just for new projects.
Why? I think the conversion is going to be painful, laborious and potentially a waste of valuable time.
"Assuming that it makes sense to begin
using a framework, is it better to
begin using it for newer projects or
attempt a full scale conversion?"
I would say that the biggest criteria for whether you should move to a framework are:
Am I spending a good amount of time maintaining current code, and is it difficult?
Am I repeating a lot of code? Do you find yourself writing a lot of the same thing over and over when adding to the current project?
Depending on how large the application is, it might be worth it to convert a current application to a framework if it saves you more time down the road by making maintenance easier and reducing code repetition for future additions to the current project. If you rarely maintenance the application except for a few tweaks here and there, then I would say leave it alone and use a framework only for new applications.
Frameworks have a short term cost and a long term gain.
When we start out without one we usually start building one over time indirectly to increase re-use of code, and make things more structured..
I have been a big fan of Fusebox, probably because I've just used it for so long.
What I have done in the past is, if I know the site will never be updated in into any real website functions, I just roll my own cfswitch to navigate between actions. each action I simply break down into the dsp act qry type files fusebox likes.
If ever I need to put it into fusebox, most of my circuits and actions are already done. The path forward is a bit easier.
On the other hand, if I know the client may want more in the future, I will just put it in a framework and leave it at that.
On a sidenote, I have also been checking out the very impressive ColdBox -- which seems to have some fantastic support, scalability and very well documented is cfc intensive... check them out too..
Have you considered using a framework such as fusebox instead of rolling your own? If you begin using a framework on new projects you might then find it easier to apply what you've learnt to existing projects.
I'm looking to create a new site and in order to encourage myself to create a powerful API for others to use, I'm tempted to write the API and use it myself to build the the actual site. The idea being, if it is capable of running the primary site, then it will give other users plenty of options to put their own spin on things. It will also encourage me to keep the API up to date.
What I'd like to know is whether this idea is worth going with, or whether its just plain nuts.
Is this common practice? Will it likely result in over complicated code? Will it cause performance issues if (by some chance) the site was to take off?
Thanks in advance.
It's a great idea, as long as you are doing it for yourself and not using up someone else's time/money.
Writing your own framework from scratch is a great way to teach yourself about planning and writing code. It may take a long time and be a long adventure, but I can personally attest that it forces you to become an expert in everything.
For anything that is being developed on someone else's dime, or which is mission-critical (security or performance) however, I would recommend re-using an existing framework where it is logical to do so.
It is common practice to build a public api and consume it internally, and from my experience it results in cleaner code (rather than maintaining two sets, one internal, one external). There may be a performance hit, but I would not worry about that too much until you see some real demand. Otherwise you can get yourself wrapped around solving problems that don't exist.
Definitely a good idea. Always program to an interface, not an implementation. So consuming your own API makes a lot of sense and not doing so is probably a form of redundancy.
The one thing to watch out for would be early optimisation. Do you really need all that functionality?
There are some really great APIs already. Why reinvent the wheel?(I'm assuming this is what you want to do)
What are the smashing (pun intended) features of grok that makes it better than django?
how do I know when my project needs grok+zope, or it can just be developed with django ?
Zope was the first object publishing framework evah, and the Zope community has a long experience with Doing Things The Right Way. Zope 2 was the first attempt, Zope 3 was the next attempt, and we are now into the third generation of web frameworks, which includes Grok, BFG and Bobo.
Grok is massive, and has even more modules available that doesn't come when you install the base (and it's in the process of reducing the number of required modules as well, so the footprint gets smaller). BFG and Bobo go the other way around, and are minimalistic frameworks but with easy access to the Zope Toolkit and all the functionalities of Zope.
And although Django is making many of the same mistakes Zope2 did, they are also fixing them much faster, so I completely expect much of this discussion to be moot in five years, because I expect every single Python web framework to use WSGI+WebOb+Repoze+Deliverance+Buildout as a base by then. But even then I'd go for frameworks where I can use the Zope Component Architecture and ZODB, but that includes not only the ones made by the Zope community, but also for example Turbogears. And maybe it will include Django too by then, who knows... :-)
Depending on what the project requirements are I would today go with either Plone (if they need CMS), Grok or BFG (depending on the involved developers, and the complexity of the task and the budget). This is of course partly depending on my large experience with the Zope technologies and my small experience with Django, but mostly because I can use ZTK and ZODB in Grok and BFG.
YMMV, etc, blahblah.
Zope Toolkit
Brandons talk on the Zope Component Architecture (Video from PyCOn, Slides from PloneConf)
BFG
Bobo
Grok is basically all the power of zope in a way easier to use package. So you do get all the luxury of a real python object database (though you can use an sql backend). And I assume you know about the adapters/utilities/views of the so-called "zope component architecture". Those allow you to make a robust application. Especially handy if you later need to selectively customize it. And security is traditionally a zope (and thus grok) strong point. Development and deployment are handled fully with eggs (and buildout): in my experience this is a robust and reliable and repeatable and comfortable way.
If you have an application that can work with straight sql tables without needing much selective customizing afterwards: nothing wrong with django. You'll have to do much security yourself, so that needs a keen eye. There's much less of a framework behind it (an ORM and a url mapper), so your python will feel more "pure and simple". This also means you need to do more yourself.
There's nothing from stopping you from selectively using parts of grok: http://pypi.python.org/pypi/grokcore.component for instance is very much the core. Pretty well isolated, so you can use it without buying into the whole zope stack. I'm pretty sure you can use that in django. grokcore/zope component is just python code. This gets you the adapters/interfaces/utilities. I don't know what you're building, so you'll have to experiment.
One thing hugely in favour of grok that I'd suggest trying out: zope's ZODB object database. A good ORM (and django's is pretty ok) helps a lot taking the pain out of SQL databases, but a real object database is just plain luxury :-)
I don't think any of the frameworks are intended to have any 'features' that make one 'better' than the other, or 'needed' in certain circumstances. Rather, the difference between Django and Grok - or Pylons, or Turbogears - is really one of approach. You may find the approach of Grok to your liking, or you may prefer one of the others. I doubt there is much you can achieve in one of them that you can't in any of the others.