Protože se náš prezident k ulehčení národa rozhodl, že nebude mít novoroční projev, zbylo to na mne. A protože společenskou a politickou situaci bych musel hodnotit slovy, které se nehodí užívat ve slušné společnosti, budu se zabývat ASP.NET a tím, co nás čeká. V dobrém i zlém, v nastávajících verzích, v nastávajících letech.

Vycházím přitom z toho, jak se ASP.NET technologie vyvíjela v minulosti a na čem týmy v Microsoftu pracují a co publikují. Nevycházím přitom z žádných tajných interních informací; Microsoft je poslední dobou čím dál otevřenější a většina věcí je prostě na GitHubu. Mohu se samozřejmě mýlit, a v některých případech bych byl rád, kdyby se ukázalo, že jsem se mýlil.

Více open source

Většina novinek v.NET Frameworku je open source. Některé tak přímo začaly. Třeba SignalR byl původně soukromý projekt pár lidí z Microsoftu. Nyní je oficiální a podporovanou součástí ASP.NET, ale jeho zdrojáky nadále najdete na GitHubu.

Oproti tomu Entity Framework začal svou životní dráhu jako proprietární technologie uvnitř Microsoftu, ale později byl také vypublikován, pro změnu na CodePlexu.

Oba dva tyto projekty (a řada dalších) přitom jsou plnohodnotným open source. Nejedná se o žádné „look, but don’t touch“, ale jsou licencovány pod Apache licencí, takže můžete třeba vytvořit vlastní odnož a dále ji šířit. A akceptují pull requesty, takže pokud najdete nějakou chybu, nebo vám chybí nějaká feature, můžete ji doprogramovat a může se stát součástí další verze.

Znamená to také ještě méně tajemství. Za těch deset let, co jsem MVP, se Microsoft hodně změnil. Řada věcí, které dříve byly neznámé nebo jenom pod NDA, je dnes volně diskutovaná na blozích a ve veřejně držených ticketech.

Častější aktualizace

Doba, kdy Microsoft vydal novou verzi Visual Studia, .NET Frameworku, Windows a SQL Serveru a pak od něj byl na pár let pokoj, je minulostí. Aktualizace Visual Studia a vývojových technologií nyní vycházejí každé tři měsíce. Řada technologií je navíc aktualizována průběžně, mimo pravidelné release cykly.

Typickým případem je třeba Entity Framework. Zatímco první verze byly svázány s verzemi .NET Frameworku, nyní jsou uvolňovány zcela samostatně. V důsledku toho je stále důležitější balíčkovací systém NuGet, protože většina Microsoftích knihoven pro .NET je publikována primárně (nebo výhradně) přes něj.

Častější aktualizace mají své výhody i nevýhody. Výhodou je, že se rychleji opravují chyby a přidávají nové vlastnosti (viz také pull requesty výše). Nevýhodou je, že rychlé změny velká část vývojářů nestíhá sledovat a reagovat na ně.

Upřímně řečeno, sledovat jejich celou šíři nezvládám ani já, a to je to v podstatě mou hlavní pracovní náplní. Běžný programátor, jehož hlavním úkolem je vytvářet a rozvíjet nějakou aplikaci, má na nějaké učení se a sledování novinek ještě podstatně méně času. Velice často se setkávám s lidmi, kteří programují pomocí technik a nástrojů aktuálních v ASP.NET 2.0. Zatímco existuje Entity Framework 6 a Code First a Migrations a NoSQL a „elita“ se dohaduje, jak to dělat nejlépe, celé zástupy lidí stále ještě píší SELECT * FROM Tabulka a nejnovějším výkřikem technologie jsou uložené procedury.

Konec WebForms

Přestože tady máme ASP.NET MVC a Web Pages, ASP.NET Web Forms pořád ještě tvoří drtivou většinu (různé zdroje hovoří o 85-95%) všech vyvíjených ASP.NET aplikací. Neodpovídá tomu nicméně množství péče, kterou jim Microsoft věnuje. Posledního zásadního upgradu se tato technologie dočkala v ASP.NET 4.0 a nevypadá to, že by se na tom mělo něco změnit. Podpora v toolingu je na tom stejně mizerně.

Typický příklad: Visual Studio 2013 má nový editor HTML, s řadou zajímavých funkcí. Jenomže nefunguje pro Web Forms. Pokud editujete ASPX/ASCX stránku, použije se stará verze editoru, s jenom kosmetickými změnami. A v dohledné době se žádná změna téměř jistě nechystá. Vše nové, co ASP.NET team plánuje, je postaveno okolo Web Pages a MVC. Na Web Forms se buďto nedají naroubovat vůbec, nebo jenom dost obtížně.

Je pravda, že současná implementace Web Forms je poplatná době svého vzniku a řeší problémy, které dnes již nejsou aktuální. A zasloužila by si výrazné překopání a v některých ohledech zjednodušení. Stejně tak je pravdou, že mnoho programátorů ve Web Forms neskutečně prasí, protože je nepochopili. Myslím si ale, že tato skupina bude prasit v čemkoliv, bez ohledu na nástroje.

Myslím si, že ASP.NET Web Forms nezemřou. Rozhodně ne v nejbližších pěti nebo deseti letech a nejspíše nikdy. Na to jsou moc rozšířené. Moc dobré na některé typy aplikací. Ne na vzrušující sexy aplikace úžasných sociálních startupů, které chtějí změnit svět (a za dva roky je buďto koupí Google nebo Facebook, zruší je a už o nich nikdo neuslyší, nebo je nekoupí a taky o nich už nikdo neuslyší). Ale na aplikace, které lidé a firmy skutečně potřebují a používají. Možná ne rádi a úplně dobrovolně, ale někdo ty line-of-business aplikace s nudnými tabulkami dělat musí.

Web Forms by si zasloužily úplně novou verzi. Která by využívala stejnou principiální filozofii komponent (která je známá spoustě lidí a je svým způsobem unikátní), ale byla jednodušší a modernější. Microsoft se nicméně zdá se rozhodl jinak.

Neříkám, že je nutné okamžitě se překotně začít učit Razor a MVC. Soudím, že většina současných programátorů si s Web Forms vystačí až do důchodu. Ale budou dostávat stále méně a méně novinek a zásadních vylepšení se nejspíše už nedočkáme, protože se Microsoft soustředí na jiné věci.

Je otázka, zda se sázka na novinky Microsoftu vyplatí. Přechod z Web Forms na MVC bude pro řadu programátorů velmi náročný, protože se jedná o úplně odlišnou filozofii. A Microsoft jim to navíc rozhodně neulehčuje. A zatímco Web Forms jsou unikátní, MVC jsou jenom x-tá další implementace téhož, takže programátoři se mohou snadno rozhodnout, že když už učiní takový skok, nedrží je nic na .NET platformě jako takové, mohou se učit třeba Python, Ruby nebo Node.js. Tím spíše, že to budou v řadě případů vnímat jako zradu ze strany Microsoftu.

MVC a Web Pages mají s Web Forms společné základy a mnoho principů je přenositelných. Myslím si ale, že dostatečně hluboké porozumění technologii má jenom málo programátorů a většina z nich je těm základům natolik vzdálena, že tu blízkost neocení.

Nejpravděpodobnější je, že ASP.NET Web Forms čeká v dlouhodobém horizontu podobný osud, jako Visual Basic 6.0: vysmívaný jako ohavný a nemoderní, pohrdaný „opravdovými programátory“. Ale přesto masově používaný, protože je prostě „good enough“. A stále oficiálně podporovaný, protože je v něm napsáno tolik aplikací, že si ho Microsoft prostě nemůže dovolit jenom tak „zaříznout“.

Přestože poslední verze klasického Visual Basicu vyšla před patnácti lety, pořád je běh aplikací v něm napsaných oficiálně podporován i ve Windows 8.1 – a bude až do konce jejich životnosti, tedy nejméně dalších deset let. Řada technologií mezitím vyrostla a zanikla a podporována není (včetně prvních verzí .NET Frameworku). Visual Basic 6.0 ovšem je nejspíš nesmrtelný. A stále má dosti živou programátorskou obec a obchod s komponentami pro něj stále kvete.

Konec VB.NET

Oproti tomu, .NETová verze Visual Basicu mele z posledního. Nejde o podporu ze strany Microsoftu, ale spíš o nezájem programátorské veřejnosti, který mimo jiné vede i k nedostatku jakýchkoliv článků, příkladů a podobně.

Vypadá to, že mouřenín vykonal své dílo, tedy usnadnit programátorům znalým VB a VBScriptu přechod na .NET. Ti, kteří nepřešli doteď tak nejspíše neučiní nikdy a mouřenín bude moci odejít.

Více kódu, méně modelů a konfigurace

Dosavadní verze .NETu byly proslulé velkým množstvím souborů, které nebyly kódem. Soubory s podivnými příponami jako .config, .sitemap, .browser, .dbml, .edmx… Většinou obsahují hromadu XML kódu, který deklarativně popisuje cosi.

V případě .config souborů pak platí, že aplikaci nejenom konfigurují, ale v podstatě též definují. Konfigurace říká, jaké HTTP moduly, handlery, providery a další udělátory jsou součástí aplikace. DBML a EDMX soubory zase vytvářejí vrstvu pro přístup k datům a z nich se automaticky definuje kód, který umožní pracovat s databázovými daty. To vše, aby bylo možné aplikaci sestavit z hotových bloků, možná i nějakým grafickým designérem, bez nutnosti psát kód a rekompilovat.

Nové technologie naopak počítají s tím, že budete psát kód. Spoustu kódu.

Jednodušší kód

Ten kód bude ale mnohem jednodušší. V řadě případů nebude nic „opravdového“ dělat, ale bude plnit funkci, kterou dříve plnila konfigurace a modely: bude deklarativně definovat cosi, spojovat jiné komponenty.

Typickým příkladem je třeba Entity Framework Code First. Rozsáhlejší modely sice vyžadují spousty kódu, ale opravdového C# a „skutečného programování“ tam mnoho není. Jde jenom o prázdné třídy, které mají hromadu nic nedělajících vlastností, u nichž jsou důležité jenom názvy, typy a hromada atributů v hranatých závorkách.

Automaticky generovaný kód nahrazuje i nástroje a GUI. Jestliže dříve se u správy databázových verzí počítalo se zvláštním typem projektu (Database Projects) a bohatým toolingem, dnes jsou v kurzu Code First Migrations. Změnové příkazy se sice vygenrují automaticky, ale pořád se jedná o obyčejný C# kód, který můžete upravit k obrazu svému.

Dalším příkladem je architektura OWIN a její implementace Katana. Hlavním cílem je umožnit, aby hosting ASP.NET aplikací (zejména Web API a SignalR) nebyl tak těsně svázán s IIS. OWIN definuje poměrně jednoduché rozhraní, které umožní hostovat webové aplikace v podstatě kdekoliv. A, co je velice podstatné, předpokládá, že kompletní definice a konfigurace aplikace bude v kódu, že místo HTTP modulů a handlerů ve web.configu bude aplikaci skládat startup class voláním extension metod. Inspirace Node.js je zjevná a zcela přiznaná.

Stejně jako další změny, i tato má své pozitivní a negativní stránky. Výrazným pozitivem je, že si prostě vystačíte s C#. Netřeba se učit žádné jiné formáty, jazyky, netřeba vytvářet žádné sofistikované nástroje, designéry… All in code, baby.

Nevýhodou je, že programátoři budou mít reálně stále menší kontrolu nad tím, co vlastně dělá kód, který napíší. Jistě, stačí zavolat „EnableFacebookAuthentication“ a magicky to začne všechno fungovat. Nebo použít vestavěnou šablonu, ve které už je všechno hotové. Nicméně, jak konkrétně to vlastně funguje, to se už běžný programátor nedozví a nebude nad tím mít přímou kontrolu. Přitom, paradoxně, právě touha dát programátorům přímou (ne nutně větší) kontrolu nad chováním aplikace vede k preferenci Web Pages a MVC na úkor Web Forms.

Jiný způsob dokumentace

Převratné změny, které nás čekají a které už nastávají, doprovází bohužel také slušný chaos v dokumentaci. Doby, kdy se jeden mohl spolehnout, že vše podstatné najde v MSDN Library, jsou minulostí. Dokumentace k různým částem ASP.NET je tu na GitHubu, ondy na blogu, jindy zase ve Wiki přináležející tomu kterému projektu… A programátor musí vědět nebo zoufale hledat.

Ještě víc alarmující mi přijde nedostatek komplexnějších materiálů, prezentujících problematiku s jistým odstupem. Ke každé technologii najdete na www.asp.net pár tutoriálů, jak snadno a jednoduše udělat Hello World a možná ještě Northwinnd. A pak vás hodí do vody a programátore plav, jak jenom umíš. Vysvětlení týkající se architektury, důvodů proč jsou věci udělané tak, jak jsou a kudy se předpokládá, že se vydáte, už nenajdete. Nebo ho musíte složitě hledat na různých blozích autorů a schované v různých videích a webcastech, pročež se musíte podívat na hodinu záznamu, abyste pochopili, co je možné vysvětlit ve třech odstavcích psaného textu. Ve chvíli, kdy vy se učíte verzi 1.0, její autor nemá čas k ní psát dokumentaci, protože už píše betu verze 2.0.

To je, podle mého názoru, druhá zásadní zrada, které se Microsoft na svých programátorech dopouští. Dosud kvalitou dokumentace vyčníval nad konkurencí rozdílem třídy. Vývoj nebyl možná tak rychlý, ale zato byl jasný a dokumentovaný. Bohužel, nevypadá to, že tomu tak bude i nadále.

Bráno kolem a kolem, jsou to skvělé zprávy pro programátorskou elitu, která chce věci dělat správně, elegantně, sexy způsobem. Která je znuděná tím, že píše po sto padesáté sedmé to samé a hledá nové a vzrušující cesty, jak to dělat jinak a zajímavěji.

Bohužel, jsou to špatné zprávy pro ty, které Scott Hanselman nazývá „temnou hmotou“. Pro tu neviditelnou masu, která prostě píše kód tak dobře, jak to jenom dovede. A není slyšet, protože nepíše blogy a nemá projekty na GitHubu. Protože na to nemá čas: musí programovat a vyvíjet systémy, které sice možná bezprostředně používá pár desítek nebo stovek uživatelů, ale v konečném důsledku na nich závisí milióny lidí. Systémy, o kterých neví nikdo mimo jejich uživatelů. Protože je to prostě jejich práce; píšou kód, stejně jako jiní lidé pečou housky, prodávají v obchodě, pilotují letadla nebo opravují auta.

Kolik blogů automechaniků znáte? A kolik webů, kde radí jiným automechanikům, jak věci dělat lépe? Existují, ale dělá je jenom malá menšina, můžeme jí říkat elita. Ta většina nemá čas, musí opravovat auta.

Můžeme samozřejmě arogantně prohlásit, že každý programátor by měl mít blog. A odpovídat na otázky na StackOverflow. A mít účet na GitHubu. A sledovat novinky. Jinak to není opravdový programátor. Možná je to nakonec i pravda, protože řada lidí, kterých se to týká, jsou programátoři z donucení. Potkal jsem a učil skupinu strojních inženýrů, které nouze naučila programovat. Vyvinuli velice komplexní systém pro vývoj a testování strojních produktů, který nakonec používá celá obrovská nadnárodní korporace. Prostě proto, že mají tu „domain specific knowledge“, kterou prostě není možné efektivně a rychle předat nějakému profesionálnímu programátorovi. Viděl jsem jejich kód a podle všech myslitelných programátorských měřítek je příšerný. Přesto je ale to nejlepší, co existuje.

Veškeré snahy nechat to napsat pořádně někým zvenčí prostě zkrachovaly. Protože je jednodušší naučit strojního inženýra programovat, než programátora mechaniku. To mohu ostatně potvrdit z vlastní zkušenosti, na průmyslovce se mě to snažili naučit. V pololetí jsem propadl a na konci roku prolezl se čtyřkou nekonečnou slitovností Boha všemohoucího a inženýra Tomáška, kterému tímto s bezmála dvacetiletým odstupem děkuji. To je důvod, proč je řada specializovaných programů z různých obskurních oborů psána takovým… svébytným způsobem. Protože je prostě nepsali programátoři.

Microsoft byl a je pro tuto „temnou hmotu“ programátorů z leknutí velkou nadějí. Novinky je nejspíše nepotěší. Na druhou stranu, adopce novinek touto skupinou je tak pomalá, že možná Microsoft mezitím vymyslí něco dalšího, co budou moci používat. Dum spiro, spero.