locked
TypeScript and LightSwitch HTML - a perfect match?

    General discussion

  • Saw the TypeScript announcement today and my immediate thought was that it could add a lot of value to the HTML client part of Lightswitch. It could potentially allow type safe programming in the HTML client in the same way as C# (or VB) does for the Silverlight client. 

    From early reading it appears to be a superset of Javascript (compiling to plain Javascript), meaning that plain vanilla javascript will just work and therefore you could include standard jQuery, etc snippets into your TypeScript code and it will just work.

    http://blogs.msdn.com/b/somasegar/archive/2012/10/01/typescript-javascript-development-at-application-scale.aspx

    http://blog.markrendle.net/2012/10/02/the-obligatory-typescript-reaction-post/ 

    Personally, and without having explored this in too much detail yet, I think this holds great promise and I might actually prefer writing TypeScript in the Lightswitch HTML client as opposed to plain old Javascript as it will provide real OOP and compile time checking.

    Thoughts?


    Xander

    • Edited by novascape Tuesday, October 2, 2012 8:43 PM
    Tuesday, October 2, 2012 8:31 PM

All replies

  • Xander,

    I've had a play with TS and I'm pretty impressed with the initail offering. I had originally thought that the way to go for LS on Win 8 was to XAML->C#/VB route as the Mobile Client Project but realise that the HTML5 / JS route is more open (Browser Choice / OS / .....). With the TypeScript compiler spewing out good ol' JS we could potentially and safely host the Mobile client app for all and sundry.

    How far the LS team have gone down the road in developing the "Mobile Client" and releasing we shall no doubts find out. In the meantime I am evaluating plumbing in a "tsproj" into my LS "solutions". Though I would have thought it would have made sense for the LS team to use their existing Data Source mechanisms, create the "interfaces" and opening the GUI design with an HTML5 palette and pin to these "interfaces". I hope the LS team are working down those lines. It would be nice to "wrench" from a team member what their plans are in this area.

    More thoughts? Anyone!

    PS The .vsix will extend both 10 and 12 flavours of VS. In case anyone desires to stick with 2010.

    PPS The TypeScript / HTML templates for new projects can be found in the C# template folders should you wonder where they are! The joys of beta testing..............


    E tenebris lux. ±



    • Edited by PlusOrMinus Tuesday, October 2, 2012 10:26 PM
    Tuesday, October 2, 2012 10:15 PM
  • I also plan to play with this over the coming weeks. It should 'just work' with LightSwitch as it is now.

    My motivation is that I do not like to write any code that is not 'compiled'. If this allows me to create needed JavaScript but have a compiler and type safety then we are good to go in my opinion.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Wednesday, October 3, 2012 2:32 AM
  • The LightSwitch team very much has TypeScript on the radar and are looking into whether it makes sense to integrate it into the LightSwitch design experience for a future release. It's good to hear that there is some interest from the community in doing this!

    Thanks,
    Stephen Provine
    LightSwitch Team


    Visual Studio LightSwitch Team

    Wednesday, October 3, 2012 5:51 PM
  • Stephen,

    Thanks for responding so positively. I think there will be a little more than "some interest"!

    Excellent news, Keith


    E tenebris lux. ±

    Wednesday, October 3, 2012 5:58 PM
  • Michael,

    Good of you to demo the present "kludginess" of using TypeScript with the latest LightSwitch HTML Preview. Note Well (Nota Bene!). This comment is far from a pop at you but I really think the LS team should take this matter into consideration at their next release. I think we have to look at how we use the build actions within the projects. Good work sharing the .js / control development process.

    Reminder - I'm a LS fan and I'm also a TS fan.

    Keith


    E tenebris lux. ±

    Thursday, November 22, 2012 11:08 PM
  • Thanks Michael for another useful article.

    TS is a godsend to C# developers. I recently had to create a JS client API for our new SignalR based Chat server and the web developers (consuming our JS API) asked me to please "wrap it into a nice component". As advanced JS is not one of my strengths as yet, I reverted to the TS playground and in no time whipped up a TS equivalent using modules and classes and then worked off the generated JS to do what they wanted. This was a life saver!

    So, to all fellow C# and VB programmers, TS is your friend to bridge that gap to JS :)

    LS+TS = Awesomeness!

    Regards


    Xander

    Thursday, November 22, 2012 11:16 PM
  • I am not sure how much more they can integrate it. They really can't get rid of the .js files. What are you expecting?

    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com


    Thursday, November 22, 2012 11:21 PM
  • Haven't tried this yet, but if you add a seperate library with your TS scripts, then "add as link" the generated JS files to your client, this might run just as smooth as we want it to. :-)

    It's your story - time to switch on the innovation. || About me || LightSwitch blog

    Friday, November 23, 2012 7:51 AM
  • As always, thank you everyone for the feedback. I did not think about source control so that one was a show stopper! I tried that “add as link” but that did not work (I think it only works if it is in a separate project. That is doable, but I also realized that you can simply point to the folder the script is in J I ended up changing the build setting for the .ts file to get past the prompt asking you to update each time.

    image

    Next, we want to click on the .ts file, and in Properties set the Package Action to None (otherwise we will get a message box asking us if we want to update it each time we debug).

    image

    We can also place the TypeScript files in their own folder…

    image

    … and update the default.htm file to point to that folder.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Friday, November 23, 2012 1:57 PM
  • Stephen,

    Count me in as being interested in TS for LightSwitch HTML Client apps.

    Cheers,

    --rj


    Microsoft Access 2010 In Depth (QUE Publishing)
    OakLeaf Blog
    Access 2010 Blog
    Amazon Author Blog

    Friday, November 23, 2012 6:48 PM
  • Without having yet looked at the html client beyond the demo videos, my guess would be that LightSwitch could do more because it has all the metadata about the object graphs / models / methods.  

    For instance, LightSwitch could write/update a set of .d.ts files in the project so that when writing custom code (like RowTemplate_render in the blog post), people writing that code would be able to do so with a strongly typed view of the world.

    It wouldn't have to just be .d.ts declaration files, of course - for instance, the LightSwitch-generated TypeScript could also generate strongly typed wrappers so those contentItem.data["foo"] calls could be switched out for strongly typed property accessors.

    Does this make sense conceptually?  LightSwitch is definitely in the right spot (AFAICT) with its rich metadata knowledge to at least potentially provide an excellent TypeScript-based developer story :)


    Friday, January 25, 2013 6:42 PM
  • Without having yet looked at the html client beyond the demo videos, my guess would be that LightSwitch could do more because it has all the metadata about the object graphs / models / methods.  

    For instance, LightSwitch could write/update a set of .d.ts files in the project so that when writing custom code (like RowTemplate_render in the blog post), people writing that code would be able to do so with a strongly typed view of the world.

    It wouldn't have to just be .d.ts declaration files, of course - for instance, the LightSwitch-generated TypeScript could also generate strongly typed wrappers so those contentItem.data["foo"] calls could be switched out for strongly typed property accessors.

    Does this make sense conceptually?  LightSwitch is definitely in the right spot (AFAICT) with its rich metadata knowledge to at least potentially provide an excellent TypeScript-based developer story :)



    ++1

    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

    Friday, January 25, 2013 6:45 PM