Locked Can we also build HTML Desktop?

  • Monday, June 11, 2012 5:20 PM
     
     
    Is the HTML restricted only to Mobile or can we also build Desktop version as well as Mobile (similar to SL version)?

    ..Ben

All Replies

  • Monday, June 11, 2012 6:28 PM
    Moderator
     
     

    Hi Ben,

    It's based on JQuery Mobile and JQuery supports IE 7-9 as well as most other browsers, so yes, you could use the HTML client on a PC. Not a desktop client in the same sense as the Silverlight desktop client. I'm curious though - why wouldn't you continue to use the richer Silverlight client for desktop apps?

    Regards,


    Steve Hoag Microsoft aka the Lights Witch (IEnumerable of Newt)

  • Monday, June 11, 2012 6:29 PM
     
     Proposed

    Hi Ben,

    Thanks for the question—I think you get the award for the first question in the forum J.

    From a technical perspective, the HTML client will run in any modern browser—desktop or mobile.  But the user model of the application, controls, and programming model are specifically designed for touch-oriented mobile devices. 

    For example, our list control follows a model that’s commonly found on phones and tablets: it uses inertial scrolling (i.e., the list is scrolled as quickly as your finger is swiped) and incremental loading of items instead of a data pager.  It works quite well in mobile scenarios, where the browser typically doesn’t show a scrollbar and you’re navigating with your finger; but it’s not a model that works particularly well when a scrollbar is present and you’re using a mouse to navigate the list.  Similarly, all of our controls are styled with ample padding to ensure users can tap them with a finger easily; most desktop apps prefer a tighter screen layout and much less padding. You can check out the jQuery Mobile website to get a feel for the amount of padding our controls have by default. (We use jQuery Mobile for the HTML client and our styling, while unique to LightSwitch, follows the same design guidelines.)

    Targeting the mobile landscape specifically has also allowed us to optimize for more modern browsers—running on legacy browsers is a non-goal for this client.  Most desktop-oriented web apps out there go to great pains to support legacy browser—and, consequently, end up writing tremendous amounts of browser-specific code to do it.  We are able to take advantage of many of the HTML5/CSS 3 constructs and provide a simpler coding experience in our client because we assume you’re using a mobile device with a modern browser.

    We focused our attention on the mobile space with the HTML client because it’s something we really can’t target at all today with our Silverlight client—most mobile devices don’t allow browser plug-ins, etc.  And while you certainly could run the HTML client on the desktop, I think you’ll find the Silverlight client to be a much better option for it.

    Please let me know if you’d like more details.

    Thanks—and please keep the questions coming!

    Joe

  • Monday, June 11, 2012 6:53 PM
     
     

    Hi Steve & Joe;

    @ Steve: As you may know I've been involved in SL since 2007 (first release) and have had many different experiences with SL runtime. One of it's most painful cases has been where the end-user can not or will not install the SL plugin. For example any government agency or anyone dealing with government agency, is not allowed to install plugins. All software are tightly controlled by government. This has expended into Medicaid/Medicare, State education, Fed. Government and legal system and growing. This alone has cost me a great amount of money, where I could not sell my mass SL app. SL/LS apps are great for Intranet and controlled environment and not wide web reach like HTML/JS. Your H5 Mobile is VERY welcomed, but I want to know if we will have a desktop version of it for mass reach?

    @Joe: You expertly explained to me the Mobile features. I had understood & imagined those great features when I read the announcement. I'm NOT rejecting or downplaying the value of this new Mobile feature, but as you properly pointed out the UI design for a mobile is different that the UI for a desktop Browser app and the other way around as well.

    So my humble question is, is there a plan for us to publish our apps in browser as H5/JS rather than using SL plug in? I love SL and it's UI design, but if the user doesn't install the plugin, my app means nothing.
    Another case for my app is that, it's potential use is a Tablet (iPad or Android tablet) which neither one can run SL, heck Win8 Metro browser doesn't even run SL apps. So, as the world is moving towards H5/JS, I'm waiting for LS to embrace it for desktop. If you manage to do it for Mobile, then I can see you going that way, but when....?

    Thanks Joe!


    ..Ben

  • Monday, June 11, 2012 7:27 PM
     
     Answered

    Hi Ben,

    Thanks for the context—that helps.

    We do not currently have plans to expand the HTML/JS client to target the desktop.  Delivering the mobile scenarios is our priority right now.  We probably won’t be in a position to consider and discuss next steps until we feel confident that we’ve delivered on the mobile offering.  That said, you mention Win8 slates and iOS and as potential targets for you—these are some of our highest priority targets for the initial HTML client release.  Win8 slates, iPad, Android, et al tablets are devices that our HTML clients are built and tested for.  It’s intentional that the devices that don’t allow plug-ins are the devices that the HTML client targets. We continue to see an upwelling of tablets in the business space as an alternative to traditional desktop devices, and we wanted to capture that emerging trend before considering an offering that would overlap with our existing Silverlight client.

    Nonetheless, I certainly understand and relate to the roadblocks you’re facing in building out desktop applications with Silverlight/WPF.

    I hope this helps give you a sense for our priorities and vision for the client.

    Thanks again.

    Joe

    • Marked As Answer by Ben Hayat Monday, June 11, 2012 7:31 PM
    •  
  • Monday, June 11, 2012 7:37 PM
     
     

    Hi Ben,

    Thanks for the context—that helps.

    We do not currently have plans to expand the HTML/JS client to target the desktop.  Delivering the mobile scenarios is our priority right now.  We probably won’t be in a position to consider and discuss next steps until we feel confident that we’ve delivered on the mobile offering.  That said, you mention Win8 slates and iOS and as potential targets for you—these are some of our highest priority targets for the initial HTML client release.  Win8 slates, iPad, Android, et al tablets are devices that our HTML clients are built and tested for.  It’s intentional that the devices that don’t allow plug-ins are the devices that the HTML client targets. We continue to see an upwelling of tablets in the business space as an alternative to traditional desktop devices, and we wanted to capture that emerging trend before considering an offering that would overlap with our existing Silverlight client.

    Nonetheless, I certainly understand and relate to the roadblocks you’re facing in building out desktop applications with Silverlight/WPF.

    I hope this helps give you a sense for our priorities and vision for the client.

    Thanks again.

    Joe

    Well Joe, I must sincerely thank you for giving me a straight and informative (none political) answer.

    After I posted my previous question, I then began to think that the Mobile HTML client "Should" satisfy the tablet need, since both mobile and table devices ping are operated similarly. So that should fulfill that gap. And I do understand your wise decision of not jumping on too many branches, i.e. Desktop HTML until you're fully satisfied.
    I now have to re-evaluate LS towards my project and see what percentages of users will be Browser desktop.

    Once again, I do appreciate your frank answers! Thank you Sir!


    ..Ben

  • Tuesday, June 12, 2012 12:26 AM
     
     

    Hi Ben,

    With the next OData capabilities that LS V2 brings, have you considered creating a WPF client for use on the desktop, for those unwilling to install the SL plugin?


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

  • Tuesday, June 12, 2012 12:29 AM
     
     
    Unfortunately my immediate project requirement is also for a desktop HTML application. I've seen posts discussing tweaking the CSS to work on both desktop and mobile browsers but although workable, apparently not ideal. Looking forward to my next mobile app though :)

    Xander

  • Tuesday, June 12, 2012 12:38 AM
     
     

    Hi Ben,

    With the next OData capabilities that LS V2 brings, have you considered creating a WPF client for use on the desktop, for those unwilling to install the SL plugin?


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Hi Yann;

    It's not just a plugin installation problem. It's "installation" of third party all together. That's first issue. Secondly, maintaining updates for mass reach is a nightmare. For example, in ASP, I publish the update in 30 seconds, everyone on any OS on any machine can see the update right away. Users are spoiled with ease of browser. This is not a controlled environment or Intranet. 


    ..Ben

  • Tuesday, June 12, 2012 12:49 AM
     
     

    Fair enough..

    I only mentioned just in case you hadn't thought of it. I should have known there'd be a reason. :-)


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

  • Tuesday, June 12, 2012 12:54 AM
     
     

    Fair enough..

    I only mentioned just in case you hadn't thought of it. I should have known there'd be a reason. :-)


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Trust me, I've fried my brain on this. And you know what, even going straight to HTML5/JS doesn't solve the problem. Because you have so many tools/libraries/widgets to figure which works on what browsers. Yes, jQuery helps to some degree. Writing muti platform os very challanging.

    ..Ben

  • Tuesday, June 12, 2012 12:57 AM
     
     
    I'm wrestling with the exact same issue to create a desktop HTML app - even have http://www.yiiframework.com on my list of options to evaluate!

    Xander

  • Tuesday, June 12, 2012 1:06 AM
     
     
    I'm wrestling with the exact same issue to create a desktop HTML app - even have http://www.yiiframework.com on my list of options to evaluate!

    Xander

    Xander, if you're are .Net developer at heart, I'd steer away from PHP, since .Net give you powerful back end and middle tier. Just to share some thoughts. In the next 9 to 12 months, you'll see more new stuff coming out in the Web stack from MSFT that uses WebAPI for middle tier and several solutions for client side, including Upshot. So, for writing SPA applications, this is one direction I'm keeping my eyes on.

    For "website & presentation", MVC offers powerful platform.

    For "webApp & LoB" Webform offer excellent solutions. Especially with the new ASP.net 4.5. The data modeling and validation and use of jQuery by framework, you can build killer apps with Webforms and Telerik controls. After months of research and trail, this is my preferred solution and works. Next year, I'll switch to SPA and WebAPI.


    ..Ben

  • Tuesday, June 12, 2012 1:24 AM
     
     
    For "webApp & LoB" Webform offer excellent solutions. Especially with the new ASP.net 4.5. The data modeling and validation and use of jQuery by framework, you can build killer apps with Webforms and Telerik controls. After months of research and trail, this is my preferred solution and works. Next year, I'll switch to SPA and WebAPI.

    Thanks Ben, this is quite useful information. I am a .NET developer at heart but one of my current applications have a large PHP API and I'm quite comfortable writing PHP code.

    The hardest part of development, for me at least, is doing the UI. Not that I do not have an eye for design, but just that it is the most work and takes forever to get right and there are so many technology choices to make and browsers to support. This is exactly where LS won me over as I could relatively easily create great UIs that just worked.

    I want something that makes desktop HTML UI development easy and quick and even more importantly, easy to maintain and enhance. Later I want that for mobile too. And this is mostly for creating LOB applications.

    I've not looked at webforms in years, but your post above has prompted me to add webforms + Telerik controls to the list as well. In the end, the technology that will solve my HTML UI problem will win me over for the next year anyway and it does not matter whether it is .NET or PHP actually.

    I am also following the whole SPA development closely, hence my other form question about what javascript libraries will be used in LS now, but I'm kind of waiting for MS to provide a bit more direction over and above the initial SPA pre-release stuff.

    EDIT: and the there is of course Kendo UI + the new ASP.NET MVC extensions for Kendo that have been pre-released to add into the mix!

    thanks


    Xander

    • Edited by novascape Tuesday, June 12, 2012 1:30 AM
    •  
  • Tuesday, June 12, 2012 1:34 AM
     
     

    For "webApp & LoB" Webform offer excellent solutions. Especially with the new ASP.net 4.5. The data modeling and validation and use of jQuery by framework, you can build killer apps with Webforms and Telerik controls. After months of research and trail, this is my preferred solution and works. Next year, I'll switch to SPA and WebAPI.

    Thanks Ben, this is quite useful information. I am a .NET developer at heart but one of my current applications have a large PHP API and I'm quite comfortable writing PHP code.

    The hardest part of development, for me at least, is doing the UI. Not that I do not have an eye for design, but just that it is the most work and takes forever to get right and there are so many technology choices to make and browsers to support. This is exactly where LS won me over as I could relatively easily create great UIs that just worked.

    I want something that makes desktop HTML UI development easy and quick and even more importantly, easy to maintain and enhance. Later I want that for mobile too. And this is mostly for creating LOB applications.

    I've not looked at webforms in years, but your post above has prompted me to add webforms + Telerik controls to the list as well. In the end, the technology that will solve my HTML UI problem will win me over for the next year anyway and it does not matter whether it is .NET or PHP actually.

    I am also following the whole SPA development closely, hence my other form question about what javascript libraries will be used in LS now, but I'm kind of waiting for MS to provide a bit more direction over and above the initial SPA pre-release stuff.

    thanks


    Xander

    All I can tell you, it's a mess right now. Even if you solve the Client UI issue, you still have to deal building the middle tier and back end.

    When I heard the LS/HTML news today, I couldn't wait to pop the question if we can do both mobile & desktop HTML in LS. That would have solved 90% of the problems. But it was too good to be true. :-)


    ..Ben

  • Tuesday, June 12, 2012 1:37 AM
     
     

    When I heard the LS/HTML news today, I couldn't wait to pop the question if we can do both mobile & desktop HTML in LS. That would have solved 90% of the problems. But it was too good to be true. :-)
    Would have solved just about all my problems too :)

    Xander

  • Tuesday, June 12, 2012 4:51 AM
     
     

    For a desktop HTML application I would call LightSwitch using OData.

    Using LightSwitch allows you to centralize your business rules and security and this save a LOT of time and effort.

    See:

    http://lightswitchhelpwebsite.com/Blog/tabid/61/tagid/34/OData.aspx


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Tuesday, June 12, 2012 4:53 AM
     
     

    Your book addresses this whole issue quite nicely from using a Lightswitch OData perspective really. Time to work through the example :)

    EDIT: the fact that LS will use datajs and your example uses that too, makes it even more relevant.


    Xander

    • Edited by novascape Tuesday, June 12, 2012 4:54 AM
    •  
  • Tuesday, June 12, 2012 5:02 AM
     
     

    the fact that LS will use datajs and your example uses that too, makes it even more relevant.


    Xander

    DataJs and LightSwitch is also covered here:

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

    The chapter in the book is the same example, but it provides a bit more explanation.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Wednesday, June 13, 2012 4:43 AM
     
     

    I watched the Beth & Joe video and thoroughly enjoyed it (btw. I hope that the re-hosting of any screen as a dialog makes it into the Silverlight client as well).

    It does make me wonder however, what specifically, over and above including the jQM javascript files and CSS makes the HTML client target mobile devices in particular? Notwithstanding Joe's comments above about focusing on mobile to start with (which I respect), it seems to me that there might be very little required to make it support desktop browser apps as well?

    Will the LS team considering opening up the addition of additional client types so the 3rd parties can create additional "client type templates", possibly targeting desktop HTML?

    Mobile is important, but I suspect there is a *huge* market for desktop HTML apps ready to embrace LS if it would support that.

    ps. Sorry about persisting on this topic, but I don't totally want to give up just yet, before understanding exactly what stops us from doing this (even if it requires 3rd party support or we have to develop our own templates).

    thanks


    Xander

  • Wednesday, June 13, 2012 4:53 AM
     
     

    "I watched the Beth & Joe video"

    What video are you talking about Xander?


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

  • Wednesday, June 13, 2012 4:54 AM
     
     

    Hi Yann,

    The channel 9 one here: http://blogs.msdn.com/b/bethmassi/archive/2012/06/12/early-look-at-the-visual-studio-lightswitch-html-client-joe-binder-beth-massi.aspx

    Regards


    Xander

    • Edited by novascape Wednesday, June 13, 2012 4:55 AM
    •  
  • Wednesday, June 13, 2012 4:55 AM
     
     

    I watched the Beth & Joe video and thoroughly enjoyed it (btw. I hope that the re-hosting of any screen as a dialog makes it into the Silverlight client as well).

    It does make me wonder however, what specifically, over and above including the jQM javascript files and CSS makes the HTML client target mobile devices in particular? Notwithstanding Joe's comments above about focusing on mobile to start with (which I respect), it seems to me that there might be very little required to make it support desktop browser apps as well?

    Will the LS team considering opening up the addition of additional client types so the 3rd parties can create additional "client type templates", possibly targeting desktop HTML?

    Mobile is important, but I suspect there is a *huge* market for desktop HTML apps ready to embrace LS if it would support that.

    ps. Sorry about persisting on this topic, but I don't totally want to give up just yet, before understanding exactly what stops us from doing this (even if it requires 3rd party support or we have to develop our own templates).

    thanks


    Xander

    I've been battling with the same thoughts since yesterday and I didn't want to sound argumentative to Joe (I have high respect for him), but I just don't see the priority of Mobile over desktop HTML. There is such a vacuum for Desktop HTML LoB tool that LS could make a killing right now. Do you know how many NEW VS12 MSFT would sell if LS could do Desktop? 
    I respectfully ask to consider pushing the desktop priority way to the top.

    Just my 2 1/2 cents :-)


    ..Ben

  • Wednesday, June 13, 2012 5:00 AM
     
     

    I respectfully ask to consider pushing the desktop priority way to the top.

    I would agree. If not pushed to the top, provide support for it in parallel to the mobile version or add support for additional community/3rd party templates to address that (say using jQuery UI). This would be HUGE.

    EDIT: I have a large desktop HTML project I need to kick of now and this would be ideal. A desktop HTML template/theme that works exactly like the new Silverlight Cosmopolitan theme (header, drop down menu at top with tabs opening and toolbar at bottom) would be perfect as a starting point or first template and it seems to me the building blocks are all in place except for the actual template/theme.

    thanks


    Xander


    • Edited by novascape Wednesday, June 13, 2012 5:09 AM
    •  
  • Wednesday, June 13, 2012 6:16 AM
     
     

    I watched the Beth & Joe video and thoroughly enjoyed it (btw. I hope that the re-hosting of any screen as a dialog makes it into the Silverlight client as well).

    It does make me wonder however, what specifically, over and above including the jQM javascript files and CSS makes the HTML client target mobile devices in particular? Notwithstanding Joe's comments above about focusing on mobile to start with (which I respect), it seems to me that there might be very little required to make it support desktop browser apps as well?

    Will the LS team considering opening up the addition of additional client types so the 3rd parties can create additional "client type templates", possibly targeting desktop HTML?

    Mobile is important, but I suspect there is a *huge* market for desktop HTML apps ready to embrace LS if it would support that.

    ps. Sorry about persisting on this topic, but I don't totally want to give up just yet, before understanding exactly what stops us from doing this (even if it requires 3rd party support or we have to develop our own templates).

    thanks


    Xander

    Everyone is talking about desktop as if it is a seperate beast or something on the browser. Still a browser. I assume your talking more about acheiving the look and feel of the current SL controls.  My take was that the multiple clients was exactly to support different clients. One client for mobile, another for ipad (for example), and another for "desktop" modified to take advantage of larger screen, mouse, etc.  Joe is best source, but sounds like you can change your css and style controls to work as you need. Granted, a lot work but probably still easier then a whole client from scratch in another tech (i.e. std asp.net).
  • Wednesday, June 13, 2012 7:13 AM
    Moderator
     
     

    Hi William,

    Yes, I think you're on the right track. Optimized for mobile devices, but really, is desktop all that different with a little efffort via CSS? Do I smell a third-party opportunity here? It would take a lot of work to match the Silverlight desktop capabilities, but if there is a market...?

    Regards,


    Steve Hoag Microsoft aka the Lights Witch (IEnumerable of Newt)

  • Wednesday, June 13, 2012 7:24 AM
     
     

    @William and @Steve, precisely my points too. There is a difference in UI control appearance and sometimes behavior between mobile/pads and desktop but down below it is all the same and more of a reason why we should be able to target desktop HTML apps as well.

    It will however require a change to use say "jQuery UI" instead of "jQuery Mobile" to get a good desktop experience. There are internet posts/discussions/blogs about using jQuery Mobile in a desktop environment with some changes to the CSS, but the universal opinion seems to be that it is not ideal. Should be doable to use jQuery UI instead though.

    My point above about the Silverlight Cosmopolitan theme was merely to illustrate what I had in mind as a starting point for a desktop HTML theme.

    Regards


    Xander

    • Edited by novascape Wednesday, June 13, 2012 7:25 AM
    •  
  • Wednesday, June 13, 2012 1:03 PM
     
     

    @William and @Steve, precisely my points too. There is a difference in UI control appearance and sometimes behavior between mobile/pads and desktop but down below it is all the same and more of a reason why we should be able to target desktop HTML apps as well.

    It will however require a change to use say "jQuery UI" instead of "jQuery Mobile" to get a good desktop experience. There are internet posts/discussions/blogs about using jQuery Mobile in a desktop environment with some changes to the CSS, but the universal opinion seems to be that it is not ideal. Should be doable to use jQuery UI instead though.

    My point above about the Silverlight Cosmopolitan theme was merely to illustrate what I had in mind as a starting point for a desktop HTML theme.

    Regards


    Xander

    At this time it appears the LightSwitch HTML designer uses all JQuery and JavaScript. For the best performance for my end users I am going to continue to use the Silverlight client, and only when I have to, a normal ASP.NET website, and make OData calls using: Calling LightSwitch 2011 OData Using Server Side Code (without the JQuery of course).

    JQuery mobile gives a great look and automatically optimizes for a small phone or a large Tablet, but it comes as a cost to performance. For most LOB apps it is great, but if people are thinking of a screen with a lot of information and a ton of buttons they will be really disappointed with the performance. This is not LightSwitch's fault, it is a limitation of the performace of JavaScript.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Wednesday, June 13, 2012 7:59 PM
     
     

    Hi Ben,

    Thanks for the context—that helps.

    We do not currently have plans to expand the HTML/JS client to target the desktop.  Delivering the mobile scenarios is our priority right now.  We probably won’t be in a position to consider and discuss next steps until we feel confident that we’ve delivered on the mobile offering.  That said, you mention Win8 slates and iOS and as potential targets for you—these are some of our highest priority targets for the initial HTML client release.  Win8 slates, iPad, Android, et al tablets are devices that our HTML clients are built and tested for.  It’s intentional that the devices that don’t allow plug-ins are the devices that the HTML client targets. We continue to see an upwelling of tablets in the business space as an alternative to traditional desktop devices, and we wanted to capture that emerging trend before considering an offering that would overlap with our existing Silverlight client.

    Nonetheless, I certainly understand and relate to the roadblocks you’re facing in building out desktop applications with Silverlight/WPF.

    I hope this helps give you a sense for our priorities and vision for the client.

    Thanks again.

    Joe

    I would appreciate any advice on how to sell a Silverlight based client, or developments on it, to a decision maker, e.g. clients, management.. I'm facing this dilemma right now, so any suggestions are appreciated.

    Or maybe someone surprises me by answering my news are outdated and MS is not ending support and developments on SL.

    I'm hoping for the latter.

  • Wednesday, June 13, 2012 8:07 PM
     
     
    I would appreciate any advice on how to sell a Silverlight based client, or developments on it, to a decision maker, e.g. clients, management.. I'm facing this dilemma right now, so any suggestions are appreciated.

    Simple, enter and update 20 records using HTML and then do the same using the LightSwitch Silverlight client.

    The LightSwitch Silverlight client will be so much faster it will speak for itsself.


    The Visual Studio LightSwitch Marketplace http://LightSwitchHelpWebsite.com


  • Wednesday, June 13, 2012 8:15 PM
     
     

    I would appreciate any advice on how to sell a Silverlight based client, or developments on it, to a decision maker, e.g. clients, management.. I'm facing this dilemma right now, so any suggestions are appreciated.

    Or maybe someone surprises me by answering my news are outdated and MS is not ending support and developments on SL.

    I'm hoping for the latter.

    For me SL was/is one of the best technologies created for the web. It's really ashamed MSFT dropped the ball and gave up so early in the game. It was one of the poorest decision and action that MSFT took (for any internal reasons or fights). MSFT with it's weight could have pushed SL into the market, but the guys in the Windows division were threaten by it's power that no one will jump on Win8, as long as beautiful [SL] apps would run on XP/Vista/Win7/Mac. So they figured discontinuing SL, will [eventually] force the devs to take on Win8 development (we'll see about that logic).

    BUT, it is what it is, SL is history and all major companies [MSFT, Google, Apple, Adobe, etc] putting force behind HTML5/JS and the sooner we get on the bandwagon the less we will lament over SL. It's very painful to part from SL, but life moves on...


    ..Ben


    • Edited by Ben Hayat Wednesday, June 13, 2012 8:16 PM
    •  
  • Wednesday, June 13, 2012 8:28 PM
     
     

    BUT, it is what it is, SL is history and all major companies [MSFT, Google, Apple, Adobe, etc] putting force behind HTML5/JS and the sooner we get on the bandwagon the less we will lament over SL. It's very painful to part from SL, but life moves on...


    ..Ben


    I feel that the LightSwitch Silverlight cleint is still the best UI when it can be used. A desktop user was never a target for the Metro-Only version of Windows 8. That version is only for Tablets.

    Silverlight is not dead. Microsoft Access is not dead. Millions of people are using both technologies.

    Now, when LightSwitch has a Windows 8 Metro XAML Client, THEN the Silverlight Client will be in trouble.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Wednesday, June 13, 2012 8:41 PM
     
     

    Silverlight is not dead. Microsoft Access is not dead. Millions of people are using both technologies.

    I never said SL was dead. I said: "So they figured discontinuing SL..."

    Access, FoxPro, Win32, WinForm, SL and etc. are not dead. The are in use and supported by MSFT. But they are discontinued.

    When GM discontinued Pontiac or Saturn brands, it did mean it kill them. People are still driving them and you still get parts and support. But will you buy your next car as a Pontiac or Saturn from a used car lot or a new car that is still in production and gets updates?


    ..Ben

  • Wednesday, June 13, 2012 8:56 PM
     
     

    Silverlight is not dead. Microsoft Access is not dead. Millions of people are using both technologies.

    I never said SL was dead. I said: "So they figured discontinuing SL..."

    Access, FoxPro, Win32, WinForm, SL and etc. are not dead. The are in use and supported by MSFT. But they are discontinued.

    When GM discontinued Pontiac or Saturn brands, it did mean it kill them. People are still driving them and you still get parts and support. But will you buy your next car as a Pontiac or Saturn from a used car lot or a new car that is still in production and gets updates?


    ..Ben

    Silverlight has not been discontinued.

    The LightSwitch team keeps pointing out that the Silverlight client is the reccomended thing to use for a normal desktop application.

    There is no replacement for desktop applications in LightSwitch. Silverlight is it and will remain so for years. For example, Silverlight works on the Apple MAC. For a Apple MAC Desktop applications you will want to use the Silverlight client.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Wednesday, June 13, 2012 9:31 PM
     
     
    indeed. thank you both for what it seems a clear summary of the opposite views.

    Business wise, against my will, I'll have to agree with Ben. In the enterprise world, that announcement is a killer. If the organization adopted MS as primary vendor, it's not easy to decide sticking or building new blocks with apps that are not actively being developed. Or alien clients for the upcoming OS. Hell, just the whisper of it is enough... Even counter arguing with arguments like stable and solid SL v5, fair time frame for support still in horizon, beautiful ?fast? applications,..etc..heart..etc..passion..it rarely works, at least in my experience and environment (finance).

    On the other hand, for what I'm trying to achieve, even if just for personal and departmental usage, 5 years of value is still value, considering the primary asset (in my specific case) is a backend KB/CMS database, re-usable by many other applications, assuring it "lives on".

    But I don't see a bright future for a dev tool that relies on such constraints..no. sadly..hope I'm wrong and hope not to offend anyone.

    But an awesome tool it is. The vision/mission will be picked up later on by this same or any other, I have no doubts and enough experience to understand a trend in IT.

    Regards.
  • Wednesday, June 13, 2012 10:34 PM
     
     


    But I don't see a bright future for a dev tool that relies on such constraints..no. sadly..hope I'm wrong and hope not to offend anyone.

    But an awesome tool it is. The vision/mission will be picked up later on by this same or any other, I have no doubts and enough experience to understand a trend in IT.

    Regards.

    What is you alternative?

    You will use HTML pages for everything because it is the safe thing to do?

    Are people using IPads to look at HTML5 sites or are they using the 200,000 IPad apps that provide good performance (and if you call LightSwitch with OData it works fine with IPad apps)?


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com

  • Thursday, June 14, 2012 1:09 AM
     
     
    Thanks Xander. I found it shortly after I posted the question.

    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

  • Thursday, June 14, 2012 5:51 AM
     
     

    I don't think we should use this thread to debate Silverlight vs HTML as that has been done at length in the past and will be done in future again. Despite our own or our customers' preferences, pros and cons of each, I think everyone will agree that there is a place for both at present. The aim of this thread was to ask whether we can build "desktop HTML" apps in the new LS and the answer was quite clear that mobile/slate apps was the priority for now.

    However, it has also become clear, based on feedback above, that there is a real need for "desktop HTML" apps today and that the capability to produce those should not be pushed out to later. In other words, we want to produce great 1) Silverlight apps 2) desktop HTML apps and 3) mobile/slate HTML apps using LS and we'd like to do all of those from the start.

    I'm confident that the purpose of this forum is to gain feedback on the great work done by the LS team and I'm confident that they are reading every single post here! Thanks guys for a wonderful product that is going from strength to strength and please take our feedback on board.

    Regards


    Xander

    • Edited by novascape Thursday, June 14, 2012 5:53 AM
    •  
  • Thursday, June 14, 2012 10:33 AM
     
     

    @Michael: I'll have to use whatever is allowed to deploy in my workstation and compliant. The notion of compliant is, IMHO, what you're not bringing into equation. It's not about what we want to use, and what's best, it's about what we're allowed to and outlined in the organization strategy, pushed by MS. But of course I admit my case is probably not the rule.
    For now, we do have SL as a "packaged" deployment option. But, from the moment that a security concern arises and  the situation of SL is debated in higher layers, this will be blocked immediately! Why not? what's the value compared to the risk? Because it's prettier and faster? MS themselves issued the statement!

    Great job yourself by the way :) I've learned a lot from your posts and website and I'll be getting the book!


    @Xander: We interpret different. I read a "NO" while you read a "maybe". I go with facts and not hunches. I would love to be proven wrong, can someone point me to a MS statement where no cordial service desk language is used to blur the roadmap? Trust me, it would make my day, I'm a LS believer.

    I'm sorry if I "hijacked" the thread, if so, I apologize but I thought it was sufficiently related for me to post my question.

    I'll shut up now. Enjoy your day. :)

  • Thursday, June 14, 2012 11:22 AM
     
     

    @Lisalena: sorry, I did not mean to chase you away or make you shut up :) Your opinions are appreciated and most welcome, don't stop, I just did not think a debate on SL vs HTML was the right thing for this thread as this thread should be concentrating on "desktop HTML" vs "mobile HTML" instead.

    Regards


    Xander

  • Thursday, June 14, 2012 11:32 AM
     
     

    So, back to the topic at hand. I've used jQuery mobile to develop apps which work on the desktop and mobile equally well. The theming will affect how big controls/buttons etc are but I would expect this to generally work. The current jquery mobile works well in IE on the desktop.

    Regarding performance (lots of buttons etc). Your app will perform better on the desktop than it does on mobile unless your mobile is more powerful than your PC, in which case it's upgrade time!

    Chris

  • Thursday, June 14, 2012 12:47 PM
     
     

    So, back to the topic at hand. I've used jQuery mobile to develop apps which work on the desktop and mobile equally well. The theming will affect how big controls/buttons etc are but I would expect this to generally work. The current jquery mobile works well in IE on the desktop.

    Regarding performance (lots of buttons etc). Your app will perform better on the desktop than it does on mobile unless your mobile is more powerful than your PC, in which case it's upgrade time!

    Chris

    I have had issues with JQuery on the desktop:

    http://lightswitchhelpwebsite.com/Forum/tabid/63/aft/761/Default.aspx

    also when I go to you link you posted: http://openchargemap.org/app/

    In IE 9 it just hangs and I get:

    In Firefox it works:

    This is OK because on Mobile web browsers it does work, but there is a compatibility chart:

    http://jquerymobile.com/gbs/

    For LOB apps in the enterprise some of us are still dealing with IE6 :)

    These are the reasons why I believe that the LightSwitch team is saying that currently this will be optimized for mobile devices.


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com


    • Edited by ADefwebserverMVP Thursday, June 14, 2012 12:53 PM removed personal speculation :)
    •  
  • Thursday, June 14, 2012 12:58 PM
     
     
    Ha, good point! However that bug is specific to that application and it's unfair to blame jQuery Mobile for that (it's a caching/async calls issue). That bug is the same on mobile IE WP7 so at least it's consistent :)
  • Thursday, June 14, 2012 1:21 PM
     
     
    Ha, good point! However that bug is specific to that application and it's unfair to blame jQuery Mobile for that (it's a caching/async calls issue). That bug is the same on mobile IE WP7 so at least it's consistent :)

    Please understand I am not trying to beat up on you :)

    I have had issues, for example when a person would enter data and click save, I needed the person to go to the next page. It worked in some web browsers and not in others. In my case I used Server.Transfer on the server side because I got frustrated after an hour and got tired of dealing with the issue :)

    Can you imagine how people would complain if this were their LightSwitch app? When people ask that the LightSwitch team support desktop HTML apps they expect it to work every time with the consitant performance that the current Silverlight client provides.

    ** Again, jQuery Mobile worked great on all mobile devices I tested it with! **

    This is why I believe the LightSwitch team is promising mobile. They can deliver on that promise!

    You CAN have a LightSwitch Desktop HTML app right now if you simply use ASP.NET Web Forms, PHP, ect and make OData calls. You will get the same consistent performance you currently get. If you don't use LightSwitch this is what you have to do anyway. If you use LightSwitch you can cut 70%+ work (because it will handle your middle-layer business and security).


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com


  • Thursday, June 14, 2012 1:35 PM
     
     

    @Michael: I'll have to use whatever is allowed to deploy in my workstation and compliant. The notion of compliant is, IMHO, what you're not bringing into equation. It's not about what we want to use, and what's best, it's about what we're allowed to and outlined in the organization strategy, pushed by MS. But of course I admit my case is probably not the rule.
    For now, we do have SL as a "packaged" deployment option. But, from the moment that a security concern arises and  the situation of SL is debated in higher layers, this will be blocked immediately! Why not? what's the value compared to the risk? Because it's prettier and faster? MS themselves issued the statement!

    Great job yourself by the way :) I've learned a lot from your posts and website and I'll be getting the book!


    Thank you for the support :)

    Please understand I am not beating up on you :)

    When my arguments are not enough that illustrates a reality. In my opinion it says that the Silverlight client may get some growth but not as much as some of us would hope because the damage done to Silverlight by decisions such as the recent one to support Flash but not Silverlight in Metro (ARGGGGG!)

    Your concerns are exactly what many others have said. Your situation is real and not going away.

    You voice is being heard and the truth hurts :(


    The Visual Studio LightSwitch Marketplace

    http://LightSwitchHelpWebsite.com


  • Wednesday, June 20, 2012 9:36 PM
     
     

    It seems we should be able to build a LS higher level Client Designer with LSML like XAML that automatically generates both an HTML desktop (for mouse usage) and mobile ( no mouse).

    Isn't it possible to have a slate/phone with a mouse and larger display?   Isn't a phone just a laptop these days?  Won't a PC in the future be Star Trek com badge - or smaller?

    Point:  We should be able to specify a 1024X768 screen that can run with a mouse/keyboard or a touch screen flick management.  Yes?


    Garth Henderson - Vanguard Business Technology

  • Tuesday, July 24, 2012 3:19 AM
     
     

    I never said SL was dead. I said: "So they figured discontinuing SL..."

    Access, FoxPro, Win32, WinForm, SL and etc. are not dead. The are in use and supported by MSFT. But they are discontinued.

    I just read your statement. Let me make this very clear. Access and SilverLight both are absolutely NOT been discontinued nor are there any plans to have it discontinued. Obviously you had no links to back up your false statements.

    Your blatant disregard of the truth has bad reprecussions and you should not spread such falsehoods around.

    We have just had a major Preview of the next version of Access that features the addition of a new Web Framework using SQL Server, SQL Azure. http://msdn.microsoft.com/en-us/library/office/jj250134(v=office.15).aspx


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Friday, July 27, 2012 5:06 PM
     
     

    Hey Patrick,

    The new Access preview looks wonderful.

    When LS first came out, it seemed like it was targeted (from a marketing standpoint) to non-developers with the capability of being expanded into a robust professional app.

    Is the new Access based on MVVM?   Is it using any of the foundational parts of LS?

    What kind of integration will be available between LS and Access?


    Garth Henderson - Vanguard Business Technology

  • Saturday, July 28, 2012 3:45 AM
     
     

    Hi Garth,

    The new Access preview looks wonderful.

    Yes it does. The fact that Access Services will now be stored in SQL Server is very welcome news to be sure. In fact, some have told us they are able to use SSMS to do a few limited things but mostly it bodes well for the future of Access and Access Services (Access Web Databases).

    When LS first came out, it seemed like it was targeted (from a marketing standpoint) to non-developers with the capability of being expanded into a robust professional app.

    I agree with your assesment of how LightSwitch was initially targeted but be know that was changed. "Visual Studio" LightSwitch pretty much says it all. I have nothing against Visual Studio, in fact I use it regularly for my ASP.Net website but that means, IMHO, that Microsoft has missed an opportunity to make LightSwitch into a very popular development platform for the average Joe. LightSwitch would have motivated a lot of Access Developers to migrate to LightSwitch development. I suppose Microsoft has it reasons but we are not privy to them.

    Is the new Access based on MVVM?   Is it using any of the foundational parts of LS?

    What kind of integration will be available between LS and Access?

    There is a lot we do not know about what is going on behind the scenes. We would not have known that Access Web Databases would be using SQL Server if it had not been announced. We do not know what role SQL Azure (now Azure SQL Databases) plays in the development and deployment of Access Web Databases. We have no information at all that either MVVM or LightSwitch is presently involved with the Access 2013 Preview. Unlike LightSwitch and MVVM you cannot use Visual Studio at all to develop 2013 Access databases. What we do know is that mostly basic database design is used. Most of what can be done can be developed with wizards. Access Web Databases are developed very differently from traditional Access database development practices.


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Saturday, July 28, 2012 3:46 AM
     
     

    Hi Garth,

    The new Access preview looks wonderful.

    Yes it does. The fact that Access Services will now be stored in SQL Server is very welcome news to be sure. In fact, some have told us they are able to use SSMS to do a few limited things but mostly it bodes well for the future of Access and Access Services (Access Web Databases).

    When LS first came out, it seemed like it was targeted (from a marketing standpoint) to non-developers with the capability of being expanded into a robust professional app.

    I agree with your assesment of how LightSwitch was initially targeted but be know that was changed. "Visual Studio" LightSwitch pretty much says it all. I have nothing against Visual Studio, in fact I use it regularly for my ASP.Net website but that means, IMHO, that Microsoft has missed an opportunity to make LightSwitch into a very popular development platform for the average Joe. LightSwitch would have motivated a lot of Access Developers to migrate to LightSwitch development. I suppose Microsoft has it reasons but we are not privy to them.

    Is the new Access based on MVVM?   Is it using any of the foundational parts of LS?

    What kind of integration will be available between LS and Access?

    There is a lot we do not know about what is going on behind the scenes. We would not have known that Access Web Databases would be using SQL Server if it had not been announced. We do not know what role SQL Azure (now Azure SQL Databases) plays in the development and deployment of Access Web Databases. We have no information at all that either MVVM or LightSwitch is presently involved with the Access 2013 Preview. Unlike LightSwitch and MVVM you cannot use Visual Studio at all to develop 2013 Access databases. What we do know is that mostly basic database design is used. Most of what can be done can be developed with wizards. Access Web Databases are developed very differently from traditional Access database development practices.

    I just found this article with some more information about the Access 2013 Preview.

    http://blogs.office.com/b/microsoft-access/archive/2012/07/20/introducing-access-2013-.aspx


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/


    • Edited by PatrickWood Saturday, July 28, 2012 3:55 AM
    •  
  • Saturday, July 28, 2012 12:45 PM
     
     

    Hi Patrick,

    From an Access Developer's perspective, this entire discussion is both amusing and illuminating. It is not the case, after all, that MS has developed "desktop amnesia" from an Office/MS-Access development perspective alone, No, it seems that the malady has infected the more developer-centric management layers within Microsoft as well.

    This would be amusing if the affects weren't so draconian for the future of desktop development. Those that believe that desktops are going to go away anytime soon are forgetting the thing we call inertia. Desktop computing will be around for a LONG time to come, and ignoring this world, forsaking it in favor of the sexy new world of mobile and internet-based computing is like trying to ignore the need for spending on interstate highways now that man has learned how to fly. One does not eliminate the need for the other.

    There is also the question of human nature at play here. People have come to have an expectation of what their desktop computing experiences SHOULD and OUGHT to be like. Trying to make too big a change here is akin to adopting a single left-side/right-side driving standard worldwide. The hurdles for attempting any such conversion would be, well immense is too small a word for it. Face it: Americans will be driving on the right, and europeans will be driving on the left far into the forseeable future, and there's nothing to be done about it.

    The same goes for desktop and web/mobile development. Both are going to exist far into the forseeable future, and MS ignores this truth to their own detriment. They imagine some bold new sexy mobile-enabled future, and think that the desktop past will just fade away? They need to wake up and smell the keyboards again. Keyboards and desktops are simply not going to disappear anytime in the near future, no matter how much anybody wants them to.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)








  • Saturday, July 28, 2012 3:23 PM
     
     

    I hear you Mark. We will be very interested to see what changes are made to the desktop development when the full version of Access 2013 is released.


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Friday, August 10, 2012 5:37 PM
     
     

    Without a commitment, is there any chance this could change:

    - before 2012 ships

    - as an incremental addition to 2012, before the next major release after 2012?

    Any chance?


    Frank

  • Friday, August 10, 2012 7:05 PM
     
     
    Sorry to be so dense but I am not sure what it is you are looking for to change. Can you elaborate?

    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Friday, August 10, 2012 7:08 PM
     
     
    Sorry to be so dense but I am not sure what it is you are looking for to change. Can you elaborate?

    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/


    The ability to build non-Silverlight, 100% HTML web apps for desktop web browsers.    Right now, the HTML direction is for Mobile.

    Frank

  • Friday, August 10, 2012 8:24 PM
     
     

    Looks like it will not be any time soon unfortunately. In the post by Joe Binder marked "Answers" we see:

        Joe Binder (MSFT) Visual Studio Team (MSFT)

        We do not currently have plans to expand the HTML/JS client to target the desktop.


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/


    • Edited by PatrickWood Friday, August 10, 2012 8:26 PM Remove inadvertanly included info
    •  
  • Friday, August 10, 2012 9:13 PM
     
     

    Hey Patrick,

    I didn't have much luck finding the Joe's post that you quoted from.

    Could you please share the link?

    There is a lot of ambiguity in what "Desktop" means.

    It is my understanding that the HTML5 client will run in a browser and that HTML5 controls can be used within LS similar to an SL control.


    Garth Henderson - Vanguard Business Technology

  • Friday, August 10, 2012 9:39 PM
     
     

    It is on this page near the top.

    http://social.msdn.microsoft.com/Forums/en-US/lightswitchhtml/thread/efe77051-66e4-4d88-9f8a-c2472ee023a5/


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Friday, August 10, 2012 10:50 PM
     
     

    As per Joe's comment (early on after the HTML preview was released), it was definitely the LS team's initial plan to focus on HTML Mobile and not Desktop, but I suspect that after all the feedback from people stating that HTML Desktop is important (e.g. this thread) they may have realized that they should not ignore HTML Desktop. Frank's post above described nicely what we mean by "HTML Desktop".

    The desktop is going to be with us for a very long time, despite the rise in popularity of mobile and potentially Windows 8 "new look".


    Xander

  • Saturday, August 11, 2012 12:19 AM
     
     

    Hi Xander,

    You may know something that I don't but unless I see some official information about it suspicions alone are not enough to get my hopes up. But I would love to see it happen.


    Patrick Wood, Access MVP
    Founder, Gaining Access Technologies http://gainingaccess.net/

  • Saturday, August 11, 2012 1:53 AM
     
     

    I wish we could get a clear statement on what the Mobile HTML support really means.

    The reality is - if they don't take steps to Disable functionality for Desktop, an HTML Mobile app Should work in a Desktop browser.   

    Are they going to explicitly Disable support, or are they simply not officially supporting the Desktop?

    There is such an Incredible opportunity for MS here.   I can't believe they are not jumping all over it.     Amazing.


    Frank

  • Saturday, August 11, 2012 2:02 AM
     
     

    The reason why the first version of the HTML client, as originally envisaged, does not play well with Desktop browsers is that they are using the jQuery Mobile framework by default, which will of course display in a Desktop browser, but will not be ideal. There are posts on the internet about tweaking the jQuery Mobile CSS to make it work on a Desktop Browser, but it is not ideal. For some very simple applications it may work, but by and large it will not, due to the styling.

    Basically I think we need two HTML clients in LS: 1) Mobile (using jQuery Mobile as is currently out in early preview) and 2) Desktop using jQuery UI for example. They are equally important IMO.


    Xander

  • Friday, August 17, 2012 6:25 PM
     
     

    The whole thing is a huge disappointment. Desktop development should be necessary for a long time since the current generation of handheld devices cannot replace desktops for most business uses.

    The mighty giant from Redmond with all the resources in the world has not been able to produce a decent 4GL tool for web development, other vendors, Wavemaker and Oracle Application Express come to mind, but I have tried many others thru the years, haven’t either.

    LightSwitch is for LOB programming, what is the projected growth for LOBs in handheld devices compared to desktops?

    Super frustrating, I can’t believe this kind of programming is a niche, the need for an easy to use web applications development tool has to be big, many business needs are not being fulfilled because traditional development is too labor intensive/expensive.

    Now you can’t event purchase the thing by itself, you need to get the whole Visual Studio package. What is the profile of a LightSwitch developer? I thought hard core programmers saw LightSwitch as a toy. Maybe it should have been part of Office. I don’t need the rest of Visual Studio, the difference between 150 and 500 specially in this economy is huge, what a shame, I wonder if they produce sales analysis to evaluate how effective was the idea of killing the option of buying the product as standalone application.

  • Friday, August 17, 2012 7:29 PM
     
     

    Very interesting comments. I share some of your thoughts.

      

    I have always been amazed at how few companies out there ever produced a legitimately useful RAD tool. There are tons of new technologies thrust on us every year, but very little effort going into actually making typical business software development less costly. LS might just become the most useful RAD tool in history.

       

    I also think MS is missing opportunities by exclusively burying LS functionality inside VS. There should be an entry level offering outside of the full VS offering.

       

    Now, on the other hand, regarding pricing: in a very small company I can understand cost concerns, but for any company with revenue to sustain more than, say, 30 people - the cost of LS is well worth it. Paying for itself - in week 1.

       

    I'm going to keep praying that we aren't hearing more about HTML Desktop client support simply because, strategically, they aren't ready to make the statement publicly. I'm praying that they have Already Decided internally that an HTML Desktop client will happen in the not so distant future. When that happens, LS will get very big, very quickly.


    Frank


    • Edited by FJA US Friday, August 17, 2012 7:30 PM
    •  
  • Friday, August 17, 2012 8:01 PM
     
     

    @Frank:  +1 - We all agree with you.  I am also praying hard that a non-SL XAML will expand as a high level generation for native windows XAML as well as a generator for HTML5 clients.

    It is my understanding that we can use HTML5 controls within LS v2.  This makes LS V2 extremely extensible.  HTML controls are much better than SL - because there are sooo many environments that just won't support SL.  This is the whole point of Windows future - being able to run client side apps on all platforms.

    I am most interested in what ComponentOne might be able to do with Wijmo immediately to create embedded controls in LS V2 apps.

    Keep in mind that LS is not constrained by XAML as it has its own LSML.

    It is my assumption that LSML currently has the ability to internally generate Screens on the client.  We would have a tremendous jump forward if we had the ability to stream down LSML code that was added to the runtime lsml object(s).  Of course, this capability would also allow us to stream down associated HTML5 Controls.  

    V2 supports reusable Modal Windows.   If we could create LSML MW "frames" that had dynamic HTML controls . . . we'd be really close to having a perfect system that requiring a minimum of SL.

    The LS HTML View runtime must (logically) already include all of the JS code to replicate the ViewModel interaction with the View.   . . . so what really remains to be written to give us a non-SL desktop?


    Garth Henderson - Vanguard Business Technology

  • Saturday, August 18, 2012 12:59 AM
     
     

    @Frank:  +1 - We all agree with you.  I am also praying hard that a non-SL XAML will expand as a high level generation for native windows XAML as well as a generator for HTML5 clients.

    It is my understanding that we can use HTML5 controls within LS v2.  This makes LS V2 extremely extensible.  HTML controls are much better than SL - because there are sooo many environments that just won't support SL.  This is the whole point of Windows future - being able to run client side apps on all platforms.

    I am most interested in what ComponentOne might be able to do with Wijmo immediately to create embedded controls in LS V2 apps.

    Keep in mind that LS is not constrained by XAML as it has its own LSML.

    It is my assumption that LSML currently has the ability to internally generate Screens on the client.  We would have a tremendous jump forward if we had the ability to stream down LSML code that was added to the runtime lsml object(s).  Of course, this capability would also allow us to stream down associated HTML5 Controls.  

    V2 supports reusable Modal Windows.   If we could create LSML MW "frames" that had dynamic HTML controls . . . we'd be really close to having a perfect system that requiring a minimum of SL.

    The LS HTML View runtime must (logically) already include all of the JS code to replicate the ViewModel interaction with the View.   . . . so what really remains to be written to give us a non-SL desktop?


    Garth Henderson - Vanguard Business Technology

    Excellent, Garth - keep praying.  Anyone else out there reading this - if you are a person of prayer - get praying.  :)

    so what really remains to be written to give us a non-SL desktop?

    I have to believe this has everything to do with Strategy, and very little to do with technical aspects.  Something tells me that if they decided to commit to it, we could be previewing a new client inside of a month.


    Frank

  • Tuesday, October 09, 2012 4:43 PM
     
     

    Just a simple and straight forward question: Where can I get inside information about how implement presentation layer templates that allow me to just add my own client into LightSwitch?

    I know that I might be able to reverse engineer or figure out how the "HTML Client" templates/views are being generated but a more pragmatic approach of how to do it will help a lot those like me that would like to make its own client while reusing the rest of the LightSwitch infrastructure.

    Very Best,
    Michael Fornaris

  • Monday, October 15, 2012 10:13 PM
     
     

    Michel has raised an interesting point. If the initial HTML client is not going to support desktop HTML clients (out of the box) it will be great if there was a way for 3rd party developers to create new HTML client "templates" that would for example, allow desktop HTML clients.

    As mentioned multiple times above, the ability to create desktop HTML clients is a big deal to me.

    I started getting excited about the new DevExpress DXTREME offering as it seemed to offer a very nice and clean way to create SPAs - that was until I realised that the controls are too limited to support LOB applications (e.g. no Grid and no Charting, etc).

    So I'm still searching for the ideal (ie. most productive) way to create LOB SPAs and hoping the the LS HTML client will fulfil that need.


    Xander

    • Edited by novascape Monday, October 15, 2012 10:17 PM
    •  
  • Wednesday, November 14, 2012 7:26 PM
     
     

    Update, as of the newly released HTML preview2:

    the mobile companion apps still mainly target mobile devices, however the team has responded to discussions like these and you can now create full-blown HTML sites with LightSwitch by using the ServerDataContext.

    Happy drooling :-)

    Keep rocking LS!


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

  • Wednesday, November 14, 2012 7:28 PM
     
     

    Just a simple and straight forward question: Where can I get inside information about how implement presentation layer templates that allow me to just add my own client into LightSwitch?

    I know that I might be able to reverse engineer or figure out how the "HTML Client" templates/views are being generated but a more pragmatic approach of how to do it will help a lot those like me that would like to make its own client while reusing the rest of the LightSwitch infrastructure.

    Very Best,
    Michael Fornaris

    Just read this, and yes this is excactly the scenario they want to embrace via the ServerDataContext.

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

  • Friday, November 30, 2012 8:51 AM
     
     

    Hi Jan

    Update, as of the newly released HTML preview2:

    the mobile companion apps still mainly target mobile devices, however the team has responded to discussions like these and you can now create full-blown HTML sites with LightSwitch by using theServerDataContext.

    I am considering using LightSwith(HTML) for LOB apps, but dont follow your above comment.

    Does this mean I can now consider using LightSwitch(HTML) for LOB Desktop apps (i.e. Apps with Moderate Data Entry requoirements) ? Up to now, reading this thread, the recommendation was NOT to use LightSwitch unles it was being deployed on   MOBILe type hardware 


    Gerard

  • Thursday, January 17, 2013 8:53 AM
     
     

    I absolutely agree with Ben,

    Lightswitch team, Please stop insist only to use silverlight in lightswitch.

    Please make the lightswitch could run using by HTML5.

    I knew RIA service was good but not for many people couldn't installed silverlight plug-in in web browser.

    Hope you refer the following URL.

    http://www.google.com/trends/explore#q=html5%2C%20silverlight&cmpt=q

    David.

  • Thursday, January 17, 2013 1:44 PM
     
     Proposed