ColdBox and FW/1 and CFML's shrinking market?

[Sean Corfield]

I posted a shorter version of this on the FW/1 Slack and – somewhat to my surprise – got no feedback at all on what I expected to be the controversial part, so I’m posting a longer version here, in order to get some discussion going. I hope! There are several questions for you at the end that I really want to hear answers to. And I want a lot of you to respond, not just the handful of “usual suspects”!

 

First off, the non-controversial part…

 

If you haven’t already seen it, I’d recommend reading Tony Junkes’ blog post about using a ColdBox module as-is with FW/1:

 

http://tonyjunkes.com/blog/working-with-fw1-and-qb/

 

I didn’t realize it was even possible – to use a ColdBox module _unchanged_ with FW/1 – let alone that it might be this easy!

 

Well, of course it’s not going to be that easy for all modules in general, because ColdBox provides a different set of extension points to FW/1 and modules that leverage those are going to be harder to use with FW/1 than those that don’t. But this – and a few recent discussions on Slack – raises the question: Can FW/1 make it easier to reuse more ColdBox modules? Can FW/1’s documentation offer guidelines on writing ColdBox modules in ways that are easier to use across both frameworks? Those questions are at the heart of this FW/1 issue:

 

https://github.com/framework-one/fw1/issues/486

 

If you have any experience with ColdBox modules, I’d welcome your input on that issue.

 

Now the part where I had expected at least _some_ feedback…

 

It was interesting for me that these questions came up because I was already having some meta-thoughts about how FW/1 ought to evolve in the context of our community and our tech stack. Years ago, there was Fusebox. Then there was Mach-II (the framework formerly known as FuseboxMX, BTW). Then Model-Glue. ColdBox. FW/1. And several others along the way (anyone remember onTap?). The CFML world was expanding and there was plenty of room for a lot of variation. We saw multiple DI/IoC frameworks arise, and multiple testing frameworks (cfUnit, cfcUnit, MXUnit, TestBox), and a bunch of ORMs (ObjectBreeze! ARF! Transfer! Reactor!).

 

What happened?

 

A few of these died out because they were superseded by better frameworks but, if we’re honest with ourselves, the majority of them died out because the maintainers moved on to other technology. At this point, the CFML world is shrinking – we can’t really argue that isn’t the case: it’s just a natural process in any technology – and with key maintainers moving on, we naturally gravitate toward other projects that have active maintainers who are staying with CFML. That means that pretty much by definition, we’re in a phase of consolidation where we coalesce around fewer and fewer frameworks – and those frameworks gain market share (albeit of a smaller market) but they also tend to gain more contributors and better documentation etc, as the focus of the over community narrows, and those folks who naturally want to contribute feel pulled in fewer directions.

 

There are really only two main camps these days: ColdBox and FW/1. Three if you count cfWheels but it’s had a number of near-dormant periods over the last several years and it seems to have very little traction overall, despite an enthusiastic community (and, interestingly, a _much_ more active mailing list than either ColdBox or FW/1 – although their Slack channel has less than 1/3 of the number of members for either).

 

There’s no doubt about it: ColdBox is the juggernaut here. They have a whole team of people, consultancy focused on the various framework add-ons, a thriving module community, they have ForgeBox and CommandBox and TestBox. They’ve cornered the market in three key areas: package management, command line tooling (across both CFML engines), and testing (both xUnit and BDD). Both FW/1 and cfWheels use ForgeBox for packages and they are both completely dwarfed by the number of ColdBox (and ContentBox) modules.

 

And so I get to contemplating what does the future for FW/1 look like in this world? Can FW/1 more closely align itself with ColdBox to take more advantage of the extensive ecosystem there? What does it look like for FW/1 to leverage ColdBox modules? What do the migration paths between FW/1 and ColdBox look like (in either direction)? Are those even feasible paths?

 

Something I’ve been thinking about a lot is: could FW/1 make it easier for users to migrate to ColdBox?

 

WAT! WAIT!! WHY???

 

Whilst I can probably make some headway on having FW/1 reuse ColdBox modules, that’s probably going to add a whole bunch of ColdBox-isms to FW/1. I’m going to guess some of those modules rely on WireBox annotations – should DI/1 support those annotations? Should FW/1 support all of the ColdBox lifecycle extension points in order to support modules? Should FW/1 support “all” of ModuleConfig.cfc in order to wire up those modules?

 

How far down the ColdBox-compatibility path should FW/1 go? At what point would FW/1 stop being “FW/1” and become “ColdBox-Lite”? Any new functionality added to FW/1 to support ColdBox modules has to be documented and tested and supported. If FW/1 became ColdBox-Lite, why would anyone use FW/1 when they could just use ColdBox in the first place?

 

So I think that line of reasoning says “There must be limits to how much FW/1 adds, in order to achieve the goal of (some percentage of) ColdBox module reuse.” and so we must look at exactly how much machinery folks – that’s you lot! – think is acceptable to add to FW/1 in the first place.

 

Why do you use FW/1?

 

I always said I created FW/1 as a reaction to framework bloat, back when there were still several MVC frameworks out there actively being maintained. FW/1 was intended to be different. Simple. Slim. Invisible. As it’s evolved, I’ve tried to maintain those original goals but the reality is that the framework has grown a lot: FW/1 itself is 3,000 lines, DI/1 is 1,000, the framework folder is about 5,500. It now has a dedicated documentation site that runs close to 3,000 lines of markdown per version. The test suite has 100 CFCs totaling just over 3,400 lines of code. And it relies on TestBox for that. And CommandBox for Continuous Integration, as well as for packaging and release management on ForgeBox (I finally stopped doing the manual process!).

 

So why do you use FW/1 instead of ColdBox? They both leverage the same infrastructure, they’re both convention-based MVC frameworks, they both offer a convention-based DI/IoC with configuration-based ways to override the conventions. What are the differentiating factors that make you choose FW/1 instead of ColdBox?

 

ColdBox offers a lot more…

 

…more documentation, training, consulting, the Ortus Developer Week (of which I was recently reminded – twice), its own conference (Into The Box), and overall a close relationship with Adobe that has led to ColdFusion Builder plugins and more visibility at Adobe events. And of course, all those modules that started this whole thread (although not this line of thinking on my part!).

 

So, seriously, why FW/1? What keeps you here?

 

And, on the flipside of that question, what if it was easy to migrate your FW/1 application to ColdBox? Would you do it? How easy would it need to be?

 

And, finally, what might cause you to abandon FW/1 for ColdBox? What changes to FW/1 itself or how the project is maintained and/or supported would drive you away at this point?

 

Thanks in advance for all your feedback (I hope!),

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

[Cameron Childress]

On Mon, Aug 28, 2017 at 11:33 PM, Sean Corfield wrote:

So, seriously, why FW/1? What keeps you here?

I will preface this by saying that I fully admit I have not spent a lot of time in the ColdBox world and as a result probably have a poor understanding of certain details. However, having said that...

For me - I tend to see FW/1 as far more lightweight and lets developers make more design/architecture decisions on their own. ColdBox makes more decisions for the developer and "does more" on it's own. Many times this is an advantage but it isn't always one.

This makes FW/1 more flexible when adapting it into an existing app, or Mura plugins, or whatever you are trying to do that doesn't fit neatly into the ColdBox model. Most things can probably be done with ColdBox as well, but I feel like it would be in a heavier handed way.

Selfishly, one of the biggest reason I prefer to stick with FW/1 at this point is also one of the reasons I still do a lot of ColdFusion development. I know it very well and have some tool in my mental toolbox for a lot of the most complicated situations already. 

But really, reading between the lines of your posting, it sounds like you are thinking ahead for a time that you may not have the time or energy to maintain FW/1 as actively as you have thus far - which is a pretty incredible amount considering you don't do as much (any?) CFML development as you use to.

In my eyes, bringing FW/1 closer to ColdBox is not a problem. Adding some code to tie the two together more closely - not a problem.

I would have a small worry that if at some point in the future Ortus became the primary maintainer of FW/1 - it could start to become more closely tied to ColdBox that I would like. Just because it would be a smart business decision for them.

There is a lot of legacy code out there using FW/1 and I would want to make sure that code has a healthy path forward that isn't going to require a lot of re-write to stay working.

So really - I would definitely want to maintain the freedom to write FW/1 code without being automatically married to ColdBox as a result. This opinion could very well change in the future. 

-Cameron

 

--

Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[Phil Cruz]

+1

-Phil

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

[John Berquist]

Thanks for initiating this discussion, Sean. I look forward to seeing what others have to see and have some somewhat scattered thoughts of my own.

FW/1 came along at a time when I was trying to wrap my head around using a MVC framework, and its simplicity was a real breath of fresh air. Even at its current size (still small!), I really value the single file approach. It makes the framework lifecycle much easier for me to grasp. DI/1 similarly has a simplicity that gives it power. Everything is right there in `ioc.cfc`
and its API is minimal. At this point I understand what FW/1 and DI/1 do fairly well; generally speaking, they do what is needed and no more. I really value this. And I value the knowledge and experience that went into creating them. I know that you know what you are doing. I can easily say that FW/1 and DI/1 are the two most important pieces of software that I have used in my CFML dev career.

I haven't really looked into ColdBox itself in a while. I know that a lot of work has gone into slimming the core down in recent years and I am sure that I would be able to be happy using ColdBox as well. Clearly it is a fantastic framework too, one that receives significant development, and I really respect the developers who head that project as well.

You ask what it would take for me to move on from FW/1. Reflecting on this, there are probably two main reasons, one negative and one positive.

Knowing that the creator/chief developer of FW/1 is moving on (at some future date), and is discussing aiding migration off FW/1, has definitely made me consider whether it would be better for me to focus on what it would take to move the projects I am involved in entirely to the ColdBox ecosystem rather than trying to incorporate some aspects of that ecosystem into FW/1. I question whether FW/1 will be able to maintain its high quality when you have moved on entirely from the project. Now I certainly understand and respect that you have moved on in your own career to other languages. In fact, I think that your support of FW/1 has been fantastic considering it is not something that has a future in your own daily work. So, I guess when you move on, I could see myself moving on as well.

More positively, I see the ecosystem being built up around ColdBox as something I really want to be able to take advantage of - to the extent that it requires ColdBox to use, I can see myself moving so that it can be used. So I am glad to see the discussion around supporting ColdBox modules in FW/1. Not necessarily as such, but I am very interested in the use of `box.json`, ForgeBox, and the easy code sharing and version control they bring - all of which make it easier to reuse code across projects. I would very much like to be able to specify dependencies in a `box.json` file, run `box install`, and then have those libraries loaded by DI/1 in a standardized way, so that injecting them into my model is easy and straightforward.

So, regarding a path forward for FW/1, I think the following is a telling quote from your post:

 

How far down the ColdBox-compatibility path should FW/1 go? At what point would FW/1 stop being “FW/1” and become “ColdBox-Lite”? Any new functionality added to FW/1 to support ColdBox modules has to be documented and tested and supported. If FW/1 became ColdBox-Lite, why would anyone use FW/1 when they could just use ColdBox in the first place?

I am of the opinion that, the situation being as you have laid out, FW/1 becoming "ColdBox-Lite" doesn't make sense. But, as I said, I do think (echoing others) there is value in supporting ColdBox modules/ForgeBox libraries in some fashion, so that they can be easily used in FW/1 projects.

There could be several approaches to this. One you mention - supporting ModuleConfig.cfc and WireBox constructs in DI/1. The advantage I see for this approach is that it might enable numerous ColdBox modules to be used in FW/1 projects without the module author having to do anything specific to add support. But, as you note, this approach becomes a bit tricky when trying to decide how much support for WireBox/ModuleConfig.cfc should actually be added, how to deal with incompatibilities, and at what point it just turns FW/1 in a ColdBox emulator.

Alternatively, perhaps something could be introduced akin to `ModuleConfig.cfc` that is DI/1 specific. Could support be added for a CFC with a conventional structure (akin to `ModuleConfig.cfc`) that could be included in ColdBox/ForgeBox projects that DI/1 could find and use, that could wire those modules into DI/1? I suspect that many projects that could actually be used by FW/1 could do this fairly easily. Looking at a number of ColdBox modules I see instructions for using them outside of the ColdBox/Wirebox ecosystem or that are wired completely by convention. In either case I think it would be straightforward to add a CFC to them that would be called by DI/1 and could instantiate the appropriate CFCs from the library and add them to DI/1. Not being an architect, I am sure I don't see all of the pain points with this approach, but at least on the surface it appeals to me. I would happily add such a CFC to any projects I put on ForgeBox. The question is would ColdBox module authors be willing to do that? Perhaps there would be interest as it would help more people move into using the ForgeBox/CommandBox ecosystem. But it would be at least some amount of work for module authors.

In any case, I look forward to seeing what other FW/1 users' views are on the current landscape.

- John Berquist 

[Sean Corfield]

Since both Cameron and John touched on the question of my continued maintenance of FW/1, I want to provide some background to that…

 

When I designed and built FW/1 (back in 2009), I wasn’t using FW/1 for work. We used ColdBox and we are tied to a customized version of one of the prerelease 3.0 Milestone builds for all sorts of complex reasons. When we needed to add some new web apps (probably 2012?), we started using FW/1 for new apps. Last year we replaced those FW/1 apps with Clojure apps, as part of our overall migration to Clojure.

 

So I developed and maintained FW/1 for about three years while I was not using it for work and I’ve maintained it for about a year now since we stopped using it for work. I do not expect to use FW/1 for work at any point in the future. I’ve been working with Clojure alongside CFML since 2011 and over the last year or two we’ve shifted focus so that Clojure is our primary language. I am now the only person at work who knows CFML, aside from one co-founder who doesn’t know OOP or ColdBox, so I do any and all maintenance on our three ColdBox apps.

 

We’re rolling out all-new React.js SPAs now, backed by all-Clojure REST APIs, OAuth2, and several other new server processes. We hope to retire our largest ColdBox app by year end, or early 2018. We expect to rewrite our other two ColdBox apps during 2018. It may take a bit longer (they ain’t broke so…). Bottom line: in another year or two, I won’t be doing any CFML at all – except for continued maintenance of FW/1.

 

And, yes, I do plan to continue maintenance of FW/1 for a “while” but I can’t provide any guarantees of how long that “while” will be. I’ve hinted a couple of times over the last year or so that I’d like to see a couple of co-maintainers step up so I can mentor them and, ultimately, hand FW/1 over to them – simply because whoever is maintaining FW/1 really should also be using it on a day-to-day basis!

 

Since no one has volunteered so far, I’ve been considering migration paths so the existing community isn’t left high and dry. Consider what happened to Fusebox: a new maintainer took it over from me but then left the CFML space and 5.6 was never released, so the last official Fusebox release was 5.5.1 in March 2008. The closest migration “path” from Fusebox is really to FW/1 but it’s a lot of work. Mach-II and Model-Glue have no migration path. I don’t want the FW/1 community to be left in that same boat.

[Nando Breiter]

I've used FW/1 because it's more simple than Coldbox. 

I'm also put off by the religious quotes sprinkled throughout the ColdBox repositories and documentation. I've met Luis and he's a very nice person. I'm just not at all a fan of the Christian doctrine, especially when it appears as graffiti on my path. It's a very personal thing, but the whole human sacrifice bit turns my stomach, and it makes no sense at all. 

Luis writes something dismissive along the lines that "If you don't like this here, then too bad." So it's FW/1 for me, or Clojure, or something else. Again, it's a personal thing, and nothing against Luis himself. 

Aria Media Sagl

+41 (0)76 303 4477 cell
skype: ariamedia

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

[Richard Tugwell]

I also like the simplicity of FW/1 - the fact that it doesn't impose anything on you. I've grown very suspicious of "enterprise", "one size fits all" etc etc. I grew up in IT of the 70's and 80's where we wrote all our own software (UK banking for me). Then came things like SAP with the promise that you would never have to hire a dveloper again. The guys I worked with then who drove the Ferraris were all SAP consultants...... Nowadays I like lightweight approaches, and it's possible with FW1. I use it exclusively now for lightweight mid tier services to orchestrate the application. Haven't written a .cfm file for a while.

I also concur with Nando. Religion is at it's worst when it is imposed on others - it should be kept personal.

--

=================================
Richard Tugwell
r.tu...@forthmedia.com

[Matthew Clemente]

My position/situation is fairly close to that of John; his post echoes my views with more clarity and depth than I would likely express.

At the risk of being redundant: FW/1 was my first MVC framework, it's simple, it's intuitive, it works. Sean's support, advice, and architecture are invaluable. I love it.

That said, I'm really impressed with the Box ecosystem, and I'm thrilled with the work they're doing for the CFML community. They seem like an awesome team, and have also been helpful when I've had questions. With the features and functionality, however, comes a lot of complexity and configuration; at least that's the impression that I've gotten each time I start to take a look at all things Box. I'm more inclined for the KISS approach, so I'd be averse to changes to FW/1 that turned it into a ColdBox-lite.

I hope to explore the modules on ForgeBox in a bit more depth some time soon; the ForgeBox project seems really promising for CFML and I'm very intrigued by the idea of being able to use more of the ForgeBox modules, but I'm not familiar enough, at this point, with their architecture, to have any meaningful thoughts on the best way to approach that integration with FW/1. 

In response to the final questions: We're actively building new projects with FW/1, but we'll likely dabble with ColdBox for a new project or two, for the sake of learning and experience; it would take a lot to consider a wholesale move from FW/1 to ColdBox. We would need to find that ColdBox made life exponentially easier or that FW/1 no longer did what we needed. I don't see either being likely in the short term. 

I'm sure I'll have further thoughts as I let this percolate; this was a bit off-the-cuff.

[Andrew Myers]

We have numerous FW/1 apps in production.

I concur with Matthew that the Box ecosystem is extremely impressive.  CommandBox and TestBox are now critical parts of my tool chain and of course this does make me look at things like ColdBox and wonder if that's where my future lies.   Certainly a migration path would be interesting and may be something useful to me in the future.

As for the religion aspect - I am by no means religious myself, but I think it's probably a fairly silly reason to reject outright refuse to use a particular technology to be honest.  

As for what would stop me using FW/1 - knowing that it was no longer under active development (even if it went into a "security and bug fixes only" scenario) would absolutely make me stop using it on new projects.

In some ways what keeps me here is the time I've invested in learning it.  And the time I need to invest to learn something else.  Plus, it's a darn good framework, does everything I need and I have huge respect for Sean and confidence in his stewardship of the project and his accessibility to us as a community.  I expect l this isn't sustainable as Sean moves onto new things however.   

Sean we probably don't say this as much as we should, but what you've created here is a wonderful thing and I'm very grateful for everything you've done no matter where you go with it in the future.

Andrew

--

Sent from Gmail Mobile

[Tim Clarke]

At the risk of over-brevity +1

--

[Tony Junkes]

I agree with everyone so far on many things.

This has been a big thought on my mind since I got so much feedback from my article. I think support for basic ColdBox modules is a positive for FW/1. A mutual structure for module integration is a big win. The integrations with CommandBox alone have been solid.

There are 2 parts I imagine helping get close to this:

1. Alias/translate the main WireBox methods to DI/1 or offer a more integrated way of tying a WireBox instance to DI/1; where DI/1 is the parent bean factory(?). Part of writing out the diConfig to talk to the QB library was simply using the equivalent DI/1 method. e.g. WireBox.map() and DI1.declare().

2. Piggybacking (#1), make ModuleConfig.cfc a first class citizen for being picked up by DI/1 and used for defining settings and bean declarations. Perhaps this format could chain to the past-mentioned future of there being a subsystem.cfc. I believe that anything with a ModuleConfig should be treated as a subsystem and therefore placed in that directory. Then have a config flag that triggers DI/1 to look for that CFC and wire up the settings in framework.subsystems.mySubsystem {};

This wouldn't be perfect as I'm unsure of all the options a ModuleConfig.cfc could have. QB was structured quite nicely.

I've tried to like ColdBox. It has pain points with the "getting started" aspects in my opinion. There's just so many moving parts and I often feel restricted by its conventions. That's where the simplicity, power, and flexibility of FW/1 have won me over time and time again. Not to mention you'll never find knowledge like Sean's anywhere else (not to put anyone else down). I'll admit I'm not as good with ColdBox so there's a natural bias. FW/1 taught me MVC in a CFML world. I learned things I never knew or understood previously.

Overall, my opinions to the future vary. At work, we're finalizing the shift from CF to Java. That leaves me with a lone Lucee/FW1 project that I've considered moving to ColdBox for the flavor of features. More and more I feel like it's at least a good roadmap. A migration point would only aid that. In the end, my days as a CF dev are dwindling; and that's ok. In the last 2 years, I've spent much of my time in other JVM langs. It's only forward from here.

As long as FW/1 is actively maintained, I'll keep giving back. When it ends, I'll move on. The bits I've contributed to have been fun learning experiences for me. I still actively maintain FW/1 Commands (aka FW/1 Console) - a CLI extension to CommandBox used for scaffolding and building FW/1 apps. If you're familiar with Grails console, that's my inspiration. The 3.0 version is almost ready for a beta phase and a big step up from the 2.x variant.

In between it all, I still have a few blog posts in the works for integrating modules and general use. Even if we don't have complete support, I want people to start using CommandBox more and see that it's already fairly simple to integrate some ColdBox supported libs with FW/1.

I've learned a lot from this bunch of the community. I'll always appreciate it.

[Eric Peterson]

This has been a really fascinating read for me, a ColdBox user and someone who has never used FW/1. I am the one who developed `qb`, the library that Tony integrated into FW/1. I feel like that will give me an interesting perspective in this group.

It’s been interesting to read your responses, and I have a few questions and comments, if you’re willing. All of these questions and comments are genuine and are coming from a place of seeking understanding.

First, I’ve read in a few places that you “tend to see FW/1 as far more lightweight.” I’m curious to find out more about this?

Is this about speed (like requests per second)?
Feature set (ColdBox definitely has more moving parts and features. Maybe that is overwhelming?)
Control over features (having features built-in feels like lock-in?)
Other things that make it “lightweight”?

I’d also be curious to know with your responses if you have ever built a ColdBox app besides a “Hello World”. I have not built a FW/1 app, so most of my thoughts are based on hearsay, not experience. I wouldn’t be surprised to find that much of our “ideas” about the other frameworks are incorrect on that regard.

As for the framework size, John said “Even at its current size (still small!), I really value the single file approach. It makes the framework lifecycle much easier for me to grasp. DI/1 similarly has a simplicity that gives it power.“ It sounds to me like the small file footprint has made it easier for some of you to learn the internals of the framework better. I’ve heard point a few times and I’m curious to hear your reasons why you prefer it. To me, the contents of the framework folder were always secondary to performance and integration into my project, so that’s why I’m curious to hear your opinions.

The last point was with regard to documentation. I think this is the place where I will just comment that I had a hard time getting started with ColdBox. It sounds like that was a big draw for many of you to FW/1. ColdBox was either not clear enough or too much information (or both). We’ve continued to work on that, but would always accept help from the community. It’s my belief that a basic FW/1 app would translate almost directly over to a basic ColdBox app. (This is something I’d love to show and write a blog post about one day.) Maybe once we show that, we can update our docs to match.

All these points are to help bridge the gap between our communities. I feel there are many artificial barriers that we perceive to be between us. I’d like to knock some of those down.

Back to the topic, I like the ideas of either reading the `ModuleConfig.cfc` and mapping the concepts to DI/1 and FW/1 or introducing a FW/1-specific subsystem convention file. I have no problem as a module author including an extra file to make integration with other frameworks easier.

As far as ColdBox-lite, I’ll be honest, I don’t yet see the need for something like that (hence my questions above to help me understand). I look forward to your responses.

One last question, coming from outside the community, I’m confused about what I perceive to be the death of FW/1 when Sean leaves CFML. Couldn’t you as members of he community take up ownership of FW/1 and advance it along the philosophies that it current embodies? I guess the reason I’m asking is that it makes me sad to see a bunch of people feel like they are forced into a technology choice or that a merging is inevitable. It might sound weird coming from a member of the Ortus team, but I like that there are multiple frameworks. It gives us choice and keeps us all improving.

Thanks for the discussion, folks. I look forward to reading your responses!

Cheers,
Eric

[Carl Von Stetten]

I think the comments everyone has made above are pretty spot on. Eric asked some good questions that I'd like to provide my perspective on, based on my albeit limited experience using an MVC framework.

When I was tasked with rewriting the reporting side of our internal web Geographic Information System (GIS - aka maps) application to work with our new GIS platform, I didn't want to perpetuate the procedural approach my previous application took. Back in 2015 I started looking at my MVC options. I'd never written an MVC application before, although I knew that was the way to go based on watching numerous presentations on the online ColdFusion Meetup and at CF Summit. I looked at the documentation for both ColdBox and FW/1, and found the minimalist approach in FW/1 and DI/1 was much easier to digest and get my feet wet with. I still struggled with some of the basic concepts (especially with DI/IOC), but Sean and others helped tremendously via the Slack channel (a lot of the time it was RTFM, which took 2 or 3 tries before some of the concepts gelled in my head). I actually feel competent enough to speak about MVC now (as I did at CF Summit last year and will at NCDevCon in October).

I'm not sure I would have been able to get this far if I had started out with ColdBox. The documentation was so heavy, and feels very much like it is written for an advanced developer as the target audience.

-Carl

[Nolan Erck]

This has indeed been a great thread, for a growing number of reasons.  I’m glad everyone has been contributing their thoughts on both FW/1 and ColdBox.

Being a consultant, I use whatever makes the most sense for the project.  I’ve done both FW/1 and ColdBox apps (and still maintain some spaghetti legacy apps for other clients that just need basic patch and fix work done too).  That being said, I’ve probably used FW/1 more than ColdBox, but I think that’s just coincidental and not by active choice: many of my recent projects have been writing Mura plugins, which are FW/1 based.

There is one situation that I run into often where I feel FW/1 is the better choice: training “legacy ColdFusion developers” how to use OOP. 

Whether we like it or not, there are still a ton of CF developers using CFInclude and nothing else; they don’t understand CFCs, they’re afraid of OOP, they think frameworks are “too complicated” and “have too many files that don’t do anything”.

I give different presentations and training classes that focus around migrating legacy CFML into an MVC framework.  In this context, I’ll basically hold their hands, slowly walking them thru going from CFInclude into a basic CFC, and show a basic DAO, etc.  The next step in that talk is, I show them how to use the MVC pattern without actually jumping into a framework.  And finally I compare that “home grown MVC app” with the same thing in FW/1, noting that it’s basically 99% the same code. 

The fact that FW/1 is literally ONE file helps tremendously in that learning curve.  Nobody gets scared off by “too many files” or any configuration steps.  I can sell this crowd easily on MVC with FW/1.  I cannot do that with any of the other frameworks that have existed in the CFML space.

As a consultant and geek and tinkerer, I like the idea of being able to combine ColdBox modules and FW/1.  As someone who often teaches people how to not be afraid of OOP, I desperately want FW/1 to always exist and always be as simple to use as it is.

The CFML space is indeed shrinking.  Whatever we can do to combine the different types of CFML development and make everything stronger as a whole seems like the better long term decision, IMHO.

/soapbox

nolan

[Cameron Childress]

On Wed, Aug 30, 2017 at 10:06 AM, Eric Peterson  wrote:

First, I’ve read in a few places that you “tend to see FW/1 as far more lightweight.” I’m curious to find out more about this?

Is this about speed (like requests per second)?

No.

 

Feature set (ColdBox definitely has more moving parts and features. Maybe that is overwhelming?)

Yes, has more moving parts. Not so much overwhelming as maybe extra features and code that will never be needed (but might get in the way).

 

Control over features (having features built-in feels like lock-in?)

Maybe.

 

Other things that make it “lightweight”?

I would bet that I use 90% of FW/1 functionality in any given project. I suspect I would use a small fraction of ColdBox's functionality for that same project. With FW/1 there is less to learn and more flexibility to do things whatever way I want. It's less rigid and has less setup.

I mentioned this in a recent reply to Sean on this list but I really dislike, as in VERY STRONGLY DISLIKE the command line. When I read a getting started manual and it starts talking about downloading a bunch of dependancies and running command line stuff it's a pretty big turn off. I hate nothing more than a battle with "apt-get" because libc-r2d2-3cpo is missing or unavailable for my system.

I like that I can just copy the code for FW/1 and it works. I don't have to run "box something" then "box something else" then "box something other things X option -user foo 3 -expletiveswitch y" to make it work. Sure I can follow the cheat sheet, but I have big fat dumb fingers and hate the command line. 

Heavy. Having to type all that command line stuff before I can "Hello World" is heavy. That is what feels heavy. Like a boat anchor heavy.

It sounds to me like the small file footprint [of FW/1 and DI/1] has made it easier for some of you to learn the internals of the framework better.

Yes.

 

The last point was with regard to documentation. I think this is the place where I will just comment that I had a hard time getting started with ColdBox. It sounds like that was a big draw for many of you to FW/1. ColdBox was either not clear enough or too much information (or both). We’ve continued to work on that, but would always accept help from the community. It’s my belief that a basic FW/1 app would translate almost directly over to a basic ColdBox app. (This is something I’d love to show and write a blog post about one day.) Maybe once we show that, we can update our docs to match.

ColdBox does more for you, it's natural that it would have more documentation. But again, if I don't need "all the more" that is gives me, why would I slog through all the docs when I have a one page doc for FW/1 that I can use to get started much faster?

 

All these points are to help bridge the gap between our communities. I feel there are many artificial barriers that we perceive to be between us. I’d like to knock some of those down.

This is probably true. I certainly would benefit from knowing more about ColdBox. I may have a totally twisted crazy ridiculous view of it.

 

One last question, coming from outside the community, I’m confused about what I perceive to be the death of FW/1 when Sean leaves CFML. Couldn’t you as members of he community take up ownership of FW/1 and advance it along the philosophies that it current embodies?

Yes. I would be willing to help with that too. But there is a pretty solid history of people volunteering (myself included) and then just getting too busy to follow through. The 20 something year old version of me would have more time. The 40 something year old version of me does not, sadly. As much as I would like to step up and say "Sean! I will gladly take over FW/1!", I am uncertain that I would have the time to follow through with that promise - if I even have the skillset.

 

I guess the reason I’m asking is that it makes me sad to see a bunch of people feel like they are forced into a technology choice or that a merging is inevitable.

History tends to repeat itself. It's certainly not inevitable, and I think trying to avoid repeating it is part of the reason for Sean's initial post here. But many of us do have benefit of experience in this area, including Sean - as he mentioned in his original comments.

 

It might sound weird coming from a member of the Ortus team, but I like that there are multiple frameworks. It gives us choice and keeps us all improving.

Agree.

 

Thanks for the discussion, folks. I look forward to reading your responses!

 

Thanks for the reply! I will be at NCDevCon, if any Ortus-folk are going.

-Cameron

[Sean Corfield]

Cameron, I’ll answer the points from your other email in here (first, and then address some of your points from this thread too):

 

I am unsure what this does for me (since I don't use much ColdBox). Loads "something" into FW/1?

 

Per the thread subject lines, this is all about allowing FW/1 users to take advantage of the wide choice of ColdBox modules, directly in their FW/1 apps. The particular examples in this thread are about Eric Peterson’s very cool QueryBuilder library, which provides a really nice DSL for composing SQL queries (something I’ve talked about being able to do in Clojure via the HoneySQL library).

 

It seems like there are 6 command line things I have to now memorize

 

It was a proof of concept, just to show how little code would actually be needed to use QB as-is (rather than having to manually perform the DI/1 configuration that Tony talked about in his blog post – which perhaps wasn’t posted here but has been discussed at length on Slack). See http://tonyjunkes.com/blog/working-with-fw1-and-qb/ for the background of all this. Now see the follow-up post in the other thread here and it’s just two function calls to pull in one or more ColdBox modules, and a tiny bit of configuration if you need it. I guess you’ve not been following the Slack conversations recently in #fw1?

 

I don't know what all of the abbreviations are in the code examples

 

I’ve no idea what abbreviations you are referring to? Maybe just QB – the name of the QueryBuilder module?

 

When I read a getting started manual and it starts talking about downloading a bunch of dependancies and running command line stuff it's a pretty big turn off

 

Well, that’s what the FW/1 Getting Started guide has now http://framework-one.github.io/documentation/#installing-fw1 and it’s much easier than having to download a bunch of different ZIP files, unpack them, copy out the pieces you need, remember to create all the folders you want, etc, etc. Aside from anything else, CommandBox brings versioned packages and dependency management to CFML – like all the “real” languages have (JS/Node/NPM, Java/Maven, etc) – it’s a HUGE win for all CFML developers!

 

The 20 something year old version of me would have more time. The 40 something year old version of me does not, sadly

 

LOL! 😊 The recently 55 year old version of me feels your pain! 😊

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[Cameron Childress]

On Wed, Aug 30, 2017 at 7:25 PM, Sean Corfield wrote:

I guess you’ve not been following the Slack conversations recently in #fw1?

No I have not. I tried to keep up for awhile but just can't keep an eye on Slack and still get work done. Email feels easier. Less of an ongoing conversation I feel like I have to continuously keep up with to know what's going on. Same reason I don't use Twitter all that much anymore.

The rest of your comments - good food for thought. My primary problem really is lack of knowledge of ColdBox.

-Cameron

--

Cameron Childress
--
p:   678.637.5072

[Captain Obvious]

+1 about the grind-y aspect of keeping up with Slack, though always
cool to see Sean and other CF luminaries commenting there when I have
the time.

In response to the OP: ColdBox being the juggernaut is *why* I still
use FW/1. Simplicity wins. I sysadmin a number of critical
applications for multiple 3-letter U.S. .gov domains. When possible I
have written or transitioned many to FW/1. They are all CRUD apps with
some embellishments here and there. Do not need or want anything from
ColdBox, Clojure, etc. at the moment. But if I did would I really
need\want custom support built-in to FW/1?

In my area - Washington D.C suburbs - there is no shortage of good CF
opportunities. If those employers were looking for ColdBox and Clojure
skill sets I might feel differently!

By the way: All hail FW/1, an amazing piece of work. If I didn't have
it I would try to make something like it.

[Sean Corfield]

My primary problem really is lack of knowledge of ColdBox

 

A meta-comment about this: TestBox is pretty much the only game in town now for testing – FW/1 switched from MXUnit to TestBox a while back. CommandBox is so amazingly convenient – FW/1’s CI and local testing is all powered by that. See the README: https://github.com/framework-one/fw1#running-the-tests If you want to scaffold out a new FW/1 app, CommandBox is the way to go, with Tony Junkes’ FW/1 Commands https://github.com/framework-one/fw1-commands (an official FW/1 project!). Neither TestBox nor CommandBox require any knowledge of ColdBox! This is just about knowing good CFML tooling.

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

From: Cameron Childress
Sent: Wednesday, August 30, 2017 4:36 PM
To: framew...@googlegroups.com
Subject: Re: [framework-one] Re: ColdBox and FW/1 and CFML's shrinking market?

 

On Wed, Aug 30, 2017 at 7:25 PM, Sean Corfield wrote:

--

[Cameron Childress]

A meta-comment about this: TestBox is pretty much the only game in town now for testing

Yeah I have used TeatBox on a few projects. I like it. But it's sort of a stand alone thing and not something I build the primary app with so I don't count it.

 If you want to scaffold out a new FW/1 app, CommandBox is the way to go,

I haven't used this at all. CommandBox = command line? Yuk.

I also have a sort of standard application structure and framework I usually copy into new projects anyway that is *probably* not the same as what CommandBox would generate. But maybe worth a look for me anyway.

-Cameron

[Matthew Clemente]

No complaints about the command line here. In fact, I'd say that CommandBox has been the single most helpful tool that's been added to my CFML development toolbox over the years. It's really incredible, and I know I'm only scratching the surface of what it's capable of. I'm also really intrigued by the potential of ForgeBox.

In reflecting a bit about Eric's questions, for me, it's not speed, features, or control.

Honestly, in going back and looking at why I dove into FW/1 instead of ColdBox in the first place, I think it likely came down to the documentation. I know that ColdBox prides itself on its documentation, but personally, I find it very difficult to use. 

In fact, I think the documentation may be part of what gives the impression that ColdBox is bloated and overly complex. There's a lot of words, but not necessarily a lot of help or clarity. As you said: "ColdBox was either not clear enough or too much information (or both)."

As an example, when the FW/1 docs first discuss the request context (a concept that would be new to a beginner or someone coming from a procedural background), there's a small example code snippet, followed by an explanation:

When you access the application now, it should say Hello anonymous! but if you put ?name=Sean on the URL, it should say Hello Sean! The request context passed to the controller method contains all the URL and form variables from the browser and is also made available to the view directly, as rc.

It's succinct, and uses an example to illustrate a new concept, in a way that a procedural programmer would be be able to grasp. Moreover, the benefit of this approach (form and url combined? cool!) may also be apparent.

Here's the initial discussion of the request context from the ColdBox docs: 

ColdBox provides you with a nice method for generating links between events by leveraging an object called event that is accessible in all of your layouts/views and event handlers. This event object is called the request context object which models the incoming request and even contains all of your incoming FORM and URL variables in a structure called rc.

To someone who understands the concepts already, this is probably clear enough, but to a newcomer, it's just not that helpful or clear. What is an event object? What does modeling a request mean? And there's no example. 

I'm not going to pick apart the documentation page by page; I know that I could dig through it, and if I spent the time, I could probably figure out what I wanted to do. I'd even bet that I'd find, at the bottom, that it wasn't that different, practically, from how things end up in my FW/1 app. 

I don't like to criticize documentation or "Getting Started Guides". Writing them is time-consuming, thankless, and honestly, very hard to do well. I'm just trying to lay out what was likely a substantial factor in why I ended up with FW/1 instead of ColdBox.

[Richard Tugwell]

I think Matthew hit the nail on the head about the docs. There's a lot there but I've never been able to find the answer to a simple 'how do I ...'

For example Testbox works really well but last time I looked there wasn't a Testbox 101 to give you a flying start. I think this echoes what someone else said that it appears you need to arrive at the docs as a fully fledged CB developer

Sent from my iPhone

--

[Nando Breiter]

Picking up on the subject of this thread, particularly the phrase "CFML's shrinking market":

I don't know about others, but I develop both front and back end. CFML, or any back end language for that matter, has shrunk in relative importance. 

It used to be that I could keep up with developments in CSS. It's become increasingly difficult over the years, browser hacks and CSS compliance issues, prefixes, new CSS layout techniques like Flexbox and CSS Grid, the plethora of screen sizes, media queries, feature queries, fallback techniques for browsers that don't support xyz, etc. It used to be simple matter to lay out a web page. 

It's a similar story with javascript. There's an explosion of libraries and frameworks, js itself is rapidly evolving. 

Then there are the build tools like grunt, gulp, webpack, etc. Node and npm. Complex dependency issues, thousands of developers rushing to break each other's code as quickly as possible, it seems ... ;-)

Bootstrap and Foundation try to mask this complexity for the developer seeking an easy way out, but the guys trying to maintain and push these frameworks forward seem quite strained. v4 of Bootstrap has been in development for 2 years and has over 16,700 commits to date to reach beta 1. And in some ways, v4 is already on its way to being obsolete because of CSS Grid 

Back in the day, CFML alone would provide a developer with much of what was needed to build a web app. That is not at all the case anymore. In this environment, I don't have the bandwidth for a more complex CFML framework. And I think, more importantly, the focus has shifted to the front end, and this is one of the reasons CFML has been left behind. It's unique value proposition has evaporated.

So, in response to the idea that FW/1 could become a ColdBox lite, I suspect that FW/1 will not really need further development. Optionally, I have no issue with any improvements to FW/1. But to keep in the game, I have to shift my focus toward, for instance, React and the ecosystem around it, CSS Grid and fallback strategies, tooling, front end development, picking apart what may be more durable in this space and what will probably be obsolete in a year or two.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

[larryclyons]

Well Captain, 

If you're in the DC area you ought to a part of the NOVA CFUG. https://www.meetup.com/nvcfug/

regards,

larry

[Sean Corfield]

I suspect that FW/1 will not really need further development

 

The roadmap is always easily available as a combination of these pages:

 

                https://waffle.io/framework-one/fw1

                http://framework-one.github.io/documentation/roadmap.html

 

The latter is intended to be the high-level overview (and hasn’t actually been updated fully for 4.1 – oops!) and the former is a birds eye view of open issues (with their milestones) and any ongoing and/or recently completed work.

 

The restructuring for 5.0 is conceptual. I haven’t formalized it yet. It’s intended to allow people to clean up their Application.cfc and to create more commonality between the “extends framework.one” and the Alternative Application Structure. I think it’s more to satisfy my architectural itches than a pressing user need – although perhaps the subsystem.cfc part is important enough to push ahead with, if it can be done in a backward compatible manner?

 

Given the ongoing work in https://github.com/framework-one/fw1/issues/486 at this point, I may change the focus of 4.5 to be “ColdBox module compatibility”, and revisit the 4.5/5.0 restructuring path.

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

From: Nando Breiter
Sent: Thursday, August 31, 2017 9:03 AM
To: framew...@googlegroups.com
Subject: Re: [framework-one] Re: ColdBox and FW/1 and CFML's shrinking market?

 

Picking up on the subject of this thread, particularly the phrase "CFML's shrinking market":

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[Nathan Strutz]

Alright, I've been quiet a few days. I guess I like to wait for everybody to say their piece before I come to a conclusion. Now I have.

I won't say that ColdFusion is dead/dying/anything. It simply is, though with a slowly shrinking market share from my point of view (which is in a small desk, in a very big company). It's still the quickest, simplest way to get a product to market on the server-side, especially for a classic web application. It's still a great platform, especially knowing Lucee is there in case the commercial product should discontinue. It's still my favorite programming platform by far.

To close one bunny-trail, FW/1 is my framework of choice because it was a natural progression from Fusebox, and it stays out of my way. You learn a few conventions, bring in one or two files, and you're done! Also I've found there's hardly anything to explain to newcomers.

FW/1 as an extension to ColdBox doesn't bother me. In fact, I could see a natural progression where FW/1 is eventually maintained by ColdBox just so that it doesn't die off. Maybe Sean could architect a plan to integrate CB in a FW/1 style before letting go. Personally I envision a framework adapter that doesn't muck-up the core framework, but like many of us, I don't have very much Box experience to how how this looks.

--- religious banter coming up ---

Nando made a religious bunny-trail. It's unfortunate, but hey, he's always been honest! Religiously, I side with Louis, so as a thought exercise, let's pretend it's Scientology. Xenu is coming back to power soon. No doubt, this is silly, and I don't need religious counterpoints to see the error in my beliefs or something. Let's get on with the experiment.

The framework may still be great, possibly the best software ever written. Using it would not hurt my beliefs, but engaging in the community and issuing pull requests would mean my name is forever linked to Scientology, and I'm not comfortable with that. Many of us may get over it and just say "Yeah, they're a little nuts, but the software is bomb," but not everyone. And then ColdFusion's only real framework and public development would be centered around Scientology, and CF would become a Scientologist programming platform. I don't like that direction.

On the other hand, if Louis builds the software and runs the web site, none of us can say what he writes and what he does with it. The free market can let you decide to use ColdBox or something else. So there's the conflict - we have the only something else out there, do we let the Scientologists win? 

How about a compromise? What if Louis would take religion out of the open source parts of ColdBox including the documentation, yet retain it on his web site and company, email tagline, and home door posts? That would make me happy enough to not think twice about using software written by Scientologists. If he doesn't go along with it --and honestly he doesn't have to, it's his choice-- then Nando can clone it and make it his own. That's how open source software works, and sounds like a valid-enough reason for forking.

On the other hand again, it's just software. Compilers don't care what's written in the comments. 

--- end religious banter ---

Last thoughts. I, too, am planning my exit from CFML. I'm just happy to still be afloat on the rapidly moving river of technology. My gradual exit from ColdFusion will probably line up close to Sean's. That said, I will continue to use FW/1 with every CF project I come across because it works well with my brain and I like it. All that to say this: If Framework One stays forever unchanged, maybe that's going to be okay.

-nathan

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--

-Nathan Strutz

[Nando Breiter]

To be clear, my discomfort is a personal thing, and I'm uncomfortable with all of it. There is this attitude, particularly in America that "religion is sacrosanct". Well, I find these ideas simply bizarre and would not even grace them with connotation the word religion infers, whether it is conversion by the sword, jihad, or drinking blood to make something "bad" "good" again, or monkey gods, elephant gods, whatever. 

If I killed my son, someone I cared for very much, and invited the neighbors over to drink his blood and eat his body to ensure all was well between us, what would you do if I invited you? What would you do if you showed up and saw my dead son's blood dripping into a chalice and I said "Drink the blood. Everything is ok between us if you drink the blood of my son." I don't mean to offend anyone, but Christianity seen from the outside is ... umm ... really bizarre. If Luis wants to promote this, it's his business. I just will head in another direction.

What does this have to do with FW/1? Nuthin. Sean has proposed potentially useful changes to FW/1, he's a genius and very generous with his time and talent, and we're lucky to have him. I'm grateful. Sean has made me a better programmer because of his generosity. Thank you.

Aria Media Sagl

+41 (0)76 303 4477 cell
skype: ariamedia

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--

-Nathan Strutz

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

[Sean Corfield]

Before this goes too far into the weeds, I’ll just ask that we _do not_ discuss religion here. It’s not an appropriate topic for the FW/1 mailing list and I think everyone is already very clear on where they stand on the topic.

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

From: Nando Breiter
Sent: Friday, September 1, 2017 9:33 AM
To: framew...@googlegroups.com

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

--

-Nathan Strutz

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

 

--

FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[larryclyons]

What you mean we cannot discuss .Net vs CF or Mac vs Windows or Subbed vs Dubbed?

[Nathan Strutz]

Also, tabs vs spaces. No holy wars.