AJAX Library: csak egy maradhat

Az elmúlt években drasztikusan megnőtt az igény a webfejlesztésnél a kliens oldali kódolásra, ám mivel ez alapvetően nem egy fejlesztői kéjélmény, újabb és újabb JavaScript keretrendszerek bukkantak fel. A Microsoft is elkészítette a sajátját Microsoft Ajax Library néven és egész szép eredményeket ért el, különösen az Ajax Control Toolkittel integrálódó új verziókban, írtam is róla eleget. A verseny azonban úgy látszik, véget ért, a favorit pedig a jQuery, amelyet mára a nagyobb webhelyek közül minden harmadik használ. Jogosan merül fel ennek fényében a kérdés: mi lesz veled ASP.NET AJAX?

Azt kell, hogy mondjam, azok számára, akik hozzám hasonlóan elég sok energiát fektettek a Microsoft Ajax Library megismerésébe, a MIX-en napvilágot látott döntés elég elszomorító: KUKA.

A döntés okainak megértéséhez azt kell látni, hogy az ASP.NET platformon kétféle kliens oldali fejlesztő van: az egyik megijed a JavaScript kódtól, a másik nem.

Aki megijed, azt úgy hívja a Microsoft, hogy “ASP.NET WebForms developer” és ők akkor tudnak igazán kliens oldali interaktivitást vinni az oldalba, ha azt egy szerver oldali komponens valósítja meg. Valami, amit be lehet húzni a Toolboxról. Az Ajax Control Toolkit (ACT) őket szolgálja és fogja szolgálni a jövőben is. Van belőlük jó sok, hiszen az ACT-t havonta százezren töltik le, ami nem véletlen, hiszen ezek a szerver oldali vezérlők óriási segítséget jelentenek a fejlesztéskor.

Aki nem ijed meg a kliens oldali kódolástól (“Ajax client developer”), eddig több lehetőség közül választhatott: vagy meztelen JavaScript kódot írt, vagy valamilyen JavaScript keretrendszert használt. A Microsoft eddig azt mondta, hogy a Microsoft Ajax Library az üdvözítő megoldás, például azért, mert van benne a szerver oldali .NET-re emlékeztető kliens oldali osztálykönyvtár, típusok, öröklődés stb. Ráadásul folyamatosan fejlődött is a Microsoft Ajax Library, a 4.0 verzióra durva újdonságokat kapunk: script loader, DataView vezérlő, adatkötés, template-ek stb, sőt nemrég az egész Ajax Control Toolkitet átírták úgy, hogy a Microsoft Ajax Library-t használja.

És ebben a pillanatban, amikor már kezdett igazán ütőssé és vonzóvá válni ez a library, akkor döntöttek úgy Redmondban, hogy a jövőben mégsem a sajátjukat favorizálják, hanem a legmenőbbet, a jQuery-t. A jQuery-t eddig is támogatták, hiszen az ACT-ben lévő vezérlők jQuery-ből is elérhetőek voltak, a jQuery a Microsoft CDN-re is felkerült, sőt az ASP.NET MVC-nek része is lett. Most azonban a MacLeod klán nagy reményű ivadéka önmaga fejét vágta le, hogy végül csak egy maradjon.

Röviden:

  • Szerver oldali fejlesztők számára várhatóan pár havonta lesz új Ajax Control Toolkit mégpedig a CodePlex Foundation kezelésében
  • Az ACT alapjául továbbra is a Microsoft Ajax Library szolgál, de az Ajax Library nem fog tovább fejlődni, legfeljebb a hibákat javítják ki benne.
  • Ha kliens oldali kódot akarsz írni, akkor lehetőleg ne a Microsoft Ajax Library-t használd, hanem a jQuery-t.
  • Ha már használod a Microsoft Ajax Library-t (például az új script loadert vagy a DataView vezérlőt), akkor sincs gond, használhatod továbbra is az ACT részeként. Nem lesz önálló RTM verzió az Ajax Library-ből.
  • Azokra a funkciókra, amikben a Microsoft Ajax Library előrébb járt, mint a jQuery, a Microsoft a standard módon javaslatokat fog benyújtani, hogy bekerüljenek a jQuery-be. A template-ekre ez már megtörtént, van is hozzá kísérleti plugin, majd jön a script loading, data binding stb.
  • A jQuery továbbra is open-source, platform- és gyártó független marad. A Microsoft a többi közreműködőhöz hasonlóan csak javaslatokat tesz, amiket a jQuery csapat vagy elfogad, vagy nem.
  • Bizonyára lesznek Microsoft specifikus részek (pl. WCF RIA Services, WCF Data Services), amik nem fognak bekerülni a jQuery-be, azok várhatóan egy jQuery bővítmény formájában lesznek elérhetőek. A kliens oldali típusrendszer várhatóan megszűnik.
  • Az ASP.NET részeként elérhető Ajaxos vezérlők (pl. UpdatePanel) továbbra is megmaradnak, az új verzióban a .NET 4-be beépített ASP.NET Ajax 4-re épülnek (ami nem épül a jQuery-re).

Hogy érezni lehessen a váltás súlyát:

“Developers on the ASP.NET team are now working full-time to contribute features to the core jQuery library.”



Balássy György (MS RD, ASP.NET MVP, MCTS)

Balássy György (MS RD, ASP.NET MVP, MCTS) Villamosmérnök, a BME Automatizálási és Alkalmazott Informatikai Tanszékén webportálok fejlesztését oktatja. 2000 óta foglalkozik a Microsoft .NET platformjával, melynek meghonosításában jelentős szerepet vállalt előadóként, konzulensként és A .NET Framework és programozása című könyv társszerzőjeként. Az MSDN Kompetencia Központon belül a Portál Technológiák Csoport vezetője, szakterülete web alapú rendszerek fejlesztése és üzemeltetése. 2004-ben Magyarországon elsőként kapta meg a Most Valuable Professional címet, majd 2005 óta a Microsoft magyarországi regionális igazgatója. Publikációi a Technet Magazinban, az MSDN Kompetencia Központ honlapján és szakmai blogjában olvashatóak.

2010.03.21. 19:49:46 | Permalink | Hozzászólások: 0 | Tárgyszavak: , , , ,


  • Gépelés saját kódból

    Dávid Zoltán A System.Windows.Forms névtérben van egy nagyon poén osztály: a SendKeys. Ennek segítségével billentyűleütéseket küldhetünk ki saját programból. Kiküldésre én a SendWait metódust használom. Ennek egy string a bemenete, melyet “begépel”. Az egyetlen kaland, ha speciális karakter vagy karakterek gépelését szeretnénk elvégeztetni: ilyenek a +, ^, %, ~ és () jelek. Ezeket { } közé kell tenni. Emiatt persze a { és a } kiírása is {{}-re és {}}-re bonyolódik. Tovább »
  • Kritikus 0day ASP.NET sebezhetőség és gyors védekezés

    Balássy György (MS RD, ASP.NET MVP, MCTS) Ahogy korábban már írtam róla, két hacker elég komoly hibát fedezett fel, amely az ASP.NET-es alkalmazások által használt titkosítást érinti. Sajnos a sebezhetőség részleteit csak pénteken hozták nyilvánosságra, ráadásul egy kész eszközt is közreadtak a kihasználására, sőt előtte a Microsofttal sem közölték a pontos módszert, így most a rossz fiúknak két teljes napjuk van, mielőtt a legtöbb webhely gazdája észbe kap (micsoda “véletlen” időzítés). Fontos, hogy a hiba alapvetően az összes ASP.NET-es webhelyet érinti, legyen az egyedi fejlesztésű, vagy kész rendszer, DotNetNuke vagy SharePoint ugyanúgy borulhat. Az üzemeltetőknek gyorsan kell lépniük! Tovább »


Írja meg Ön is véleményét!


Hozzászólásokat csak regisztrált, bejelentkezett felhasználóktól tudunk elfogadni!

Hozzászólások