The question I'm being asked is why would we want to have two ways of
developing web and mobile applications?
The reasons are probably similar to the ones that prefaced the choice to
deploy 2 disparate technology stacks in the first place. You've already
selected 2 distinct server operating systems, databases, virtual machines,
language environments, skill-sets, etc.
It appears that you're now considering a move to SPAs, which are more
client-centric than what you have traditionally done using ASP.Net. That in
and of itself would introduce another way of developing web and mobile
applications.
FWIW, I'm considering the same thing. We already have a server-centric
approach. Should I introduce a client-centric one too?
Some factors I'm considering - how best to support both desktop and
handheld devices? How best to streamline development? Would it be feasible
to reduce the amount of code required? Would client-centric improve the
user experience; would the UI be more responsive?
Regarding the question of streamlining development and reducing coding
requirements, that get's back to the idea of using "utilities". We talked
about a server-based utility a week ago. Angular now interests me in that
it includes a utility which automatically merges HTML templates like:
http://www.radile.com:9220/rdweb/phones/details.html
With JSON objects like:
http://www.radile.com:9220/rdweb/phones/details.json
A utility "injects" the merger into a portion of a page; nice!
Under a traditional server-centric web application, a fair amount of coding
would be required to "map" data to HTML, using templates. What if that
could be replaced by a utility?
In summary, you might consider multiple approaches in order to reduce
future code requirements, improve the user interface, improve performance,
take advantage of platform specific features, reduce future maintenance
requirements, adapt to handheld devices, etc.
midrange.com
