Why FubuMVC Failed, a bit of a retrospective
Jeremy D. Miller
FubuMVC was a technical success in some nontrivial ways (modularity, diagnostics, testability) and for a while around 2010-2012 we had a decent little community, but it fell very far short of the hopes and goals I had for it. I think it’s safe to safe to say that the biggest causes for its failure was the lack of documentation or examples, being late to deliver a good getting started story (fubu new was showing a lot of promise late last year), and the general lack of community building. I think that simply having had more contributors and users providing feedback early would have made a huge difference.
FubuMVC was originally envisioned way, way back in 2008 when most rendering happened on the server side and using jQuery to “progressively” enhance the actual browser experience was cutting edge. Fast forward to 2014 and many of the capabilities in FubuMVC that I thought were cool like html conventions, lots of server view helpers, and the old asset pipeline are largely unnecessary and unused when folks moved to single page application architectures where the server is mostly just slinging around JSON. At the same time, FubuMVC was weak when it came to low level HTTP manipulation and didn’t have much to support building hypermedia services. While FubuMVC 1.3 and 2.0 embraced external OWIN middleware, I think it was just too late. For fans of Stephen King’s Dark Tower books, “the world moved on.”
The early focus on conventions and especially the build your own (meta-) conventions was probably detrimental for understanding FubuMVC and in getting a new project started. In retrospect, I think we would have been much better off if we’d picked out the baseline conventions very early on and made them well known. On the whole, I think we put far too much emphasis on conventions to the point where it was awkward to do one-off configurations on single endpoints and far too often made code difficult to reason about because so many behavioral aspects were happening in other places than the application code. NancyFx and Simple.Web and even the MS tools are better in this regard.
FubuMVC’s focus on minimizing ceremony code simply didn’t resonate with most developers. I think that it turns out that many developers will accept much more repetitive code if it means that the code will be more explicit. Any future effort will need to create a better balance between our emphasis on “clean code” and being explicit in intent.
The FubuMVC/FubuCore/Bottles ecosystem was simply too huge for the small handful of us who were trying to maintain everything. Any future effort should be much more focused. FubuMVC also suffered severely from NIH, and while tools like FubuValidation, FubuLocalization, and Ripple might have provided some value by themselves and integrated quite well with FubuMVC, but these efforts spread us way too thin. In retrospect, we might have been better off creating integrations for commonly used tools like FluentValidation. FubuDocs, “fubu new,” and FubuCsProjFile sucked down an absurd amount of my time last year.
The BehaviorGraph/BehaviorChain model created a tremendous amount of flexibility that I have never seen equaled in any other web framework on any platform, but at the cost of making FubuMVC seem absurdly over-complicated. Customizing FubuMVC, especially before 2.0, required way too much knowledge of how policies were applied and the order in which things happened at bootstrapping time. It got easier in 2.0 when the framework itself got much smarter about ordering configuration actions for you, but that was too little, too late. In future efforts I would recommend ditching the “everything is a behavior” design idea.
Globally applicable policies and assembly scanning killed us. Policies were great, until they started applying and mixing into places where you didn’t want them (like adding transactional behaviors to diagnostics chains). Globally scanning any Bottle assembly for services for automatic container registration was disastrous. The move in FubuMVC 2.0 to separate policies into globally scoped vs. local scoped policies helped tremendously but came too late.
The FubuMVC ecosystem never got the build automation quite right and spreading the code between all the different code repositories made this issue much worse. FubuMVC projects became fairly difficult for newcomers to work with because we were so far outside of the mainstream and Ripple was never very successful. We originally divided the FubuMVC.Core assembly up to achieve faster build times and more responsive VS.Net usage when the codebase started getting large. In retrospect, the effort to coordinate development across multiple repositories did far more harm than good. The opportunity cost of developing Ripple alone was massive. If I had it to do all over again, we would have kept almost everything in the main FubuMVC repository and used multiple Rake scripts and Visual Studio.Net solutions to pick and choose smaller working sets as needed. Part of this I blame on the poor state and immaturity of the Nuget tooling in .Net. Even though I consider it to be a failure, we were better off with Ripple than we would have been trying to use Nuget OOTB across multiple repositories but developing it was still a big time sink.
The choice of Rake for build automation was off-putting for many people and might have hurt us in attracting contributors. MSBuild is a terrible tool and everything else is just as fringe as Rake in the .Net world, so I don’t know what we could have chosen instead. Starting today, I think I would opt for Gulp or maybe FAKE or even pure Make, but who knows? I do know that we would make sure that you could build in VS.Net out of the box without having to run a build script just because so much of the .Net world is so absurdly attached to VS.
We never had any integration to Visual Studio.Net for FubuMVC, but I’ve never regretted that. While it would certainly have helped adoption, I think it would have been a time sink that would mostly have been useful for a “dip the toes in the water” experience rather than for daily development.
For IoC container integration, I think we played it the worst way possible. Either we should have made FubuMVC completely dependent on StructureMap and ditched the goofy IoC abstractions (ObjectDef) or we should have adopted other IoC containers much earlier. Too much of FubuMVC’s behavior was based on StructureMap (which is of course the exact right way an IoC tool should work;)). If we’d adopted other IoC containers earlier it would have forced us to use IoC internally in a much more vanilla fashion and we would have more quickly supported other tools than StructureMap. Simply supporting Windsor, Ninject, and maybe Unity would have helped our early adoption. The caveat to this is my observation that frameworks that abstract the IoC container either reduce the container to lowest common denominator usage or simply integrates very poorly with all but the first IoC container to be integrated. NancyFx is a perfect example of this problem as it was built around TinyIoC and its StructureMap integration is abysmally implemented.
There was just flat out too much churn. FubuMVC development could be described as a whole lot of furiously throwing spaghetti against the wall fast and seeing what stuck. I should have known we were completely dead when many early adopters didn’t bother to upgrade to the SemVer 1.0 version for over a year. In retrospect I think we should have actually done much more upfront analysis about some of the innards and had a better sense of where we wanted to go. In this case, building features out just in time for whatever big project I happened to be doing then trying to smooth everything out later in the lead up to 1.0 and later in the 2.0 effort wasn’t helpful.
Performance both at runtime and bootstrapping were a significant issue, but I’ll address that later.
Kijana Woodard
--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel.
For more options, visit https://groups.google.com/d/optout.
Adam Schröder
Ryan Kelley
Gleb Chermennov
среда, 17 сентября 2014 г., 1:01:06 UTC+4 пользователь Jeremy Miller написал:
Jeremy Miller
On Tuesday, September 16, 2014 5:20:01 PM UTC-5, Kijana Woodard wrote:
On the IoC front, I recently read http://blog.ploeh.dk/2014/05/19/conforming-container/ which helped me understand friction around several projects in this regard.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-devel+unsubscribe@googlegroups.com.
Jeremy Miller
Rob Reynolds
Personally I think Rake + ripple is great toolset for .NET developer, especially if one target Mono as runtime. I learned quite a bit from both technologies, and it's certainly better than writing clumsy Powershell scripts. I didn't look at Fake yet, will have to check it out.As for NuGet, it's getting better, but they certainly made some bad decisions right from the start. Many times I read anger tweets about version numbers embedded in folder names; restore command appeared fairly recently.
--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel.
For more options, visit https://groups.google.com/d/optout.
Rob
"Be passionate in all you do"
http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder
