Hello,
I know everyone hates the phrase Ajax, but has anyone seen the new plug-in for asp.net. You really can't not be impressed by it all, especially those beavering away hard at it with dynamic database content in java or php

http://ajax.asp.net/default.aspx?tabid=47
just click on the 'scotts to do list', or it's here
http://download.microsoft.com/download/0/f/6/0f651a0f-6f2b-4497-b061-e1b2825e22e0/MSAJAX-ToDoList.wmv

Most of MS's ajax products I've seen are pretty un-inspiring. The company I work for is obsessed with them though.

Watch the video and tell me you weren't inspired. You're probably talking a good day or more to do that much functionality in php or java.

Why would I implement AJAX using php or java?

I'm talking the whole thing, creating a dynamic database driven page with asyncronous updating of the page.

[edit (misread post)]
I'm just saying there are good AJAX libraries out there, both free and commercial. So far I haven't seen anything particularly noteworthy from MS. Although that might change.

I haven't quite fallen asleep yet... So far I'm thinking, "I'd already be done with my PHP based framework." I'll keep waiting for something cool to happen.

Update #1: Woah, they are copying and pasting huge chunks of code and leaving duplicates everywhere. I hope that's not common practice.

Update #2: I loved how he made sure to emphasize a couple times NOT to put a sleep(2) on your production server.

I am completely unimpressed by the video. The method he was using was hardly maintainable and was simply copy and pasting a bunch of crap that made the source horrible to read. I'd have to actually implement something that didn't look like a nerdy front-end to a database to be impressed.

Maybe someday I'll put together a similar video showing how to do it using a real man's method, which includes actually having a clue about what's going on in the background.

I don't know, I didn't find the movie to be all that impressive. As presented it merely replaces the burden of coding a database enabled (with ajax) webpage in whatever technology (php, jsp, asp) to learning the developer studio plugin and libraries it has.

The guy in the video seems to know dev studio very well, and certainly seems to be highly productive. But then that is a trivial little application with zero design behind it. So that's a bit misleading, in my estimation. It's easy to be productive on the simple parts, it's working on a large project as part of a team (optionally with the requirement to interface with a legacy application) were things get complex. And the ide doesn't help you out much there.

I'll get my coat then

What I mean is, they might as well have just dragged this onto the page:

<asp:TodoList ajax="true" />

it would have been quicker.

I know it's all noddy code, but the principle remains the same, that you can be far more productive inside visual studio due to the integration between the ide, the code, the wizards and the other tools (such as the data modeller, etc).

Maybe someone who doesn't know what he's doing can be, but that's only because he would be clueless without it.

I could easily introduce that same level of functionality in a 20 minute video, and I believe the audience would actually end up feeling like they understood what was happening behind the scenes. It would require a bit more code, but not a whole lot.

I agree with Matthew. Using the tool vs not using the tool is about the same level of complexity. Only by not using the tool you actually learn whats going on as opposed to... learning the tool.

Yes but learning the tool instead of the background means that you cannot use a library that isn't MS! You cant discount that benefit.

Sure, it's a great benefit. For MS, at least .

I thought Ajax was a dutch soccer club

I thought Ajax was a dutch football club

Interesting! But here is a potential better way:

For all the time spent in developing ASP, Ajax, Web Developer, etc Microsoft could spent in developing a decent functional programming language with DSL capabilities and spare us the trouble of having to spend 20 minutes in clicking for a program that's 15 lines of code...

Stupid LISP Isn't Server Pages...

Eh, AJAX isn't hard. This is handy.

That's the biggest drawback to .NET if you ask me. I have no idea why it works or what it's doing.

I prefer PHP/Smarty still.. but it takes a lot less time to whip together a more complex page (but simple code) with C#. The AJAX video looks rather impressive to me, but I hate drag-and-drop coding

I wish the company I work for used PHP instead

1. LISP is not stupid. Those who don't understand it are doomed to re-invent it.

2. My comment has nothing to do with ASP.

Don't let Paul Graham hear you say that, he got rich with a lisp based web application (rtml).

Being a .NET person I've been impressed with atlas/ajax since I first saw it.

You can cause user controls, etc to do invisible posts to the server without mucking each other up, make your datagrids etc not require post backs for things like "edit" -- a text box will just show up... --- all this WITHOUT changing any of your applications existing code...

All I had to do was create a script manager, throw it on the page -- put the controls I wanted to not post back inside of an update panel (basically a div) and I was done. Adding ajax to an existing program that doesn't already have it probably takes under 2 minutes per page.... (I'd like to say ~30 seconds, but I wanted to be safe...)

I've written my own client side ajax code before, and that was easy for what it did, but the integration with asp.net is a lot smoother...

When I use the STL, I couldn't give a fuck what code is behind it. I simply want to use it. That's the .NET shift, you don't have to give fuck about writing a whole bunch of code (though it is nice if you know what it is you're doing), it's all about component based gui development.

That's crazyness! You most certainly do need to know when to use an anchor and when to use a LinkButton, or when to processes form input in user code, or when to check for validation. Despite anyone's best efforts to the contrary, you still need to know the difference between a GET and a POST.

It's just easier.

easier = faster development times for me.

I can make an entire site with almost no code (the ide will even write stored procs for you if you need it to -- also expression web, another great m$ product, will write some server side ASP.NET code too IIRC...)

I really don't think the comparison to STL is meaningful here. When I program in PHP, I don't care how the array is handled. When I program in .NET, I don't care how its array is handled either.

There is nothing hard about doing AJAX. The trouble with .NET programmers is they wait for Microsoft to solve their tasks and the minute they are outside the comfort zone of look and click, they are in trouble. They often end up just slopping crap together that "works" but is as optimal as driving from Chicago to New York via Los Angeles.

To give a more literal example of what Matthew just said, you end up with pages redirecting the client 2-3 times per page view because you stick a server post-back control in where a link should go, and then your pages require javascript for no good reason. If you're really bad, you will lay out your page using absolute positioning (I think VS 2003 had this called a "Web Panel" or something, but VS 2005 doesn't do it), completely destroying any trace of accessibility.

Oh, and then when your application requirements change and instead of fixing the problem at its root you simply add some code somewhere intermediate in the process, maybe add some code in a later event to cope with code in a previous one or something.

It's really easy to write really bad code if you don't know what's going on.

P.S. I don't mean to imply that "you" (or any one person) would make all of these mistakes. They are just the worst things that I have seen in my .NET development lifetime.

I had to dash off earlier, so I couldn't complete my previous post. Give a newbie the STL. Don't explain how it works to him. He might just very well take the std::vector and start inserting elements into the middle of it. If he'd ever taken a data structures course, he'd realize a std::list is a way better choice.

When I use std::vector, I understand how it's implemented. I know what's going on behind the scenes. In fact, I could write my own vector class. I have no need though, because I couldn't add anything to the supplied one.

The AJAX in .NET is an extremely high level component that is overlaying a lot of lower level stuff. Do people actually know whats happening? If not, be prepared for some horrible performance. If a programmer can easily write his own AJAX-RPC and understands how the Microsoft component works, then I have no problem with its use.

In other words, if you truly understand your tools, then go for it. But I question how good a high-level AJAX solution can work for general purpose, useful scenarios without an unnecessary performance loss occurring

Excellent way to phrase it.

I use AJAX to kill those silverfish that try to eat my cerial. I found two of them in my captain crunch yesterday.

You really shouldn't put it on your food... it's highly caustic.

I usually use it to clean windows and other surfaces
.
http://ajax.jp/images/usa.jpg

I prefer STL and I'm more a fan of PSV

When I read things like that portrayed as 'advantages' I just cringe. All that crap over the wire is death for a application with any real volume.

The unstated cost of using vis studio and the atlas stuff is the cost of training people to use it like I eluded to above. In addition to the cost of licensing it. The reason I don't use eclipse is because it's to complicated for the projects I work on.

So Pros:

1) super productive for those who know the tool
2) great for low volume sites
3) great for sites that require little design

Cons:

1) High cost of ownership
2) Training
3) Undiscplined use will result in poor code quality both performance and maintainability
4) Proprietary, EVIL.

I'd rather just do it myself. Its funner that way and more flexible.

I expect you're a XAML hater as well

The reason I don't particularly find it (namely the screencast) impressive is that you can easily do things like this (in Javascript):

var t = new wTable(document.getElementById('data-grid'));
t.enableEdit([ 'int', 'int', 'string' ]);
t.onRowChange = function(id, fields)
{
  var rpc = RPC.create();
  for (var i in fields)
    rpc.addField(i, fields<i>);

  rpc.post('/rpc/update.rpc/foo/' + id);
};

Where wTable is a class I created that enables the user to double click a cell to edit its contents.

Then foo.rpc could look like:

<?php
  $dbo = DBO::get($req[0] /* model type */, $req[1] /* id */);
  if ($dbo->hasPermission(DBO::PERM_WRITE))
  {
    $dbo->setProperties($_POST);
    $dbo->update();
  }
?>

This is about 75% of what is needed to get a fully functional, automatic data updates across the site using a generic method. And any coder who is worth hiring can easily figure out what's going on and extend it to fit specific needs.

A properly designed AJAX application should use less bandwidth than a static one

Don't forget the debugger! Single greatest feature of VS. Also, don't assume that all applications coded in Visual Studio are foolishly made drag 'n' drop applications. Keep in mind sites like http://msn.com and http://microsoft.com are written using it.

Drag and drop programming mmmm... sounds like the Alice of game programming.

and whoever "you" is, should get smacked for it...

ditto.

Umm... all that crap would have to go over the wire, and more, without ajax... when you click the edit button in a classic asp.net application's datagrid, it posts the whole page back to the server and the server sends back rendered HTML for the FULL page -- not only does it hit the server harder, but MORE data is sent per click... With Ajax it only sends the data and the javascript client-side does all the work... infact it's not even xml data -- there's a smaller footprint data format they for with Atlas/Ajax .NET data to be passed back and fourth, they look sort of like .ini files... It's been since summer since I read about the format though, IIRC it looked something like this:

MyData { 
X=15
Y=23
Z="Hello World"
};

Excuse me? Isn't all of the source openly avilable? Including the javascript source? And M$ even endorses the usage of their Ajax javascript in non ASP.NET applications...

Whoa, are you absolutely sure it didn't look like this?({ X: 15, Y: 23, Z: "Hello World" });If so, it actually makes sense

How well does Atlas degrade?

it could be like that; again, my memory is vague and rusty about the actual file format and I've not touched it -- only seen it once or twice during this last summer during an atlas presentation... -- I remember it generally looked something like that, and kicks xml in the nuts when it comes to file size.

degrade? you'll have to explain that term, I'm just a lowly high-level programmer.

edit:
I also remember a binary format for web services (as opposed to xml format) -- a presenter wrote a program that was basically a web service and a consumer -- he did something to the web service to put it into binary mode or some such (I wasn't paying a lot of attention, but it was as simple as just changing a property somewhere), it only took 300 - 500 milliseconds to send the data -- the same data in xml took about 20 seconds (all localhost to localhost) -- it wasn't a real bench mark or anything, just a proof of concept that one was faster than the other...

The binary format is proprietary obviously, since everyone expects a web-service to be xml -- but if you're just writing a web service to be consumed by a .NET desktop app, then you're ok...

It'd be really cool if Asp.Net Ajax could handle binary web data between ASP.NET and the javascript client... (For reducing the amount of data sent over the wire.) and I wouldn't be suprised if the Ajax team has plans to do it at some point.

You test your websites in browsers without JavaScript support, right?

In my most recent application, I decided to serialize using XML after consideration: the XML serialization was easier to code, but bandwidth for this application was the top priority. I looked at the XML code and found that using a binary format wouldn't save much bandwidth at all, because the entire XML document fits into a single packet, anyways. I say this just to point out that blanket conclusions never work (haha, get it? I said "never").

I can't speak for ASP.NET's implementation, but JavaScript and XML both support it, so it's easily possible. Just something simple like this:<?xml version="1.0"?><data><![CDATA[/*File data inserted*/]]></data>Adds a constant overhead of 46 bytes, plus any occurrence of "]]>" in the binary data must be replaced with "]]>]]><![CDATA[".

[append]
Of course, I think all browsers support receiving content that isn't XML (including the misnamed "XmlHttpRequest"), so you don't even need to wrap in XML.

Is that what you meant?

We test our public websites on machine's without javascript, we usually also put a little caution for them in a noscript tag that they should upgrade their browsers or turn it back on.

Because we don't give public access to areas of our sites that use dynamic technology (mostly employee only stuff) we simply require that they have Javascript turned on.

-- He was sending something pretty small, like 4 or 5 integer values, and a string of text -- also it recv'd a string of text from the client upon request before sending anything (most clients have slower upload than download speeds) -- he generated some absurd number of requests, and the binary beat xml hands down -- of course this wasn't a true bench mark, for all we know it could have been that binary data was just a lot quicker to pack/unpack, and the network load was only increased slightly.