Nieuwe preview Microsofts Ajax-ontwikkelomgeving Atlas

Microsoft heeft een tweede preview vrijgegeven van wat uiteindelijk zijn ontwikkelomgeving voor Ajax-applicaties moet gaan worden. Atlas, zoals de technologie gedoopt werd, werd in maart aan het grote publiek voorgesteld en kreeg nu dus een update met een tweede Community Technology Preview. In deze tweede versie zijn een aantal bugs verholpen met betrekking tot de zogenaamde 'gadgets', de Windows-equivalenten van Mac OS X' widgets. Daarbij werd onder andere aan veiligheid gedacht, door cross-domain toegang tot DataService-services standaard onmogelijk te maken. Deze CTP van Atlas wordt beschikbaar gesteld onder de Go Live-licentie, wat betekent dat ontwikkelaars de software mogen gebruiken om eigen applicaties te ontwikkelen, maar niet op ondersteuning van Microsoft kunnen rekenen als er iets fout gaat.

Naast de Atlas-ontwikkelomgeving heeft Microsoft ook de Atlas Control Toolkit voor Visual Studio beschikbaar gesteld. Daarmee zouden programmeurs clientside controls voor ASP.NET-applicaties kunnen ontwikkelen. In de toolkit vinden zij niet alleen documentatie voor het gebruik ervan, maar ook de broncode van de software. Bovendien kondigde het softwarebedrijf aan van plan te zijn de Atlas Control Toolkit vrij te geven als Shared Source-project, zodat 'selected community members' zelf hun bijdrage zouden kunnen leveren aan de software. Eerder al had Microsoft overigens benadrukt dat Atlas niet enkel bedoeld is om Internet Explorer-applicaties te ontwikkelen, maar met elke courante browser compatibel zou worden.

Reacties (40)

[_AvA_]

Leuk dat ze het vernoemen naar een server van tweakers.net

[d-snp]

Ja, als ze het hadden vernoemd naar de god die de wereld op zijn schouders draagt dan was dat misschien een tikkeltje arrogant geweest

[SWINX]

Of de Crew zit erachter... http://tweakers.net/gallery/105773

[Verwijderd]

Hier nog wat voorbeeldjes:
http://atlas.asp.net/atlastoolkit/

Van die dingen die daar staan krijg ik het nou niet bepaald warm. Minstens de helft van die dingen kan je gewoon 'ouderwets' met JavaScript doen en dan werkt het waarschijnlijk nog sneller ook (al is dat meer iets tegen Ajax dan tegen Atlas; de meeste dingen waarvoor Ajax gebruikt worden is gewoon niet revolutionair en zou 'gewone' JavaScript beter zijn).

Ook ben ik het wel met Robbbert eens dat het allemaal wat trager is dan andere dingen, bijv. Google startpagina. Maar misschien ligt dat wel bijv. aan dat het beta is, dat ik Linux/FireFox gebruik, etc.

[maikr]

Flash. Punt.

[Verwijderd]

Inderdaad kunnen een hoop zaken ook gewoon met Javascript.

Maar als je bijvoorbeeld iets wilt maken als in het voorbeeld gegeven CollapsiblePanelExtender en dit panel moet dynamisch gevuld kunnen worden ( dus 200 of meer mogelijkheden ana content) is Ajax hiervoor een zeer goede oplossing. In combinatie met Atlas is het zelfs een makkie. Buiten je standaard webapplicatie hoef je maar een paar regels code toe te voegen en je gebruikt Ajax.

[MaZo]

Ajax is Javascript.

[CyberArt]

Nog erger, van wat ik er van zie kun je de Textbox Watermark zelfs met CSS doen..

[sopsop]

Wat is dit voor non-reactie? Als je Ajax wilt gebruiken moet je alsjeblieft geen gebruik maken van Atlas. En dan als voorbeeld wat je wel moet gebruiken geef je Ruby on Rails. Geef dan een voorbeeld van een een Ajax-toolkit en niet een of ander mega-systeem met als onderdeel daarvan Ajax. Dat is als iemand adviseren om een vrachwagen met oplegger te kopen, waarop 1 auto staat, terwijl de persoon alleen een auto wil.

En dan geef je nog een voorbeeldpagina waarin dingen staan die met Atlas ook allemaal gerealiseerd kunnen worden. En ook het argument 'alleen interessant als je in asp ontwikkeld' raakt kant nog wal.

Daarnaast is Atlas zeker voor de dotnetters een welkome uitbreiding. En ook voor de niet-dotnetters.

[Robbbert]

Hier een voorbeeld van het gebruik van Atlas: http://www.pageflakes.com

Ligt het aan mij of is Atlas stukken trager dan Ajax? Op bovenstaand voorbeeld begint bij mij zelfs de muiscursor te schokken. Met de Google startpage loopt alles veel sneller en vloeiender.

Edit:
Sorry Yoeri, ik heb het blijkbaar niet helemaal begrepen
Ik heb altijd gedacht dat Atlas en Ajax net zoiets was als ASP vs PHP

Maar als ik alles zelf schrijf met C++ en Win32 in plaats van grafisch met Visual C++, werken bij mij de programma's stukken sneller.

Wellicht is dat hier ook het geval, door overbodige code van de ontwikkelomgeving werkt het blijkbaar trager dan dat je alles zelf schrijft? Of moet ik er rekening mee houden dat alles nog 'Beta' is?

[Padschild]

Ik heb zelf ook al het een en ander gemaakt met Atlas, staat nog niet online, maar ik heb wel een filmpje gemaakt over wat ik tot nu toe heb:

http://www.oblivionsource.com/gulst/gulst_show.wmv

Ik heb hier alleen geen standaard controls van Atlas gebruikt, alles zelf geprogrammeerd

[_Thanatos_]

misschien wil je er wat meer over vertellen? hoe makkelijk was het, hoe snel kon je een eerste resultaat tonen, hoeveel code heb je nodig, hoe transparant is de werking?

iyanic, reageer es ff normaal man.

[Yoeri]

Atlas is gewoon een ontwikkelomgeving om Ajax-applicaties in te maken. Net zoals Visual Studio een ontwikkelomgeving is voor bijvoorbeeld C++. Nu lijkt het alsof jij zegt "Visual Studio werkt een stuk trager dan C++" wat natuurlijk niet echt ergens op slaat

Ik vermoed dat pageflakes gewoon wat gecompliceerder is dan de google startpagina

[edit]
Je moet wel al een echte die-hard zijn om zelf Win32-functies op te roepen en daarmee je applicatie sneller te krijgen dan wanneer je Visual Studio zult gebruiken. In de meeste gevallen zul je namelijk alleen maar tragere code schrijven vermoed ik. In theorie zou je het snelste programma hebben door alles in assembler te schrijven, maar slechts hééél weinig mensen zijn daartoe in staat. De meesten die al in assembler kunnen programmeren, zullen uiteindelijk een traag en buggy programma hebben gok ik.

Jouw stelling geldt wel voor iets als Dreamweaver. Daar zal een select op een database door middel van de templatecode inderdaad trager zijn dan zelf php schrijven. Met Visual Studio schrijf je echter nog steeds zelf je code, maar roep je wel ingebouwde functies aan en zo. Ik ga er echter van uit dat de ontwikkelaars daarvan weten wat ze doen en dat dit in 99% van de gevallen de snelste oplossing zal zijn.

[Verwijderd]

Atlas is een AJAX toolkit voor ASP.Net. Het is geen ontwikkel omgeving, je kan VisualStudio gebruiken als onwikkelomgeving voor je Atlas applicaties.

[Milt]

Je moet wel al een echte die-hard zijn om zelf Win32-functies op te roepen en daarmee je applicatie sneller te krijgen dan wanneer je Visual Studio zult gebruiken. In de meeste gevallen zul je namelijk alleen maar tragere code schrijven vermoed ik.

Wat betreft snelheid gaat er natuurlijk niks boven een applicatie die rechtstreeks op de Win32 API is geprogrammeerd. Al die application frameworks zijn leuk en makkelijk voor de ontwikkeling, maar sneller worden je applicaties er niet van. De basisopzet van een Win32 API messageloop applicatie is overigens redelijk simpel te maken in assembly. Maar heel veel sneller dan de C implementatie zal het niet zijn.

[Justice]

Crossbrowser ondersteuning bij Atlas lijkt wel te betekenen dat alle non IE browsers een traditionele pagina voorgeschoteld krijgen ipv AJAX.

AJAX is echt wel goed werkend te krijgen op Opera en Safari maar alle voorbeelden die ik nu bekeken heb vallen terug op traditionele manieren. (form submit en page reload)

Test Atlas of een feature ondersteund wordt of maakt het gebruik van browsersniffing?

edit:
Hier (http://blogs.msdn.com/sburke/archive/2006/04/14/576637.aspx) is meer informatie te vinden.

[EfBe]

Alle atlas functionaliteit wordt cross-browser. Scott Guthrie liet dat ook zien op de devdays, in firefox.

Ze hebben een complete library geschreven waar je mee werkt als ajax-devver, en die library zorgt voor een abstractie van de browser functionaliteit, dus je programmeert altijd maar 1 routine en de library zorgt voor de browserspecifieke zaken.

In ASP.NET werk je gewoon declarative, dus je plaatst html tags en de runtime zorgt voor de rest. De 'runtime' houdt in feite in dat er controls zijn gemaakt die gewoon werken zoals iedere andere control maar de ajax code emitten in de html source die naar de browser gaat. Zodoende kunnen ze iedere bestaande asp.net control ajax-enabled maken.

[Verwijderd]

In ASP.NET werk je gewoon declarative, dus je plaatst html tags en de runtime zorgt voor de rest

Dit is een enorm krachtige werkwijze van ASP.NET. Je plaats componenten (controls) op de pagina, en je bekommerd je er niet om hoe deze intern werken. Je kunt er ook makkelijk meerdere van op 1 pagina zetten zonder dat deze elkaar in de weg zitten.

Vergelijk dat met een werkwijze als PHP of ouderwets JSP waarbij je geen componenten hebt, maar handmatig HTML met script er tussen plaats. Wil je meerdere van dezelfde 'dingen' op je pagina dan moet je deze handmatig uit elkaar zien te houden. Moeilijker wordt het als je op postbacks van verschillende blocken HTML moet reageren in script; dan moet je deze handmatig uitelkaar houden.

In de traditionele request-response cycle is dit eigenlijk al rottig, en alles behalve een uiterst triviale pagina wordt al heel snel een chaos kwa source in PHP.

Het ASP web controls idee werdt ontworpen lang voordat AJAX een hype werd. Hoewel AJAX en ASP.NET wel uit de zelfde stal komen hielden ze niet expliciet rekening met elkaar. Sterker nog, het leek wel of de technieken elkaar beconcureerde.

Nu blijkt echter dat het ASP web controll model uitstekend de complexiteit van AJAX uit handen kan nemen van de gebruiker van de technology. Een web tier programmeur / autheur hoeft amper te weten dat een control AJAX gebruikt. Hij/zij plaats gewoon het component op een pagina, en voorziet het van de zogenaamde bindings. Het component verzorgd dan zelf de 'rendering' van de benodigde AJAX code en treed ook op als 'locale mini server' voor de AJAX requests. Zoals al gezegd, voor de programmeur die gebruikt maakt van de componenten is er dus amper verschil met een traditioneel component.

Natuurlijk is niks helemaal gratis in de ICT wereld; de complexiteit verschuift namelijk naar de developper van een component. Het ontwikkelen van een AJAX gebruikmakend ASP.NET control is duidelijk moeilijker dan een gewone control maken. Als deze eenmaal geschreven door meer mensen wordt gebruikt (wat dus de bedoeling is), dan heb je al winst.

(In de komende versie van Java EE zal exact hetzelfde model toegepast gaan worden (Sun noemt het JSF), en ook hier zullen er controls komen die precies op de ASP.NET manier de page author afschermen van de AJAX complexiteit)

[bluewalk]

Vergelijk dat met een werkwijze als PHP of ouderwets JSP waarbij je geen componenten hebt, maar handmatig HTML met script er tussen plaats. Wil je meerdere van dezelfde 'dingen' op je pagina dan moet je deze handmatig uit elkaar zien te houden. Moeilijker wordt het als je op postbacks van verschillende blocken HTML moet reageren in script; dan moet je deze handmatig uitelkaar houden.

In de traditionele request-response cycle is dit eigenlijk al rottig, en alles behalve een uiterst triviale pagina wordt al heel snel een chaos kwa source in PHP.

Dat ligt aan de programmeur zelf! Als ik een website in elkaar zet, maak ik gebruik van mijn template parser zodat je echt alleen maar code in een phptje hebt. Zo blijft je source ook overzichtelijk.

[Nordlys]

De website die je op de screenshot ziet is hier te bekijken:

http://atlas.asp.net/atlastoolkit/

[Verwijderd]

hmmmz
ik gebruik opera onder Mac.

En bijna niets van die samples werkt.
Zoals die drag-drop, ... werken totaal niet
Dat belooft.

Die pageflakes werkt dan weer wel volledig.

[Noxious]

Vanaf bij mij thuis met opera werkt het ook niet super, met konqueror iets beter

Maar vanaf ze zaak met IE werkt het perfect. Hoop dat ze overal goed gaan werken toffe functies!

[Roeland4]

Helaas ziet die pageflakes site in safari al niet goed uit. Dat belooft voor de ondersteuning van andere browsers.

[burne]

In Safari gaat het nog beter. Exact niets werkt.

[EfBe]

Microsoft heeft een tweede preview vrijgegeven van wat uiteindelijk zijn ontwikkelomgeving voor Ajax-applicaties moet gaan worden.

Atlas is geen omgeving, het is/wordt een add-on voor ASP.NET 2.0. Het is dan ook te gebruiken in iedere ASP.NET 2.0 applicatie en dev omgeving.

[Verwijderd]

Dergelijke initiatieven zijn uitstekend om "simpele" resultaten te bereiken maar wil je echt iets neerzetten wat goed performed, wat complex is, en wat de browser op het randje pushed van wat er mogelijk is dan zal het toch aankomen op het ouderwetse handwerk met de nodige praktijkervaring. Er komt onderwater veel meer kijken bij dergelijke applicaties dan alleen een xmlHttpRequest.

[mclukas]

Dit is weer typisch microsoft, deze toolkit is volledig asp georienteerd.

ik experimenteer al een tijdje met ajax en ik gebruik de lib's van backbase http://www.backbase.com

veel beter, sneller en mooier.
en een groote compatibiliteit qua browsers en qua talen: jsp, php, asp, coldfusion, ...

[Verwijderd]

Dit is weer typisch microsoft, deze toolkit is volledig asp georienteerd.

Iets te voorbarige conclusie:

http://www.shankun.com/AtlasPhp.aspx

Bovendien zijn de Atlas Control Toolkit en Atlas zelf twee verschillende dingen. De Control Toolkit is wel ASP.Net specifiek, maar dat is nou juist de bedoeling. Ze zijn bedoeld om te kunnen gebruiken in Visual Studio naast de standaard controls.

[YaPP]

Zo te zien is het ene framework nog uitgebreider dan het andere.

Voor ontwikkelaars die meer eenvoud zoeken kan ik www.xajaxproject.org aanraden. Het is alleen voor PHP, maar het concept is goed te implementeren in andere talen.

Deze library gebruikt AJAX niet om XML in de client te verwerken (wat het meeste werk is), maar gebruikt het om Remote-Prodecure-Calls uit te voeren:
* De aanvraag naar de server wordt gebruikt om een methode met parameters aan te roepen.
* Het antwoord bevat opdrachten die de client moet uitvoeren, bijvoorbeeld een JavaScript functie aanroepen, alert box tonen of een eigenschap (bijv. style of innerHTML) aanpassen van een element.
In feite werk je dus event-based i.p.v. data-based, en kun je alle bestaande server-side libraries herbruiken.
Dit heeft in mijn project op het werk zeker zijn vruchten afgeworpen. Op een eenvoudige en inzichtelijke manier kan je hele krachtige AJAX-applicaties maken.