Vlákno názorů k článku Úvod do jazyka Reason: varianty, pattern matching a ošetřování chyb od zivoslav - Seriál je výborný. Také jsem zasvětil cca 10...

To jsem z té původní věty o desetiletém hledání nevypozoroval. Jinak mi nepřipadá frontend ničím specifický, ale to je tím, že se dívám skrz prsty na celou koncepci webu, která je chybná a zpackaná od samého začátku.

Žádný HTML, žádný JavaScript, ale prostě jen nějaký bajtkód, který se transparentně stahuje a spouští na mém počítači, a velice primitvní protokol na přenos toho bajtkódu (+ cache a hash na ověření, zda je to vůbec nezbytné; formát dat mezi "klientem" a "serverem" by byla jejich vnitřní záležitost, pokud by byl v daném případě vůbec nutný jejich přenos). Jestli jen vytvoří aplikaci vypadající jako dnešní statická webová stránka, nebo se bude chovat jako plnohodnotná aplikace, či cokoli mezi tím, to už by záleželo čistě na autorovi takové internetové služby. Z jakého jazyka by se do toho bajtkódu překládalo nebo třeba i generovalo z nějakých programů, by taky bylo čistě na autorovi. Na straně "klienta" by nebylo třeba žádného prohlížeče, jen VM na stahování a spouštění toho bajtkódu + stáhnutelné cachované knihovny a konfigurátor, kde bych povoloval a zakazoval VM přístup k různým prostředkům na mém počítači apod. "Klient" v uvozovkách, protože by technicky šlo o peer2peer vztah. Jestli by šlo o server nebo o klienta nebo o obojí by záleželo jen na tom, jak by taková aplikace byla napsána.

Technicky jednoduché a ortogonální, neomezeně rozšiřitelné, podstatně omezující množství dat tekoucí sítí (kolik balastu v podobě nadbytečných a zbytečně ukecaných HTML tagů a JavaScriptu se každou sekundu naprosto zbytečně přelévá sem a tam internetem...), lépe využívající výpočetní výkon u klienta, žádné řešení statický/dynamický, stylů apod., žádné omezení plynoucí ze schopností prohlížeče - dynamická rozšiřitelnost založená na relativně bezpečných knihovnách v tom samém bajtkódu, nebo rizikovějších binárních knihovnách (včetně nějaké standardní knihovny náležející k VM, představující standardizované minimální API/UI) - možno řešit přes certifikáty, podobně jako dnes.

Vždyť celý počítač, který máš právě před sebou, ať už desktop, notebook nebo smartphone, je jeden velký prohlížeč + mnohem víc. Tak proč v něm spouštět ještě nějaký jiný prohlížeč (technicky/his­toricky vlastně jen grafický terminál) s omezenými schopnostmi, na který se pak složitě roubují různá rozšíření, která umožňují aspoň trochu se přiblížit schopnostem toho, na čem to celé běží? To je jak kdybych v bytě postavil bunkr z matraček a pak řešil, jak v tom bunkru udělat kuchyni, záchod, sprchu, druhé patro...
To, že někteří autoři a některé nejmenované firmy začali vzhled a chování normálních aplikací připodobňovat prohlížečům, považuji za vrchol perverze.

vm a nejaka standardni knihovna nalezejici k vm .. cili neco jako dnesni browser

Automobil? Podvozek a 4 kola .. čili něco jako dnešní koňský povoz.

Cili neco jako http://webassembly.org ?

Přesně tak, ovšem s vyřazením prohlížeče. Browser je podle mě historický anachronismus, zbytečný mezičlánek. Na formátování textu, zobrazování obrázků, vytváření a organizaci oken, kreslení v nich, realizaci prvků GUI atd. přece žádný hypertextový prohlížeč nepotřebujeme. To vše umí samotný OS. A domnívám se, že to byla zbytečná věc už v době vzniku na začátku 90. let. Z tehdejšího pohledu to byl jen kosmeticky vylepšený gopher, v podstatě grafický teletext, zatímco bylo bývalo možné se inspirovat v té době už existujícím X.

Proč by web měl být založen na ze své podstaty pasivním formátu, historicky určenému k přípravě tisku na papír? Proč by to nemohl být normální program, využívající zdroje OS jako kterýkoli jiný program?

Docela se divím, že někomu asi připadá normální a správné (soudě dle těch minusů), když se zobrazovač hypertextu (jako je třeba také klasické unixové info) postupně obohacuje o funkce, jako je možnost zadávat data od uživatele a vyhodnocovat je, spouštět nějaké skripty, až je z toho vlastně takový virtuální systém, z podstaty své výše naznačené evoluce naprosto nemožně navržený, včetně komunikačního protokolu, který byl původně jen značkovacím jazykem filosoficky vycházejícím z něčeho jako troff.

Opravdu mi to připadá podobné, jako kdybych u koňského povozu postupně koně nahradil parním strojem a nakonec traktorem, s jehož řidičem komunikuji pomocí elektronického biče, hvízdátka a mlaskátka, a povoz vylepšoval o odpružení kol, čalouněné sedačky a klimatizaci, místo abych celou tu koncepci konečně zahodil a vytvořil normální auto.

Já na tom teda nic geniálního nevidím a podle mě je to přesně naopak, než říkáš - i velmi jednoduché věci se ve webových technologiích stávají dost komplikovanými.

Nejdřív degradovat počítač na terminál k prohlížení elektronické knihy a pak tento terminál pomocí různých rovnáků na ohejbáky zase postupně obohacovat zpátky na něco, co se chová jako virtuální stroj, a data a kód si s tím vyměňovat pomocí něčeho, co bylo určeno k zápisu té elektronické knihy - protože, jak už tu bylo poznamenáno, dnešní browser v podstatě představuje taky takový virtuální stroj, akorát neskutečně blbě koncipovaný, zbytečně složitý a šíleně neefektivní.

Že něco bylo převálcováno něčím jiným, nedokazuje vůbec nic. Betamax byl taky převálcován VHSkem, OS/2 MS-DOSem, Motorola Intelem...

V čem přesně má spočívat ta výhoda a genialita, že na použití webu potřebuji mimo OS ještě moloch zvaný prohlížeč, který chroustá turingovsky neúplný statický popis hypertextové stránky, který i přes svou značnou komplikovanost stejně není (a ze své podstaty nikdy nemůže být) ve svém standardu schopen vyhovět dnes již ani průměrným požadavkům na weby, pročež je nutné jej generovat dynamicky v serveru a rozšiřovat jej o všelijaké CSS, JavaScript apod., což není nic jiného než právě ty rovnáky na ohejbák, a k praktické realizaci pak tento prohlížeč stejně volá služby OS?
Třeba mi něco uniká, rád se nechám poučit, ale - nic ve zlém - vážně by mě zajímalo, jak něco tak debilního může být vnímáno za geniální.

Jakou výhodu to má oproti tomu, když by např. tento portál byl tvořen programem, který všechny ty rámy, textboxy, tlačítka, labely, menu, reklamy, odkazy atd. zobrazí přímo, bez nějakého browseru, prostředky OS ve svém okně, při zadání URL by se akorát zkontroloval nějaký hash, jestli se ten program nezměnil a pokud ne, jen by se vytáhl z cache a ze serveru by si stáhl akorát konkrétní data v nějaké své proprietární binární podobě?
Prostě bych ten web naklikal podobně jako GUI kterékoli jiné aplikace ve svém oblíbeném designeru, dopsal kusy kódu ve svém oblíbeném jazyce (pokud by bylo vůbec nezbytné nějaký kód přidávat - u statických "stránek" asi ne), zkompiloval, zveřejnil, uživatel zadá URL, kód webu se stáhne (a jak tak koukám na zdroják těchto stránek, byl by ten bajtkód mnohonásobně kratší), dynamická data si dososne ve formátu a způsobem, který mu vyhovuje nejlépe - a hotovo. Na co browser, na co HTML, na co CSS, na co JavaScript, na co PHP...? Ani jedno na vytvoření takovéhoto portálu ve skutečnosti nepotřebuji. Nějaký statický popis stránky či stylu může být součástí dat nějakého programu. Ale aby byl program součástí statického popisu stránky - to je návrh principiálně broken by design. Asi jako bych si v OOP nejdříve vyrobil konkrétní třídu "hypertextová kniha" a pak se rozhodl z ní odvodit třídu "dynamická interaktivní aplikace". Ne že by to technicky nešlo, jen je to neskutečně blbý a po všech stránkách nešikovný postup.

"pročež je nutné jej generovat dynamicky v serveru........ Nějaký statický popis stránky či stylu může být součástí dat nějakého programu. Ale aby byl program součástí statického popisu stránky - to je návrh principiálně broken by design." - Četl jste článek, pod kterým diskutujeme? V Reactu je popis stránky generován programem na klientu.

"Na co browser, na co HTML, na co CSS, na co JavaScript, na co PHP...?" - javascript použít nemusíte. Diskutujeme pod článkem o Reasonu. Mezi mimifikovaným javascriptem a bytekódem je malý rozdíl.

"Prostě bych ten web naklikal podobně jako GUI kterékoli jiné aplikace ve svém oblíbeném designeru" - výstupem toho designéru bude pravděpodobně nějaký XML popis, stejně ukecaný jako HTML. GUI designéry existují i pro HTML, je to použitelné jen pro jednoduché statické formuláře.

mmm:

Popis stránky generován programem na klientu... A proč vůbec něco generovat? Je to úplně zbytečný krok. Když zapomenu na celý ten koncept webové stránky a nahradím ho normální aplikací, tak přece nemusím nic generovat. Webová stránka je totiž speciálním typem aplikace (ve své původní variantě by se vlastně dala popsat programem print"Obsah stránky"). Proto je tak komplikované obohacovat webovou stránku o schopnosti, jež mají normální aplikace.

Ve skutečnosti by nebylo třeba použít nic z toho mnou jmenovaného.

Pro boha proč XML? To se tu opravdu nikdo nedokáže oprostit od všech těch příšerných stereotypů, na něž si zvykl, ale které ve skutečnosti k ničemu nepotřebuje? Když jsem psal, že browser look normálních aplikací je perverze, pak celé XML je podobná perverze. Výstupem toho designéru samozřejmě nebude žádné XML, ale normální bajtkód programu, který se spustí na klientovi. Co do velikosti bude podstatně menší, protože u XML na každý bajt informace připadá deset bajtů XML balastu. To se dá překousnout u lokálního popisu nějaké konfigurace, ale šoupat to smetí sem a tam internetem je šílenství!
No právě, že ty současné designéry jsou zcela zbytečně použitelné jen pro jednoduché statické stránky. Protože problém je v samotné podstatě - není problém něco, co je principálně dynamické, udělat statickým. Ale statickou věc dynamizovat, to je fuška. S obytným autem prostě nebudu jezdit, když nebudu chtít. To je jednoduché. Ale postavit si zděný domek a pak se rozhodnout, že bych vlastně chtěl, aby se mohl přemísťovat z místa na místo, to není úplně optimální a jednoduché. Jenže to je přesně ta cesta, po níž se vydaly webové technologie. Je to ze samotné podstaty slepá ulička, proto jakýkoliv rozvoj technologií nějak založených na tomto principu je ztrátou času - je to totiž celé od základu špatně. Podobně jako byly od základu špatně první elektromotory, inspirované principem parního stroje.

Ale to bylo jen takové malé zamyšlení a povzdechnutí nad tím, jak je možné, že si toho všimlo tak málo lidí, a že si na tuto na hlavu postavenou věc všichni zvykli natolik (někteří ji dokonce považují za geniální), že si to ani jinak už neumějí představit a nadále se věnuje čas a energie do udržování tohoto mrtvě narozeného dítěte ve vegetativním stavu na přístrojích, za cenu neuvěřitelného plýtvání lidskými, výpočetními, síťovými a v důsledku energetickými zdroji.
Ze své strany bych to uzavřel. :)

React programově generuje DOM. HTML se neposílá, ani negeneruje. Celý popis máte v javascriptu, který je mimifikován téměř do podoby bytekódu. Nevidím velký rozdíl oproti vámi navrhovanému řešení.

v čem by byl ten váš systém lepší?