It's funny get into a technical discussion with anyone who does alot of web development. Opinions are rife and vary across the board. You can create conflict on any number of topics. "Hey I like smart client/windows desktop applications better then web applications" or "I like C# over VB for my projects", whatever. The fact is the type of people that spend time sitting in front of computer screen constantly making minor adjustments in a source file and reviewing the results to see if the results are exactly as desired tends to have more then a few strong opinions.
Now let me add a disclaimer here: this post is only refering to web development - not server scripting.
In most cases just like the any other opinion, everyone has their own, and the live and let live approach is the most productive. Yet I've tested the above statment - Working with Javascript sucks - out on dozens if not hundreds of developers and I've never gotten anyone with a truly different opinion. Sure now and then someone will say it's not that bad - but consistently even those who proceed to tout its benefits on the client are still at some level of the opinion that it sucks as a developer tool for web development.
Which brings us to the question of: What's the alternative? For a while we could simply refer to Javascript as a way to make screens a bit more interactive and for clueless developers to place data validation code so hackers could completely bypass it. The useless nature of Javascript for browser based data validation could be a complete discussion. Of course it's been done repeatedly yet even newly developed systems that shoot themselves in the foot are being released - proving there will be a subset of developers who will never understands. The point being that the only real value of Javascript was as a language to make a screen react, and even then doing more then shuffling data around was difficult at best.
Then along came Ajax. With the introduction of Ajax (I last wrote of Ajax a little over a year ago: http://blogs.interknowlogy.com/billsheldon/archive/2005/09/09/415.aspx) it has become apparent that Javascript isn't going away anytime soon (like so many technologies which have outlived their true value: http://en.wikipedia.org/wiki/COBOL). The fact is that Ajax took what people had been hand coding in Javascript for page interactivity and packaged it. Of course toolsets like the Microsoft ASP.NET for AJAX suite have been slow in truly making it to market, but the market has continued to grow in spite of this. The only disadvantage of course is that while this will provide you with a set of specialized controls from the ASP.NET standard.
Of course the challenge right now is that to leverage AJAX you still need some, you guessed it, basic Javascript that you have to customize. After all AJAX has Javascript right there in the acronym. Meanwhile the underlying issues with Javascript and the fact that it has a lousy development environment remain. Thus when you talk to people working with Microsoft's ASP.NET AJAX, it's all about the Javascript (http://blogs.interknowlogy.com/joelrumerman/archive/2006/09/22/5126.aspx for a good example...)
But again - Is there an alternative?
Well little by little two alternatives are emerging. One is still based on Javascript but in this case you never touch the Javascript. That is where thrid party vendors have wrappered the complex Javascript for you. Telerik provides such a soluction at: http://www.telerik.com/products/ajax/r.a.d.ajax.aspx. (The Telerik suite with it's support for everything from native ASP.NET to Dot Net Nuke and Sharepoint is rather impressive.) It may not be as efficient in what it sends to the server in a given round trip as say custom coded controls which are handling the AJAX communications, but then again its way easier to implement and get the same behavior. In a cost - benefit analysis you'll probably find this solution wins out the majority of the time, and since it's based on AJAX you can even have developers like those here at InterKnowlogy customize those pages where you need a custom solution. More important just like the Microsoft ASP.NET AJAX solution it approaches the market with compatibility across multiple vendor's products as a focus. This solution favors compatibility over what we'll call capability - and that is a very marketable feature.
The other alternative is, as with most technology, coming from an alternative direction. It's called WPF.
Nothing against the Ajax/Telerik solution, but for those of you not paying attention even as Microsoft provides basic support for the AJAX model that they invented so long ago they have also seen a better way. The Windows Presentation Foundation (WPF) is an XML based user interface definition. Now as we all know XML already runs in browsers so we have the basics of what you might think of as a next generation HTML. Go a step beyond the current namespaces we use for custom controls in ASP.NET. Go beyond well formatted HTML. Take the next step and say - what if the declaration of a Textbox was just that... a declaration that both the Smart Client Application and the browser understood. Now go a step further - suppose the browser wasn't just a rendering engine but instead allowed for a recogniztion of the fact that a change in that drop down was actually designed to trigger an Ajax style update from the client. One that didn't require a full round trip of the entire user interface (postback) to the client nor any Javascript - not even generated script. Admitedly it wouldn't be compatible with all of the existing browsers on the market right away - but that's only one form of compatibility and in this case perhaps not the driving one...
WPF addresses a different type of compatibility. Compatibility between desktop based and browser based applications. The ability to design a user interface which works well and looks the same in both environments without needing to completly re-implement the interface. For an "enterprise" or "corporate" developer this is actually a more important type of compatibility. Within an organization it's possible to dictate that everyone must use version 8 of browser X or to produce a smart client application... these developers are constantly being challenged to choose between smart client and browser alternatives (even if they do both it's still extra work like double data entry).
It's this arena of compatibility which WPF targets in the short term. Of course as more and more companies move to WPF for it's reuse across desktop and web more and more corporate users will demand third party browsers support the WPF model. These browsers will respond because they want people to be able to use their product in their work environment. Over time what will start as a tool which is focused as much on Smart Client applications has the potential to again revolutionize the market. Note I'm not saying that AJAX wont' survive for decades to come or that it isn't viable - I'm just noting a future alternative, one which I think web developers will be a little late in coming to the party... by the way note all the AJAX and WPF presentations on the blogs.interknowlogy site... compare who is posting on WPF to who is posting on AJAX (here's a hint: Joel works for Adam)