0

I need some recommendations for a software stack that will allow me to put a desktop application on the web. Because it will need to look like and work like the original application as much as possible, it probably needs to be a SPA application. Delays of 1 to 3 seconds to push an HTML5 form to the client are probably not acceptable. Styling is important as well.

What I know

The original application is in Winforms. It uses a Tab metaphor, and has about 10 tabs. Each tab can have a summary view, where a list of records is displayed, and a detail view, where a specific record is displayed. Most of the main forms in the tabs are CRUD, but some have specific workflow uses. There are several reports, of the 8 1/2 x 11 variety. There is already some form of Data Access Layer and Business Logic Layer, but no web API yet.

Ideally, I hope to get close to the quality of a WPF application, but in HTML5 and CSS3.

The foundational infrastructure is SQL Server and ASP.NET MVC, which I am already familiar with. I figure I need to push out a skeletal HTML5 infrastructure, and then hand most of the operation of the APP to the browser. There are many moving parts, so I may need to code-generate some of it.

Improve this question

2 Answers 2

Reset to default
3

You're going to need to break this next project out and consider several different components.

Please note: I have tried to refer to the 3rd party products in alphabetical order. You'll find that they are fairly similar and any given one in each category should meet your needs.

Starting from the UI and working backwards:

  • UI widgets - you'll need / want to use some sort of pre-packaged controls for your HTML5 pages. Yes, you can write your own or just use native elements from HTML5. But if you're used to Winforms development and you're targeting WPF quality levels, pre-packaged is the way to go. Syncfusion and Telerik / Kendo are solid options to consider.

  • Javascript framework - you'll want to consider a framework to provide the equivalent MVVM paradigm that you're used to working with from WPF. AngularJS, EmberJS, and ReactJS are all worth considering from that perspective.

  • Data mapping - you may need to consider an additional framework to help with data mapping, caching, and concurrency concerns depending upon the number of users on your product and how much data is changed. BreezeJS is worth taking a look at to see if it will help you in that regards.

As far as the back-end API, I would recommend sticking with ASP.NET MVC since you said the existing application already has this in place. There are alternatives, but I don't think there is anything that merits replacing that portion of your software stack at this point. If need be, you can tweak ASP.NET MVC to provide REST style services.

You're going to need to do some experimenting to see if you want to use a SPA approach or if you want each tab of the existing application to present as separate pages within the new site. It sounds like you're at the edge of what a SPA can reasonably handle and have a reasonable download size.

Using a SPA would make it easier to present the same (modified) information across the tabs, whereas a more traditional web app would have problems with that local data persistence. BreezeJS may be the answer for local persistence if you decide you need each tab as a separate page.

Improve this answer
1

I agree with @GlenH7, but figured I'd add to the conversation by offering you the stack I use for my web/conversion projects (since many he mentioned match my list).

This answer is broken up into 2 parts.

Part 1 - The Stack I use:

Client Side:

  • HTML5
  • JavaScript
  • CSS3 (via LESS)
  • AngularJS
    • ocLazyLoad for Angular
    • ui-router for Angular
  • REST/ODATA
  • BreezeJS (client side - used for data pulling)
  • SignalR (client side - used for data pushing)
  • Bootstrap (responsive layout, quick styling)
  • Component Libraries - AngularUI and KendoUI

Midtier:

  • C# / ASP.NET
  • MVC 5+
  • WebAPI 2+ (ODATA Web API for our web services)
  • EntityFramework 6+ (ORM to make database access standardized)
  • MS Identity 2+ (Authentication and Authorization)
  • BreezeJS (server side)
  • SignalR (server side)

Backend:

  • SQL Server

Development, Support and Testing Tools

  • Visual Studio 2013 (Development IDE)
  • GIT (Source Control)
  • LESS (see CSS3 above)
  • Gulp (Build scripts and automation)
  • Web Essentials for Visual Studio (Tools to make development easier - like LESS)
  • Bower (Package management)
  • PhantomJS (Testing)

There are many reasons why we chose what we did for our stack. For example, BreezeJS works well with Entity Framework, which works well with SQL Server. Take one away and you lose much more than just the single item. So it's up to you as @GlenH7 mentioned to determine what works best for you.

But believe me, it took a while to whittle this list down as much as we did.

What we still have not standardized on, is a reporting engine that won't break the bank.

There are several great libraries to generate DOCX, XLSX and PDF files, but I felt I wanted more than that. Company offerings I've looked at so far (in no particular order): stimulsoft, telerik, gemboxsoftware, devexpress, componentone

Part 2 - Answers/Comments to your questions:

"...it will need to look like and work like the original application as much as possible..."

First it's important to remember that desktop apps and web apps will look and feel different in most cases. But without seeing screenshots, I can only assume you mean a generic Windows look and feel.

For this, you might want to look at something like ExtJS since they offer a skin and component set that (to me) looks closer to a Windows based application. Why didn't I use ExtJS? Probably because it didn't feel "Angular'ish" enough to me. Kendo was "close enough" to a desktop look for me and my clients and they have official Angular support (which is important).

"...Delays of 1 to 3 seconds to push an HTML5 form to the client are probably not acceptable..."

Comparing load time of a pre-installed app to a web app isn't quite fair, however with caching and pre-loading you could make it rather close (as long as the connection between the user and the server is good). A benefit of the web is to load things only as you need them and have access to them, so I'd look at it as a benefit.

Generally SPA apps are loaded all at once, then only data is transferred back and forth.

Using something like ocLazyLoad, you can "dynamically load" in new html/javascript/css files as the user accesses them for the first time (without leaving your SPA). Once a "page/module" loads, it will be cached and won't have to go to the server again. But if you can't have any delay when using the web app, then you'll take a big hit up front. If you are ok with that, then you should be fine.

You could also start up the app with a default module (for example a Dashboard) and in the background start downloading the modules you think they might be requesting (or just load them all) That handles the User Pacification problem but it might feel a bit sluggish for a few seconds while everything continues to load.

I'd also look at browser local storage for data caching (in BreezeJS as Glen mentioned) - it should make the initial load time seem quicker to the user, and you could refresh the data in the background after the app starts.

Well, hope that helps. Let me know if you have any questions or need more detail. Good luck in your endeavor!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.