Atlas is an ASP.NET control collection for creating AJAX enabled websites. It is also developed by the man who brought us ASP.NET some years ago, the one and only Scott Guthrie.

The idea behind Atlas is to make it easy to create powerful AJAX enabled websites, using the same code as you normally use and some new stuff as well. It then wraps all of the difficult plumbing of doing cross-browser DHTML and XMLHTTP requests into a collection of controls you can seamlessly implement on your ASP.NET web page.

Scott recently did a video presentation of just how easy it is to create an AJAX enabled web application. It takes him 18 minutes to create a to-do list with a SQL Server database and a functional UI using Atlas. He doesn’t even write any C#, he just uses the new controls mixed with the old ones. He uses the designer to drag ‘n drop controls onto the page and edits some properties in the property windows in Visual Studio. Could it be any easier?

I’ve been watching a lot of presentation of Visual Studio features during the last 4 years, both live and on the web. These presentations are always centred on using the Visual Studio designer then dragging controls onto it and letting the different built-in wizard create the boring stuff like data binding etc.

These demos are absolutely useless to me, because I never use the designer, and certainly not the code generating wizards. Who uses this stuff?? I don’t know a single professional developer that does. Furthermore, the Atlas controls generate a lot of code at runtime - both JavaScript and HTML. This means, that I’m not in control with the output of my page. I really don’t like that. I’ve learned to live with the generated JavaScript ASP.NET insert into my web pages to enable postbacks and client-side validation, but it’s still a thorn in my eyes.

Having said that, the power off Atlas seems immense. The stuff you are able to do in very short time is impressive. When you think of the combined forces of AJAX and Scott Guthrie, you at least owe it to yourself to try Atlas. I see the benefits of using Atlas for smaller web applications, but when you are developing huge solutions with tens of thousands code lines in various separate projects, the story is different. I would dread to maintain such a website with generated code you are not in control of.

Maybe I’m crazy. Maybe the “getting you’re hands dirty” is the old way of development. Maybe the Visual Studio designer is a huge benefit in productivity. Maybe Atlas is the next big leap forward in web development. Maybe uncontrollable code generation is the way to be more productive. I don’t know.

As I see it, the big difference is the type of web developer you are. If you just want to build apps that work, but don’t really care about what’s under the hood, Atlas is for you. If your approach to development is towards engineering and control, I would be a little bit reluctant using it.

I tried Atlas when it was still in beta, but I didn’t like it much. To be honest, I didn’t give it the time it disserved, so my experience with it is somewhat Spartan. I haven’t given up on it just yet, but I’ll probably wait for the next release before jumping onboard again. After all, the next version is in general always better than its predecessors.

Come on, who am I to judge the work of Scott Guthrie without at least come up with a couple of ideas of my own. Luckily I have and it’s about the implementation of the client callback feature.

The client callback feature provided natively by ASP.NET 2.0 is very powerful and easy to use and it lets you be in total control of the output. I use it for many different types of functionality and it works very well for me.

What could be really cool for the next version of ASP.NET is to build AJAX capabilities directly into the controls like the input button. Give it a boolean property called EnableClientCallback that automatically triggers a client callback when you click it. It would be a huge timesaver. The GridView control already has such a property but the usefulness is fairly limited in my opinion. The important part is that AJAX has to be built seamlessly into the different controls without writing a lot of JavaScript onto the page. It should be kept in separate .js files. That would make the use of it almost free with no real learning curve.

All in all, Atlas is a great initiative that really shows Microsoft’s commitment to the developer community. I hope they receive a lot of feedback from the community so they can implement the best parts into ASP.NET 3.0 to make it even better.

Just this moment, I am writing this sentence in a rich text editor here on my blog. It let’s me format text, insert images, tables and a lot of other great stuff as well. I can do bold or italic fonts, which helps clearing up the text and underline my point and what not.

I do have a lot of years of experience in using these kinds of online text editors like RichTextBox and FCKeditor. In fact, I build my own 3 years ago. I spend a lot of hours perfecting it, but even then, it only worked in IE and it was error prone. Writing massive amounts of JavaScript and make it work is incredibly difficult. I take my hat off for people who do that for a living. I couldn’t. Nor would I ever do it again. I lost too many nights of sleep on that account.

What are really cool about these kinds of editors, all kinds, are also the things that make them bad. And I mean really bad; to the point where they suck and I want to stop writing because of the bad editor. That’s not true, because I know how to use them. I use my knowledge about HTML to do tables and float images to the left or right in CSS. To do the floating of images I have to switch from regular WYSIWYG layout to HTML code layout. Then I manually add the style attribute to the image and make it float to the left. Could my mother do that? No chance. Could yours?? I doubt it.

For me as a web developer I have no problem switching between design and code view. But the average secretary has. She is used to Word and also know how to insert images and tables. She is an intermediate user of Word; in fact she is a little better. She also knows how to make hyperlinks and header formatting. When she sees the online rich text editors with their Microsoft Office style buttons and menus, she finds herself at home right away.

What she didn’t realize is that the online editor is nothing like Word. It looks like Word, but under the hood, a whole different ballgame is in play – HTML. She cannot place an image wherever she wants, text wrapping isn’t working and I could go on.

I’ve worked a couple of years developing content management systems, and the online editors were always a weak spot for the reasons I just mentioned. What the end customer wants is Word. Not an online editor, but Word. They know it very well and they feel at home.

Then I was thinking about the new Visual Studio Tools for Office (VSTO). Using these tools, it is possible to create a Word document with a direct link to a web service – it could be your blog engine or CMS system for that matter. Instead of using the online editors for editing blog posts, we could use Word. Think of the added benefit your customers would get when they can stay in their favourite text editor to create their HTML content? They probably write their content in Word before copying it to the online editor anyway.

It actually sounds too good to be true so why haven’t anybody done it already? Maybe they have and I just don’t know about it yet. Then why not make it my self? Well, I don’t think it is that easy to implement in an existing CMS/blogging application. If it is a CMS, you still need the online editors for people that haven’t got Office 2003 and .NET Framework 2.0 installed. On the other hand, I estimate it to be a fairly straight forward task, with little surprises for the experienced programmer. Of course, it also depends on the amount of functionally you want as well as the overall scope of the project.

The added benefits you gain from this have potential. After all, it let’s your customers use what they believe to by the one true text editor.