If you are aiming on iOS and Android with Windows Phone 7/8 as a plus you should use C# as the language and Xamarin Studio as the IDE/Framework. You may also choose to use Visual Studio on Windows as an option.

Take a look on their website: http://www.xamarin.com

Even Microsoft is using Xamarin to build iOS applications and they have over 400k developers using it. Your application will be native (compiled to the platform you choose) and you are able to use all the native libraries, widgets and UI parts.

You will need a cross-platform architecture to be able to reuse code among platforms and using Xamarin you may be able to reuse more than 50-60% of your C# code among platforms.

This solution may render the same experience on the devices as on the website, but it enables your applications to deliver much more performance and features than any HTML5 solution. Facebook went from HTML5 to native applications due to performance and user experience limitations (gestures and other platform features are not present using HTML5).

I just recently wrapped up a project that was similar to what it sounds like you are looking for: a web application that adapts the user experience to the type of device being used, desktop or mobile.

Part of the answer depends on if you envision your application being distributed to mobile platforms only on the web or if you plan on releasing mobile applications available in the App Store or Google Play.

For an application that is web-only, the key phrase is "responsive design." An ideal front-end architecture would be AngularJS + Bootstrap.

For an application that may also be deployed as a mobile app sold or offered in an app store, the AngularJS + Bootstrap combination mentioned above would work well with PhoneGap as a container. I prefer Sencha Touch for HTML5-based mobile apps as the user experience is excellent, with the downside that you have to write separate applications for mobile and web as it is not a responsive design framework.

For the back end, it's really up to what you are comfortable with, how conservative or bleeding edge you want to be, and how you see the application growing over time. The important part is that the back end is completely uncoupled from the UI, providing data via services that the UI can consume as opposed to generating HTML.

Feel free to contact me if I can help more!

After building several mobile web application I can say that the 3 top most common, mature, extensive and supported frameworks are:
Twitter Bootstrap: http://getbootstrap.com/
jQuery.mobile: http://jquerymobile.com/
Zurb Foundation: http://foundation.zurb.com/
They are all "mobile first" and support all devices incl. desktop. they are responsive and you can really build an app on top of them.

Which one to pick you ask?
It really depends on the nature of you app.
for example, If you're focusing on parent child relationship and want to achieve nice page navigation of master-details, my gut feeling would probably go for jquery.mobile (page navigation: http://view.jquerymobile.com/1.3.2/dist/demos/widgets/transitions/)

For a heavy data entry app, bootstrap and zurb may be a better fit.

I'll be glad to hear more about your app and recommend the perfect fit for you.

In my opinion html5 works best in case of cross platform integration. Also this is widely used by developers and accepted by google FB and other bigger platforms so it make sense to go for HTML 5 .

It is for you to decide, but I will present you different technical architecture options you have so that you can make the right choice:
1. Layered (n-tier) architecture: This approach is probably the most common because it is usually built around the database, and many applications in business naturally lend themselves to storing information in tables. This is something of a self-fulfilling prophecy. Many of the biggest and best software frameworks—like Java EE, Drupal, and Express—were built with this structure in mind, so many of the applications built with them naturally come out in a layered architecture. The code is arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. Along the way, each layer has a specific task, like checking the data for consistency or reformatting the values to keep them consistent. It is common for different programmers to work independently on different layers. The Model-View-Controller (MVC) structure, which is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture. Just above the database is the model layer, which often contains business logic and information about the types of data in the database. At the top is the view layer, which is often CSS, JavaScript, and HTML with dynamic embedded code. In the middle, you have the controller, which has various rules and methods for transforming the data moving between the view and the model.
The advantage of a layered architecture is the separation of concerns, which means that each layer can focus solely on its role. This makes it:
1. Maintainable
2. Testable
3. Easy to assign separate "roles"
4. Easy to update and enhance layers separately
Proper layered architectures will have isolated layers that are not affected by certain changes in other layers, allowing for easier refactoring. This architecture can also contain additional open layers, like a service layer, that can be used to access shared services only in the business layer but also get bypassed for speed. Slicing up the tasks and defining separate layers is the biggest challenge for the architect. When the requirements fit the pattern well, the layers will be easy to separate and assign to different programmers.
Best for:
1. New applications that need to be built quickly
2. Enterprise or business applications that need to mirror traditional IT departments and processes
3. Teams with inexperienced developers who do not understand other architectures yet
4. Applications requiring strict maintainability and testability standards

2. Event-driven architecture: Many programs spend most of their time waiting for something to happen. This is especially true for computers that work directly with humans, but it’s also common in areas like networks. Sometimes there’s data that needs processing, and other times there isn’t.
The event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the type. This handoff is said to generate an “event,” and it is delegated to the code assigned to that type. Programming a web page with JavaScript involves writing the small modules that react to events like mouse clicks or keystrokes. The browser itself orchestrates all the input and makes sure that only the right code sees the right events. Many different types of events are common in the browser, but the modules interact only with the events that concern them. This is quite different from the layered architecture where all data will typically pass through all layers. Overall, event-driven architectures:
1. Are easily adaptable to complex, often chaotic environments
2. Scale easily
3. Are easily extendable when new event types appear
Best for:
1. Asynchronous systems with asynchronous data flow
2. Applications where the individual data blocks interact with only a few of the many modules
3. User interfaces
3. Microkernel architecture: Many applications have a core set of operations that are used again and again in different patterns that depend upon the data and the task at hand. The popular development tool Eclipse, for instance, will open files, annotate them, edit them, and start up background processors. The tool is famous for doing all these jobs with Java code and then, when a button is pushed, compiling the code, and running it. In this case, the basic routines for displaying a file and editing it are part of the microkernel. The Java compiler is just an extra part that is bolted on to support the basic features in the microkernel. Other programmers have extended Eclipse to develop code for other languages with other compilers. Many do not even use the Java compiler, but they all use the same basic routines for editing and annotating files. The extra features that are layered on top are often called plug-ins. Many call this extensible approach a plug-in architecture instead. Richards likes to explain this with an example from the insurance business: “Claims processing is necessarily complex, but the actual steps are not. What makes it complex are all of the rules.” The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. The different business units can then write plug-ins for the different types of claims by knitting together the rules with calls to the basic functions in the kernel.
Best for:
1. Tools used by a wide variety of people
2. Applications with a clear division between basic routines and higher order rules
3. Applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently
4. Microservices architecture: Software can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change. The microservice architecture is designed to help developers avoid letting their babies grow up to be unwieldy, monolithic, and inflexible. Instead of building one big program, the goal is to create several different tiny programs and then create a new little program every time someone wants to add a new feature. Think of a herd of guinea pigs. “If you go onto your iPad and look at Netflix’s UI, every single thing on that interface comes from a separate service,” points out Richards. The list of your favourites, the ratings you give to individual films, and the accounting information are all delivered in separate batches by separate services. It is as if Netflix is a constellation of dozens of smaller websites that just happens to present itself as one service. This approach is like the event-driven and microkernel approaches, but it is used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. The servers delivering Netflix’s content get pushed much harder on Friday and Saturday nights, so they must be ready to scale up. The servers that track DVD returns, on the other hand, do the bulk of their work during the week, just after the post office delivers the day’s mail. By implementing these as separate services, the Netflix cloud can scale them up and down independently as demand changes.
Best for:
1. Websites with small components
2. Corporate data centres with well-defined boundaries
3. Rapidly developing new businesses and web applications
4. Development teams that are spread out, often across the globe
5. Space-based architecture: Many websites are built around a database, and they function well if the database can keep up with the load. But when usage peaks, and the database cannot keep up with the constant challenge of writing a log of the transactions, the entire website fails. The space-based architecture is designed to avoid functional collapse under high load by splitting up both the processing and the storage between multiple servers. The data is spread out across the nodes just like the responsibility for servicing calls. Some architects use the more amorphous term “cloud architecture.” The name “space-based” refers to the “tuple space” of the users, which is cut up to partition the work between the nodes. “It’s all in-memory objects,” says Richards. “The space-based architecture supports things that have unpredictable spikes by eliminating the database.” Storing the information in RAM makes many jobs much faster and spreading out the storage with the processing can simplify many basic tasks. But the distributed architecture can make some types of analysis more complex. Computations that must be spread out across the entire data set—like finding an average or doing a statistical analysis—must be split up into sub jobs, spread out across all of the nodes, and then aggregated when it’s done.
Best for:
1. High-volume data like click streams and user logs
2. Low-value data that can be lost occasionally without big consequences—in other words, not bank transactions
3. Social networks
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath