Microsoft weidt uit over Ajax-plannen

Scott Guthrie, General Manager van Microsofts Developer Division en in die functie onder andere verantwoordelijk voor de .NET Common Language Runtime, ASP.NET, Atlas, Avalon en dergelijke producten, heeft op zijn blog wat meer openheid gegeven omtrent Microsofts plannen met Ajax en de Atlas-bibliotheek. Tegen het jaareinde moet Atlas 1.0 beschikbaar zijn en de status van 'fully supported product' bereikt hebben. Deze status houdt bij Microsoft in dat ondersteuning desgewenst 24 uur per dag, 365 dagen per jaar beschikbaar is en dat hotfixes beschikbaar zijn voor alle gebruikers. Het betekent bovendien dat Microsoft zich ertoe verbindt de software minstens tien jaar lang te zullen ondersteunen.

De 1.0-versie die dit jaar nog gelanceerd moet worden, zal bestaan uit een 'core' met basisfunctionaliteiten voor het bouwen van clientside controls en integratie met ASP.NET. Er zijn echter een aantal features in de huidige Community Technology Preview van Atlas die niet in de volledig ondersteunde core-versie te vinden zullen zijn. Guthrie benadrukt echter dat deze features niet geschrapt worden, maar als afzonderlijke download aangeboden zullen worden en naadloos samen zullen werken met de core. Alle features zullen overigens onder de eerder geïntroduceerde Go-Live-licentie vrijgegeven worden. Bovendien zullen in de toekomst meer features aan de volledig ondersteunde 'core' toegevoegd worden.

Met het volwassen worden van het product, is men bij Microsoft ook over de definitieve naamgeving gaan nadenken. Deze zal namelijk niet 'Atlas' luiden. De scriptbibliotheek die tot nu toe als Atlas door het leven gaat, zal in drie onderdelen gesplitst worden. De clientside javascriptbibliotheek zal onder de noemer 'Microsoft AJAX Library' aangeboden worden en zal volgens het bedrijf met elke browser compatibel zijn. De benaming 'ASP.NET 2.0 AJAX Extension' zal gebruikt worden voor de serverside 'Atlas'-functionaliteit. De tag prefix voor deze toepassing zal dan ook veranderen van <atlas:> naar <asp:>. De 'ASP.NET AJAX Control Toolkit' ten slotte zal gebruikt worden voor een verzameling gratis controls en componenten waarvan de broncode beschikbaar zal zijn in het 'shared source'-programma.

Microsoft maakt zelf ook intensief gebruik van Ajax, onder andere voor Local.live.com.

Reacties (49)

[Jay.NET]

Ik heb inmiddels een beetje ervaring met de Atlas library, en het werkt vrij aardig. Eenvoudige dingen zoals alleen een gedeelte van de pagina refreshen is redelijk makkelijk te implementeren. Wat ik alleen niet snap is waarom ze niet, nu ze het toch willen integreren met het .NET framework, ze deze functionaliteit ook niet direct inbouwen in de servercontrols. Het zou volgens mij vaak, vooral in een wat uitgebreidere en ingewikkeldere applicatie, een stuk makkelijker zijn om direct een server control "AJAX-enabled" te kunnen maken dan er b.v. zelf weer een custom controol van te moeten maken, of alles te moeten wrappen in Atlas controls (iets wat bij sommige dynamisch opgebouwde pagina's een vrij lastige klus kan zijn).

[SchizoDuckie]

Als er één library is waar een *berg* browser check inzitten dan is het atlas...

Kunnen ze niet gewoon cross browser code schrijven? Dit is wederom weer *zo* bloated allemaal, dat als er een iemand een wijziging aan zn browser maakt, iedereen z'n atlas source weer mag gaan updaten...

[edit]
Okee, score me maar als flamebait... Het is een FEIT dat andere libs het zonder browser checks kunnen, of alleen checken op features (wat een veel betere optie is imo)

[Ad-]

Tja,
B.v. Opera, FireFox en IE doen (X)HTML, CSS én om het feest compleet te maken ook Javascript zo elk op hun eigen manier. Wil je bij élk van de browsers het onderste uit de kan halen mot je dus browserchecks doen.
Anders werken alléén die dingen die het in álle browsers doen en dan houdt je weer ( te ?) weinig over.

Kortom, ik vind het wel prima dat ze voor die route hebben gekozen.

[Verwijderd]

Je moet geen browser-check doen, je moet capability-check doen. Anders is je code niet opgewassen tegen browser-updates zoals de overgang van IE6 naar IE7.

[YaPP]

Ahum. Er bestaat zoiets als "Standard mode" en "Quirks mode". Als je de goede doctype gebruikt zullen Firefox, Safari en Opera de pagina's hetzelfde renderen, anders blijven ze in Quirks mode oude bugs emuleren.

Alleen Internet Explorer 6 heeft nog een aantal hardnekkige CSS bugs. In IE7 zijn ook deze bugs opgelost, en renderd IE7 de pagina ook hetzelfde.

[BikkelZ]

Nou nou, je hebt inderdaad wel verschillen, maar die zijn te ondervangen door zeer algemene checks die je code uberhaupt veiliger maken.

Als je door een setje childNodes heenstapt die in IE geen #text er tussen hebben en in Mozilla wel, dan zorg je dus dat je niet rucksichtlos element-bewerkingen loslaat op de children maar dat je eerst ff kijkt wat je precies voor vlees in de kuip hebt.

Dan schrijf je in principe ook gewoon betere software.

Met een browsercheck maak je twee keer zoveel buggy code, met generieke checks heb je iets meer code en deze is meteen robuuster op alle verschillende clients.

Want STEL dat IE8 opeens ook die #text nodes er tussen zet, dan kun je weer alles gaan ombouwen.

[freaky]

Wellicht zitten al die checks erin omdat zekere browsers de standaarden zo lekker hanteren waardoor dezelfde code zo lekker loopt op alle browsers... Daar komt nog eens bij dat niet alle standaarden zo geweldig omschreven zijn.

[Verwijderd]

Daarnaast is de 'standaard' vaak niet eens de defacto-standaard wat implementatie van de standaard en niet de defacto-standaard erg lastig maakt. Je product zal dan niet echt gebruikt worden denk ik zo.

Iedere browser heeft zo z'n eigen mooie snufjes, het is nu eenmaal niet zo dat alle browsermakers aan hetzelfde werken. Ze willen graag een USP toevoegen aan hun browser wat per definitie niet standaard betekent.

Nu maken ze gebruik van die functionaliteiten is het weer niet goed.

Daarnaast valt de performance hit heel erg mee, die checks kosten allemaal niet zoveel (ze doen het waarschijnlijk maar 1x en dan niet meer). Over die paar MB dat de runtime er groter van wordt... who cares?

[Bosmonster]

Paar MB? Dat wil je echt niet binnenhalen. De hele Atlas bibliotheek mag maximaal 200K wegen oid. (Dat was het streven iig als ik me niet vergis...)

En runtime? Ik neem aan dat de checks clientside plaatsvinden.

[bitflusher]

de php bibliotheek is toch ook wel wat groter dan 200k, gelukkig worden de bibliotheken aan de serverzijde gebruikt.

[Verwijderd]

@Bosmonster:

Client side haal je natuurlijk niets extra's binnen vanwege de browserchecks

Je krijgt gewoon de client library binnen geschikt voor jouw browser en geen andere. Het lijkt me een beetje dom om op de client (waar de browser dus een constante is binnen de sessie) een library binnen te gaan halen die realtime gaat checken of je spontaan ineens niet op een andere browser zit.

[OpenMinded]

dat kunnen ze waarschijnlijk wel, maar dat willen ze niet, want iedereen moet straks zijn nieuwe virussen, trojans en spyware binnenhalen via IE 7...
En aangezien nog steeds niet alle CSS bugs uit IE 7 zijn, en voorlopig dat ook niet gaat gebeuren, is de beste oplossing een andere browser te gaan gebruiken.
De GO-live licentie is nou ook niet echt aantrekkelijk, je mag het wijzigen en hebt geen support meer.
Dan gebruik ik wel volledige Open Source software, hoef ik me niet aan een M$-licentie te verbinden met alle ellende van dien en huur ik een ontwikkelaar in voor problemen en aanpassingen.

[Verwijderd]

Kunnen ze niet gewoon cross browser code schrijven? Dit is wederom weer *zo* bloated allemaal, dat als er een iemand een wijziging aan zn browser maakt, iedereen z'n atlas source weer mag gaan updaten..

ik begrijp je punt, maar ze geven teminste alles vrij voor in elke browser te gebruiken. dit zal dus wss ook linux en mac betekenen. toch al een stap in de goede richting. er is veel werk bij. maar het is en blijft M$ he ^^

[Verwijderd]

Ik las net dat de laatste builds 6k aan js geven. J emoet niet vergeten dat het op dit moment allemaal erg beta is

[crisp]

Het probleem met Microsoft in z'n algemeenheid is dat ze in eerste instantie altijd uitgaan van hun eigen technologieën en daarna pas gaan kijken hoe het op een standards-compliant manier gedaan moet worden zodat het ook in andere browsers werkt.

[Qorne]

Alweer een goed voorbeeld van Microsoft Marketing,
Ajax staat in de kinderschoenen en groeit snel, Microsoft gebruikt Ajax heel erg veel in het Live concept, opzich een mooi concept (nee ik ben alles behalve MS lover) aangezien computers en internet steeds sneller wordt verwacht ik wel dat Microsoft een leuke monopolie gaat krijgen met Ajax technologie op het web. weer gecombineert met hun server toepassingen.

Dit is een grote stap van Microsoft verwacht ik.

[Verwijderd]

Grappig alleen dat Ajax al enkele jaren bestaat (IE 5.5 ondersteunt het zelfs al) totdat een of andere popie jopie er een naam voor bedacht en het ineens hip werd.

Ach ja het is een leuke technologie maar een beetje overhyped als je het mij vraagt.

[Verwijderd]

Sterker nog.
XMLHTTP is een uitvinding van het Outlook Web Access team.
Daarom zit het in IE5.5


Het blijft natuurlijk JScript en HTML en dat is hopeloos verouderd.
Waar blijven de XUL of XAML applicaties

[Verwijderd]

Via iFrames is het eigenlijk iets wat al in IE 3 is geintroduceerd.

[Maurits van Baerle]

Nou en?

Het internet bestond ook al jaren voordat het een hype werd, ruim tien jaar geleden. Toch is het die hype geweest die voor de revolutie van honderden nieuwe diensten en toepassingen heeft gezorgd, niet de introductie van een paar protocollen.

Als het gebruik van een label als AJAX er voor zorgt dat al die dingen die al zo lang bestonden eindelijk ook eens echt gebruikt worden (in plaats van slechts theorie zijn) moeten we de hype dankbaar zijn.

[Verwijderd]

Enkele jaren? Zeg maar gerust een flink aantal jaren...

[Bosmonster]

Zolang niet heel het web werkt op basis van .NET zal dat wel meevallen. En zelfs .NET developers weten dat de Atlas bibliotheek niet de beste is die op internet te vinden is. Veel zullen voor het gemak en de VS implementatie wel voor Atlas gaan.

Een monopolie op het ajax fenomeen lijkt me dus vrij sterk

[Ahrnuld]

Links naar betere?

[skabouter]

http://www.ajaxpro.info/

[skabouter]

Ja maar het gaat hier wel over een framework met intergratie in het .NEt framework he

[Bosmonster]

Google Web Toolkit
Prototype
Dojo
Script.aculo.us
etc.

Ow, vergeet ik bijna ons neerlandse BackBase!

[Sv3n]

kijk eens naar dit:
http://www.wicket-library.com/wicket-examples/ajax

Java framework met ajax intergratie

[Blaise]

Voor AJAX kan je in veel gevallen toch het beste je eigen library schrijven? Mijn ervaring met dit soort totaalpaketten is dat er enorm veel onzin in zit die je toch niet gebruikt (maakt ook traag), en als je iets geks wil uithalen kan dat vaak weer net niet.

Voor sites gebruik ik nu een enkele XMLHttpRequest(url) functie, en de rest regel ik serverside met vervolgens een eval(responseText). Enorm krachtig, overzichtelijk en eenvoudig. Ik denk zelfs dat dat in veel gevallen eenvoudiger is dan Microsofts libraries te integreren.

@Cowboy op zee: het is veel makkelijker om serverside de specifieke acties te genereren in javascript die moeten worden uitgevoerd, dan dat je voor elke handeling een aparte javascript functie maakt.

[Cowboy op zee]

@blaise:
Jouw clientside code is inderdaad erg eenvoudig. Maar het "eval(responseText)" statement lijkt er op te wijzen dat er aan de server kant complete javacode wordt gegenereerd.
Dit is slechts een verplaatsing van de complexiteit. De kans is ook groter dat je dan presentatie- en datalogica sterk door elkaar heen gaat gebruiken, terwijl ajax nu juist een fijne kans biedt om die te scheiden.
Met je stelling

Voor AJAX kan je in veel gevallen toch het beste je eigen library schrijven?

ben ik het niet eens. Het is juist goed om, voordat je zelf van alles gaat ontwikkelen, te bekijken of een ander dat misschien al heeft gedaan. Niet alleen is dat meestal goedkoper, maar vaak hebben die anderen het ook beter gedaan, omdat men er met meer mensen al langer mee bezig is en het door meer mensen wordt gebruikt (=meer feedback). Slechts in uitzonderingssituaties moet je zelf opnieuw het wiel gaan uitvinden.

[mxcreep]

Zelf ontwikkelen van een AJAX lib heeft weldegelijk behoorlijke voordelen :

- Je weet exact wat er gebeurt, dus je zult niet snel voor verrassingen staan, iets wat met ingewikkelde javascript bibliotheken geen uitzondering is.

- Je implementeert alleen wat je nodig hebt. Standaard bibliotheken proberen altijd zo generiek mogelijk te zijn, mooi om zoveel mogelijk te ondersteunen aan mogelijkheden, maar het komt de efficientie en foutgevoeligheid niet ten goede.

[chaos.be]

Fijn,

zal ik dat ff gaan voorstellen aan men klanten. Kan ik er direct de rekening bij geven voor hoelang de ontwikkeling van zijn "applicatie met eigen bibliotheken" duurt...

[Cowboy op zee]

Vergeet niet de kosten voor de "eigen bugs" te specificeren

[Ahrnuld]

Als je ASP.NET 2.0 gebruikt is het wel degelijk eenvoudiger (in ieder geval minder code). Zolang je er maar niet teveel van verwacht.
De updatepanel control (werk een deel van je pagina bij zonder refresh, evt met triggers van andere controls) is erg handig. Zo kan je een bestaande site vrij snel 'ver-ajaxen'.
Helaas draagt dit (afgezien van minder refreshes) niet zo heel veel bij aan een betere gebruikerservaring.

[Verwijderd]

hangt er vanaf wat je ermee doet. Neem nu mijn respons hier op Tweakers.net. Ik klik en wat gebeurd er? nieuw venster. Ik zie jouw tekst niet meer, andere tekst niet, moet alt-tabben, ik zie niet hoe het eruit zal zien in de eigenlijke thread, etc.

Met 'AJAX' zou je dat dus zo kunnen maken dat de edibox, met juiste font (CSS) direct op de juiste plaats wordt gezet in de thread. Druk je dan op 'Reactie plaatsen', dan staat het er dan ook 'meteen' (edibox weg, gewone content erin) - hoef je niet meer te refreshen de server hoeft niet de hele pagina meer over te sturen, etc.

[Verwijderd]

Er zijn wel wat andere issues met de lay-out en de pagina-overgangen in de comments op tweakers.net die iets meer prio hebben lijkt me

[sjunnie]

Zoals vBulletin dat dus ook alweer een tijdje doet

[StGermain]

Toen ik het topic zag kreeg ik een visioen over Ajax truitjes gesponsord door Microsoft........

[Bulls]

ik dacht eerlijk gezegd ook eerst aan dat microsoft Ajax wil gaan sponsoren.

edit: geen dubbelpost, maar simultaan post

[SiliconError]

Ik had wel iets beters verwacht van de Microsoft marketing afdeling. Nou hadden ze een gouden kans om die belabberde term AJAX in ieder geval uit hun deel van de wereld te helpen, blijven ze het gebruiken. Aargh!

[Ahrnuld]

Ja, iets als ASP.NET Live Extensions ofzo

[Verwijderd]

Oei, Oei, Feyenoordfan?

[rodeduivel]

Ik ben zelf (web) software ontwikkelaar en kan je vertellen dat vele dingen anders zit in elke browser. Vooral met nieuwe technieken zoals AJAX wilt elke browser-maker 'voorlopen' op de concurentie en implementeren dan reeds functies ook al is het nog geen standaard hiervoor.

Bijna elke AJAX library zal vooral deze browser afhankelijke functies worden 'verborgen' en daarvoor zal waarschijnlijk browser checks voor nodig zijn, ik vind dat helemaal geen probleem, sterker nog ik vind het zeer fijn dat er een uniforme manier wordt aangeboden om iets gedaan te krijgen!

[Verwijderd]

Ik denken: Jippie Ajax Amsterdam versie Windows

Overbodig: Ja, maar wel waar