Visula Studio LightSwitch

[Michael Washington]

I am not sure if you are familiar with Visual Studio LightSwitch.
I feel it could be a good candidate for your tool.
Currently it has limited controls (assuming you ignore any custom
controls for now)

I made a post on a project I was considering to convert LightSwitch to
HTML:
http://lightswitchhelpwebsite.com/Forum/tabid/63/aft/117/Default.aspx

However your plan is clearly MUCH better and I would rather spend time
supporting your project

[Rob Ashton]

Isn't Lightswitch just Silverlight anyway?

I don't know much about the project as it's not something I'd use in
my daily activity

On Jun 30, 11:40 pm, Michael Washington <webmas...@adefwebserver.com>
wrote:

[Michael Washington]

Because it allows an "average developer" to complete their project in
a reasonable amount of time, I suspect that the majority of
Silverlight applications will be LightSwitch applications by next
year :)

Also see:
This Is How LightSwitch Does MVVM
http://lightswitchhelpwebsite.com/Blog/tabid/61/tagid/12/MVVM.aspx

> > supporting your project- Hide quoted text -
>
> - Show quoted text -

[Dave Arkell]

From the looks of it, if sljs gets to a point where you can put any silverlight app in and get html/js out, then LightSwitch would work too, because as Rob says, it is just Silverlight.

[Michael Washington]

Yes, but LightSwitch has some pretty complex code, for example it
reads a .lsml file, uses MEF, and requires a ton of assemblies in the
"bin" directory.

If it all works with no problem, great :)

> > > - Show quoted text -- Hide quoted text -

[Ryan D. Hatch]

Rob -

The vision is for you to set.  I will add my efforts to what the vision should be.  Common themes here with JSIL; you may want to speak with Kevin about where the baton pass is between your projects.

Ryan

SLJS / JSIL Vision
The true power of SLJS & JSIL is:

 - Combining C#, Databinding, MVVM, Templating - not with just XAML - but with HTML5/CSS -   We can succeed - knowing where others have failed.

Desired Development Environment:

• View Models in C#
• Views in HTML5/CSS   (hand written or generated using xaml converter)
• Declarative Databinding to HTML elements.  (Knockout-style)
• Send/Receive C# objects to WCF JSON endpoint

In essence, a .NET version of Knockout JS on steroids.

My reasoning follows:

1.) Focus on C# Databinding to HTML

This is absolutely key.  And I believe - is the real home-run for SLJS / JSIL.  What we need is a clean way to declaratively bind HTML elements to C# objects.  And to be able to send those objects up & down to the server.  This will absolutely change the way web applications are written.

This includes

• Full databinding support for INotifyPropertyChanged, INotifyCollectionChanged, INotifyDataErrorInfo, etc.  From C# to HTML, two-way.  With HTML Templates.  With value Converters.
  
• Sending C# object graphs to/from WCF JSON endpoint.  And eventually - Generate client-side C# API for a WCF service, much like Add Service Reference.
  

This will change EVERYTHING.  Rob, when you / Kevin get this - the flood gates will burst open.

2.) Embrace HTML5/CSS  (Don't hide Developer behind XAML)

Take for example Wallaby, Adobe's Flash-to-HTML5 converter.  Wallaby produces a mess. Google's Swiffy, even worse.  These products will fail because they attempt to hide / shield developers from the HTML5/CSS environment where their applications actually run.  This is a mistake.  Developers are trapped behind their converter.

Now take a success - MonoTouch.  MonoTouch is a C# runtime on iPhone/iPad.  Miguel took a very different approach.  MonoTouch / Xamarin does not shield developers from native iOS, with some device-neutral abstractions.  Instead, to create the best user experience - Miguel knew he had to embrace iOS.  Screens for MonoTouch are developed in native iOS Interface Builder, and databind to C# objects.  This creates excellent user experiences with full control of the native iOS views - with the power of C# doing all the business work through databinding.

3.) Fully Support hand-written HTML5/CSS

Tooling for HTML5/CSS is getting much better.  Adobe's Edge is one good example.  Expression Blend will follow suit.

We want to combine C# with any HTML view.  This will offer the best possible user experience.  Grab an HTML theme, and write your application.  Additionally, it's much easier to find HTML designers than it is XAML designers.

4.) Make Xaml-converter Optional (a sub-project)
XAML Converter is awesome.  Really.  And it certainly has its place.  However, I feel it is important to distinguish between SLJS and a XAML-converter.

I love XAML as much as anyone.  However, Betting the farm on a 100% XAML-to-HTML5/CSS converter is a recipe for failure.

Certainly I may want to convert an existing Silverlight Application to HTML5/CSS.  Or mock up screens in Blend and convert them over to HTML5/CSS.  But I don't expect the output to be perfect.  I expect and anticipate the need to massage the output.  Notice the workflow:  It's Convert and start massaging, not convert & walk away.  The output HTML5/CSS needs to be workable.


Reference: GWT
-----------------------
As you all know, GWT compiles Java to Javascript.  (See Video).  It is extremely smart stuff.  Latest Angry Birds HTML5 runs on GWT.  Big differences, though.  GWT has a built-in debugger.  That is huge, and hopefully something we can integrate into JSIL someday.

Reference: Moonlight in Javascript
--------------------------------------------------
For me, SLJS is not about running 100% of Silverlight in Javascript.  If that was the goal, then don't rewrite it - help port Moonlight to Javascript using LLVM.

I have already talked to Miguel & Mozilla about this. (See Here)  Azakai / Kripken at Mozilla has offered to do the port, but they need help with Mono expertise, which I don't have.  With this approach, there would be zero HTML5/CSS elements and the runtime would draw directly onto Canvas / WebGL.  This is a huge undertaking, and even if it were possible - I would not expect it to be as capable as Silverlight's runtime.


In summary, I don't think that having 100% compatibility with Silverlight (or a Lightswitch app) should be our goal with SLJS.  If it is, the bar will be set too high, expectations will never be met - and everyone will be let down.  I think the correct play is the C# / MVVM / Databinding to HTML with ability to send C# objects to/from the server.

Ryan

[Rob Ashton]

Okay, well at least you have a vision (I don't have much of one, I'm
relying on others to tell me what they want from this beyond "proof of
concept")

Here is where I stand on your points!

I agree entirely about data-binding being key, and binding to styles,
models, etc is Pretty Damned Important. and Something To Focus On.

I would say that the XAML converter is still pretty important, at
least as far as generating the markup goes (HTML "controls" bound to
the data) - but the control over this markup should be made vary
obvious to the developer. I say this because it's nice to have real
controls to bind to in XAML world, even if you're not going to spend
too much time styling them. Onto the next point...

I would say that you're 99% right about styling with CSS etc, the
output is template-able, and it should be *easy* to style by
hand-rolling CSS, while it might be fun to bring across styles from
XAML I don't think it would be ultimately all that useful in an
end-product.

I would say that Moonlight in Canvas is the wrong approach (one that I
did consider), and that's mostly because the other points are rather
counter to that.

Services? They're next after binding and a touch up of styling - I
have no plans to go crazy over implementing the .NET framework in
Javascript beyond what is needed to make an application work. I am
keen to see how far this can be pushed and whether there are any valid
use cases that people would actually .. well find useful.

If you want to assist me with vision then hang around, play, request
things, keep the interest in the project, and obviously - contribute
if you can, I'm all ears - it seems we mostly agree with what NOT to
do!

[Rob Ashton]

Addendum: It would be pretty cool to make the service calls seamless,
so that the boundary between web/server doesn't seem quite so big -
that perhaps is something big to focus on.

[Rob Ashton]

PS: As far as I understand it, the baton point between JSIL and SLJS
is he's pushing on XNA and language support (and core system types),
whereas I am primarily focused on the Silverlight aspect of things. In
other words, JSIL is the runtime and SLJS a framework built on that
runtime.

I am hoping to contribute more to JSIL as time goes on, it's a big
project with many points where contributions could potentially break
other many points, so it's going to take some time before I'm happy
just adding stuff :-)

[Ryan D. Hatch]

Sounds great, Rob.  Looking forward to this!

This will change the way I write applications.  Hands down.

Ryan