CODEWITHSUNDEEP
javascriptsilverlightwebmetadataenterprise
Josh
Josh

Reputation: 31

HTML technology choices for an Enterprise Metadata app

Problem

Deciding on what technologies to choose when moving from a rich client Silverlight application to an HTML client that can handle a metadata driven approach.

Background

Requirements

  1. It must be metadata driven. This means that views and data models are not known at compile time. Views can be created and used at runtime. It appears that the JavaScript libraries I have been looking at have little support for this feature, they are anticipating the views and data models to be known at compile time.
  2. Dynamic and responsive client. On any of our custom views, some fields when the value changes may trigger a server hit. The server in turn may send instruction back to the client such as to automatically populate some of the fields on the view, to change styles of some of the fields to make them read-only or required, to spawn dialogs, or maybe even some DOM manipulation.
  3. If possible, an easy conversion path from Silverlight. With the other requirements, I know that this may not be feasible.
  4. We need to make a five year commitment to whatever technologies we choose. We don’t want to choose anything that is volatile or risky. We are looking for stable and dependable for the foreseeable future.

Summary

Looking for guidance on which direction to take when it comes to which technologies and development patterns to use. That support the requirements.

Upvotes: 3

Views: 134

Answers (1)

Scott
Scott

Reputation: 2028

There's a number of ways you can approach this.

Firstly, Depth vs Breadth. If you're goal is to have depth experiences with breadth deployment, then you're chasing the Technical Unicorn (many deadlines have purged on this hunt). The reality is there's a catch with any and all choices you make, but the part you need to sit down and think about is where are you likely to gain users and how do you influence them. Often folks will want breadth because of the fear of losing out to the "mobility" coverage, yet when you factor in development costs and actual usage often at times this is a false positive.

So settle on that as once you do, it will help shape the conversation around what technology is available to you.

Breadth: Web or Xamarin is a likely candidate . Xamarin however will make you have to earn your pay in terms of generating UI's dynamically, as Xamarin Forms is heading towards the XAML way of life but bare in mind they deviated away from the Silverlight/WPF XAML (I don't know why or where the Moonlight project went compared to where they are now... )

Web such as AngularJS would be likely suitable to you given your Silverlight background - it has that MVVM binding style of thinking and you'll also have more of a community backing behind you along those lines. It will retain a lot of Microsoft familiarity as well.

Depth: WPF ... seriously, as long as Windows Xp to Windows 10 exist so will WPF, so bare that in mind. WPF may not have any future actual additions to its code base but majority of the effort is already in place anyway, so its really not as if you're missing on too much growth opportunities should you head down this path.

At the time of Silverlight/WPF we in the team underestimated the popularity of WPF as well, so while Microsoft still assume its an "old tech" they never really had good numbers around its actual penetration statistics and I found it personally had stronger growth than Silverlight, so there also is likely to be a stronger community support ratio for this as well.

The new Microsoft SDK's are attractive but bare in mind anything below Windows 8 isn't going to win you some desktop breadth.

HTH.

Upvotes: 1

Related Questions