Framework vs. čistý kód

[Kit]

Pokud framework vnucuje styl chybně, jde o chybně vybraný framework.

Když se jedná o Nette, tak nikoho nezajímá, že je špatně vyprojektován.

[Reklama]

[Ondřej Surý]

Tady nikdo nezpochybňuje používání knihoven, které napsal někdo jiný. Řeč je o frameworcích, které nutí vývojáře pracovat stylem, který mu ten framework vnucuje a často i chybně.

Framework je jenom sada knihoven. OpenSSL mne taky nutí pracovat nějakým stylem (1 je OK, 0 je chyba, -1 je větší chyba, což je na hlavu, protože většina knihoven má 0 jako OK), libuv mne nutí pracovat nějakým stylem (asynchronní callback hell), userspace-rcu mne nutí pracovat nějakým stylem (read-copy-update, deferred memory reclamation, hash-tabulka má nějaké konvence).

Ale všechno tohle jsem si buď vybral a adaptoval (případně dokonce něco z toho stylu přešlo i do zbytku kódu) nebo je to nějaký kompromis, který mi umožňuje se věnovat věcem, které jsou pro projekt důležité a moje expertíza je v těchto oblastech mnohem větší.

[Kit]

Tady nikdo nezpochybňuje používání knihoven, které napsal někdo jiný. Řeč je o frameworcích, které nutí vývojáře pracovat stylem, který mu ten framework vnucuje a často i chybně.

Framework je jenom sada knihoven. OpenSSL mne taky nutí pracovat nějakým stylem (1 je OK, 0 je chyba, -1 je větší chyba, což je na hlavu, protože většina knihoven má 0 jako OK), libuv mne nutí pracovat nějakým stylem (asynchronní callback hell), userspace-rcu mne nutí pracovat nějakým stylem (read-copy-update, deferred memory reclamation, hash-tabulka má nějaké konvence).

Ale všechno tohle jsem si buď vybral a adaptoval (případně dokonce něco z toho stylu přešlo i do zbytku kódu) nebo je to nějaký kompromis, který mi umožňuje se věnovat věcem, které jsou pro projekt důležité a moje expertíza je v těchto oblastech mnohem větší.

Asi máme na mysli různé frameworky, protože pokud je to jen sada knihoven, tak s tím nemám problém. Opravdu nemám ambici reimplementovat OpenSSL a raději ho použiji jako blackbox, který si případně obalím dekorátorem, který mě odstíní od zmíněných 1, 0, -1 a nahradí je například výjimkou, která je mnohem užitečnější.

Byla zde řeč hlavně o frameworcích, které určují styl práce podle pravidel, která se občas mění, jak se autor zrovna vyspí.

[Standa Blábol]

Každý framework má nějaké části, které nejsou ideální, někdy i úmyslně z důvodu, že se jedná o experimentální složku frameworku a vy jste testeři.

Nebudu tady říkat, co třeba má Spring, se kterým denně dělám, ať se tu zase nepřetahuju zbytečně s Jirsákem.

Mimochodem, není tak velký rozdíl v principu používání mezi Reactem a třeba vanilla PHP. Těch rozdílů není zase tolik, jak by se mohlo zdít, když je mým cílem udělat fungující web. Hlavní a zásadní rozdíl vidím v tom, že React mi umožňuje definovat model pro moje formuláře (tím je JS objekt), kdežto v PHP musím ručně vepisovat "name" atributy (definuju si je jako konstanty).

V Javě to nebyli schopni něco podobného udělat až do vzniku Thymeleafu, a i Thyemeleaf má problémy s fragmaenty a jejich podporou v IDE, kde pro takto zásadní a elementární věc nefunguje ani našeptávání parametrů do fragmentu. To mě brutálně točí.


A proč to říkám a proč mě to tak sejre. Protože tím, že všechno to byly kompromisní technologie, kde jedna měla haprující to a druhá zase ono, tak kvůli tomu je všechny převálcoval React, který má vesměs všechno Done right. A jeden z důvodů, proč je React všechny převálcoval, jsou "ty kecy a kydy" co se tady dlohá desetiletí šířily, že backing kód musí být v separátním souboru, a do template si musím všechno připravit předem a ani Math.round si tam asi nesmím v tom template zavolat. Jedním ze šiřitelů těchto polopravd a frází je mimochodem i Jirsák.

Heh, to je ale snuska blabolu. Jojo, dokud Pivotal neprisel s Thymeleafem, nic jako JSTL (defacto to samy jako Thymeleaf, ktery prinesl jenom jednodussi syntaxi) neexistovalo. A JSF2 taky neexistuje.
A widgety taky neexistujou, Apache Wickets je dilo heretiku.
A treba JSF2 widget library Primefaces, tady mas jednu nahodne vybranou komponentu na ukazku
https://showcase.primefaces.org/ui/menu/menubar.xhtml?jfwid=cb934

V realu se React rozsiril z jedineho duvodu, a to ze je v javascriptu spustitelnem v browseru, tedy vhodny pro client-side SPA aplikace a rozsiril se jenom proto, ze byl prvni.
Jinak je Ract naprosty otres navrzeny magory, co v zivote o computer science neslyseli, eco jako useEffect() muze vymyslet jenom jouda, co v zivote nevidel jediny navrhovy vzor...

Naproti tomu pozdeji vznikle VUE bylo navrzeno clovekem s prislusnym vzdelanim a VUE3 se "script-setup" syntaxi, typescriptem, k tomu Vue router a Pinia je uz velice slusny stack, co neurazi cloveka s alespon matnyM tusenim o computer science...

 

[to_je_jedno]

Byla zde řeč hlavně o frameworcích, které určují styl práce podle pravidel, která se občas mění, jak se autor zrovna vyspí.

Zkus nejaky priklad. Nebo zkus najit co je tak spatne treba na Symfony. Myslim jako skutecne spatne a ne ze se to jen zrovna nelibi tvemu genialnimu mozku, ktery je ten spravny na znovuvynalezani kola v implementaci kterou nikdo dalsi nikdy nevyuzije.

[Reklama]

[BlackMagic]

co je tak spatne treba na Symfony

Třeba to, že když chceš v UI nějaký přeložený string, tak v Symfony je na to objekt.

Kód: [Vybrat]

$translator->trans('Symfony is great');
https://symfony.com/doc/current/translation.html

Zatímco třeba Drupal na to má funkci, čili výrazně kratší zápis.

Kód: [Vybrat]

t('Drupal is great');

[makovec_3]

co je tak spatne treba na Symfony

Třeba to, že když chceš v UI nějaký přeložený string, tak v Symfony je na to objekt.

Kód: [Vybrat]

$translator->trans('Symfony is great');
https://symfony.com/doc/current/translation.html

Zatímco třeba Drupal na to má funkci, čili výrazně kratší zápis.

Kód: [Vybrat]

t('Drupal is great');

A v čem je ta výhoda?

[Ondřej Surý]

co je tak spatne treba na Symfony

Třeba to, že když chceš v UI nějaký přeložený string, tak v Symfony je na to objekt.

Kód: [Vybrat]

$translator->trans('Symfony is great');
https://symfony.com/doc/current/translation.html

Zatímco třeba Drupal na to má funkci, čili výrazně kratší zápis.

Kód: [Vybrat]

t('Drupal is great');

A v čem je ta výhoda?

Ušetřených 17 písmenek, které nebudou muset ve Vietnamu vyrobit čínské děti...  nebo tak něco

[skopda]

Dobrý programátor by měl být schopen rozeznat jaký je rozsah projektu, kolik času chce projektu věnovat a podle toho se rozhodnout jestli framework použít nebo ne.
Příklady:
- Když budu psát jednoduchou konzolovou aplikaci na 100 řádků, tak asi framework nepotřebuju.
- RealTime záležitosti v embedded systémech, nebo věci velmi náročné na optimalizaci z důvodu výkonu, kde se každý clock cycle procesoru počítá - tady frameworky ne - ale je hodně okrajová věc a nejspís mimo scope původního dotazu.
- u webových a databázových věcí naopak ve vetšině případů dává smysl používat framework. To co bych sám programoval týdny na tisíce řádků kódů tak s frameworkem udělám na 100 řádků za pár hodin.
- Framewroky mají taky svoje výhody, často řeší abstrakci (třeba nad různými DB servery) nebo řeší spoustu věcí kolem kompatibility a bezpečnosti.
Programátor co tvrdí, že si vše raději napíše sám a potřebuje znát každý řádek kódu tak je mentálně zamrzlý v 90tých letech.  Ve chvíli kdy chcete budovat komplexní aplikace tak je potřeba nějaká úroveň abstrakce protože není v kapacitě lidského mozku aby rozumněl všemu.
Zkušenost s assemblerem nebo C++ se hodí, ale spíše na low level debug nebo pro představu že takový jeden řádek ve stylu array.Sort(); udělá na pozadí třeba miliony instrukcí.
Embeded se ještě programuje v C++ ale cokoliv jiného už přešlo na vyšší programovací jazyky.

[Filip Jirsák (forum)]

Heh, to je ale snuska blabolu.

Ale je to marný, je to marný, je to marný – stejně je bude opakovat pořád dokola.

Jojo, dokud Pivotal neprisel s Thymeleafem

Pivotal nemá s Thymeleafem nic společného, pokud vím.

V realu se React rozsiril z jedineho duvodu, a to ze je v javascriptu spustitelnem v browseru, tedy vhodny pro client-side SPA aplikace a rozsiril se jenom proto, ze byl prvni.

React zdaleka nebyl první. Angular byl dřív, ještě před nimi byla starší generace jako Knockout, Ember, Backbone, ještě před tím Dojo Toolkit. A další, vyjmenoval jsem jen pár zástupců.

Jinak je Ract naprosty otres navrzeny magory, co v zivote o computer science neslyseli, eco jako useEffect() muze vymyslet jenom jouda, co v zivote nevidel jediny navrhovy vzor...

Kdyby to bylo tak hrozné, nepoužívalo by se to. Všichni programátoři, co to používají, nejsou magoři. Jazyky/frameworky, které jsou z pohledu programátora založené na pár jednoduchých principech, jsou docela oblíbené – Java, React… React například donutil (a usnadnil to) programátory řešit stavy načítání dat, což výrazně přispívá dobrému UX. Předtím to všichni lidé s příslušným vzděláním ignorovali a čekali, že si to každý programátor hezky odprogramuje od nuly, a nebo prostě bude uživatel koukat na bílou obrazovku a čekat, co bude.

Kupodivu vyhrávají jazyky a frameworky, které jsou kompromisem mezi computer science a pragmatickým přístupem. A nemyslím si, že by při návrhu Reactu chyběla computer science.

[to_je_jedno]

Zatímco třeba Drupal na to má funkci, čili výrazně kratší zápis.

Kód: [Vybrat]

t('Drupal is great');

Tak to jsi jen ukazal vlastni neznalost. Ted po uvedeni OOP Hooks (vc. PHP attributu, autowiringu atd) nemas v podstate krom themes jediny rozumny duvod pouzivat globalni t(), ale mel bys ve svych tridach pouzit \Drupal\Core\StringTranslation\StringTranslationTrait::t()

[to_je_jedno]

Příklady:
- Když budu psát jednoduchou konzolovou aplikaci na 100 řádků, tak asi framework nepotřebuju.

Pokud na takovou aplikaci pouziju PHP (protoze me cely zivot zivi takze bych v jinym jazyce byl neefektivni) tak stejne pouziju symfony/console. Je to framework nebo knihovna? Nevim, je to jedno. Rozumne je to pouzit nez psat cisty PHP.

(chapu, ze nejlepsi by bylo pouzit jiny jazyk, ale to je jina debata)

[alfi]

Programátor co tvrdí, že si vše raději napíše sám a potřebuje znát každý řádek kódu tak je mentálně zamrzlý v 90tých letech.  Ve chvíli kdy chcete budovat komplexní aplikace tak je potřeba nějaká úroveň abstrakce protože není v kapacitě lidského mozku aby rozumněl všemu.

Jj., za mně je takový kód (pokud je to složitější aplikace a ne primitivní stránka) v podstatě nepředatelný někomu dalšímu - zatím jsem nepotkal, že by to mělo vývojářskou dokumentaci, spousta konstrukcí je jen v hlavě autora, někdy divokých a nesrozumitelných.. tj. jako jednu z největších výhod frameworku vidím to, že má nějakou definovanou kulturu a kdo ji zná, umí do projektu s frameworkem naskočit výrazně rychleji a kdo nezná, tomu pomůže AI - to se se samo-domo frameworkem nepodaří

[Tomáš Crhonek]

Programátor co tvrdí, že si vše raději napíše sám a potřebuje znát každý řádek kódu tak je mentálně zamrzlý v 90tých letech.  Ve chvíli kdy chcete budovat komplexní aplikace tak je potřeba nějaká úroveň abstrakce protože není v kapacitě lidského mozku aby rozumněl všemu.

Jj., za mně je takový kód (pokud je to složitější aplikace a ne primitivní stránka) v podstatě nepředatelný někomu dalšímu - zatím jsem nepotkal, že by to mělo vývojářskou dokumentaci, spousta konstrukcí je jen v hlavě autora, někdy divokých a nesrozumitelných.. tj. jako jednu z největších výhod frameworku vidím to, že má nějakou definovanou kulturu a kdo ji zná, umí do projektu s frameworkem naskočit výrazně rychleji a kdo nezná, tomu pomůže AI - to se se samo-domo frameworkem nepodaří

Používám Golang a ten má vet i fmt v sobě.

[Ondrejjj]

Programátor co tvrdí, že si vše raději napíše sám a potřebuje znát každý řádek kódu tak je mentálně zamrzlý v 90tých letech.  Ve chvíli kdy chcete budovat komplexní aplikace tak je potřeba nějaká úroveň abstrakce protože není v kapacitě lidského mozku aby rozumněl všemu.

Jj., za mně je takový kód (pokud je to složitější aplikace a ne primitivní stránka) v podstatě nepředatelný někomu dalšímu - zatím jsem nepotkal, že by to mělo vývojářskou dokumentaci, spousta konstrukcí je jen v hlavě autora, někdy divokých a nesrozumitelných.. tj. jako jednu z největších výhod frameworku vidím to, že má nějakou definovanou kulturu a kdo ji zná, umí do projektu s frameworkem naskočit výrazně rychleji a kdo nezná, tomu pomůže AI - to se se samo-domo frameworkem nepodaří

Používám Golang a ten má vet i fmt v sobě.

A co to má společného s tímhle vláknem? Asi tolik jako bych napsal že používám Rust kde vet ani nepotřebuji..