After cheerleading Silverlight for the past few years I have to admit a few “truths” (as I see them)
So my “LightSwitch will save Silverlight” campaign, that is now kicked into high gear after what I have seen at the MVP Summit, is all I can think about.
HTML, whether it is HTML or HTML5 is going to take a huge blow when LightSwitch comes out because you can create a LightSwitch application 75%+ faster than a HTML one.
I think the message is simple:
“If you want a good looking LOB application, that is as easily deployed as a web app, AND you want to save 75%-90% cost and development time, you will want to look at LightSwitch vs HTML 5”
“universalness” (ok that is not really a word), was the Java message. After a ton of failed Java LOB projects, people continue to pump out Web forms LOB applications. Not because Web forms is better than Java, it is simply faster and cheaper, yet still gets the job done.
The reason you hear that HTML 5 is “the future”, is because HTML “reaches the most devices” (from the desktop to the IPad). However, a LOB application usually has a limited audience. Does your current LOB application need to run on an IPad? If not, why are you considering HTML 5?
In the future “LOB Battle”, I believe this is a HTML vs XAML fight and the ONLY thing that I think that XAML has that is faster and cheaper than HTML or HTML 5, is LightSwitch.
@Clinton Gallagher - Thanks for the feedback. However, I think the integration in Visual Studio, and that you will automatically get it if you have MSDN, will "automatically put it on a lot of computers" and that create a lot of use.<br><br>I also believe that you will be able to easily make HTML pages using a LightSwitch back-end. However, people will use the Silverlight pages most of the time because they will have a better user experience. <br><br>If you have a smart phone, you know that a app is usually better than a web page.
@Michael Crump - Thanks for the comments :)
Just an excellent post by Michael Washington. I have been talking about LightSwitch on Twitter for the past few week and this post brings smiles to my face. In the end, the customer doesn't care how you got there, they just want their app to work and address all the business needs.
@Bill Campbell - The new Oracle EF provide should work but you will want to ask on the LightSwitch Forums <a href="http://social.msdn.microsoft.com/Forums/en-us/lightswitchgeneral/threads" rel="nofollow">social.msdn.microsoft.com/Forums/en-us/lightswitchgeneral/threads</a>
Hey Michael - always enjoy your blogs. I've been in this business for 30+ years and have seen so many things come and go but totally agree with what you are saying about LightSwitch. The one thing that I need, really need, is a way to use this with an Oracle database. We have so much of this that connecting to it isn't really even a choice for us. Is there any secret sauce that can get me there? Will the new Oracle ODAC for EF let me get there with LightSwitch? Any thoughts would be very appreciated! Having that, for me, would be a silver bullet.<br>As always - thanks for the Great content!!<br>regards,<br>Bill Campbell
Yup, well said.<br><br>You pretty much nailed down what I was trying to illustrate. Access probably wasn't the best example to use.<br><br>Cheers!<br><br>Paul
@Paul Patterson - You are not far off by bringing Microsoft Access into the discussion. I spent 5 years creating Microsoft Access front-ends to SQL server and the point is that it worked (still works).<br><br>The problem with Microsoft Access is deployment. Also, I can make much better User Interfaces in Silverlight. I can create multiple front-ends to the WCF Service layer that LightSwitch creates.<br><br>I can even make a HTML5 site that talks to the WCF Services layer that LightSwitch creates, and any business rules I have made in LightSwitch will still be enforced.<br><br>Can't really do all that in Microsoft Access.<br><br>Also (Paul I know you already know all this), this is the point that I tried to cover in:<br><br>"LightSwitch: Can We Handle The Truth?" <a href="http://openlightgroup.net/Blog/tabid/58/EntryId/160/LightSwitch-Can-We-Handle-The-Truth.aspx" rel="nofollow">openlightgroup.net/Blog/tabid/58/EntryId/160/LightSwitch-Can-We-Handle-The-Truth.aspx</a><br><br>LightSwitch gives us a new "Design Pattern". Development is much faster because the LightSwitch Framework was carefully designed to allow you to define an Entity (a table) and then put a dynamically created Screen on top of it.<br><br>With Microsoft Access you can create a Screen, but if the table changes you have to delete Screen elements and add the new ones, plus your business rules can break (with LightSwitch you would always get a compile-time error).<br><br>This seems like a small thing, but your productivity is massive and your mistake are almost zero. <br><br>
Dang, I wish I was invited to that MVP Summit! I am hearing a lot of great enthusiasm for what LightSwitch is going to offer. <br><br>You nailed it in two words Michael, "Money talks". <br><br>My clients do not care about how sexy a LOB solution is going to be as long as it gets the job done. It's all about the value that the solution is going to deliver, and if that means a solution can be delivered in 75% less time, then that means 75% less cost to to shell out for something that is, say, more subjective or sexy. <br><br>Take Access for example. Look at how many businesses use Access today for LOB work. Do you think that if an enterprise was looking for a robust LOB solution that they would have considered Access in the first place? Probably not, but because the tool is so easy to use it provides a value proposition that a business can't ignore. Access is not a LightSwitch replacement, and may not be a good example for what I am trying to say, but I think you get the point.<br><br>My gut tells me to keep on top of LightSwitch. It's not an emotional thing, nor is it a subjective opinion thing either. It is because I know that there will be a demand for LightSwitch. I spent years as a very successful Business Analyst and I can tell you from years of experience and expertise, that there is going to be great opportunity here.<br><br>Cheers!<br><br>Paul<br>www.PaulSPatterson.com<br><br><br><br>
@MikeC - If I use the logic, "can I guarantee my app will never need (fill in the blank)" I will find myself spending time and money creating things I may never need.<br><br>I can build a LightSwitch application at a 75%+ savings over web forms and MVC. I can build it by myself so I don't have the problems that you have with any project that requires multiple developers.<br><br>My clients only care about an application that works and allows them to perform the business functions they need. The application needs to be affordable or they simply will just use Excel to perform the business function.<br><br>The truth is, that only a small fraction of business processes are done with web apps (even though they can be greatly improved by using a web app) because of the cost. Tell them that it will take 3 developers 3 weeks to create a MVC or web forms (or PHP) and they will simply perform the business process manually using Excel.<br><br>LightSwitch will allow us to create web deployed apps that would otherwise not be created. To not create these apps because they "may" need to be used on a IPad?<br><br>So I am simply asking, do you need this particular app to be used on an IPad? If not, pay me for 1-2 days of work and I will have your LOB app ready to go, period.<br><br>Trust me this argument will win every time. You will see a flood of LightSwitch apps. <br><br>Change is coming, it cannot be stopped.
Can you guarantee that your LOB app will NEVER have to run on the iPad or any other O/S or device that doesn't support Silverlight? That's why the best advice for green-field applications is that all apps are web apps until you can demonstrate a need for something only Silverlight or a WPF app can do that is either impossible to do with a web app or is inordinately difficult (defined as: costs the client money because their customers cannot or will not deal with the app and will go elsewhere).<br><br>As such, the assumption remains: new apps will be ASPNET MVC until proven otherwise.