Sam Gentile's Blog

Windows 7 Of course, the big news is the availability today of Windows 7 on MSDN and TechNet. The bad news is that the MSDN servers are so overloaded, no one can even log into subscriptions ASP.NET MVC Chad Meyers summarizes the discussion so far and

1. We're using ASP.Net at work, some new parts of the project could be done in MVC in a near future

2. We're using quite a lot of ASP.Net AJAX, it integrates well with classic ASP.Net, and the UpdatePanel make dynamic parts easy even if it's not true Ajax...

3. You don't need lots of javascript, but you should learn modern javascript style that make it easier to maintain. New javascript technics let you put a lot of little scripts together without friction.

4. We're using JQuery and it helps for maintainability, it integrates a lot of the plubming to achieve what I said in 3.

5. Not much, we use Dundas for graphs.

6. Not for now.

7. Remember it's just a presenation layer :P

1. We're still doing quite a bit of web forms development; however, two of our new projects are 100% MVC and going quite well. If I were starting with a blank slate, I'd recommend moving forward with the MVC framework (whether it's .NET's or another language). It's less of what to focus on and more of what to be aware of (pros/cons) of web forms vs. MVC and what the project at hand would benefit from most.

2. Honestly, I'm shifting more and more to jQuery for the finite controls and behaviors. I do admit that when I simply need a quick update panel, .NET AJAX is easy and quick. We've found that a majority of our users "expect" an AJAX (on the fly updates, no "flashing" of the page, etc) on current web applications.

3. 2009 feels a lot like 1999. JavaScript, for me, is back with vengeance and helps bridge that gap now that clients have enough push to handle client manipulation. "Enough" JavaScript is necessary, but the heavy lifting is handled by modern frameworks like jQuery, which leads to #4..

4. As #3 said, JavaScript is back, but rather than hand cranking code, frameworks like jQuery provide both the functionality and a plug-in structure for endless features. I recommend focusing on jQuery vs. learning the "Microsoft AJAX"--if nothing else, for re-usability outside of .NET projects.

5. We have a few projects running Tekerik controls; however, those controls were implemented back in the .NET 1.1 and 2.0 days. Since those projects, we've moved away from the 3rd party controls. I no longer need a fancy control to sort a grid--I can use jQuery, some CSS, and get most of the same experience.

6. Our organization hasn't seen much value in Dynamic Data, but the concepts are interesting. Most of our data infrastructures are around non-EF data systems (PeopleSoft, Oracle, etc) so the required providers are either costly or complex. Building out the same, basic framework using other tools is working just fine.

7. 3am? Get some sleep. :) That helps any coder. I think the web forms vs. MVC is like any technology comparison--each has pros/cons and is suited towards the situation. I'll admit, as I use MVC more and more, it's hard to go back to standard web forms.. but I admit I can crank out a quick application in web forms a lot faster. That's just due to experience and, over time, that difference will fade.

In an in-house training I did, we took the requirements for a project and built it (in free time) using both architectures: web forms/AJAX update panels/LINQ and MVC/jQuery/FluentNHibernate and stepped back and compared what worked, what didn't, and what added unnecessary complexity. :) It made for a good exercise and helped clarify the strengths of each.

Here's my responses to the web work I do these days ... mostly at work.

1. Currently all 'Asp.net' classic

2. In most cases we tend to only use AJAX for user experience - if load times are too slow, etc.

3. More than you would think. Hard to not put a complete site together and not have to right some javascript ... though knowing jQuery will make that amount of javascript code smaller.

4. Perfwise you'll notice the onload stuff, but maintenance wise it makes things easier.

5. Very little ... I tend to try and get by without them unless it REALLY has to have some wizbang nice gadget. With jQuery and a good CSS book you can by pretty good ... but of course I like to do it myself instead of buy it - so it would depend.

6. Yes - especially for admin pages that allow you to quickly create a site that will allow db table management quickly ... not for users to see.

7. Test on multiple browsers - IE 6, 7, 8, FF, Safari and Opera at least ...

I'm spending my time on MVC as I think it will become the more prevelant framework for those who don't want to do drag/drop web development. I'm also spending some time learning JQuery and the underlying javascript as I think it is a big part of making dynamic sites today. I'm aware of Dynamic data, and plan to try it out for quick and dirty sites like admin pages for a site, where I need a CRUD UI and don't want to spend a lot of time building it, but so far, I havne't seen it be a major player.

My $.02 as I get back into web development after a few years in that murky middle tier.

1) We're using ASP.NET web forms at work in an MVP pattern. The existing third-party support in tooling and controls plus the existing knowledge developers out there have that can be leveraged is too much to ignore. In a really good MVP scenario you can still get your testability while using all the resources available to you.

2) We're using a combination of ASP.NET AJAX and jQuery. ASP.NET AJAX does a lot for you in automatic creation of client service proxies and other client-side things (like localization of client-side values), but jQuery beats it by far for the rest of the work. There looks to be a lot of goodness coming in ASP.NET AJAX 4.0, too. That said, learning "ASP.NET" and learning "ASP.NET AJAX" are not mutually exclusive skills; they're complimentary, and one builds on the other.

3) I think knowing the JavaScript basics should get you by to begin with, but you'll quickly learn a lot more as you troubleshoot things.

4) jQuery is pretty big on making things easier to deal with all around and helping you write one codebase that works on all browsers. Something I noticed is that you'll start out writing standard JavaScript code for retrieving elements and setting values and forget that jQuery does that in a simpler, cross-browser fashion for you. Eventually you default to using jQuery for that instead.

5) We use third-party controls for lots of things, but the majority of the work is not in "using the controls." You basically just stick them in your view, set up some validation, and get some values out of them. That's sort of the beauty of the control - it's packaged logic that you don't have to deal with. You might use System.Configuration.ConfigurationManager to get config values out of web.config, and you may need to read config in several places, but one or two method calls to a "third-party" like that doesn't really mean you "work with it a lot." That's about the extend of third-party controls - get a value out, put a value in, call DataBind, maybe style it... done.

6) In my experience, ASP.NET Dynamic Data seems to be great for a quick admin interface for an IT-level app where you have 10 users, but it very quickly loses value when you start getting into actual user stories. No one really wants to work in an interface where they're editing and viewing tables in the database in "spreadsheet form." Add to that the challenges around localization, business-rule based validation, etc. and you'll find that if you only have a "products" and "categories" table, it's great; if you have more than that, you're going to be doing some manual work.

7) Don't forget some of the key things that a lot of folks leave out, like localization and a good deployment/upgrade story for your app. Learn to work in the HTML view of the designer rather than the WYSIWYG view. The same good patterns you used in back-end coding (IoC, testability, etc.) are still valid here but since you have to interact with markup and a lot of sealed/static classes, it's going to be a little harder to achieve. Don't give up - it's possible, you'll just need to do a little more work. If you go with web forms, you'll want to look at a good model-view-presenter framework or maybe roll your own using a DI container of your choice (I recommend Autofac) - doing that can get you a long way.

Sam,

Don't let the "buzz" words flying around scare you too much. Not that I would expect a person with so much middle-tier knowledge to be afraid of the front-end. :)

The only thing you need to be afraid of is the user. Being a user yourself you should be able to determine what's a good user interface. You're a brilliant fellow and I don't expect you learning curve to be as steep as you feel it might be.

Fundamentally, development is still the same: KISS (keep it simple stupid).

But as a person that has taken his time to shared the wealth of knowledge with me don't hesitate to drop me a line with a question... any question no matter how simple or stupid your think it is. I'm sure you can count on the community for help as well. But more importantly count on me to be on the front of the line if you need help.

Good Luck!

-v

p.s. hell, I'll still pay for the cup of Red-Eye at Starbucks!!!

Sam,

First, thank you for sharing your wealth knowledge for all the years, your blog is one of the first and top ten blogs I subscribe. I asked you a few questions in the past and you answered them quickly and expertly.

I'd like to share my experience and thoughts with you. I have the same background as you - middle tier, backend, CAB, smart client, WinForms, WCF, WPF. Since last year I have been working on two ASP.NET projects. Back in 2004, I developed a whole business web application based on DotNetNuke (ASP.NET 1.1), which was my brain child for startup, not a working project though.

1. the first project was to rewrite classic ASP website with new modules, using ASP.NET 3.5 with AJAX, using DevExpress for UI and Reports. The second project using classic ASP.NET and DevExpress with extensive DevExpress callback with no ASP.NET AJAX. If I were you, I will focus on MVC for new project, and get by with ASP.NET classic or ASP.NET AJAX for existing project.

2. ASP.NET AJAX or other similar library is just a choice of deveroper's taste or experience.

3. Javascript is mostly for client side interaction and validation.

4. JQuery is not used in both projects due to developer's awareness and skills, but should be very useful tool for client side Javascript as others pointed out.

5. both projects use DevExpress and it's decent. Telerik is another strong player. Working with Infragistics before (mostly WinForms), the web offer is behind other vendors.

6. no demand or action for ASP.NET Dynamic Data, mostly due to awareness. It's pretty good for simple Forms Over Data scenario. And it has potential for big stage as I like its template (UI) and model (view model) based development.

7. Anything else? Please get more sleep :-). Use either MVC, MVP(Web Client software factory), or even portal (dotnetnuke, sharepoint) based development for enterprise is far better than traditional web forms development. Last point, SilverLight should be better UI/Client platform in the long run, yes, I am bias since I worked with WPF.

You are expert and will get all these stuff in place as you want :-)

Sam, I'll take a stab at offering an opinion hoping it is of any help - good luck with your new endeavors!

Regarding MVC - At my work we have not yet used it for a real project. I think it would be appropriate but there is some pushback and I'm new here and I have bigger fish to fry first :) Not that I'm a huge fan of MVC but for certain scenarios I think it's great. All the cool kids are doing it too - but that doesn't usually intimidate you, does it?

Ajax is everywhere, but more and more people are using jQuery to do it rather than the MS stuff. You'll spend all day editing your web.config one day and then you'll know why.

Javascript / jQuery - the more the better it seems. I avoid plain javascript like the plague but jQuery is actually nice.

We usually avoid third party controls but are considering Telerik. Most people I know favor that brand and the support is fantastic.

I've only ever heard of the Dynamic Data stuff on blogs :) No one I know is using it. Or admitting it :)

Hi Sam,

Here's my two cents. Best of luck to you!

1. All I'm seeing is ASP.NET Classic at the moment. I've worked with one of the ASP.NET MVC betas on a project for a couple of weeks about a year ago and frankly I was underwhelmed. Of course I've worked with ASP.NET since .NET 1.0 Beta 2 so I think I know pretty well what the hard parts are:

- thoroughly understanding the page life cycle and all its consequences

- managing viewstate size

I now have 5 years of experience as a freelance software developer and in that time I'd say 90% of the apps I've worked on could be described as "winforms on the web" apps. So there's basically some data entry screens and some lists/reports (+ all the business logic around that data of course, but that's not what we're talking about now). For those types of apps I think the WebForms model is a perfect match and I actually really like the abstraction it provides.

Now if I were to make a "true" website I could see how some of the abstractions of WebForms might not be that useful so it might be useful to try ASP.NET MVC there. I still probably wouldn't but I could see how others might make that call.

Apart from the technical arguments of MVC vs. WebForms there's also the economic POV: Given that there's a huge installed base of ASP.NET WebForms apps and that the recession will most likely limit the amount of greenfield projects that could choose ASP.NET MVC I would definitely start by learning ASP.NET WebForms if I were in your shoes.

2. Not a big factor at all and after having used it in two different projects I can see why: once you get off the beaten path you tend to run into lots of problems fast. The fact that Microsoft is hedging its bets with the inclusion of jQuery in VS2010 is telling. Also, knowing ASP.NET Ajax without understanding "Classic ASP.NET" doesn't make much sense to me. It would be like knowing Javascript but not knowing HTML.

3. No matter which Ajax/Javascript framework wins, it's still going to be using Javascript so knowing this well will help you understand how the frameworks work and how you could extend them. Javascript at it's core is a very simple language so once you let go of the securities that a strongly typed language like C# gives you it shouldn't be to hard to learn. The reason many people think Javascript is hard is because they don't differentiate between Javascript and the DOM (Document Object Model), which would be the same as thinking C# and the BCL are 1 thing. One good thing about most of these javascript frameworks is that they abstract away a lot of the cross-browser weirdness of the DOM, so learning about the differences between inserting a row into an HTML table in IE, Safari and Firefox for example would not be something I would put a lot of time into.

4. jQuery: I've not used it so far but they seem to be in the lead of the Ajax framework wars right now and it's definitely on my list of things to learn soon.

5. From what I've seen the bigger shops that have specialized Architect roles tend to like these components because of the perceived development time gains. Having been "in the trenches" yourself I'm sure you know that those time gains can quickly turn into losses if there are special requirements that the component is not able to support. I've used both Infragistics and Telerik at different companies. Don't have much good to say about Infragistics unfortunately. Telerik has worked well for me, but even with their stuff there is definitely a point at which you have to say that the component does not support certain requirements and just fall back to building your own control.

6. None that I've seen. It is on my list of things to learn though and I've heard some positive things about it.

7. From what I've heard here in the Netherlands through two different recruiters and a consulting company demand for S

My last point was cut short. Here it is again:

7. From what I've heard here in the Netherland through two different recruiters and a consulting company demand for Sharepoint experts is still strong so that might be something to look into, also given your ties with Groove which (at least functionally) resembles Sharepoint somewhat.

Also, Sharepoint is basically ASP.NET so maybe you could combine learning about the two. One note though: the developer experience on Sharepoint tends to...uhhmmm...-how do I say this-...bring me to tears! So be warned :-)

I'm spending my time on MVC as I think it will become the more prevelant framework for those who don't want to do drag/drop web development. I'm also spending some time learning JQuery and the underlying javascript as I think it is a big part of making dynamic sites today. I'm aware of Dynamic data, and plan to try it out for quick and dirty sites like admin pages for a site, where I need a CRUD UI and don't want to spend a lot of time building it, but so far, I havne't seen it be a major player.