Sean Corfield wrote on 11/04/09 4:37 am

How good is FW/1?

Well, the 70+ folks on the FW/1 mailing list seem to love it and there are already some sites in production using FW/1.

Can FW/1 hold its own against the big frameworks?

How would you measure this? By definition, these "lite" frameworks do not have all the features of the bigger frameworks - but that is by design, based on the premise that not all developers need those features. The bigger frameworks have established user bases and communities. Time will tell whether any of the smaller frameworks gain such traction.

Is FW/1 really easier to pick up and run with?

That I'll say "yes" to, and point people at the Getting Started Guide:

http://fw1.riaforge.org/wiki/

Four lines of code across three files gets you a working FW/1 application.

FW/1 as a learning tool / stepping stone?

Because it's easy to pick up, I'd hope that FW/1 offers an easy on-ramp for anyone considering a framework. If they can happily build applications with it, they may not need to go elsewhere. FW/1 wasn't built as a stepping stone, it was built as a simple, self-contained framework. It already has a real community and real production sites are running on it (and I haven't really promoted it much). Can it serve all your needs / everyone's needs? No, but no framework is a one-size-fits-all deal. I've used CB / FB / M2 / MG over the years and they each have pros and cons. I expect I'll use FW/1 more and more over time tho'...

Hobbyist vs Real Developer?

I built it for real developers but I won't be upset if hobbyists use it too :)

Lite vs Monolithic?

FW/1 has some over-arching design principles that will keep its scope under control. One of those principles is that the framework should be a single, self-contained CFC. Anything that would break that model would be refused as an enhancement request. FW/1 was 'born' almost feature complete and the (fairly well-commented) code is still under 750 lines. I'd like it to always stay in triple digits which is another limit on scope.

Barney Boisvert wrote on 11/04/09 8:30 am

First, my framework's name is "FB3Lite" not "Fusebox Lite". I believe the "Fusebox" name is protected, though obviously that is the intent of the "FB".

I haven't used FW/1 or LightFront, but I happen to think FB3Lite is pretty nice. I pretty much use it for any app I develop, and after I used it for a little one-off app at work, it quickly was adopted as the standard framework for our team (replacing Fusebox 5) pretty much behind my back.

I think a "lite" framework can certainly hold it's own against a "big" framework. It's all based on need. The former are focused on minimalism (I've studiously avoided the 100-line mark on FB3Lite), while the latter are focused on meeting a wide array of needs. If you need lots of things from your framework, you either need a "big" framework, or you'll need to piece together a bunch of smaller things to get what you need. But if you already have some of those smaller bits in place, using a "big" framework for filling in the last couple can be an oversize burden.

In many ways, it's similar to the coupling/cohesion dichotomy often discussed in OO circles. I want small and tight, so FB3Lite is perfect. I also don't want binding between my front controller and other parts of my app. For example, Model-Glue requires ColdSpring to run. What if I don't want ColdSpring? What if I have the wrong version and can't upgrade? Suddenly Model-Glue isn't a choice because it's too coupled to external dependencies. Not a slight on Model-Glue in anyway, I might add, just an example.

As for hobbyists vs. real developers, I think a lite framework carries an advantage to hobbyists because there is less to learn, but that doesn't detract from it's utility to real developers. I.e. the two populations' usage are not correlated; they're based on different criteria. Same thing goes for a stepping stone to a "big" framework. If you start "lite" and need more features, "big" might be the solution, but I don't know that there's any sort of progression. It could easily work the opposite way: using a "big" framework has too much cruft so a "lite" framework is where you step to. The latter is what we've done at Mentor; Fusebox was a stepping stone to FB3Lite.

I don't feel any pressure to increase the functionality of the framework. It does it's job very well, and it doesn't attempt to do any other job. When there is functionality required that the framework doesn't provide, the next question is SHOULD the framework provide it. To this point, the answer has been "no" every single time, either because it's extraneous or because it would complicate the core usage.

Like Sean says of FW/1, FB3Lite was born pretty much feature complete. Code has been added for a couple bug fixes and edge cases not initially covered (UDF argument name collisions, use as a recursive custom tag, etc.), but it's still 72 lines of code (115 if you include include blank lines and comments) and unlikely to grow much beyond that.

AJ Mercer wrote on 11/04/09 9:21 am

Sorry Barney - I have renamed your Framework.

Brian Meloche wrote on 11/10/09 1:36 pm

I tried to resist commenting... but I guess I'll say a few things. LightFront's still a work in progress. That's how I see it, although others seem to think it's more fully baked than I do. :-) LightFront's core will not expand beyond dealing with the model, and a simple plugin architecture, possibly with the model becoming a plugin. The plugins will extend the core, but the core itself will not expand beyond that. It may get above 300 lines, but not much more. Plugins would include other frameworks, libraries, applications, etc.

I wanted to build a simple controller framework, in the spirit of the ease of ColdFusion itself. It should EXTEND ColdFusion, not complexify it. I built LightFront with the intention that a junior developer could learn it, understand it and use it productively.

Is LightFront a framework on "training wheels"? Yes, but that doesn't mean it's not powerful. I think you can build in LightFront ANY complex application as well or better than one of the bigger frameworks. With its limited scope and speed, it frees you to be able to take a more natural development path than other frameworks can.

LightFront is a framework... though calling it a "framework" is something I'm not all that comfortable with. I want LightFront to be able to go where other frameworks cannot. I want it to be small enough that an architect won't have a conniption fit if you use a "framework". Perhaps it is a controller "library of functions"? I don't know. I'll call it a framework, but call it something else if it'll help you use it at your company.

LightFront also needs to build up some documentation. I'll contend that LightFront doesn't NEED a lot of documentation, but it will need more than it does now.

OK... I'm done!

Nathan Stanford I wrote on 12/09/09 9:01 pm

I have longed for a lite framework. I have grown to HATE a lot of frameworks. I will not go into details.

I am excited about the new frameworks coming up and I will try them all.

Since most web applications are in Maintenance mode much longer then creation mode, I want as little complications as possible.

If a big framework can do this then Awesome. However I tend to want the lite versions.

I for one am a Real Developer. I think a lite framework is much easier to sell now. If you have to do to much to explain your framework then some groups will not adopt it.

Web developement needs rapid application development but with a eye for maintenance. I do think the eye toward what some think is PERFECT code, which there is NO such thing. I say if doing something cool or awesome makes maintenance harder then I don't like it.

Again I hope more people develop lite versions and versions that require less maintenance for when developer has moved on.

I started to develop a framework years ago then lost time to work on it.

~Big Nate

AJ Mercer wrote on 12/09/09 9:38 pm

Hi Nate,

Thanks for your comments.

I have decided to focus my energies on FW/1.
It is amazing how much it can do for a single CFC.

I started wondering what the heck is going into those other frameworks.
But now that sub-modules has been added to FW/1, I think we will see a lot of 'plug-ins' appearing (security, logging, persistence/ORM/...) that when are all loaded and configured may start to approach the size of the other frameworks.