ASP.NET AJAX 1.0 RC

[dlynes2005]

I've been developing a few internal websites using Atlas/M$ Ajax for
quite a while now.

Now that Atlas has been developed to the release candidate stage, does
anyone have any idea as to how long it will be before the final release
is released?

One other thing, if I have a web page with an UpdatePanel on it, I'm
getting 3 javascript files totalling 128kb, which contain (from what I
can see) most of the javascript for the Atlas functions. Is this likely
to be reduced and optimised in the final relase? Whilst its not a great
deal for the user to download, it does seem like quite a hit on the
initial request.
Thanks

Dave.

[Joe (MCAD)]

Yep I know exactly what you are talking about. Its way toooo heavy for a
website, at least any that is to be taken seriously and not an intranet.
That javascript file alone will probably prevent you from hitting your
'time to view page' benchmark... It does contain a lot and lot and lot
of stuff you dont need since its a framework. Trace through what that
framework is actually doing before making a call, scary. See thread 'Is
ASP.NET outdated?' in this newsgroup.

dl********@gmail.com wrote:

I've been developing a few internal websites using Atlas/M$ Ajax for
quite a while now.

Now that Atlas has been developed to the release candidate stage, does
anyone have any idea as to how long it will be before the final release
is released?

One other thing, if I have a web page with an UpdatePanel on it, I'm
getting 3 javascript files totalling 128kb, which contain (from what I
can see) most of the javascript for the Atlas functions. Is this likely
to be reduced and optimised in the final relase? Whilst its not a great
deal for the user to download, it does seem like quite a hit on the
initial request.
Thanks

Dave.

[Joerg Jooss]

Thus wrote Joe (MCAD),

Yep I know exactly what you are talking about. Its way toooo heavy for
a website, at least any that is to be taken seriously and not an
intranet. That javascript file alone will probably prevent you from
hitting your 'time to view page' benchmark...

Hardly. ScriptResource.axd delivers JavaScript gzip-compressed and with all
whitespace removed if your application runs with <compilation debug="false"
/>. The delivered script is also marked as publicly cacheable, and is set
to expire after one year.

Cheers,
--
Joerg Jooss
ne********@joergjooss.de

[Joe (MCAD)]

Joerg Jooss wrote:

Thus wrote Joe (MCAD),

>Yep I know exactly what you are talking about. Its way toooo heavy for
a website, at least any that is to be taken seriously and not an
intranet. That javascript file alone will probably prevent you from
hitting your 'time to view page' benchmark...

Hardly. ScriptResource.axd delivers JavaScript gzip-compressed and with
all whitespace removed if your application runs with <compilation
debug="false" />. The delivered script is also marked as publicly
cacheable, and is set to expire after one year.

Cheers,

I am using a 3rd party compression in IIS 5, I am getting a
scriptresource.axd and webresource.axd, uncompressed they are 80k and
20k with a simple one button in an updatepanel test page. Compressed
they are 24k and 6k for a total of 30k of javascript; fairly good
compression. Now granted AJAX.NET framework offers far more than what
the above example is using it for, but i've in the past written similar
logic to whats being used here at about 1.5k uncompressed (conservative).

Point being 20X larger really is a big deal when you are talking about
benchmarks. I'm sure some would disagree...

Joe (MCAD)

[Joerg Jooss]

Thus wrote Joe (MCAD),

[...]

I am using a 3rd party compression in IIS 5, I am getting a
scriptresource.axd and webresource.axd, uncompressed they are 80k and
20k with a simple one button in an updatepanel test page. Compressed
they are 24k and 6k for a total of 30k of javascript; fairly good
compression. Now granted AJAX.NET framework offers far more than what
the above example is using it for, but i've in the past written
similar logic to whats being used here at about 1.5k uncompressed
(conservative).

You probably didn't include a full-blown library that emulates core parts
of the BCL ;-)

Point being 20X larger really is a big deal when you are talking about
benchmarks. I'm sure some would disagree...

Again, all of the script files are fully cacheable. Unless users go crazy
with Ctrl-F5, or turn off caching altogether, I wouldn't expect the production
size of these files to become an issue.

Cheers,

--
Joerg Jooss
ne********@joergjooss.de