March '15 Update on Jasper Thinking and FubuMVC 2 enhancements

[Jeremy Miller]

So fubumvc isn't dead, just mostly dead. I just got back from a visit out to Salt Lake City with the other Extend Health guys last week and there's a tiny bit of news on Jasper/FubuMVC3:

I think the first work is going to be the consolidation effort and the replacement of the old IActionBehavior interface with OWIN delegates as outlined last time: https://groups.google.com/forum/#!topic/fubumvc-devel/rquRFa77hGc. Right now my best guess is that I start work on that next month when I'm able to tie a bow on the Storyteller 3 work.

Jasper vis a vis ASP.Net MVC/Web API in vNext

FubuMVC exists in the first place because way back when Chad & I really didn't like the direction of ASP.Net MVC and most of the issues we had with MVC way back when are still there in the vNext MVC. That being said, we're getting some pushback in our own shop about the Jasper idea from folks who'd rather just use the out of the box ASP.Net MVC tooling in vnext. I think there's a couple causes for that: 

• employability
• lack of documentation and knowledge about fubumvc
• tooling support in VS.Net & ReSharper. 

Corey & I feel like the Jasper work has to happen regardless of whether we end up using MVC to protect our investment in FubuTransportation and get it ready for the .Net vNext world. As a compromise and response to feedback I've gotten on this list, we could position Jasper as an optional wrapper around the vnext MVC/Web API tooling such that you can use some hopefully large subset of the built in MVC behavior within a Jasper application. It's an attempt to have our cake (behavior chains, policies, diagnostics, bottle type extensibility) and eat it too (MVC style endpoints and VS integration). At a minimum, I say that Jasper should be able to mount any middleware written for ASP.Net vNext's OWIN like standard *and* any middleware written for the OWIN spec (MS being MS, they went their own way and partially ignored the OWIN spec). I think we can also allow you to use MVC/Web API style controllers and action results as just another "behavior" inside a Jasper application. Even so, I'm confident that putting Jasper in charge with its own routing and middleware configuration will provide performance, scalability, and diagnostic improvements over out of the box MVC/Web API. 

Other Decisions and New Things

• Even before we make the move to the vNext runtime, I want to drop the ASP.Net hosting and eliminate any dependency on System.Web. I'm assuming that Helios will be perfectly viable for production hosting. If that's not really true, I'll beat the retreat back to ASP.net and System.Web.
• FubuMVC.Validation is definitely going away in the future
• FubuMVC.Diagnostics is going to fold into FubuMVC.Core as early as late this week. I'm eliminating the dependency on the Spark engine while I'm at it. Diagnostics will be an opt in feature, but will be on automatically when running in "Development" mode.
• We're going to drop Spark support and only support Razor. Whatever we do, we'll make Razor intellisense work for Jasper apps
• I'm adding some support for data aggregation to FubuMVC 2 this week. Think about being able to batch a sequence of query requests in one ajax POST and get all the matching data responses in that one request. 

[hcoverlambda]

That sounds great.

[Kevin Miller]

Regarding employability. I didn’t get too much resistance for not being up to speed with ASP.Net MVC when looking around. Most employers were pretty impressed with what they heard when I would talk about what we do with Fubu.

I can see a lot of benefit and potential adoption if vNext could provide some behaviors support for existing ASP.Net MVC apps.

---

KevM

--
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.

[Jeremy Miller]

It might make fubumvc/jasper less scary for folks to try out if it can just be layered on top of an existing MVC app or if you've got an easier route to escape back to MVC if you end up not liking Jasper. 

On Wednesday, March 11, 2015 at 12:17:07 PM UTC-5, KevM wrote:

Regarding employability. I didn’t get too much resistance for not being up to speed with ASP.Net MVC when looking around. Most employers were pretty impressed with what they heard when I would talk about what we do with Fubu.

I can see a lot of benefit and potential adoption if vNext could provide some behaviors support for existing ASP.Net MVC apps.

---

KevM

On Wed, Mar 11, 2015 at 11:16 AM, 'Jeremy Miller' via FubuMVC Development Group <fubumvc-devel@googlegroups.com> wrote:

So fubumvc isn't dead, just mostly dead. I just got back from a visit out to Salt Lake City with the other Extend Health guys last week and there's a tiny bit of news on Jasper/FubuMVC3:

I think the first work is going to be the consolidation effort and the replacement of the old IActionBehavior interface with OWIN delegates as outlined last time: https://groups.google.com/forum/#!topic/fubumvc-devel/rquRFa77hGc. Right now my best guess is that I start work on that next month when I'm able to tie a bow on the Storyteller 3 work.

Jasper vis a vis ASP.Net MVC/Web API in vNext

FubuMVC exists in the first place because way back when Chad & I really didn't like the direction of ASP.Net MVC and most of the issues we had with MVC way back when are still there in the vNext MVC. That being said, we're getting some pushback in our own shop about the Jasper idea from folks who'd rather just use the out of the box ASP.Net MVC tooling in vnext. I think there's a couple causes for that: 

• employability
• lack of documentation and knowledge about fubumvc
• tooling support in VS.Net & ReSharper. 

Corey & I feel like the Jasper work has to happen regardless of whether we end up using MVC to protect our investment in FubuTransportation and get it ready for the .Net vNext world. As a compromise and response to feedback I've gotten on this list, we could position Jasper as an optional wrapper around the vnext MVC/Web API tooling such that you can use some hopefully large subset of the built in MVC behavior within a Jasper application. It's an attempt to have our cake (behavior chains, policies, diagnostics, bottle type extensibility) and eat it too (MVC style endpoints and VS integration). At a minimum, I say that Jasper should be able to mount any middleware written for ASP.Net vNext's OWIN like standard *and* any middleware written for the OWIN spec (MS being MS, they went their own way and partially ignored the OWIN spec). I think we can also allow you to use MVC/Web API style controllers and action results as just another "behavior" inside a Jasper application. Even so, I'm confident that putting Jasper in charge with its own routing and middleware configuration will provide performance, scalability, and diagnostic improvements over out of the box MVC/Web API. 

Other Decisions and New Things

• Even before we make the move to the vNext runtime, I want to drop the ASP.Net hosting and eliminate any dependency on System.Web. I'm assuming that Helios will be perfectly viable for production hosting. If that's not really true, I'll beat the retreat back to ASP.net and System.Web.
• FubuMVC.Validation is definitely going away in the future
• FubuMVC.Diagnostics is going to fold into FubuMVC.Core as early as late this week. I'm eliminating the dependency on the Spark engine while I'm at it. Diagnostics will be an opt in feature, but will be on automatically when running in "Development" mode.
• We're going to drop Spark support and only support Razor. Whatever we do, we'll make Razor intellisense work for Jasper apps
• I'm adding some support for data aggregation to FubuMVC 2 this week. Think about being able to batch a sequence of query requests in one ajax POST and get all the matching data responses in that one request. 

--
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-devel+unsubscribe@googlegroups.com.

[Gary Brunton]

Jeremy,

I wanted to say that I like the idea of layering on top of vnext a lot. It seems like a great way to go for many reasons.  I also wanted to let you know that we've been using fubumvc with razor for a couple of years now and it works great so hopefully the path to jasper integration won't be too difficult.

One more thing. I'm sad to hear that fubumvc.validation is going away. I understand that there are other alternatives but we've used it with quite a bit of success. There are some issues with it out of the box but we've changed it slightly and absolutely love it. Both form based and ajax based validation completely stays out of our way now because of it.

Just my two cents.

Gary Brunton

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