Diskuze: Diskuze o web technologií
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 7 zpráv z 7.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Ty problémy s Blazorem by mě docela zajímaly. Nějakou dobu s tím už dělám, zatím jsem na nic vážného nenarazil. Nejméně příjemné věci jsou podle mě chybějící podpora hot-realoadu a špatná podpora dynamických komponent. Obojí je vyřešeno v .NET 6, které má myslím vyjít v listopadu. Už nemám potřebu a ani nechci dělat v budoucnu web v něčem jiném, po prokousání node js a angularem jsem konečně našel technologii s velkým T. Takže jak mluvíš o tom příjemném vývoji - dlouho jsem ho taky hledal, a Blazor zatím jednoznačně vítězí.
Ahoj, diky za odpověď. Četl jsem například, že pokud potřebujes doplnit js, tak je to celkem neprijemny. Ale mozna uz je to ted v novych verzich opravene. A pouzivas server side a nebo wasm?
WASM jedině v případě, že je potřeba oddělit klienta od serveru a
propojit je přes API. Pak možná ještě na realtime hry (i když tady fakt
blazor, angular a podobní nemají smysl vůbec). Jinak vesměs zbytečné.
Dříve jsem byl skeptický vůči server side kvůli odezvě, ale praxe
ukázala, že je více než dostačující a žádné zpomalení ve srovnání s
WASM nepociťuji, právě naopak, mnohem rychleji se web načte.
Samozřejmě když budeš dělat web pro miliony uživatelů, tak možná
raději šáhneš po WASM a API, abys převedl výpočetní výkon na
uživatele. Každé se prostě hodí na něco jiného.
Pokud potřebuješ doplnit js, zpravidla to děláš jen občas. Nevím jestli je to nepříjemné, podle mě to nijak hrozné není, ale i kdyby bylo, je to stále až poslední řešení. Je pravda, že v C# nenajdeš tolik frontendích knihoven jako v JS, ale to důležité už většinou pokryté je, např. integrace google recaptcha nebo tinymce editor. Oni vnitřně sice JS využívají, ale vystaví ti Blazor komponentu a nemusíš nic extra řešit.
Rozumím. Taky jsem byl trochu skeptický co se týče server side aa jeho
výkonu, ale pokud je to takhle v pohodě, tak to asi zkusím. Chápu, že pokud
budu mít milion lidí, tak je vždycky lepší api a nějakej frontend, ale
myslím, že zatím apky pro milion lidí dělat nebudu. Díky moc zkusím mu dát šanci
na jednom projektu a prostě uvidím
Taky další věc je, že záleží na kvalitě serveru. Já mám k dispozici dobrý server s dobrou sítí a šlape to bez problému, stránka reaguje prakticky ihned. Samozřejmě nevím, jak to bude, když to pak nahraješ na nějaké servery typu webzdarma a podobné.
Já třeba mimo jiné preferuji Blazor, protože moc nemusím JS a líbí se mi prostě ta myšlenka C# všude. Zkus no a uvidíš, je však třeba věnovat hodně času dokumentaci a pořádně pochopit, jak to funguje.
TLDR: Server-side rendering není problém, pokud lze aplikace replikovat a
zátěž distribuovat.
Ono výkon v případě server-side renderingu se prostě pro velké weby
řeší několika instancemi a load balancingem. Nemusí člověk živit jeden
velký server (lterý ještě navíc může spadnout), ale má několik
menších serverů a zátěž distribuuje mezi ně.
Má to háček a to že s tím aplikace musí počítat. Samotná aplikace musí
fungovat state-less (protože další požadavek může přijít na jiný
server) a tak například sesion se typicky řeší před externí rychlou
služby (například Redis). Potom je otázka, jak moc škálují ty služby na
pozadí, protože pokud na relační databázi pálí 100 instancí tak to
nemusí zvládat sama o sobě (například DynamoDB od AWS je děláno na velké
zátěže).
Zobrazeno 7 zpráv z 7.