Question

I work as internal software developer. We used Silverlight to build our application, but we have been asked to start considering their replacement.

Currently our set-up is:

  • Silverlight application for client side.
  • Asp.Net soap web service. Deployed in two servers with a load balancer.
  • MS SQL server 2008. Also Deployed in two servers with a load balancer.

Our application as as a sort of suite, performing several different functions, included but not restricted to:

  • Reporting.
  • Data analysis.
  • Front-end for several database tables that are used both for other processes in the application, and for other applications in the company.

Our constraints:

Limited development resources: We are a small team, a dozen or so developers, and while we have already hired more people to be able to cope with a increasing work load, getting more reinforcements is unlikely. Time also is constrained, as new projects, bug fixes,requests for new features in existing application and changes in the business logic are quite frequent.

Slow technology update: Our company changed from Windows XP to Windows 7 last year, and only because the support ended. We started considering to upgrade database servers to SQL server 2010 recently. Official browser is Internet Explorer 9 and Chrome. New Servers,licenses and tools can be requested, but they often take time.

Big, slow data: Some of our data come from tables big, clunky tables with million of rows and many columns, with only the bare minimum indexing, because they are updated frequently. We have little control over those specific big tables because they are feeds from other systems and requesting changes in those feeds is possible, but, as before, it takes time.

User mentality: The managers appreciate the fancy interfaces and dashboards to show in meetings. All users appreciate responsiveness and general UI smoothness. Also, many of our users come from a Excel background, which means that they are accustomed to take big chunks of data and filter them, perform analysis, make statistics, generate charts, etc, and they expect to be able to do it in the application too.

Our own experience: Most of our developers have backgrounds related to .net, asp.net, Windows Forms and Silverlight. Only a few of us have Java experience (non android). Only a few of us have experience with web applications besides some small projects.

Our past: The first iteration of our application was a windows forms application who suffered an acute case of installer bloating. Some of the IT heads decided that this could be solved by turning it into a web application. Since this was before HTML5 and we were still using IE6 as our official browser, we decided to go with Silverlight as it offered us the best compromise.

Our advantages:

Homogenized hardware: Most users use exactly the same type of laptop with the same specifications. Available screen size range is not very wide, so we should not have to struggle with different resolutions.

Intranet: We work in a controlled environment.

Reasonable budget: Most request for Servers,licenses and the like will be approved if a sufficiently good reason is given.

Recently, the higher ups has started to fear that Silverlight support may end abruptly. And they have suggested that we update the application to a more stable technology, hinting that HTML5 would be a good idea. They have asked us how feasible would be, and how much time it would take. We have next to 0 experience in this type of projects, so we are researching a bit to be able to give them an answer. This is my question:

Given this situation and set-up, would be feasible to port this kind of application to a web application with HTML5 and asp.net while keeping most of its functionality?

If not, why? Which of the above would need to be changed in order to make it possible?.

Was it helpful?

Solution

First rule of thumb - never start over if you can avoid it. That's a Joel Spolsky rule of software development. So that's automatically a strike against re-writing your app in HTML5. Fortunately, you really only have to re-write the client. You can update the server app incrementally, but you don't need to replace it wholesale.

However, moving from Silverlight to HTML5 is hardly a slam-dunk. I wrote Flex apps for a few years before switching to JavaScript as the front end of my apps. Like most folks, I had written a decent amount of JavaScript, but never an end-to-end app like a Silverlight app, and it took quite a bit of re-education to get me up to speed. Here is what I learned in no particular order.

  1. JavaScript/HTML5 is only just now getting to the point where Flex was in 2010. Maybe older JavaScript devs will argue that point with me, but to my experience, the tooling, libraries, UI elements, etc. have taken quite a bit of time to catch up to what Flex/Silverlight could offer out of the box. In this sense I still miss how easy certain things, like data binding and customized component view handlers, are in Flex.

  2. Unlike Flex/Silverlight, where there is a small ecosystem of well-thought-out tools, libraries, etc., the JavaScript ecosystem is gigantic, scattered, and not easy to navigate. Gituhub, npm and bower help organize things to some extent, but there are literally hundreds of thousands of projects in JavaScript registered and who knows which of them is going to apply to what you need.

  3. jQuery/jQueryUI are your friends. jQuery takes a lot of the old cross-browser nightmare out of JavaScript on the client. jQueryUI provides a base of UI elements from which to choose.

  4. I don't know your specific needs, but there are commercial JavaScript libraries for graphing/charting that you might be very well advised to use.

  5. Frameworks in JavaScript are like sunrises - there is a new one everyday. Pick a mainstream framework you like and stick with it.

So, is it feasible, re-writing your app? That depends on your project functionality, time and resource constraints. I suggest you look at the visualization packages available in JavaScript to see if they fit your needs. Given that you need advanced functionality, finding a match there will be your biggest challenge. Give yourself a month - research available packages, maybe try to implement a couple of functional items and see where your gaps are. That will give you a sense of what you are facing. Then you can make an informed decision about whether the tools exist (yet) to achieve your goals in a reasonable time frame. If the answer is no, re-visit the issue in another year to see how things have advanced.

Licensed under: CC-BY-SA with attribution
scroll top