Responsive web design with Webforms

Hi,

Just asked by my boss to create a tablet based application. I am new here and for reasons unknown we are still using web forms and, possibly, javascript. I feel that it is doubtful that using webforms for responsive web design would be problematical and eventually a bigger problem as technology advances. I don’t want to write three webform apps for phone, tablet and browser. My immediate concern isusing the “per centages” techniques I’ve read about with CSS and HTML 5 with objects like GridView which really are rendered as javascript and html using the webforms algorithm.

I have done some research but can’t be sure I’m right. My intention is to gather reasons why I can’t or shouldn’t use webforms for rwd, something I feel in my gut is right. The reason is that I will have to use other technology such as mvc, bootstrap, etc. to create a fully responsive app as opposed to three web form apps for browser phone or tablet. This may upset some here despite the fact that it might be absolutely necessary.I have also heard rumors that webforms will be depricated
I’m assuming that the answer to this is obvious if only I could find what seems like some elusive hard realities based on what can be done with rwd. Can anyone point me in the right direction?

Any help would be appreciated.

Neil

You can easily use webforms and has NO impact on RWD. It’s the end generated HTML which is important.

Granted webformst may deprecate but that’s the same as any technology stack.

I think this question is actually about Web Forms, which is done in the ASP.NET environment. Probably what you are really asking is server-side versus client-side. Ask yourself this: would the problems also exist for server-side PHP? Probably.

As @DaveMaxwell indicated, only one app is needed for all the relevant devices. It is just the UI that would be different.

Microsoft has already done much of the client-side programming for common requirements such as for the GridView. There are some relatively advanced things such as drag-and-drop of GridView items that might not be supported that we must add ourselves. (That is something I am working on now.)

You don’t say much about the requirements. Assuming there is a database in the requirements, you nearly certainly want to do that much in the server. You should learn the Entity Framework. You can improve the software significantly by moving the organization toward EF.

Also on the subject of requirements, it is not clear if the internet is a requirement. You might be able to develop a UWP application. However that is very different from Web Forms.

Continuing with what I said previously, there are other alternatives (besides UWP) that might apply.

What have you read indicating that WebForms is or will be deprecated? See Why is WebForms being deprecated? | The ASP.NET Forums.

Samuel,

Thanks for answering. Just to let you know, my questions are around rwd because that is our pain point at the moment. I started this to run in the browser and got told it had to run on a tablet. I don’t want to write three separate apps and since rwd has been around for so long I thought it was worth the effort. The apps we write already use sql server and EF (though I seem to be in a minority and feel that EF is somewhat bloated and sometimes causes issues).
I’d appreciate it if you would point me in the direction of the places where Microsoft has done a lot of client side programming for the gridview; I was not aware of that. I think this will help me the most as I need to see the complexity involved; I am considering doing this in MVC which I assume will not have the issues of rendering complicated controls (gridview) as is the case with webforms.
UWP sound fascinating but it seems like it’s still in flux and won’t run on plateforms earlier that 10.
So I’ll turn this around and ask what software you feel would offer the most efficiency in developing rwd applications. I am pretty certain that a tablet with wi-fi can run web services/apis which can also be used by a browser running the same application and probably a phone can do the same; all three can get to the same data. So I am more concerned about resizing screen real estate. Perhaps I am missing the point?

Thanks,
Neil

Dave,

Thanks for answering. Are there problems with resizing the complex controls such as the gridview since it really is a bunch of controls and javascript when finally rendered?

Thanks,
Neil

First let us ensure we have the requirements.

  • Are all the tablets Windows tablets?
  • Is there a need to access the applications outside of the local network?

I do not know much about Xamarin and Microsoft is offering many options for creating portable applications.

The advantage of UWP is that applications can be downloaded from the Microsoft Store. That option can be limited to just personnel authorized to do so. Yes UWP requires Windows 10. The data can be stored in the Azure cloud and accessed anywhere there is an internet connection. One disadvantage of UWP is that it seems to lack a GridView type of control. Hopefully that has been provided recently. UWP offers much shock and awe features such as video and graphics and game-playing but I admit it seems to lack some fundamental (boring but critical) business requirements.

If the devices are not all Windows then Microsoft has options for creating applications for Windows, Linux (Android) and Apple iOS. A single executable file can work in all environments.

I am not familiar enough with MVC to answer that but my guess is that there is no relevant differences.

I am not adequately familiar with development of device independence but I assume there are features provided by most of the options provided by Microsoft. I apologize that I cannot help more.

Applications can use web services/apis outside of browsers. For example my desktop computer can use HTTP without a browser in a desktop WPF application to access a Tivo computer to receive information about movies and shows. Web services that exist in a cloud such as Azure can be used anywhere an internet connection exists and outside of a browser.