use of other frameworks?

Question

Watching the C9 video with Joe Binder and Beth Massi, I was happy to see the "don't reinvent the wheel, use what's out there!" stance for using jQuery Mobile (an excellent choice!), but then I saw a couple other areas where it seemed like the team could have leveraged existing frameworks.

The first (and IMHO more 'egregious' case) was the data binding, where the rebinding of the map data was present, and Joe mentioned the team had done a bunch of data binding work on their own.  Admittedly, not knowing much about LightSwitch, that comes across as kind of odd given how awesome knockout.js is, how much it makes transition from MVVM-in-Silverlight nice and easy, and how it's coming from ASP.NET team member Steve Sanderson.

If there's some fundamental reason knockout isn't a good fit for this, could the team explain that?  it would help explain things for the rest of us. :)  Also, there are many other data-binding types of engines (for instance, the meteor team has been packaging up liveui to be usable outside of meteor), so it seems like a particularly odd area to reinvent the wheel.  Leveraging knockout would make my transition to the HTML client much easier (admittedly, I've used knockout, but it's awesome!)

The other one is likely easier to explain "why we don't use that", but I figured I'd ask anyway.  Given the nature of the screen templates, it seems like twitter's bootstrap project and its grid system would be a great fit.

On a related note, whatever frameworks are used (or not) for things like templating (or whatever the team decides to call it) and layout, is this something that will be 'pluggable'?  I can imagine that it might be a PITA to do so (given the 're-plumbing' that Joe mentioned was necessary for the screen templates, so it sounds like the 'viewmodel'/tree might not be as decoupled from the generated html/javascript as necessary for such), but especially as a potential source of community effort, I think it'd be a huge win.  

Especially by the time this RTM's, you can expect many web dev teams will already have a given templating engine they use already, so not having to learn a new one and maintain it would be a huge advantage. Certainly teams will be able to make their own html clients 'by hand' (I'd imagine) talking to the lightswitch middle tier, but extensibility would be preferred over having to throw it all away and start from scratch. :)

Thanks!

Answer 1

Hi James,

Thanks for the comments and feedback.  In response to your general question, yes, we do expect that you’ll want/need to plug-in frameworks to augment or supersede what LightSwitch provides.  Right now, we’ve really optimized for using JQuery and jQueryMobile plugins in a straightforward manner, but there is certainly opportunity for us to enable similar plugin-like experiences for data-binding, globalization, etc.

In specific reference to knockout, you will hear no argument from us regarding the framework’s usefulness—the first time I used it I was blown away by its power and simplicity. It is very well designed, pragmatic, and uses patterns that have close analogs in the SL/WPF world.  Internally, we evaluated knockout, backbone—and by extension, underscore—and a few other lesser-known data binding frameworks.  While there was no clear winner or obvious choice, they all had strengths and solved the general problem of data-binding and templating well.   Similarly, they also carry implications that gave us some pause because LightSwitch’s support for JavaScript is new, and we don’t yet have a good handle on what’s acceptable and what’s not from an API perspective. 

As one example, knockout observables are functions, which allows knockout to work on legacy browsers that do not support getters and setters.  The nuance is small relative to the ease-of-use that knockout provides.  However, the view model of your LightSwitch screen/page constitutes the lion’s share of the programming model for the client; and using functions for something to represent fields will likely be unexpected for folks who are not familiar with knockout. API patterns are hard to change, so we are particularly sensitive to the APIs we introduce in this first iteration.  (There were some other, largely internal details to sort out for knockout specifically; I just wanted to give you an example of some of the things that informed the decision.)

In any case, we felt that the most prudent path was to minimize the dependency graph for our first iteration and remain open to taking larger dependencies in the future. Our view models are quite simple today and could easily be tuned to a specific framework in the future.  We also kept in mind that frameworks such as knockout have a very robust extensibility model, and it would not be difficult to implement a mapping between the LightSwitch view model and that of knockout, backbone, et al.  For example, I can easily envision a general-purpose utility that creates a knockout mapping plugin for the LightSwitch JSON model and/or the screen view model.

In the meantime, our data binding capabilities are pretty simplistic and manifested in a single api—bind(object, path, callback).  If we do add in-the-box support for more expressive data bindings (foreach, count, etc) or data templating, we’d very likely do so by using an existing framework.

If there are other frameworks you’re interested in integrating, please let us know.  We’re keen to understand any specific hooks we can provide to allow people to use the frameworks that are most valuable to you.

Thanks again for taking the time to pass along your question and feedback.  This is an important discussion to keep going as we move forward.

Joe

Answer 2

I have done a lot of projects, and blogs on MVVM. However, I have also done a lot of speaking on MVVM over the years and talked with a lot of developers around the world and mentored a lot on their projects.

For the average developer, I feel MVVM is way too much abstraction and too hard to understand (or perhaps I am not a good teacher?). So I am not excited about 'baking in' any of the 'JavaScript MVVM frameworks'.

My Article:

A Full CRUD DataJs and KnockoutJs LightSwitch Example Using Only An .Html Page

is incomprehensible to most developers :( :(. knockout is brilliant, but when developers have a hard time comprehending/implementing Silverlight compile-time MVVM with great tools such as Expression Blend, I feel that they will have a really hard time with code such as this:

            makeRequest(request, function (newItem) {
                that.newproduct.id("Id");
                that.newproduct.productName("New product");
                that.newproduct.description("Product description");
                that.newproduct.price("Price");
                that.products.push(productModelToViewModel(newItem));
            });

Now, most pro developers are rolling their eyes saying 'that is so simple! what do you mean they can't understand it?!'.

The that.products.push(productModelToViewModel(newItem)) is the part where the MVVM abstraction comes in (and I feel people get lost).  One change to one part has a rippling effect across everything that is bound. The average developer simply wants to set the vales and Save, that's it.

You can do a lot of 'cool nifty things' in productModelToViewModel, you can create dependency chains, and you now have to hold all this in your head as you make programming decisions.

LightSwitch does all this but writes most of the code for you and provides an understandable UI to navigate everything that is wired-up. I think LightSwitch would get 'away from its mission' if it required people to understand things like throttle.

In my opinion, Lightswitch is MVVM... but it isn't. Meaning, it does not force the developer to deal with the abstraction that I feel causes MOST developers to get lost with MVVM.

Take value converters. Powerful stuff that you sometimes need, but LightSwitch instead gives you computed properties that are very easy to understand and require minimal code because it scopes the method to a single entity field. If you are a pro developer and you really need something complex, LightSwitch provides WCF RIA Services, but it now says 'listen buddy, you're such a pro developer, take care of this yourself, we will not complicate the product trying to handle complex stuff like that'.

For that reason I hope LightSwitch continues to use JQuery as its only dependence (in the Mobile HTML Client), and require any other JavaScript libraries to use their extensibility to 'play well with LightSwitch'.

I hope bind(object, path, callback) remains as the only "official built-in" binding. 

---

The Visual Studio LightSwitch Marketplace

http://LightSwitchHelpWebsite.com

Answer 3

Sorry for not being clear - I realize in retrospect I should have clarified WRT interface vs. implementation.  Since I'm extremely new to LightSwitch, I may be off-base here at a philosophical level, which would be great to know if true. :)

My current understanding (which could be way off now that I think about it) is that the render/postrender events I saw in the videos were LightSwitch-specific 'interfaces' and not something that comes 'in the box' with jQuery Mobile.  IOW, if someone is using LightSwitch to make their HTML client, when using those events, you're writing code that gets called by bits of LightSwitch at runtime, and it then interacts with jQuery Mobile (or whatever else) to make things work correctly at runtime.

So, while the html and css generated are 'raw', the javascript experience is that there's a LightSwitch specific interface that you leverage/code-to (instead of writing/using 'raw' jquery mobile).

From that perspective, I'm happy to have the bind call be the only official interface provided for binding.  My comment was meant more that when implementing the binding, instead of doing it all 'from scratch', the LightSwitch team could leverage existing work (for instance, like knockout).

By providing such an interface, LightSwitch is able to potentially swap out implementation later on, but the team could leverage the work of others instead of reinventing that wheel.

And that gets into the philosophy of LS that I might be 'off' about.  Is LightSwitch a higher-level set of abstractions (and tooling to go with them) so developers can leverage/code-to?  If so, then there are runtime parts to LightSwitch such that while there are underlying/enabling technologies, but LightSwitch wraps them.

The alternative (and maybe this is what LS targets) is to instead provide the tooling, but instead of having runtime components, LightSwitch focuses on solely generating the code based on the tooling interactions, much like the "one-time" scaffolding done by other frameworks (for instance, using the MVC wizards to scaffold a new controller or view).

They each have their pros and cons, but I was under the impression that LS targets more the former, providing 'wrappers' such that the level of abstractions (and specific supported interfaces) were 'higher up the stack'.

So, long story long, I completely agree with that single bind call being the only supported interface for the HTML client, and my comment was more just about the engineering decision around implementation.

Thanks!

Answer 4

The plugin philosophy is I guess where I'm unclear, admittedly on LS philosophy of runtime vs. designtime.

For instance, WRT the 'enable similar plugin-like experiences', is the thought process that these would be VS/tooling plugins (or extensions, or whatever) such that it would change the design-time/build-time generation?  Or is it instead that there would be more runtime plugins with the one 'in the box' wrapping jQuery (or jQuery Mobile, or whatever else is needed), but others could either implement their own or intercept the calls to modify the behavior?

Somewhat related, will the LightSwitch client take an approach similar to MVC WRT NuGet use for dependencies?  That's probably more trouble than it's worth for V1, admittedly, but since the video specifically talked about dealing with the faster versioning of dependent projects, I was curious if NuGet (or similar) would be used to help decouple them or not.

Thanks!