ASP vs. ASP.NET ( Thin client vs. thick client )

I'm troubled by this question for a long time now. I work in the little company in Eastern Europe. We work primarily for local clients, web apps, mostly b2b and b2c-s. Our internet infrastructure is not very good, so we often have problems with local isp-s and hosts that are stationed in companies who have information systems that we build our apps upon.

Technology th开发者_开发技巧at we are using is Microsoft IIS, SQL Server and ASP with a lot of Javascript and Ajax. As a student and developer I`am aware that ASP is old and do not support many many cool and useful things, but i believe that we done a very good job with our code. And we created very fast apps too (8000 rows from table in less than 4,5 sec on one page without pagination (don't ask) is pretty damn fast). For that we used thick client approach and pull out max from Javascript. So, what is our problem?

Naturally we have to migrate, and logical step is ASP.NET. But we have confrontation, from our thick client, mini Javascript grid and components, we have to focus on server side and a thin clients.

I would appreciate your point of view on this. What are we going to gain with using ASP.NET and a thin client architecture? Are the greater benefits that will compensate speed downgrade? Many references are dogmatic on a stand that complete logic should be on server and doesn't explain why (i am well aware of MVC and using it)?

Thanks

Before I get into my answer, I want to point something out.

You don't have to give up your existing client-side infrastructure to move to ASP.NET!

While it is likely that ASP.NET Forms will be a downgrade in performance, there are more features available (besides MVC) in ASP.NET that you can use that don't require you to convert to Forms.

HttpHandlers have the same flexibility and more capability than ASP pages. You can map tricky pages to ASP.NET by converting your ASP pages to code statements, and reducing in-page declarations to output statements. Depending on your existing design, you may even find that the mapping coincides nearly line-by-line for a lot of your existing work.

Creating HttpHandlers @ MSDN
IHttpHandler Interface @ MSDN

In addition, if you wanted, you could remap the .ASP extension handlers to .ASHX handler to preserve your links as well. Your client-side code may not even notice the change.

Finally, aside from any debate on thin/thick client architecture, here are my top reasons you should move to .NET / ASP.NET.

1. Access to a better IDE (I hope you've moved on from InterDev!)
2. Vastly improved debugging support
3. Access to .NET-specific features.
4. Exception support (instead of OnError semantics)
5. Ability to use Compiled Libraries without writing COM components.
6. Ability to write components and page handler in languages other than VB/VB.NET, if desired.
7. Better Authentication support, particularly in regards to Negotiate/Kerberos.

With the fat server + thin clients approach you'll need considerably less bandwidth and client-side resources, and so you boost performance - but this is not your main concern, if I understand you right.

What's more important for a dev shop: ASP.NET is at least one generation farther than pure ASP in terms of software technology, which means that it has a MUCH cleaner architecture and far better maintainability and extensiblity. This is in - terms of business value - the single most important factor for a dev shop (far more important than the initial development costs)...

Thick Client - huh? This kinda old dichotomy. If I understand correctly, your 'thick client' is some heavy JavaScript code running in browser and the server side you have classic ASP - right?

If this is the case it is rather unusual interpretation of the term "thick client". When I see "thick client" I usually think client server app - an executable running over some database. In terms of .NET that would be a WinForms app.

As far as the ASP.NET goes the classic use of this technology is to build WebForms which were conceived as a web analog of WinForms. With this approach you build your forms server side out of Controls - very much like you build WinForms. There is virtually no executed code in the pages - just HTML with additional markup for WebControls. In a sense you can call it "Thin Client"

The funny thing is that more and more developers are moving away from this approach - just run lookup for JQuery here on SO. And many of them still use ASP.NET server side.

AS for classic ASP - IMHO it should be buried. You will be much better off relaying on something 21st century for your server side, i.e. ASP.NET

Old ASP will waste your time. New development techniques and libraries let you do big things a fraction of the time you'd waste in classic ASP. Sure, for a one-off simple script, ASP might carry you, but a full site, no thanks.

Anyway...

I think you're right. I always get a site running in plain, no-JS code first. This ensures it works for people that don't use JS (probably not an issue for you) but it's not difficult to layer on the AJAX at a later point.

In fact, if you're willing to spend money on components (as it sounds you have in the past) there are plenty of extensions for AJAX.NET that can take you from zero-JS to lovely pages. They might not be as efficient as what you had before, but they'll be a lot easier to maintain.

Or you can layer on the AJAX after the site is done. You could even try to keep the API from the server to client the same as the old site so your old JS "just works".

There's clearly not just one best answer for this.

As for what you gain: So many benefits in terms of rapid development, a much better design, seriously improved language features (C# and VB.NET are proper programming languages after all) and the ability to do now-everyday things without having to run off to a third-party component.

And if you want to save a bit more time and a whole shed-load of infrastructure and licensing cash, you could even take a look at Django and/or Ruby on Rails.

If you're comfortable with ASP classic it means that you haven't had to try and significantly modify or extend your base code. If you did, you would have seen the pain of maintaining ASP, though it is a powerful technology in its own right.

There are a few other things you should consider: 1) Your team seems very proficient and successful with ASP. Why change if you don't have a really compelling reason? Your hosting woes will not really improve if you change your technology. 2) It is a VERY significant learning curve to go from ASP to ASP.NET web forms. Some of your team might not succeed. It's a real risk. But, you should really check out ASP.NET MVC as an option. It has some things in common to ASP classic and might make for a smoother transition than web forms.

We are in the same position as you are at the current company I am working at. Couple of points I would make for the upgrade is:

1. Ease of debugging. I have to spend hours nesting through a lot of messy ASP code in order to look into problems. I find it much easier to do this in asp.net or .net MVC.

2. Compatiblity. Asp is ancient and although still supported would probably justify an upgrade down the line. Developer knowledge is also easier to find for .net over asp.

   That being said, we are not aggressively upgrading since the apps are doing their jobs fine. You are on the right track with MVC though, asp lends itself more easily to an upgrade to that platform over asp.net due to the view markup.