Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Nickovic 17. 07. 2025, 14:03:01
-
Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
-
Že je to blbost.
Čistý kód je jako stavět klasický panelák a vozit si na jeho stavbu písek, cement, vodu - a beton míchat na místě - protože vozit hotové panely je podvod ;D .
-
Diky za odpovedi chlapi. Ja se teprve ucim zaklady programovani a to jsou jeho nazory, tak me to prekvapilo...
Rikal ze chce mit absolutni prehled o kazdem radku a pokud clovek se ma nazyvat programatorem, mel by umet C++ a Assembler.
Myslite si, ze to je teda nesmysl jo?
Nick
-
Osamely vlk, ktery vyviji aplikaci sam bez frameworku?
Nakonec skonci s tim, ze zacne psat svuj vlastni framework - jinak to dopadnout nemuze.
PS: Ukolem programatora neni ani tak psat kod, jako spis cist kod. Ctenim ciziho kodu se stravi daleko vic casu nez psanim.
-
Zalezi na jazyku. Napriklad v PHP je to prakticky nutnost. Nette, Symfony, Laravel... pripadne Drupal, Wordpress, Joomla,... Ked som skoncil s PHP a presiel na Go, tam je to presne naopak. Ziadne framework(i ked su nejake dostupne), ale cisto nativny kod je proste standard. Ked si vezmem JS, tam je to zase Vue, React a podobne. Ruby malo Rails a td.
Jasne, tu indikujem zameranie na web, ale v principe myslim, ze to plati pre akykolvek aspekt daneho jazyka.
-
Tak hlavně, opravdový programátor nepoužívá PHP, Javu, Python, C, ani Pascal, ale jen a pouze FORTRAN: https://www.logix.cz/michal/humornik/Pojidaci.Kolacu.xp
-
Ano, osamely vlk programator, jenz rozumi C, C++, PHP, JAVA, LUA, Haskell.
Rikal mi, ze programator je clovek co rozumi nizsim programovacim jazykum.
btw ten odkaz je super :)
Nick
-
Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
Že to je naprostá kokotina a kamarád je kokot jak cyp, nebo tě spíš trollí.
Podle jeho do důsledku dovedený logiky by sis měl nejen sám naprogramovat operační systém a všechny aplikace, ale i si vyrobit celej počítač, tzn začít od nakopání písku a mědi, antimonu, kobaltu, atd.
Vybrat si framework pro tebe vhodnej je otázka úplně jiná a zcela nesouvisející.
-
fortran jeste obcas pouzivam, takze si s chuti odkaz prectu.
zacatecnik si ma na zacatku vsecko mozne osahat, takze nejake veci na zacatku si napise na zelene louce. pozdeji uz chce delat vetsi veci a tak zacne pouzivat knihovny, frameworky, ktere mu ulehci otravnou a zbytecnou praci.
taky mam radsi programatory, kteri vedi o systemu, neco o assembleru, c, pointerech.
ale uznavam, ze dnes uz lze zit i bez toho.
-
Zalezi od pouzitia. Ak niekto potrebuje napr. jednoduchu staticku stranku, tak je zbytocne tam dat wordpress. Podobne, ako ked potrebujes nejaku kriticku apku, tak ides cim nizsie, aby si minimalizoval chybovost.
Framework sa uplatni v pripade velkych, alebo timovych projektov, kedy ide hlavne o cas, a o rychlu udrzbu.
Kazdopadne velka vyhoda je zacat programovat cistym kodom, aby si pochopil ako vlastne funguje, a neskor pouzijes framework.
-
Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
Že to je naprostá kokotina a kamarád je kokot jak cyp, nebo tě spíš trollí.
Podle jeho do důsledku dovedený logiky by sis měl nejen sám naprogramovat operační systém a všechny aplikace, ale i si vyrobit celej počítač, tzn začít od nakopání písku a mědi, antimonu, kobaltu, atd.
Vybrat si framework pro tebe vhodnej je otázka úplně jiná a zcela nesouvisející.
on je stara skola a moc neuznava tuny softwatu a vymyslu dnesni doby no...
-
Tohle je nesmysl. Ten kdo nepoužívá framework skončí s tím že si napíše vlastní. Nevýhoda toho vlastního je že je většinou děravý jak cedník, je to one-man show a je to asi miliontátý design "kola" na světě.
Reálně:
- nikdo nikoho nezplatí za vývoj vlastního frameworku
- nikdo rozumný si ten vývoj nepřebere
- frameworky se rozvíjejí N let a rozvíjí je komunita. Pokud si myslí že je chytřejší než celá komunita vývojářů za N let, dost to o tom člověku vypovídá.
- one-man show je z principu špatný
Všeobecně k přirovnáním typu podvod: ne, není to podvod. To je jako říct že podvod je v podstatě cokoli co dnes máme -- protože to vychází z výzkumů, pokusů a omylů generací před námi (případně současných). Všeobecně ten kdo vychází z toho (nebo používá) co někdo jiný vytvořil a "posune" myšlenku dál je efektivní a chytrý. Ten kdo si všechno musí udělat sám protože všechno ví nejlíp je možná tak argantní.
-
Zalezi od pouzitia. Ak niekto potrebuje napr. jednoduchu staticku stranku, tak je zbytocne tam dat wordpress. Podobne, ako ked potrebujes nejaku kriticku apku, tak ides cim nizsie, aby si minimalizoval chybovost.
Framework sa uplatni v pripade velkych, alebo timovych projektov, kedy ide hlavne o cas, a o rychlu udrzbu.
Kazdopadne velka vyhoda je zacat programovat cistym kodom, aby si pochopil ako vlastne funguje, a neskor pouzijes framework.
Dřív jsem si říkal: „Proč používat framework, když si to můžu napsat sám?“ Ale pak mi došlo, že když projekt trvá víc než měsíc, bez frameworku začneš dost trpět.
-
Zalezi na jazyku. Napriklad v PHP je to prakticky nutnost. Nette, Symfony, Laravel... pripadne Drupal, Wordpress, Joomla,... Ked som skoncil s PHP a presiel na Go, tam je to presne naopak. Ziadne framework(i ked su nejake dostupne), ale cisto nativny kod je proste standard. Ked si vezmem JS, tam je to zase Vue, React a podobne. Ruby malo Rails a td.
Jasne, tu indikujem zameranie na web, ale v principe myslim, ze to plati pre akykolvek aspekt daneho jazyka.
Ja este doplnim, ze prave z toho sveta Go mi pride, ze to ma najviac logiky a ze je najvhodnejsie ist cestou kombinovania kniznic podla potreby, namiesto prisposobovania sa nejakemu frameworku. Napriklad ak chcem servirovat HTTP a potrebujem router/muxer, tak nema dovod riesit vsetko cez nejaky velky framework, ktory to ma ako komponentu, ale je vhodnejsie si prave len importovat iba kniznicu, ktora nerobi nic ine len riesit rourovanie. A takto nasledne vystavat system. Clovek sa tak nezamkne to frameworku a nie je nim, casom, limitovany - co je prave najvecsi problem frameworkov, ktory sa vzdy ukaze az neskor, ked je projekt uz solidne zabehnuty a clovek naraza viac a viac na limitacia a obmedzenia a treba to potom zacat vselijako ohybat a obchadzat.
-
Framework bude užitečný, pokud splňuje tvé požadavky na funkčnost. Pokud tě nutí dělat rovnáky na ohejbáky, tak je takový framework k ničemu a je lepší napsat vanilla kód s knihovnami, které mi vyhovují.
-
Já osobně frameworky nesnáším a vyhybám se jim jak čert kříži.
Proč? Protože je to typicky nějaká zpatlanina názorů, která navíc při trochu složitějším systému (třeba http framework) začne velmi rychle chtít úplně specifické (zkryplené) řešení všeho (http, https, sessions, db, orm, crtd??, ..).
Autoři jsou navíc typicky ujetí do nějaké perverzní filosofie jakože je lepší neprogramovat a místo toho všechno konfigurovat (=> programovat v konfiguráku), takže to vždycky končí stejně; reálně musíš mít hrozně moc nepřenositelných (doménově specifických) znalostí konfigurace a debugování bazmeku. Až pak přijdeš k bazmeku 2, nebo to nadšeně přepíšou do verze 2, tak tohle celé co ses pracně naučil můžeš vzít a zahodit. Ta tvoje pracně vydobitá znalost jak definovat xml entity a mapovat je na beany, aby se ti autogenerovaly orm třídy co automaticky překládají REST na CRUD? K ničemu.
Co je tedy alternativa? Microframeworky nebo knihovny. Obecně věci které si uvědomují, že framework je ten jazyk a prostředí ve kterém děláš. Takže vezmou jednu věc a vyřeší jí dobře a pro tebe pohodlně. Třeba ten HTTP server. A pak ti umožní jednoduše pracovat s čímkoliv.
Příklad je třeba Flask v Pythonu, vs Zope (https://www.zope.dev/) (tam si doslova udělali vlastní databázi), vs Spring v Javě.
Jsem pokorná http knihovna, co ti nebude kecat do toho jak se loguje a jak si děláš ORM. Ne. Ja jen překládám http cally na metody a tím to hasne. Jestli chceš validace, tak si najdi něco na validace.
vs
Sežral jsem kaši z rendlíka, ucháč mlíka, pecen chleba, http požadavek, html parser, session manager, validační systém, ORM classy, půlku lispu a metaprogramování, aniž bych o něm cokoliv věděl, react backend, mámu, tátu a Tebe taky ještě sním, zatímco si mažu bradavky XML beanou. ୧༼ಠ益ಠ༽୨
A to vynechávám sto dalších plechovek s červy, jako třeba debugovatelnost, přenositelnost, rozšiřitelnost a tak podobně, nehledě na čas co do toho musíš investovat a dokumentaci která často bývá dost špatná.
-
- frameworky se rozvíjejí N let a rozvíjí je komunita. Pokud si myslí že je chytřejší než celá komunita vývojářů za N let, dost to o tom člověku vypovídá.
Na tohle odpovím volnou citací jistého pana Feynmana: "Jestli jsem chytřejší, než všichni tito lidé? To jistě ne. Jestli jsem chytřejší, než výbor složený z těchto lidí? To v každém případě ano."
-
Já osobně frameworky nesnáším a vyhybám se jim jak čert kříži.
Proč? Protože je to typicky nějaká zpatlanina názorů, která navíc při trochu složitějším systému (třeba http framework) začne velmi rychle chtít úplně specifické (zkryplené) řešení všeho (http, https, sessions, db, orm, crtd??, ..).
Autoři jsou navíc typicky ujetí do nějaké perverzní filosofie jakože je lepší neprogramovat a místo toho všechno konfigurovat (=> programovat v konfiguráku), takže to vždycky končí stejně; reálně musíš mít hrozně moc nepřenositelných (doménově specifických) znalostí konfigurace a debugování bazmeku. Až pak přijdeš k bazmeku 2, nebo to nadšeně přepíšou do verze 2, tak tohle celé co ses pracně naučil můžeš vzít a zahodit. Ta tvoje pracně vydobitá znalost jak definovat xml entity a mapovat je na beany, aby se ti autogenerovaly orm třídy co automaticky překládají REST na CRUD? K ničemu.
Souhlasím, většina frameworků má spoustu konfigurací, které navíc nebývají zpětně kompatibilní se staršími verzemi. Navíc mnoho z nich porušuje SOLID, doslova každou z jeho kýžených vlastností. Má to cenu se jimi zabývat? Překlad REST na CRUD by se automaticky dal dělat, pokud jsou v databázi vnořené procedury, proti kterým ti neumětelové tolik brojí. Jenže to umím i bez frameworku a pokud budu línej, tak si to nechám vygenerovat AI. Skutečně kvalitními a výkonnými frameworky s teoretickými základy však pohrdají, protože jsou již součástí jazyka...
-
Tohle je nesmysl. Ten kdo nepoužívá framework skončí s tím že si napíše vlastní. Nevýhoda toho vlastního je že je většinou děravý jak cedník, je to one-man show a je to asi miliontátý design "kola" na světě.
Jenže spousta dnešních frameworků je napsána bez teoretických základů a snaží se nahradit standardní knihovny, které jsou již součástí jazyka. Například šablonovací systémy v PHP jsou dost závažnou tragédií a přitom PHP obsahuje luxusní knihovnu, která generuje validní HTML, umí dědičnost, rekurzi, procházení stromem, řazení, překrývání default parametrů a další užitečné vlastnosti. Navíc je rychlá a vytvořená šablona se dá beze změny používat i v Javě, Pythonu a dalších jazycích, které tuto knihovnu mají implementovánu.
-
To je jako kdyby někdo tvrdil, že opravdový stavař nepoužívá bagr. A všechno dělá lžící, protože chce mít pod perfektní kontrolou každý tah. Ve skutečnosti má každý z těch nástrojů jiné určení. Když budete stavět silnici, kopat základy bytového domu nebo stavět průplav, použijete bagr. Můžete samozřejmě zkusit i tu lžíci, ale nikdy ten projekt nedokončíte. Když naopak potřebujete zazdít díru po poštovní schránce, nebudete na to brát bagr.
Podobně když budete psát systém pro banku, na kterém dělají desítky lidí, nebudete to psát čisté Javě nebo Kotlinu. Když si budete psát pětiřádkový skript na přesun souborů, nebudete k tomu používat Spring.
Mimochodem, opravdu ten kamarád zmiňoval C++ a assembler? Nebylo to C a assembler? Protože C++ je od assembleru hodně daleko a mít v C++ perfektní kontrolu nad každým řádkem – možná pokud by to psal jenom sám, spoustě konstrukcí C++ by se vyhnul a v překladači vypnul všechny optimalizace. A pokud je kamarád tak proti používání podpory, proč píše v assembleru a ne přímo ve strojovém kódu?
To přirovnání k horolezci s kyslíkem a bez kyslíku je ale celkem trefné. Bez kyslíku lezou horolezci, kteří si chtějí něco dokázat, chtějí překonat sami sebe. Pokud cílem není něco si dokazovat, ale dostat se co nejvýš, je potřeba si vzít ten kyslík. Takže pokud si programátor chce něco dokazovat, ať si klidně píše v assembleru. Pokud ale má dodat funkční aplikaci uživatelům, ty nezajímá, co si programátor chce dokázat, zajímá je výsledek. Mimochodem, horolezci jsou omezeni výškou hor, která je celkem omezená. Kdyby mohli šplhat výš a výš, až na ISS, tak narazí na nějakou hranici, za kterou už se nedostanou bez kyslíku ani ti nejlepší. Prostě už to není v lidských silách. Stejně jako není v lidských silách naprogramovat bankovní systém v assembleru.
-
To je jako kdyby někdo tvrdil, že opravdový stavař nepoužívá bagr. A všechno dělá lžící, protože chce mít pod perfektní kontrolou každý tah. Ve skutečnosti má každý z těch nástrojů jiné určení. Když budete stavět silnici, kopat základy bytového domu nebo stavět průplav, použijete bagr. Můžete samozřejmě zkusit i tu lžíci, ale nikdy ten projekt nedokončíte. Když naopak potřebujete zazdít díru po poštovní schránce, nebudete na to brát bagr.
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
-
To je jako kdyby někdo tvrdil, že opravdový stavař nepoužívá bagr. A všechno dělá lžící, protože chce mít pod perfektní kontrolou každý tah. Ve skutečnosti má každý z těch nástrojů jiné určení. Když budete stavět silnici, kopat základy bytového domu nebo stavět průplav, použijete bagr. Můžete samozřejmě zkusit i tu lžíci, ale nikdy ten projekt nedokončíte. Když naopak potřebujete zazdít díru po poštovní schránce, nebudete na to brát bagr.
Podobně když budete psát systém pro banku, na kterém dělají desítky lidí, nebudete to psát čisté Javě nebo Kotlinu. Když si budete psát pětiřádkový skript na přesun souborů, nebudete k tomu používat Spring.
Mimochodem, opravdu ten kamarád zmiňoval C++ a assembler? Nebylo to C a assembler? Protože C++ je od assembleru hodně daleko a mít v C++ perfektní kontrolu nad každým řádkem – možná pokud by to psal jenom sám, spoustě konstrukcí C++ by se vyhnul a v překladači vypnul všechny optimalizace. A pokud je kamarád tak proti používání podpory, proč píše v assembleru a ne přímo ve strojovém kódu?
To přirovnání k horolezci s kyslíkem a bez kyslíku je ale celkem trefné. Bez kyslíku lezou horolezci, kteří si chtějí něco dokázat, chtějí překonat sami sebe. Pokud cílem není něco si dokazovat, ale dostat se co nejvýš, je potřeba si vzít ten kyslík. Takže pokud si programátor chce něco dokazovat, ať si klidně píše v assembleru. Pokud ale má dodat funkční aplikaci uživatelům, ty nezajímá, co si programátor chce dokázat, zajímá je výsledek. Mimochodem, horolezci jsou omezeni výškou hor, která je celkem omezená. Kdyby mohli šplhat výš a výš, až na ISS, tak narazí na nějakou hranici, za kterou už se nedostanou bez kyslíku ani ti nejlepší. Prostě už to není v lidských silách. Stejně jako není v lidských silách naprogramovat bankovní systém v assembleru.
Diky za odpoved.
No ano, rikal C i C++. Strojovy kod pry resi v techto casech a obecne uziva zasadne Linux. Ma rad prehled o tom, co se deje v jeho PC. Jinak mate pravdu, je takovy sveraz...
-
No ano, rikal C i C++. Strojovy kod pry resi v techto casech a obecne uziva zasadne Linux. Ma rad prehled o tom, co se deje v jeho PC. Jinak mate pravdu, je takovy sveraz...
Strojový kód jsem řešil asi před půl rokem. Ne pod Linuxem, ale na železe. Assembler je o něco lepší, ale stále je závislý na druhu železa. Na hraní je to docela fajn, ale v dnešních podmínkách je lepší sáhnout po C. Pošilhávám po LLVM a WebAssembly. Zkus to navrhnout svému kamarádovi.
Každý z nás je aspoň trochu svéráz, jinak by na světě byla nuda.
-
Podle mě se právě frameworky píšou proto, abych se neupsal k smrti.
Čistý kód je takový, který je krátký, a to se bez frameworku (ať už si pod tím představím cokoliv) dělá těžko.
-
Podle mě se právě frameworky píšou proto, abych se neupsal k smrti.
Čistý kód je takový, který je krátký, a to se bez frameworku (ať už si pod tím představím cokoliv) dělá těžko.
On nikdo netvrdí, že nikdy nemáš použít kód někoho jiného. To o čem je ta diskuze (aspoň pokud to chápu) je jestli používat specificky frameworky. Schválně se prvně zamysli nad tím co to vlastně je, a jak se to liší od knihoven a kde je ta hranice mezi tím.
-
Koukej, třeba ChatGPT to dal docela dobře:
Rozdíl mezi frameworkem a knihovnou není ostrý, ale dá se popsat hlavně podle toho, kdo volá koho – to je tzv. inversion of control:
Knihovna (library)
- Ty ji voláš.
- Je to sada funkcí nebo tříd, které používáš podle potřeby.
- Kódová logika zůstává ve tvých rukou, knihovna jen pomáhá.
Framework
- On volá tebe.
- Framework definuje strukturu aplikace a diktuje, jak ji psát.
- Tvůj kód je zapojený do frameworku skrze "háčky" (např. definované třídy, názvy funkcí, decorators...).
- Framework obvykle řídí běh programu a tvůj kód je jen plugin.
Co mu tam chybí tak třeba to že framework se typicky snaží poskytnout nástroje na řešení všeho v dané doméně.
-
Podle mě se právě frameworky píšou proto, abych se neupsal k smrti.
Čistý kód je takový, který je krátký, a to se bez frameworku (ať už si pod tím představím cokoliv) dělá těžko.
Když můj kód bez frameworku je kratší a jednodušší než ten s frameworkem a používá architektonické vzory, které ve frameworcích nejsou, tak patří kam?
-
on je stara skola a moc neuznava tuny softwatu a vymyslu dnesni doby no...
To je jasný, chtěl jsem tím říct, že to je pokus o zobecnění něčeho, co obecný řešení nemá.
Na triviality jako překlopení kódování řetězce je framework (typu .NETu) nesmysl, ale na cokoli přiměřeně většího je to obrovská pomoc. Jen ti hrozí jak to, že vybereš něco nedostačujícího, tak že to bude kanón na vrabce.
-
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
Protože se dopouštíš úplně stejný chyby, jako prvopočáteční kamarád. Zobecňuješ v momentě, kdy o zobecnění nikdo nestojí a nedává smysl. Tedy to, že ti někdo na vyvrtání dvou děr pro hmoždinky a pověšení poštovní schránky vnucuje bagr, je jen ve tvý hlavě.
-
Je dobre si "osahat" toho co najviac. Dnes, ale vacsina programatorov funguje tak, ze viem jeden framework a ten pouzivam na vsetko. A vymyslam vselijake ohybaky, aby to aspon ako-tak chodilo.
Ja si vyberam, co sa mi na dany ucel viac hodi. na jednoduche skripty powershell, alebo python, na zlozitejsie veci c#, mcu C, web - tam sa drzim minimalizmu, takze ciste html + nejaky lightcss, kde su uz zastylovane zakladne prvky, a jquery na dynamicke dotazy.
A tiez kniznice sa snazim vyuzivat len tie zakladne, kde kazda ma nejaky presny ucel a nie riesenie vsetko v jednom.
lahsie sa tak udrzuje kod, a v pripade problemov viem velmi rychlo upravit program na pouzitie inej kniznice.
-
Já doporučuji se frameworkům vyhýbat, zejména začátečníkům, u nich imho vždy více berou než dávají.
Začátečník by měl pochopit jazyk a programování. To framework ztěžuje, je to další vrstva navíc, kterou je potřeba se prokousat a kterou se začátečník neprokouše, takže mu skryje to pod tím a pochopit základy. Takže důležité je říct si, proč chci framework? Protože se chci vyhnout nudné rutině a ušetřím tím spoustu času a vím co dělám, nebo protože nevím co dělám a doufám, že to framework nějak vyřeší za mě? S frameworkem mám také spojen pojem bloatware, kdy kvůli jedné funkci člověk používá desítky až stovky rozsáhlé knihovny. U malých projektů je framework prakticky vždy přítěž.
-
Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
Ze je to blbec.
-
Jsem pokorná http knihovna, co ti nebude kecat do toho jak se loguje a jak si děláš ORM. Ne. Ja jen překládám http cally na metody a tím to hasne. Jestli chceš validace, tak si najdi něco na validace.
vs
Sežral jsem kaši z rendlíka, ucháč mlíka, pecen chleba, http požadavek, html parser, session manager, validační systém, ORM classy, půlku lispu a metaprogramování, aniž bych o něm cokoliv věděl, react backend, mámu, tátu a Tebe taky ještě sním, zatímco si mažu bradavky XML beanou. ୧༼ಠ益ಠ༽୨
Přesně tak. Třeba Laravel v PHP, to je přesně takovej Otesánek.
-
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
Protože se dopouštíš úplně stejný chyby, jako prvopočáteční kamarád. Zobecňuješ v momentě, kdy o zobecnění nikdo nestojí a nedává smysl. Tedy to, že ti někdo na vyvrtání dvou děr pro hmoždinky a pověšení poštovní schránky vnucuje bagr, je jen ve tvý hlavě.
Proč mi vnucuješ myšlenku, že se dopouštím chyby nějakým zobecňováním? Používám standardní knihovny, které mnoho vývojářů ani nezná a místo nich používají komplikované frameworky s nestabilním rozhraním.
-
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
Protože se dopouštíš úplně stejný chyby, jako prvopočáteční kamarád. Zobecňuješ v momentě, kdy o zobecnění nikdo nestojí a nedává smysl. Tedy to, že ti někdo na vyvrtání dvou děr pro hmoždinky a pověšení poštovní schránky vnucuje bagr, je jen ve tvý hlavě.
Proč mi vnucuješ myšlenku, že se dopouštím chyby nějakým zobecňováním? Používám standardní knihovny, které mnoho vývojářů ani nezná a místo nich používají komplikované frameworky s nestabilním rozhraním?
podle tech zprav to vypada, ze jsi hodne zkuseny programator Kite.
kazdopadne diky chlapi za reakce a blbec to urcite neni
-
Po 20 letech praxe bych to viděl takhle - framework je nástroj.
Pokud chceš udělat jednoúčelovou appku bez nějaké vize dalšího vývoje, nepoužívej framework.
Pokud chceš udělat appku, na které bude dělat více lidí a bude vize rozšíření do budoucna, použij framework.
Dobrý framework se pozná tak, že staví na návrhových vzorech. Pokud na něm musíš něco ohýbat, je to buď špatný framework nebo jsi špatný programátor. Čím víc kódu jsem viděl, tím víc zastávám, že nejlepší přístup je Convention over configuration a čím míň framework umožňuje programátorovi prasit, tím lépe.
Programátor, který ti řekne ze používat framework je špatně, bude dost špatný programátor a po takových je pak radost to „dílo“ přebírat. V one-man-show aplikacích to může fungovat, ale tam to taky končí.
Typická aplikace, která je v něčem důležitá řeší logování, zachytávání výjimek, performance monitoring, session handling, background joby, routing, ORM a spoustu dalších věcí, které ve finále umí být dost komplikované a nechtěl bych je psát od nuly, protože tím způsobím hodně chyb, na které už někdy někdo narazil a jsou vyřešené, tak proč znovuvynalézat kolo.
-
Koukej, třeba ChatGPT to dal docela dobře:
Rozdíl mezi frameworkem a knihovnou není ostrý, ale dá se popsat hlavně podle toho, kdo volá koho – to je tzv. inversion of control:
Knihovna (library)
- Ty ji voláš.
- Je to sada funkcí nebo tříd, které používáš podle potřeby.
- Kódová logika zůstává ve tvých rukou, knihovna jen pomáhá.
Framework
- On volá tebe.
- Framework definuje strukturu aplikace a diktuje, jak ji psát.
- Tvůj kód je zapojený do frameworku skrze "háčky" (např. definované třídy, názvy funkcí, decorators...).
- Framework obvykle řídí běh programu a tvůj kód je jen plugin.
Co mu tam chybí tak třeba to že framework se typicky snaží poskytnout nástroje na řešení všeho v dané doméně.
Podle mě je v hodně případech jen velmi tenká čára mezi knihovnou a frameworkem.
Pokud použiju existující HTTP server, který volá můj callback, tak je to automaticky framework?
Já pochopil tu otázku asi jinak...
-
"Profesionální" programátor je osoba, která v zadaném čase a v zadané kvalitě dodá požadovaný software. Je to osoba touto činností se živící. Pokud mu v tom pomáhej Bůh a framework, což se většinou v praxi stává, budiž. Pokud by tato osoba mohla programovat v něčem jí libém, např. assembleru nebo jinak stavět věci od píky, bylo by to sice pěkné, ale možná, že by tato osoba nestíhala termíny a brzy byla odejita z práce. "Hobík" nechť si staví v čem chce a jak chce, ideálně na proužku papíru může programovat vlastníma rukama postavený Turingův stroj.
-
Podle mě je v hodně případech jen velmi tenká čára mezi knihovnou a frameworkem.
Naopak, mezi knihovnou a frameworkem není čára, není tam žádná pevná hranice, částečně se to překrývá. Kdo koho volá je docela dobré poznávací znamení. Z trochu jiného úhlu pohledu je to – když mám svůj kód a k němu přidám nějakou závislost (která můj kód ovlivní jen částečně), je to knihovna. Když stáhnu „knihovnu“ a dovnitř začnu implementovat svůj kód (typicky nepíšu spouštěč aplikace, ale kód, který ve vhodnou chvíli zavolá ta knihovna), je to framework. Tím pádem ta hranice není pevně daná, protože záleží na množství, na způsobu použití.
někde je to dokonce přiznané – třeba React Router 7 má dokumentaci rozdělenou na dvě velké části, jedna popisuje použití jako framework, jedna jako knihovna.
-
Autoři jsou navíc typicky ujetí do nějaké perverzní filosofie jakože je lepší neprogramovat a místo toho všechno konfigurovat (=> programovat v konfiguráku), takže to vždycky končí stejně; reálně musíš mít hrozně moc nepřenositelných (doménově specifických) znalostí konfigurace a debugování bazmeku. Až pak přijdeš k bazmeku 2, nebo to nadšeně přepíšou do verze 2, tak tohle celé co ses pracně naučil můžeš vzít a zahodit. Ta tvoje pracně vydobitá znalost jak definovat xml entity a mapovat je na beany, aby se ti autogenerovaly orm třídy co automaticky překládají REST na CRUD? K ničemu.
Já bych se těch molochů zastal.
když si vezmu nejhnusnějších z hnusných: Wordpress
Je to bastl.
Jeho architektura je příšerná.
Implementace je ještě děsivější.
Je to přesně jak píšeš, musíš se ohejbat různým divným neintuitivním požadavkům.
A v neposlední řadě to přerostlo svůj původní účel.
A přesto je to na mnoho problémů vyhovující řešení. Lepší jak Flask (například), protože ten by nejdříve musel splnit požadavky X a Y.
-
Já doporučuji se frameworkům vyhýbat, zejména začátečníkům, u nich imho vždy více berou než dávají.
To je jako doporučovat začátečníkům nepoužívat bagr a používat lžíci. Jenže používáním lžíce se nenaučíte ovládat bagr. Používání frameworku je zkrátka jiná dovednost, než používání programovacího jazyka a základní knihovny. A opět se to překrývá – pro použití frameworku je potřeba znát některé části jazyka a knihovny; některé části jazyka a knihovny nejsou potřeba vůbec, protože je daná aplikace nepoužívá nebo je řeší interně ten framework; a některé věci jsou v tom jazyce nebo spíš knihovně a také jsou v tom frameworku, ale jinak – a pak je dobré se držet frameworku a ne jazyka (protože ten framework to implementoval jinak z nějakého důvodu – obvykle je ta implementace ve frameworku modernější, protože framework se může vyvíjet rychleji než jazyk a základní knihovna).
Navíc nemá smysl stavět proti sobě základní knihovnu a framework – i základní knihovna je jen knihovna nebo framework, její výlučnost je daná jenom tím, že je shodou okolností už přibalená k běhovému prostředí daného jazyka.
-
ten umi to a ten zas tohle a vsichni dohromady udelaji moc.
tenhle ma framework, tehle zdrojak, a ten cerny ten ma assembler, tohle je devops, tady zase ceckar, tamhle nahore je frontendak.
a vsichni dohromady udelaji vse.
-
Já doporučuji se frameworkům vyhýbat, zejména začátečníkům, u nich imho vždy více berou než dávají.
To je jako doporučovat začátečníkům nepoužívat bagr
Však také začátečník by měl nejprve umět používat jednodušší stroje a také rozumět kopání, pěkně si ho ošahat ručně krumpáčem, aby pochopil jak funguje a je uspořádaná zemina. Pak teprve dokáže bagr používat rozumně a nenadělá s ním škody. Krom toho, bagr je něco jako nějaký vysokoúrovňový jazyk. Framework je něco jako korporátní stavební firma.
-
Já doporučuji se frameworkům vyhýbat, zejména začátečníkům, u nich imho vždy více berou než dávají.
To je jako doporučovat začátečníkům nepoužívat bagr
Však také začátečník by měl nejprve umět používat jednodušší stroje a také rozumět kopání, pěkně si ho ošahat ručně krumpáčem, aby pochopil jak funguje a je uspořádaná zemina. Pak teprve dokáže bagr používat rozumně a nenadělá s ním škody. Krom toho, bagr je něco jako nějaký vysokoúrovňový jazyk. Framework je něco jako korporátní stavební firma.
To přirovnání tě střílí do nohy.
V praxi se běžně setkáš s člověkem, který by si o lopatu zlomil nohu, ale bagrista je výborný.
Na rekonstrukci si běžně najímáš kompletní stavební firmu právě proto, že detailům nerozumíš, a kolikrát ani rozumět nechceš.
-
Framework je dobrý sluha, ale zlý pán. V začátcích to hází klacky pod nohy, protože člověk se musí učit o jednu komplexní věc víc.
Odpověd pak závisí na tom, o jaký typ programování a učení se jedná. V řadě případů to jde bez frameworku a tak je lepší se tím zatím nezatěžovat a učit se bez nich. V jiných případech je práce bez frameworku neskutečné sebemrskačství a ve výsledku se tím naučíte leda tak jak si napsat vlastní framework. V těhle případech je lepší si nějaký vybrat a začít s tím. Ale těch frameworků je více a časem, až člověk nabere nějaké zkušenosti, je lepší zkusit ještě nějaký jiný, ať máte porovnání. Nesnažte se začínat tím, že si vyberete "ten nejlepší". V práci za vás stejně vybral již dávno někdo jiný.
Jinými slovy: framework je vždycky zátěž navíc. Ale jsou případy, kdy to bez nich už prakticky nejde. Například si nedokážu představit, že bych dobrovolně programoval něco pro AWS bez AWS CDK.
Podobně jako si již dávno nepíšeme vlastní knihovny na HTTP komunikaci, tak obor v řadě míst doiteroval do stavu, kdy už bez frameworku nepracujeme. I když to občas je framework, který si ve firmě v průběhu let napsali sami.
-
Podobne, ako ked potrebujes nejaku kriticku apku, tak ides cim nizsie, aby si minimalizoval chybovost.
To bych obecně netvrdil. Framework i u malých věcí může řešit spoustu věcí, které by bylo potřeba řešit ručně, a u kterých jde nadělat spoustu různých chyb. CSRF, clickjacking, různé injekce, DNS rebinding, …
Pravda, ne každý framework vyřeší všechno, je dobré i tady mít přehled. Ale řešit to sám nemusí zrovna situaci zlepšit.
-
Ok, ale vtedy siahnes po nejakom konkretnom minimalistickom frameworku, ktory ma osetrene len tieto zakladne veci. Kedze sa obcas venujem aj elektronike, tak to bolo myslene skor v zmysle mcu, a procesov, ktore su niekde "dole", rozne riadiace systemy, zabezpecovacky... kde potrebujes aby to na tej najnizsej urovni fungovalo, a netrapi ta, ak by vypadla komunikacia s nejakym obsluznym sw, ktory uz riesi nejake requesty od uzivatelov, alebo komunikuje s mikroservismi.
-
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
Protože se dopouštíš úplně stejný chyby, jako prvopočáteční kamarád. Zobecňuješ v momentě, kdy o zobecnění nikdo nestojí a nedává smysl. Tedy to, že ti někdo na vyvrtání dvou děr pro hmoždinky a pověšení poštovní schránky vnucuje bagr, je jen ve tvý hlavě.
Proč mi vnucuješ myšlenku, že se dopouštím chyby nějakým zobecňováním? Používám standardní knihovny, které mnoho vývojářů ani nezná a místo nich používají komplikované frameworky s nestabilním rozhraním.
Netvrdím, že neumíš programovat. Tvrdím, že ta tvoje formulace je nesmyslně zobecňující a žes nejspíš napsal něco jinýho, než ses snažil sdělit.
-
Proč je nám tedy na upevnění poštovní schránky vnucován bagr?
Protože se dopouštíš úplně stejný chyby, jako prvopočáteční kamarád. Zobecňuješ v momentě, kdy o zobecnění nikdo nestojí a nedává smysl. Tedy to, že ti někdo na vyvrtání dvou děr pro hmoždinky a pověšení poštovní schránky vnucuje bagr, je jen ve tvý hlavě.
Proč mi vnucuješ myšlenku, že se dopouštím chyby nějakým zobecňováním? Používám standardní knihovny, které mnoho vývojářů ani nezná a místo nich používají komplikované frameworky s nestabilním rozhraním?
podle tech zprav to vypada, ze jsi hodne zkuseny programator Kite.
kazdopadne diky chlapi za reakce a blbec to urcite neni
Že někdo umí programovat automaticky neznamená, že se umí správně a přesně vyjadřovat jinak než v programovacím jazyce.
-
Ok, ale vtedy siahnes po nejakom konkretnom minimalistickom frameworku, ktory ma osetrene len tieto zakladne veci. Kedze sa obcas venujem aj elektronike, tak to bolo myslene skor v zmysle mcu, a procesov, ktore su niekde "dole", rozne riadiace systemy, zabezpecovacky... kde potrebujes aby to na tej najnizsej urovni fungovalo, a netrapi ta, ak by vypadla komunikacia s nejakym obsluznym sw, ktory uz riesi nejake requesty od uzivatelov, alebo komunikuje s mikroservismi.
Záleží taky na životnosti toho projektu a co člověk zná. Když je to rychle spíchnutá jednoúčelovka na měsíc, dva, tak naopak dává smysl sáhnout klidně i po overbloated nástrojích, protože s nimi to člověk udělá za půl dne, byť to bude neefektivní na zdroje, než si tady tři týdny po večerech něco šmudlat v něčem, co neznám a nebudu už nejspíš nikdy potřebovat, aby se to vzápětí celé zahodilo.
-
Ok, ale vtedy siahnes po nejakom konkretnom minimalistickom frameworku, ktory ma osetrene len tieto zakladne veci. Kedze sa obcas venujem aj elektronike, tak to bolo myslene skor v zmysle mcu, a procesov, ktore su niekde "dole", rozne riadiace systemy, zabezpecovacky... kde potrebujes aby to na tej najnizsej urovni fungovalo, a netrapi ta, ak by vypadla komunikacia s nejakym obsluznym sw, ktory uz riesi nejake requesty od uzivatelov, alebo komunikuje s mikroservismi.
Záleží taky na životnosti toho projektu a co člověk zná. Když je to rychle spíchnutá jednoúčelovka na měsíc, dva, tak naopak dává smysl sáhnout klidně i po overbloated nástrojích, protože s nimi to člověk udělá za půl dne, byť to bude neefektivní na zdroje, než si tady tři týdny po večerech něco šmudlat v něčem, co neznám a nebudu už nejspíš nikdy potřebovat, aby se to vzápětí celé zahodilo.
Bohužel tyto jednoúčelovky bývají jen z pohledu vývojáře, nikoli však majitele, který předpokládá delší životnost.
-
Jenomže pak se dá taky očekávat rozvoj, takže se framework může hodit právě proto, že až k tomu budeš něco dodělávat, neušoupeš si ruce.
-
O tebe nejde, jde o toho chudáka co to dostane do ruk až tě trefí šlak nebo autobus
-
Priority mohou být různé, například:
1. Co nejrychlejší start.
2. Co nejmenší velikost binárky
3. Co nejdříve mít prototyp, na základě kterého se rozhodne, zda bude další vývoj, a kam se má ubírat.
V prvních dvou případech se může hodit (zejména u jednoduchých věcí) framework nepoužít vůbec, případně použít něco fakt malého. Třeba i za cenu složitějšího vývoje a zevrubnější kontroly, že jsem nezapomněl na nic z toho, co by za mě mohl řešit framework. Asi jde o celkem specifické případy, ale nastat mohou.
Ve třetím případě se naopak nejspíš vyplatí to udělat jakkoli, možná použít nějaký framework bez pečlivého výběru, prototyp nějak narychlo naprasit, a až bude zpětná vazba, třeba to celé zahodit a udělat od nuly s většími znalostmi. Jasně, není to platné za všech okolností, ale někdy to může být (i s ohledem na dostupné informace) ideální postup.
-
Tak zrovna v pripade bodu 1 prave sahnu po frameworku. Treba u webovky to proste a jednoduse v Next.JS rozjedu za 5 minut zatimco bez nej to bude trvat dele.
EDIT: aha, ted mi doslo, ze mozna myslis "start aplikace" zatimco ja "start vyvoje"
-
Ok, ale vtedy siahnes po nejakom konkretnom minimalistickom frameworku, ktory ma osetrene len tieto zakladne veci. Kedze sa obcas venujem aj elektronike, tak to bolo myslene skor v zmysle mcu, a procesov, ktore su niekde "dole", rozne riadiace systemy, zabezpecovacky... kde potrebujes aby to na tej najnizsej urovni fungovalo, a netrapi ta, ak by vypadla komunikacia s nejakym obsluznym sw, ktory uz riesi nejake requesty od uzivatelov, alebo komunikuje s mikroservismi.
Záleží taky na životnosti toho projektu a co člověk zná. Když je to rychle spíchnutá jednoúčelovka na měsíc, dva, tak naopak dává smysl sáhnout klidně i po overbloated nástrojích, protože s nimi to člověk udělá za půl dne, byť to bude neefektivní na zdroje, než si tady tři týdny po večerech něco šmudlat v něčem, co neznám a nebudu už nejspíš nikdy potřebovat, aby se to vzápětí celé zahodilo.
Bohužel tyto jednoúčelovky bývají jen z pohledu vývojáře, nikoli však majitele, který předpokládá delší životnost.
To je otázka specifikace. A ceny. A v tom konkrétním případě, který jsem měl na mysli z osobní zkušenosti, jsem byl svým vlastním zákazníkem a věděl jsem na 100 %, že to je na měsíc a něco, a jestli to někdy za pár let budu potřebovat znovu, tak to zaručeně nebude 1:1 a bude snazší to pak zase slepit za půl dne.
-
Ok, ale vtedy siahnes po nejakom konkretnom minimalistickom frameworku, ktory ma osetrene len tieto zakladne veci. Kedze sa obcas venujem aj elektronike, tak to bolo myslene skor v zmysle mcu, a procesov, ktore su niekde "dole", rozne riadiace systemy, zabezpecovacky... kde potrebujes aby to na tej najnizsej urovni fungovalo, a netrapi ta, ak by vypadla komunikacia s nejakym obsluznym sw, ktory uz riesi nejake requesty od uzivatelov, alebo komunikuje s mikroservismi.
Záleží taky na životnosti toho projektu a co člověk zná. Když je to rychle spíchnutá jednoúčelovka na měsíc, dva, tak naopak dává smysl sáhnout klidně i po overbloated nástrojích, protože s nimi to člověk udělá za půl dne, byť to bude neefektivní na zdroje, než si tady tři týdny po večerech něco šmudlat v něčem, co neznám a nebudu už nejspíš nikdy potřebovat, aby se to vzápětí celé zahodilo.
Bohužel tyto jednoúčelovky bývají jen z pohledu vývojáře, nikoli však majitele, který předpokládá delší životnost.
To je otázka specifikace. A ceny. A v tom konkrétním případě, který jsem měl na mysli z osobní zkušenosti, jsem byl svým vlastním zákazníkem a věděl jsem na 100 %, že to je na měsíc a něco, a jestli to někdy za pár let budu potřebovat znovu, tak to zaručeně nebude 1:1 a bude snazší to pak zase slepit za půl dne.
Za půl dne takovou záležitost slepím i bez frameworku s použitím standardních knihoven a navíc SOLID.
-
Za půl dne takovou záležitost slepím i bez frameworku s použitím standardních knihoven a navíc SOLID.
Ja za dve hodky s frameworkem, ktery SOLID, DP a tydle srandy samozrejme vyuziva. Šach mat.
-
Za půl dne takovou záležitost slepím i bez frameworku s použitím standardních knihoven a navíc SOLID.
Ja za dve hodky s frameworkem, ktery SOLID, DP a tydle srandy samozrejme vyuziva. Šach mat.
Který framework využívá SOLID? Ty neumíš používat DP bez frameworku? Vždyť jsou tak jednoduché.
-
Proc bych to delal? Kdo by me za to platil? Porad si zijes ve sve bubline akademickych znalosti a nechapes, ze byznys jede jinde.
-
Proc bych to delal? Kdo by me za to platil? Porad si zijes ve sve bubline akademickych znalosti a nechapes, ze byznys jede jinde.
Než se lopotit s frameworkem, který nedodržuje DP ani SOLID, tak si to raději napíši sám a pořádně. Stejně nejvíc práce je s výstupní šablonou, u které moderní frameworky neumí ani dědičnost, ani rekurzi. Raději použiji šablonovací jazyk, který funguje i v jiných jazycích než v PHP a umí dědičnost i rekurzi.
-
Jenže spousta dnešních frameworků je napsána bez teoretických základů a snaží se nahradit standardní knihovny, které jsou již součástí jazyka. Například šablonovací systémy v PHP jsou dost závažnou tragédií a přitom PHP obsahuje luxusní knihovnu, která generuje validní HTML, umí dědičnost, rekurzi, procházení stromem, řazení, překrývání default parametrů a další užitečné vlastnosti. Navíc je rychlá a vytvořená šablona se dá beze změny používat i v Javě, Pythonu a dalších jazycích, které tuto knihovnu mají implementovánu.
Len tak pre zaujímavosť, ktorú konkrétnu knižnicu máš na mysli?
-
Len tak pre zaujímavosť, ktorú konkrétnu knižnicu máš na mysli?
Neptej se... ;D az se provali ze mluvi o XML/XSLT bude z toho dalsi flamewar :D
-
Já vám řeknu, v Pythonu je takový framework a jmenuje se Bottle, je to ještě osekanější než Flask. A je podle mě úplně super, dokonce už i pár let nikdo nešáhnul na jeho jediný zdroják, tipuju že už je vyladěn :D
A jeho SimpleTemplate nemá ani kontrolu uživatelského vstupu.
A já bych ten framework úplně v klidu používal na svoje osobní věci - proč? Protože jaký je problém v tom, si tam prostě jednou tu metodu, která uživatelské vstupy ošetří, napsat?
Jenže problém s ním spočívá v něčem jiném - není pro něj podpora v IDEčku, ani v Pycharmu. A to je hlavní kámen úrazu - když budu psát template a mi to ani nezvýrazní syntax, tak jak s tím asi udělám nějaký větší projekt? Zkoušel jsem si kvůli toho napsat pro Pycharm svůj plugin, a vykašlal jsem se na to, je to složité jak hrom. IntelliJ ani neumí nějak jednoduše umožnit, abych třeba pomoc regexu si definoval, co jsou projektová klíčová slova, aby mi je to umělo našeptat. Smůla.
PHP, React, Thymeleaf, Ruby, Django, ASP.NET, ty mají všechny podporu v IDE pro ty svoje templates.
Ale na Rest API bych ho klidně použil.
-
z pohledu desktopového vývojáře co dělá WPF / knihovny / konzole / API ... tak moc nerozumím místní diskusi. Framework používám jen ten co je od MS v .NET. Nugety třetích stran pouze vyjímečně a jen pokud si s sebou netahají miliony referencí. Nedokážu si představit, že bych měl dělat desktopovku bez wpf pouze v základním c#.
S čím však souhlasím je mít věci pod kontrolou a netahat si do projektu zybtečnosti co sotva umím využít. Čím míň závyslostí tím lépe.
Pokud moje aplikace pracuje s citlivými informacemi, nechci aby to šlo do nějakcýh random knihoven nebo frameworků jen abych si ušetřil pár dní práce.
Koneckonců spoustu věcí jsem si za tu dobu už postavil sám do svých knihoven které recykluji.
-
z pohledu desktopového vývojáře co dělá WPF / knihovny / konzole / API ... tak moc nerozumím místní diskusi. Framework používám jen ten co je od MS v .NET. Nugety třetích stran pouze vyjímečně a jen pokud si s sebou netahají miliony referencí. Nedokážu si představit, že bych měl dělat desktopovku bez wpf pouze v základním c#.
C# je koncipován jako štíhlý základní jazyk plus knihovny a frameworky. U něj se tedy předpokládá, že vývojář vybere některý z frameworků a na něm postaví aplikaci. Podobné je to u Pythonu či Javy, i když Python má toho už v základu víc.
PHP má spoustu knihoven integrovánu již v základní výbavě. Práce s databázemi, JSON, XML, obrázky, ... to umí PHP v základu a není potřebné volat nějakou knihovnu. Je jich tolik, že se aplikace dá zpravidla napsat i bez externích knihoven a frameworků. Jen je vývojáři musí umět používat.
-
No PHP toho má spoustu v základní výbavě. Ale pokud se něco nezměnilo, i u jednoduchých aplikací se framework hodí:
1. Jednoduchý formulář funkční bez JS, s validací. Když data nejsou validní, zobrazit formulář i s daty. Kontrolovat, jestli skutečně dostávám string, nebo třeba pole. Možná ještě řešit CSRF. Prostě takové základní věci. Bez frameworku to je opruz a náchylné na chybu.
2. OK, dnes bychom mohli akceptovat, že potřebujeme JS, a bez něj formulář fungovat nebude. Poslat můžeme třeba i JSON, vrátit můžeme též JSON. Opět ale validace dat (a případně řešení CSRF) je bez nějaké aspoň jednoduché knihovny opruz.
-
No PHP toho má spoustu v základní výbavě. Ale pokud se něco nezměnilo, i u jednoduchých aplikací se framework hodí:
1. Jednoduchý formulář funkční bez JS, s validací. Když data nejsou validní, zobrazit formulář i s daty. Kontrolovat, jestli skutečně dostávám string, nebo třeba pole. Možná ještě řešit CSRF. Prostě takové základní věci. Bez frameworku to je opruz a náchylné na chybu.
2. OK, dnes bychom mohli akceptovat, že potřebujeme JS, a bez něj formulář fungovat nebude. Poslat můžeme třeba i JSON, vrátit můžeme též JSON. Opět ale validace dat (a případně řešení CSRF) je bez nějaké aspoň jednoduché knihovny opruz.
Zmíněné doplňky se dají uložit do několika málo tříd. Stačí je tedy dát do jedné knihovny a tu používat. Není tedy třeba kvůli tomu instalovat celý framework, který mě nutí programovat stylem autora frameworku. Obvyklou architekturu MVC si umím udělat lépe než framework, který používá MVP a vydává ji za MVC, protože je to víc cool. Místo Dependency Injection používá Service Locator a vydává to za DIC. Šablonovací jazyk napsaný v šablonovacím jazyce. Proč bych měl používat něco tak pokřiveného?
-
To jsou ty silácký řeči. Narážím na projekty, které jsou vytvářeny bez FW, protože autor si myslí, že to není třeba, nebo ba co hůř, že to zvládne líp. A nikdy to není pravda. A to si dokonce ani nemyslím, že by to byli nějací méně schopní vývojáři.
Klasický vývoj zkušeností:
- junioři zásadně používají FW na všechno
- medioři zásadně nepoužívají FW
- senioři používají FW a v ušetřeném čase chodí na pláž
-
Kit: Jenže tady mi přijde, že se od „Nepitřebuju framework“ dostáváme k „Vytvářím vlastní framework, protože existující mi nevyhovují.“. Nechám stranou výhodu vašeho/tvého přístupu oproti jiným frameworkům (to by tu už bylo asi hodně OT), podstatné je, že tomu bych pak neřekl vývoj bez frameworku.
BoneFlute: Tak ony budou existovat věci, kde framework smysl fakt nedává. Dělal jsem třeba skript, který podle nějakých kritérií řadí řádky na vstupu. Něco jako /usr/bin/sort, ale s jinými kritérii řazení. Nečte to nic z cmdline, jen ze stdin řádek po řádku. Framework by tu asi ničemu nepomohl.
Na druhou stranu, hranice, kdy se nějaký vhodný framework vyplatí, může být i docela nízko.
-
Kit: Jenže tady mi přijde, že se od „Nepotřebuju framework“ dostáváme k „Vytvářím vlastní framework, protože existující mi nevyhovují.“. Nechám stranou výhodu vašeho/tvého přístupu oproti jiným frameworkům (to by tu už bylo asi hodně OT), podstatné je, že tomu bych pak neřekl vývoj bez frameworku.
Neřekl bych, že si vytvářím vlastní framework, ale vlastní knihovnu tříd, které používám ve svých projektech. Souhlasím, že stávající frameworky mi nevyhovují, protože mi až nepříjemně diktují, jak má moje aplikace vypadat. Svou štíhlou knihovnu však nepovažuji za framework. Důsledná aplikace SOLID mi umožňuje ji snadno rozšířit o další vlastnosti.
-
BoneFlute: Tak ony budou existovat věci, kde framework smysl fakt nedává. Dělal jsem třeba skript, který podle nějakých kritérií řadí řádky na vstupu. Něco jako /usr/bin/sort, ale s jinými kritérii řazení. Nečte to nic z cmdline, jen ze stdin řádek po řádku. Framework by tu asi ničemu nepomohl.
Na druhou stranu, hranice, kdy se nějaký vhodný framework vyplatí, může být i docela nízko.
Jistě. Pokud dělám jen nějakou rychlovku, něco malého, kde z toho FW vlastně nevyužiju nic, tak samozřejmě nemá smysl ho používat. O tom žádná.
Stala se mi taková věc, že jsem dostal od klienta na vstupním pohovoru zadání, a součástí zadání byl zákaz používat FW. Jenže to zadání nebylo úplně jednořádkové. Tak jsem si musel spatlat vlastní loader, vlastní DIC, vlastní FrontController. Ve výsledku jsem dostal velkou pochvalu, ale stejně bych to do produkce necpal. FW je o tom, že se kumulují schopnosti a znalosti. Mám uplatňovat své zkušenosti na výběr vhodného řešení. Ne na to, abych jako trubka si všechno psal sám.
-
Stala se mi taková věc, že jsem dostal od klienta na vstupním pohovoru zadání, a součástí zadání byl zákaz používat FW. Jenže to zadání nebylo úplně jednořádkové. Tak jsem si musel spatlat vlastní loader, vlastní DIC, vlastní FrontController. Ve výsledku jsem dostal velkou pochvalu, ale stejně bych to do produkce necpal. FW je o tom, že se kumulují schopnosti a znalosti. Mám uplatňovat své zkušenosti na výběr vhodného řešení. Ne na to, abych jako trubka si všechno psal sám.
Třeba to mělo být na 20-30 řádek a ty sis kvůli tomu vyrobil framework.
Ty používáš jen jeden DIC?
-
Mě by v práci nenapadlo nepoužít framework, používám Spring a na FE React, ale doma momentálně laboruju s Python Bottle a Server side redneringem. A člověk by ani neřekl, kolik se toho v tom dá udělat, ale problém spočívá v podpoře v IDE, která je katastrofická - a nejde ani tak o Python část zdrojáků, tam framework nepotřebuju, ale jde o ty jeho templates.
Takže Bottle podporu pro svoje templates vůbec nemá, pak je tam Mako templates - tyhle byly velice oblíbené ale JetBrains dropnul podporu už v roce 2021. Teď je tam tiket v jejich systému, má podporu 80 likes aby vrátili zpatky podporu pro ty Mako templates, ale smůla, už několik let tam podpora není.
Pak je tam Jinja template, to tam plugin má a momentálně je používám, ale je to katastrofa, nedokáže to propojit vstupní parametry s těmi co jsou v templatu, ani to neumí propojit volání fragmentu, nejen že to nenašeptá parametry, ale nepropojí to ani metodu. Hrůza je to. Už jsem v tom naprogramoval kus aplikace a asi to vzdám a přepíšu to do něčeho jiného.
A zdůrazňuju, že to není kvůli tomu mikro frameworku samotnému, ale je to kvůli podpoře v IDE. Bez ní se to prostě nedá.
Dobrou podporu v IDE má Django, ale mám k tomu frameworku nějaký odpor, pokaždé jak vidím ty jejich tzv. "batteries" included, tak mě to odradí, dávají tam řadu věcí, které nepotřebuju. Dokonce i svoje ORM namísto SQL Alchemy - kdoví, jaká úskalí to skýtá.
Nejlepší Keep it simple "template" je to, co má PHP, ASP, nebo co měly staré JSP a nebo právě to, co měly Mako templates nebo co má Python Bottle - a ty nejlepší "templates" jsou ty, kde se píše přímo kód. To jsou IMO nejlepší templates. Hlupáci to historicky zarazili, protože v tom lidi prasili, ale v roce 2025 se všude používá React a to je defacto v pricnipu právě to, co byly JSP nebo PHP, prostě kód a html jsou dohromady.
Bohužel, vždycky když je něco dobrý způsob který funguje, tak musí přijít nějaký dbl, který to zničí a zkomplikuje. Aby to náááhodou nebylo potom, pro ostatní až moc jednoduché.
-
A zdůrazňuju, že to není kvůli tomu mikro frameworku samotnému, ale je to kvůli podpoře v IDE. Bez ní se to prostě nedá.
Podporu frameworků v IDE raději vůbec nehledám. Možná i proto mi připadají takové těžkopádné. Pro mne jednodušší připojit vlastní knihovnu tříd které se snažím udržovat stylem KISS.
-
Mě by v práci nenapadlo nepoužít framework, používám Spring a na FE React, ale doma momentálně laboruju s Python Bottle a Server side redneringem. A člověk by ani neřekl, kolik se toho v tom dá udělat, ale problém spočívá v podpoře v IDE, která je katastrofická - a nejde ani tak o Python část zdrojáků, tam framework nepotřebuju, ale jde o ty jeho templates.
Takže Bottle podporu pro svoje templates vůbec nemá, pak je tam Mako templates - tyhle byly velice oblíbené ale JetBrains dropnul podporu už v roce 2021. Teď je tam tiket v jejich systému, má podporu 80 likes aby vrátili zpatky podporu pro ty Mako templates, ale smůla, už několik let tam podpora není.
Pak je tam Jinja template, to tam plugin má a momentálně je používám, ale je to katastrofa, nedokáže to propojit vstupní parametry s těmi co jsou v templatu, ani to neumí propojit volání fragmentu, nejen že to nenašeptá parametry, ale nepropojí to ani metodu. Hrůza je to. Už jsem v tom naprogramoval kus aplikace a asi to vzdám a přepíšu to do něčeho jiného.
A zdůrazňuju, že to není kvůli tomu mikro frameworku samotnému, ale je to kvůli podpoře v IDE. Bez ní se to prostě nedá.
Dobrou podporu v IDE má Django, ale mám k tomu frameworku nějaký odpor, pokaždé jak vidím ty jejich tzv. "batteries" included, tak mě to odradí, dávají tam řadu věcí, které nepotřebuju. Dokonce i svoje ORM namísto SQL Alchemy - kdoví, jaká úskalí to skýtá.
Nejlepší Keep it simple "template" je to, co má PHP, ASP, nebo co měly staré JSP a nebo právě to, co měly Mako templates nebo co má Python Bottle - a ty nejlepší "templates" jsou ty, kde se píše přímo kód. To jsou IMO nejlepší templates. Hlupáci to historicky zarazili, protože v tom lidi prasili, ale v roce 2025 se všude používá React a to je defacto v pricnipu právě to, co byly JSP nebo PHP, prostě kód a html jsou dohromady.
Bohužel, vždycky když je něco dobrý způsob který funguje, tak musí přijít nějaký dbl, který to zničí a zkomplikuje. Aby to náááhodou nebylo potom, pro ostatní až moc jednoduché.
Bottle je super, rád čtu že ho nepoužívám sám. Podpora šablon v idečku je možná horší, dá se s tím ale žít. Na malé věci osobně používám bottle, na velké django a na obojí nedám dopustit.
-
A zdůrazňuju, že to není kvůli tomu mikro frameworku samotnému, ale je to kvůli podpoře v IDE. Bez ní se to prostě nedá.
Podporu frameworků v IDE raději vůbec nehledám. Možná i proto mi připadají takové těžkopádné. Pro mne jednodušší připojit vlastní knihovnu tříd které se snažím udržovat stylem KISS.
Tak kolega tady spíš narážel na problém v podpoře šablon, to ani nepoužívání frameworku nezachrání..
-
A zdůrazňuju, že to není kvůli tomu mikro frameworku samotnému, ale je to kvůli podpoře v IDE. Bez ní se to prostě nedá.
Podporu frameworků v IDE raději vůbec nehledám. Možná i proto mi připadají takové těžkopádné. Pro mne jednodušší připojit vlastní knihovnu tříd které se snažím udržovat stylem KISS.
Tak kolega tady spíš narážel na problém v podpoře šablon, to ani nepoužívání frameworku nezachrání..
K čemu by mi byla podpora šablon, když těch šablonovacích systémů jsou mraky a podporovány jsou jen některé? Pro mne je důležitá podpora samotného jazyka. Můj šablonovací systém je však podporován také.
-
Kit, ty jsi jak tajemný hrad v karpatech. Neděláš náhodou v PHP?
-
Kit, ty jsi jak tajemný hrad v karpatech. Neděláš náhodou v PHP?
To se tady přece ví, že dělám v PHP.
-
No ale to v tom případě my o voze a ty o koze... V PHP Framework nepotřebuješ nutně mít, na to jsme přišel taky. PHP je snad jediný jazyk do dneška, co už ve vanilce je dělaný ve stylu JSP nebo ASP, nebo JS + HTML, tzn. že PHP kód se dá psát přímo do HTML "templatu" (Jestli se tomu teda vůbec dá říkat template).
A PHP za těch 30 let má naprosto skvělou podporu ve WebStorm, funguje plně refaktoring všeho. A ten refaktoring všeho funguje i díky tomu, že to není jen nějaký zasr* template jako Thymeleaf nebo Jinja nebo Django, ale že je to 1:1 převeditelné na kód. V JSP taky pokud vím fungoval refaktoring, než tam přidali ty tagy.
PHP je do dnešních dnů snad jediná webová technologie, která se drží a je pro ní plný refaktoring. Ikdyž teď přišly nové technologie, v Javě je to JTE, a v .NET myslím že se to jmenuje Blazor, kterými se navrátilo psaní kódu přímo do "templates", jako to bylo za dob JSP.
PHP to tak má už 30 let.
Někdy uvažuju, že bych můj projekt předělal do PHP, ale další jazyk na naučení už nedám, protože už dělám v Javě, Pythonu a JS.
-
Akorát jedna věc, co mi vadí na PHP, je že když chci udělat komponentu, tak k ní chci přistupovat jako k funkci, tzn. žebere na vstup nějaké parametry a něco vrací.
Pokud to udělám pomocí include, tak nemám našptání vstupních paremtrů. A pokud si udělám svoji funkci a budu volat tu funkci, tak mi v PHP chybí nějaká pěkná podpora pro multiline html stringy ve stylu JSX. Takže to potom vypadá takto (z DokuWiki)
public static function fatalException($e)
{
$plugin = self::guessPlugin($e);
$title = hsc(get_class($e) . ': ' . $e->getMessage());
$msg = 'An unforeseen error has occured. This is most likely a bug somewhere.';
if ($plugin) $msg .= ' It might be a problem in the ' . $plugin . ' plugin.';
$logged = self::logException($e)
? 'More info has been written to the DokuWiki error log.'
: $e->getFile() . ':' . $e->getLine();
echo <<<EOT
<!DOCTYPE html>
<html>
<head><title>$title</title></head>
<body style="font-family: Arial, sans-serif">
<div style="width:60%; margin: auto; background-color: #fcc;
border: 1px solid #faa; padding: 0.5em 1em;">
<h1 style="font-size: 120%">$title</h1>
<p>$msg</p>
<p>$logged</p>
</div>
</body>
</html>
EOT;
}
To má 2 problémy:
1. Nevypadá to tak pěkně jako JSX v Reactu
2. Nedají se do toho psát pěkně další foreache atd
Dá se to však obejít a udělat toto:
function renderUserList($users) {
ob_start();
?>
<ul>
<?php foreach ($users as $user): ?>
<li><?= htmlspecialchars($user['name']) ?></li>
<?php endforeach; ?>
</ul>
<?php
return ob_get_clean();
}
A tohle už je docela hustý, ikdyž mi tochu vadí ten ob_clean. Dá se to dát úplně pryč a udělat jen:
function renderUserList($users) {
?>
<ul>
<?php foreach ($users as $user): ?>
<li><?= htmlspecialchars($user['name']) ?></li>
<?php endforeach; ?>
</ul>
<?php
}
Ale z toho se mi trochu chcou zbláznit barvy v IDE (to bych asi pořešil) ale není tam ta výhoda toho return. Ale možná to ničemu nevadí?
-
No ale to v tom případě my o voze a ty o koze... V PHP Framework nepotřebuješ nutně mít, na to jsme přišel taky. PHP je snad jediný jazyk do dneška, co už ve vanilce je dělaný ve stylu JSP nebo ASP, nebo JS + HTML, tzn. že PHP kód se dá psát přímo do HTML "templatu" (Jestli se tomu teda vůbec dá říkat template).
Bavíme se obecně o všech jazycích. Vkládání PHP do šablony HTML nepoužívám, všechno dělám přes OOP. Nepoužívám ani koncovou značku ?>.
-
Tohle uděláš jak?
<?php foreach ($users as $user): ?>
<?php if ($user === 'Bob'): ?>
<li><strong><?= $user ?></strong></li>
<?php else: ?>
<li><?= $user ?></li>
<?php endif; ?>
<?php endforeach; ?>
To mi chceš říct, že jsi to "podělal", a na PHP, které má skvělou podporu v IDE pro refaktoring všeho, tak jsi tam úplně zbytečně dal šablonovací systém typu Thymeleaf, který má vymyšlené svoje tagy? Takže se to v IDE opět rozbije a nebude nad tím fungovat IntelliSense?
-
Akorát jedna věc, co mi vadí na PHP, je že když chci udělat komponentu, tak k ní chci přistupovat jako k funkci, tzn. žebere na vstup nějaké parametry a něco vrací.
Pokud to udělám pomocí include, tak nemám našptání vstupních paremtrů. A pokud si udělám svoji funkci a budu volat tu funkci, tak mi v PHP chybí nějaká pěkná podpora pro multiline html stringy ve stylu JSX. Takže to potom vypadá takto (z DokuWiki)
Heredoc jsem kdysi používal. Dnes ti kdejaký vývojář řekne, že je to fuj. Vlastně ho stále používám pro delší SQL dotazy. Pro účel generování HTML jsem ho opustil, protože neumí ohlídat párovost HTML značek a také kvůli zmíněnému odsazení. V Pythonu se však běžně používá.
Output buffering nepoužívám, for nebo foreach v šablonách také ne.
-
To mi chceš říct, že jsi to "podělal", a na PHP, které má skvělou podporu v IDE pro refaktoring všeho, tak jsi tam úplně zbytečně dal šablonovací systém typu Thymeleaf, který má vymyšlené svoje tagy? Takže se to v IDE opět rozbije a nebude nad tím fungovat IntelliSense?
PHP má vymyšlené svoje tagy úplně stejně, jako Thymeleaf. Resp. ještě víc – Thymeleaf je navržen tak, že šablonu v Thymeleafu můžet eudělat tak, že je to pořád HTML soubour zobrazitelný v prohlížeči. To s PHP neuděláte. A IDE mají podporu pro Thymeleaf – pokud nějaké IDE podporu nemá, je to problém toho IDE.
-
Tohle uděláš jak?
<?php foreach ($users as $user): ?>
<?php if ($user === 'Bob'): ?>
<li><strong><?= $user ?></strong></li>
<?php else: ?>
<li><?= $user ?></li>
<?php endif; ?>
<?php endforeach; ?>
To mi chceš říct, že jsi to "podělal", a na PHP, které má skvělou podporu v IDE pro refaktoring všeho, tak jsi tam úplně zbytečně dal šablonovací systém typu Thymeleaf, který má vymyšlené svoje tagy? Takže se to v IDE opět rozbije a nebude nad tím fungovat IntelliSense?
Tohle řeším až v šabloně. Co kdybych nechtěl výstup v HTML, ale třeba v prostém textu nebo v PDF? Ty značky by mi tam překážely. Také je nutné ošetřit výstupní text.
-
To mi chceš říct, že jsi to "podělal", a na PHP, které má skvělou podporu v IDE pro refaktoring všeho, tak jsi tam úplně zbytečně dal šablonovací systém typu Thymeleaf, který má vymyšlené svoje tagy? Takže se to v IDE opět rozbije a nebude nad tím fungovat IntelliSense?
PHP má vymyšlené svoje tagy úplně stejně, jako Thymeleaf. Resp. ještě víc – Thymeleaf je navržen tak, že šablonu v Thymeleafu můžet eudělat tak, že je to pořád HTML soubour zobrazitelný v prohlížeči. To s PHP neuděláte. A IDE mají podporu pro Thymeleaf – pokud nějaké IDE podporu nemá, je to problém toho IDE.
Jirsák, už mi řekneš co ty jsi kdy udělal za web?
Přestaň tady žvatlat ty svoje teorie a otevři si v IntelliJ Ultimate 1 projekt v PHP, 1 projekt v Thymeleaf a k tomu 1 projekt ve starých JSP, a začni refaktorovat.
Takových hlp, co říkají, že něco je problém IDE, už jsem narazil hromadu. Naposledy takoví hlupáci, co podělají Maven build nebo Gradle build, v IntelliJ to je pořád rozbité, a pak říkají, že za to může IntelliJ a ne oni.
IntelliJ je nejlepší IDE na světě, a když něco nepodporuje ani IntelliJ, tak máš smůlu.
Běž a udělel si plugin do IntelliJ, běž a naprogramuj si vlastní Lexer, Parser a ty další věci. To všechno se musí udělat. Když refactor ani v IntelliJ nefunguje spolehlivě pro Thymeleaf, tak to znamená, že to nejde udělat, aby funguoval. Refaktoring spolehlivě funguje pouze pro JSP (ty prvotní verzi bez EL) a PHP, protože je to přímo kód jazyka.
-
A ještě refaktor zjevně funguje spolehlivě pro nejnovější Java JTE, protože rovněž je to přímo kód jazyka, jako to měly JSP ;)
Teoretik Jirsák se z toho zblázní, až se vítr zase otočí a všem dojde, že ty prvotní JSP to dělaly dobře. Thymeleaf je i po 15 letech vývoje a nejlepší možné podpoře ze strany IDE co asi jde udělat, pořád větší shit na refaktoring, než React s Javascriptem. A to je co říct. A proč to tak je? No protože React + JS + HTML (JSX) je taky "šablona-je-kód-systém" stejně tak, jako to měly ty JSP, nebo jako to už 30 let má PHP.
-
To mi chceš říct, že jsi to "podělal", a na PHP, které má skvělou podporu v IDE pro refaktoring všeho, tak jsi tam úplně zbytečně dal šablonovací systém typu Thymeleaf, který má vymyšlené svoje tagy? Takže se to v IDE opět rozbije a nebude nad tím fungovat IntelliSense?
PHP má vymyšlené svoje tagy úplně stejně, jako Thymeleaf. Resp. ještě víc – Thymeleaf je navržen tak, že šablonu v Thymeleafu můžet eudělat tak, že je to pořád HTML soubour zobrazitelný v prohlížeči. To s PHP neuděláte. A IDE mají podporu pro Thymeleaf – pokud nějaké IDE podporu nemá, je to problém toho IDE.
Jirsák, už mi řekneš co ty jsi kdy udělal za web?
Přestaň tady žvatlat ty svoje teorie a otevři si v IntelliJ Ultimate 1 projekt v PHP, 1 projekt v Thymeleaf a k tomu 1 projekt ve starých JSP, a začni refaktorovat.
Tohle nefunguje? https://www.jetbrains.com/help/idea/thymeleaf.html (https://www.jetbrains.com/help/idea/thymeleaf.html)
-
Funguje to asi nejlpíp z šablonovacích jazyků které jsem zkoušel, ale nefunguje to tak dobře, abys udělal refaktor a nemusel se jít podívat case to case co všechno sedí. IDE tomu Thymeleaf totiž 100% nerozumí.
100% fungují jen PHP, prvotní varianta JSP bez EL, nové JTE, fungoval by i JS + React refactor, ale IDE tam 100% nerozumí věcem které se týkají importů souborů, je tam kolem toho nějaký mess.
Refaktor musí fungovat na 100%, ne na 90%, protože jinak musím pokaždé ručně prolízat závislosti a ručně opravovat.
Navíc hrůza je, že nefunguje napovídání vstupních parametrů do fragmentu, a není oživená ani reference že by fungoval proklik na fragment:
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="cs">
<head><title>Users</title></head>
<body>
<h1>All Users</h1>
<a href="/users/add">Add User</a>
<ul>
<li th:each="user : ${users}">
<div th:replace="user_card :: userCard(${user.name}, ${user.email})">${user.email}</div>
<div th:text="${user.email}"></div>
<strong th:text="${user.name}">Name</strong> - <span th:text="${user.email}">Email</span>
<span th:text="${T(com.example.demo.constant.UserConstant).MY_CONST_1234}"></span>
</li>
</ul>
<span th:text="${@stringUtil.parse123('ahoj')}"></span>
</body>
</html>
A toprosím po 15 letech vývoje. A i tak má ten Thymeleaf asi nejlepší podporu v IDE, co momentálně je. A prřsto nfungují elementární věci, co i v React JS fungují.
-
Tohle nefunguje? https://www.jetbrains.com/help/idea/thymeleaf.html (https://www.jetbrains.com/help/idea/thymeleaf.html)
Samozřejmě že funguje. Funguje tam jak napovídání kódu samotných šablon, tak napovídání dat, kterými se šablona plní.
Jinak podpora jazyků a frameworků v produktech JetBrains je přímo úměrná tomu, jak moc se daná věc používá. PHP se samozřejmě používá daleko víc než Thymeleaf, JetBrains má pro PHP i samostatný produkt, tak je podpora PHP samozřejmě lepší. Což ovšem neznamená, že je PHP lepší než Thymeleaf. Hlavně je to každé něoc jiného.
Já zrovna Thymeleaf nemusím a dávám přednost Freemarkeru, když teda je důvod nepoužít JSX. Ale kvůli tomu ještě nebudu označovat Thymeleaf za zbytečný a nebudu psát nesmysly jako „vymyšlené svoje tagy“, když „vymyšlené svoje tagy“ má každý šablonovací systém a zrovna Thymeleaf se jim snaží maximálně vyhýbat (a mně to nevyhovuje a proto dávám přednost Freemarkeru).
-
Tohle nefunguje? https://www.jetbrains.com/help/idea/thymeleaf.html (https://www.jetbrains.com/help/idea/thymeleaf.html)
Samozřejmě že funguje. Funguje tam jak napovídání kódu samotných šablon, tak napovídání dat, kterými se šablona plní.
Samozřejmě že nefunguje, lenivý teoretiku Jirsáku, co si to ani nezkusíš sám zapnout, když Ideu Ultimate určitě máš. Funguje perfektně Kitovo PHP, funguje JSP a JTE, ale Thyemeleaf ani žádný jiný custom-language templatovací jazyk perfektně nefungují. A možná by nám i někdo z JetBrains dokázal vysvětlit, proč ani fungovat třeba nemůžou, protože v těch custom jazycích nich třeba něco nesedí, hapruje nebo chybí.
Fungují Šablona-Je-Kód typy templates, ale Šabloje-Je-Můj-Nový-Zbrusu-Nový-Kód templates nefunugje ani jeden.
-
Fungují Šablona-Je-Kód typy templates, ale Šabloje-Je-Můj-Nový-Zbrusu-Nový-Kód templates nefunugje ani jeden.
Když jste si vymyslel tyhle dva termíny, jistě je dokážete definovat. Bez definice nemohou ostatní vědět, o čem vlastně píšete.
-
Takhle má vypadat řádný šablonovací jazyk, a přesně takhle fungovaly JSP a 30 let podobně funguvaly PHP, to co vzniklo po JSP je oproti tomu slabota:
https://github.com/casid/jte
(https://github.com/casid/jte/raw/main/docs/jte-intellij.gif)
https://www.youtube.com/watch?v=K5DALXwOe0s
-
Takhle má vypadat řádný šablonovací jazyk, a přesně takhle fungovaly JSP a 30 let podobně funguvaly PHP, to co vzniklo po JSP je oproti tomu slabota:
https://github.com/casid/jte
To by se ti mohl líbit i XSLT, který to umí lépe. Je součástí PHP, Pythonu, Javy i Reactu. Umí i rekurzívní šablony.
-
To je zajímavý nápad, ale vyžadovalo by to generátory XSD schémat, abych mohl psát domain model třídy v tom jazyce, kterém pracuju, takže Python nebo Java.
- Bez těch XSD nebudu mít přístup k Intelli Sense v IDE
Další problém je, že si nemůžu bez toho XSLT pokud vím zavolat třeba nějakou util metodu z Backendu, takže bych musel všechno pedantsky připravit předem v Controlleru.
-
Takhle má vypadat řádný šablonovací jazyk, a přesně takhle fungovaly JSP a 30 let podobně funguvaly PHP, to co vzniklo po JSP je oproti tomu slabota:
Píšete o šablonovacím jazyku a pošlete screencast IDE. Nejdřív si ujasněte význam temrínů, co je „šablonovací jazyk“, co „IDE“, jaký je rozdíl mezi „nefunguje“ a „nedaří se mi provést konkrétní typ refaktoringu“, a pak vás ostatní nebudou opravovat, protože píšete nesmysly.
Mimochodem, to, co ukazujete na screencastu, je samozřejmě nově vytvořený jazyk, můžete se na to dívat i jako na custom tagy.
-
vyžadovalo by to generátory XSD schémat
Které samozřejmě existují.
Další problém je, že si nemůžu bez toho XSLT pokud vím zavolat třeba nějakou util metodu z Backendu
Ale můžete. Podporuje to jak Saxon (nejlepší XSLT procesor pro Javu), dokonce několika způsoby, tak i Xalan.
-
To je zajímavý nápad, ale vyžadovalo by to generátory XSD schémat, abych mohl psát domain model třídy v tom jazyce, kterém pracuju, takže Python nebo Java.
- Bez těch XSD nebudu mít přístup k Intelli Sense v IDE
Další problém je, že si nemůžu bez toho XSLT pokud vím zavolat třeba nějakou util metodu z Backendu, takže bych musel všechno pedantsky připravit předem v Controlleru.
XSD pro XSLT si můžeš stáhnout, v tom nevidím problém, ale nepoužívám ho.
Dále je zbytečné vytvářet XML jako mezičlánek. DOM plně vyhovuje.
Z XSLT je možné volat funkci z PHP. Jen je nutné ji registrovat v XSLT procesoru. V Pythonu a Javě to určitě bude také. Ovšem tím je omezena přenositelnost mezi těmito jazyky - vidí to jen ten konkrétní jazyk v PI. Osvědčila se mi ta pedantská příprava dat ve View - Controller používám jen pro modifikaci dat, View pro jejich zobrazení. Šablona je pak řízena tokem těchto dat, mohu tedy použít jedinou šablonu pro všechny stránky aplikace.
-
To je zbytečné bych tu něco psal, nikdo jiný než Kite nebo Jirsák se tu už do diskuze nezapojí.
ještě jednou - řeším tady podporu pro refaktoring pro šablonovací jazyky v IDE, která je špatná, vyjma šablonovacích jazyků psaných ve stylu "šablona se transformuje do kódu" jako JSP, PHP, ASP, JTE.
XSLT nevyhovuje, protože:
1. Musel bych si napsat generování XSD schémat, abych měl při psaní XSLT funkční Intelli Sense pro přístup k modelovým třídám
2. Generování XSD mi zpomalí start aplikace a bude s tím opruz
3. Ikdyž bych to udělal, pořád mi nebude fungovat refaktoring - tzn. když změním atribut v modelové třídě, tak IDE změnu nepropíše automaticky i do XSLT souborů.
4. Funkce sice z XSLT volat můžu, ale musel bych vyrábět další XSD, kde je budu muset ručne definovat, katastrofa
5. A opět mi ani u funkcí nebude automaticky fungovat refaktoring názvů těch funkcí.
Katastrofa. XSLT v ničem z toho, co tu řeším, nepomůže.
-
1. Musel bych si napsat generování XSD schémat, abych měl při psaní XSLT funkční Intelli Sense pro přístup k modelovým třídám
Jsem líný psát XSD schémata a protože je nepotřebuji, tak je nedělám. XSLT mi funguje perfektně i bez nich.
XSLT nevnucuji, jen jsem ho navrhl jako alternativu. Je to jedna šablona pro všechny jazyky, které používáš.
-
ještě jednou - řeším tady podporu pro refaktoring pro šablonovací jazyky v IDE, která je špatná, vyjma šablonovacích jazyků psaných ve stylu "šablona se transformuje do kódu" jako JSP, PHP, ASP, JTE.
Všechny šablony se transformují do kódu. Vy pořád vymýšlíte nějaké vlastní termíny, kterým nerozumíte ani vy sám, a pak se divíte, že vám nikdo nerozumí. A na základě těchto výmyslů pak děláte dalekosáhlé závěry, které nemají nic společného s realitou.
-
Jirsák nekecej. JSP se tranformovalo do Servletu, dokonce v Eclipse šlo na JSP soubor kliknout a nechat si zobrazit ten vygenerovaný Java Servlet.
Thymeleaf a podobné to dělá kdoví jak, ale určitě jinak, protože IDE jim pořádně nerozumí.
Takhle Jirsoš funguje "Šablona je kód ®":
Mám PHP. Tohle je PHP kód:
<?php
$furtTrableSJirsakem = true;
?>
A pak mám výraz:
<?= Util::localize("Filtr", "Filter") ?>
Který se přeloží vždycky takto:
<?php
echo Util::localize("Filtr", "Filter");
?>
Done. Hotovo. Kapiš to? To je celé.
A teď se poď znovu hádat o tom, jak v IDE není řádná podpora pro 100% fungující refactoring v Thymeleaf nebo v čemkoliv podobném, co vymýšlí jakési svoje konstrukce.
-
Všechny šablony se transformují do kódu.
Otázkou je, co je myšleno tím kódem. Latte je transformováno do PHP a poté kompilováno a provedeno. XSLT je transformováno do stromu DOM, který poté slouží jako procesor pro vstupní data. Tím dosahuje vyššího výkonu než běžné šablony.
-
Ještě jednou pro méně chápavé, takto vypadá "Šablona je kód". Mám v PHP (JSP,ASP) tohle:
<h1>Seznam uživatelů</h1>
<ul>
<?php foreach ($users as $user): ?>
<li><?= htmlspecialchars($user['name']) ?></li>
<?php endforeach; ?>
</ul>
A přeloží se to na tohle:
<?php
echo "<h1>Seznam uživatelů</h1>\n";
echo "<ul>\n";
foreach ($users as $user) {
echo " <li>" . htmlspecialchars($user['name']) . "</li>\n";
}
echo "</ul>\n";
?>
Není divu, že IDE, které má 100% podporu pro PHP, tak bez potíží i dokáže mít 100% podporu pro výše uvedené, aby se v tom dalo zcela bez výhrad refaktorovat.
-
A přeloží se to na tohle:
K takovému překladu do PHP vůbec nedochází, ale obě zmíněné šablony jsou přeloženy do binárního mezikódu, který je následně interpretován.
-
Ale já to chápu celou dobu – vymýšlíte si nemyslné termíny, kterým sám neorzumíte; a vymýšlíte si nesmyslné konstrukce.
Každá šablona se nakonec přeloží do instrukcí, které se provedou na procesoru. Někdy je tam víc kroků překladu, někdy jen jeden. Někdy se ty kroky překladu dají jednoduše serializovat, někdy jsou jen v paměti. Někdy se dokonce dají serializovat do nějakého běžného programovacího jazyka, jindy to je třeba jen nějaký AST. To, že se JSP překládaly do zdorjového kódu Javy, byla mezi šablonami spíše výjimka. A IDE to vůbec nijak nepomáhá – například pro to, že IDE potřebuje mít obousměrnou vazbu mezi kódem a jeho vnitřní reprezentací, a zatímco každé JSP můžete přeložit do Servletu, ne každý Servlet můžete přeložit do JSP. Takže používat v IDE pro reprezentaci JSP formu přeloženou do Servletu by bylo velmi kontraproduktivní.
-
100% fungují jen PHP, prvotní varianta JSP bez EL, nové JTE
JTE je jen další template engine, který má taky "vymyšlené svoje tagy". Jen mu prostě udělali dobrý plugin do Intellij. Není to, že to "samo funguje", protože to vypadá jako Java. Zdrojáky IDE pluginu mají 7247 řádků ve 136 souborech.
Navíc tyhle "template je kód" svádí k prasení, kdy po chvíli lidi začnou dělat DB dotazy v šabloně, protože to jde. Někomu to vyhovuje (než se v tom zamotá tak, že musí celý projekt zahodit/přepsat), jiní mají radši striktnější oddělení...
-
Navíc tyhle "template je kód" svádí k prasení, kdy po chvíli lidi začnou dělat DB dotazy v šabloně, protože to jde. Někomu to vyhovuje (než se v tom zamotá tak, že musí celý projekt zahodit/přepsat), jiní mají radši striktnější oddělení...
Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.
V šabloně se dá udělat kdeco.
-
Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.
V šabloně se dá udělat kdeco.
Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).
-
Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.
V šabloně se dá udělat kdeco.
Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).
Byla to třída XSLTProcessor v PHP. Byl to asi milión položek ceníku, který jsem nejprve natáhl do DOM. SAXem to ani nemělo smysl parsovat, protože ten je v PHP šíleně pomalý. XSLT jelo rychle, úzkým hrdlem pak byla databáze. Je to už dávno, tenkrát bylo aktuální PHP 5.3.
-
Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).
Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?
-
Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).
Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?
Já? Ten objem dat není moc velký, takže pokud bych nad těmi daty nepotřeboval před nalitím do databáze provádět nějakou složitější byznys logiku, použil bych XSLT (Saxon). Pokud by tam byla složitější logika, napsal bych si to v Groovy nebo v Javě s použitím dom4j.
-
Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?
Já? Ten objem dat není moc velký, takže pokud bych nad těmi daty nepotřeboval před nalitím do databáze provádět nějakou složitější byznys logiku, použil bych XSLT (Saxon). Pokud by tam byla složitější logika, napsal bych si to v Groovy nebo v Javě s použitím dom4j.
To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.
-
Použít XSLT nebo vlastní kód na ty potřebné úpravy je OK, ale na samotné rychlé nalití výsledku do MySQL je doporučováno použít LOAD DATA příkaz.
-
To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.
Saxon je jen XSLT 3.0 procesor s nějakými rozšířeními. Placená verze má rozšíření SQL, ale já jsem takové věci řešil tak, že jsem pomocí XSLT vygeneroval SQL skript. Kdyb potřeboval přímo při práci s XML spouštět SQL příkazy, spíš bych to napsal v Groovy nebo Javě. Pokud bych to řešil v XSLT, apostrofy v datech bych asi vyřešil funkcí replace.
Do Saxonu se dají psát i vlastní funkce a rozšíření, ale už to není tak jednoduché, takže pro jednorázovou věc se to nevyplatí.
Ale ono to hodně závisí na konkrétní situaci. Někdy jsem to XML třeba potřeboval nejdřív prozkoumat, takže jsem psal různé XPath výrazy, abych zjistil, co je tam vlastně za data. A pak už jsem měl sadu XPath výrazů, které stačilo jen trochu obalit do XSLT a bylo hotovo. Jindy k tomu zase potřebuju dodělat stažení souboru odnkěud z HTTP, rozzipování, nějaké zpracování textů uvnitř elementů. A to XML je jen posloupnost záznamů, vpodstatě XSV převedené do XML – tak to radši zpracuju v Javě nebo Groovy, protože pracuju vždy jen s jedním záznamem, takže bych nevyužil sílu XSLT, a dokážu tak zpracovat potenciálně nekonečný XML.
-
To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.
Saxon pro jednorázové importy i velkých dat (různé číselníky, exporty) používám taky. Zrovna u MySQL je výhoda, že má přímo funkci pro natažení XML, která je relativně velmi rychlá (v rámci zpracování s jedním připojením).
https://dev.mysql.com/doc/refman/8.4/en/load-xml.html
Takže vstupní XML transformuju podle XSLT Saxonem na dočasný XML pro import se strukturou cílové tabulky (nebo víc, pokud je potřeba), a následně natáhnu zmíněným LOAD XML třeba přes mysql konzolový klient.
Samozřejmě pokud by šlo o něco periodického nebo bych třeba chěl využít třeba segmentování dat a víc spojení do db, něco bych si napsal.
-
To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.
Saxon je jen XSLT 3.0 procesor s nějakými rozšířeními. Placená verze má rozšíření SQL, ale já jsem takové věci řešil tak, že jsem pomocí XSLT vygeneroval SQL skript. Kdyb potřeboval přímo při práci s XML spouštět SQL příkazy, spíš bych to napsal v Groovy nebo Javě. Pokud bych to řešil v XSLT, apostrofy v datech bych asi vyřešil funkcí replace.
Do Saxonu se dají psát i vlastní funkce a rozšíření, ale už to není tak jednoduché, takže pro jednorázovou věc se to nevyplatí.
Na ty mé účely vyhovuje XSLT 1.0, které poskytuje utilita xsltproc nebo v PHP třída XSLTProcessor. Právě to druhé jsem použil, protože umožňuje v XPath použití php:function(...)
Ale ono to hodně závisí na konkrétní situaci. Někdy jsem to XML třeba potřeboval nejdřív prozkoumat, takže jsem psal různé XPath výrazy, abych zjistil, co je tam vlastně za data. A pak už jsem měl sadu XPath výrazů, které stačilo jen trochu obalit do XSLT a bylo hotovo. Jindy k tomu zase potřebuju dodělat stažení souboru odnkěud z HTTP, rozzipování, nějaké zpracování textů uvnitř elementů. A to XML je jen posloupnost záznamů, vpodstatě XSV převedené do XML – tak to radši zpracuju v Javě nebo Groovy, protože pracuju vždy jen s jedním záznamem, takže bych nevyužil sílu XSLT, a dokážu tak zpracovat potenciálně nekonečný XML.
Tohle vše zvládá i PHP, ve kterém byl napsán celý e-shop. Jen s tím nekonečným XML by to bylo trochu horší, protože SAX je v PHP docela pomalý. Tedy aspoň tenkrát byl.
Saxon pro jednorázové importy i velkých dat (různé číselníky, exporty) používám taky. Zrovna u MySQL je výhoda, že má přímo funkci pro natažení XML, která je relativně velmi rychlá (v rámci zpracování s jedním připojením).
https://dev.mysql.com/doc/refman/8.4/en/load-xml.html
Takže vstupní XML transformuju podle XSLT Saxonem na dočasný XML pro import se strukturou cílové tabulky (nebo víc, pokud je potřeba), a následně natáhnu zmíněným LOAD XML třeba přes mysql konzolový klient.
Samozřejmě pokud by šlo o něco periodického nebo bych třeba chěl využít třeba segmentování dat a víc spojení do db, něco bych si napsal.
Saxon je asi nejlepším nástrojem, ale pokud vím, tak nespolupracuje s PHP. Musel bych tuto část aplikace poskládat jinak. LOAD XML mi tenkrát nechtěl fungovat podle mých představ.
Pokud vím, tak žádný framework tohle neřeší. Přesněji podle původního algoritmu to trvalo víc než 24 hodin a bylo to nutné spouštět automaticky denně.
-
Chápu, ž epoužíváte, co máte dostupné v nástrojích, na které jste zvyklý. Ale nemůžu nezmínit, že XSLT 2.0 je výrazně bohatší, než XSLT 1.0 – umožňuje to přímo v XSLT řešit spoustu věcí, které se v XSLT 1.0 musely složitě obcházet nebo řešit pre- nebo post-processingem.
Existuje i varianta SaxonC, která se dá použít z PHP (https://www.saxonica.com/saxon-c/documentation12/index.html#!api/saxon_c_php_api). Ale víc o tom nevím a nevím, jak je na tom v porovnání s „originálním“ Saxonem v Javě.
To php:function(…) je samozřejmě mocný nástroj. V tomhle měla Java nevýhodu, že vkládat do Javy skripty nebylo snadné. Pak vzniklo Java Scripting API a dnes by bylo nejlepší napojit to na GraalVM Truffle, ale pokud vím, nic z toho Saxon out-of-box nepodporuje.
-
Chápu, že používáte, co máte dostupné v nástrojích, na které jste zvyklý. Ale nemůžu nezmínit, že XSLT 2.0 je výrazně bohatší, než XSLT 1.0 – umožňuje to přímo v XSLT řešit spoustu věcí, které se v XSLT 1.0 musely složitě obcházet nebo řešit pre- nebo post-processingem.
I v XSLT 1.0 se dá dělat hodně věcí, například dvojitý průchod jednou šablonou, kterým se dá udělat i ten postprocessing. Zatím mě to nenutí do vyšší verze, která je sice lepší, ale nemá podporu v PHP. Na obyčejném webhostingu si vývojář nemůže moc vymýšlet.
-
Ještě jednou pro méně chápavé, takto vypadá "Šablona je kód". Mám v PHP (JSP,ASP) tohle:
<h1>Seznam uživatelů</h1>
<ul>
<?php foreach ($users as $user): ?>
<li><?= htmlspecialchars($user['name']) ?></li>
<?php endforeach; ?>
</ul>
A přeloží se to na tohle:
<?php
echo "<h1>Seznam uživatelů</h1>\n";
echo "<ul>\n";
foreach ($users as $user) {
echo " <li>" . htmlspecialchars($user['name']) . "</li>\n";
}
echo "</ul>\n";
?>
Ne, nepřeloží. Všechno mimo PHP tagy se ignoruje a parser to pustí přímo do výstupu, to je naprostý základ.
When PHP processes a file, it recognizes the opening and closing tags, <?php and ?>, to define the boundaries of PHP code execution. Content outside these tags is ignored by the PHP parser, allowing PHP to seamlessly embed in various document types.
https://www.php.net/manual/en/language.basic-syntax.phptags.php
-
No, to je jedno, každopádně faktem zůstává to, že JSP, JTE a PHP mají 100% fungující IntelliSense a to jako jediné frameworky. Všechno ostatní má IntelliSense s výhradami. React a JS obecně má lepší IntelliSense než Thymeleaf. A největší katastrofa a zklamání je Freemaker, který sice má plně funkcí Intelli Sense pro všechno, co jsem ve Spring MVC controlleru dovniř do template, ale už ten plugin nedokáže zachytit ani to, že si udělám třeba ControllerAdvice, kde si chci vložit svoje util metody pokaždé do modelu. Takže nepoužitelné. A to už je to tady 30 let.
Poučení které z toho pro mě plyne - jakmile uvidím nějaký šablonovací systém, co má IntelliSesnse založený na dedukci toho, s čím se kdesi ve zdrojácích volá render metoda, tak zdrhám pryč. Protože je jasné, že to bude fungovat jako na baterky.
Já už mám pokrk nefungujícího našeptování v templates.
-
Poučení které z toho pro mě plyne - jakmile uvidím nějaký šablonovací systém, co má IntelliSesnse založený na dedukci toho, s čím se kdesi ve zdrojácích volá render metoda, tak zdrhám pryč. Protože je jasné, že to bude fungovat jako na baterky.
Já už mám pokrk nefungujícího našeptování v templates.
K čemu vlastně v dnešní době potřebuješ IntelliSense v šablonovacích systémech?
-
A presne kvoli takymto diskusiam uz takmer vobec nechodim na root. 5 stran, infromacna hodnota nula.
-
A presne kvoli takymto diskusiam uz takmer vobec nechodim na root. 5 stran, infromacna hodnota nula.
Co jsi čekal od tématu framework vs. vanilla?
-
Napriklad, ze sa tu nebude traposit z XSD
-
No, to je jedno, každopádně faktem zůstává to, že JSP, JTE a PHP mají 100% fungující IntelliSense a to jako jediné frameworky. Všechno ostatní má IntelliSense s výhradami. React a JS obecně má lepší IntelliSense než Thymeleaf. A největší katastrofa a zklamání je Freemaker, který sice má plně funkcí Intelli Sense pro všechno, co jsem ve Spring MVC controlleru dovniř do template, ale už ten plugin nedokáže zachytit ani to, že si udělám třeba ControllerAdvice, kde si chci vložit svoje util metody pokaždé do modelu. Takže nepoužitelné. A to už je to tady 30 let.
Poučení které z toho pro mě plyne - jakmile uvidím nějaký šablonovací systém, co má IntelliSesnse založený na dedukci toho, s čím se kdesi ve zdrojácích volá render metoda, tak zdrhám pryč. Protože je jasné, že to bude fungovat jako na baterky.
Já už mám pokrk nefungujícího našeptování v templates.
Zkus Windsurf plugin, je to AI (nejen) našeptávač a myslím že je i v základu free.
-
Napriklad, ze sa tu nebude traposit z XSD
Pokud tě zajímá traposit z XSD, tak ses mohl zeptat nebo si založit nové vlákno. Osobně XSD nepoužívám, ale respektuji ho. A XSLT je také možné považovat za framework.
-
Ahoj, mam dotaz na vas profesionaly.
Kamarad mi rikal ze opravdovy programator nepouziva framework. Prirovnava to k horolezci s kyslikem (framework) a bez kysliku (real programator). Framework je podle nej vlastne "podvod"...
Co si o tomto nazoru myslite?
Kamarád není opravdový programátor. Opravdový programátor používá prostředky, které jsou vhodné pro aktuální situaci.
To co popisujete, je spíš NIH (https://en.wikipedia.org/wiki/Not_invented_here) syndrom, a výsledek bude nepoužitelný a děravý. Jsem takhle od stolu na 100% schopný říct, že kamarád nebude schopný napsat dobře kryptografickou knihovnu, a nejspíš pravidelně bude dělat chyby i při implementaci složitějších algoritmů. A pokud každá re-implementace kola bude obsahovat kompletní sadu testů (včetně testů kompatibility s jinými implementacemi), tak celkový čas strávený na programování bude časem vyhozeným z okna.
Opravdový programátor se taky zabývá zajímavými a zábavnými věcmi. A to reimplementace spousty věcí, které již mají kvalitní implementaci, fakt není.
-
Opravdový programátor se taky zabývá zajímavými a zábavnými věcmi. A to reimplementace spousty věcí, které již mají kvalitní implementaci, fakt není.
Bohužel pro spoustu lidí jo, a proto taky je NIH tak rozšířená věc (sám k tomu mám sklony a často se musím krotit, abych použil knihovnu, která třeba nedělá 100% to, co bych chtěl, a nezačal si to psát sám)
-
Jsem takhle od stolu na 100% schopný říct, že kamarád nebude schopný napsat dobře kryptografickou knihovnu, a nejspíš pravidelně bude dělat chyby i při implementaci složitějších algoritmů. A pokud každá re-implementace kola bude obsahovat kompletní sadu testů (včetně testů kompatibility s jinými implementacemi), tak celkový čas strávený na programování bude časem vyhozeným z okna.
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ě.
-
Pokud framework vnucuje styl chybně, jde o chybně vybraný framework.
-
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ě.
A ještě častěji ten framework vnucuje styl, který je lepší, než jak by to ten vývojář napsal bez frameworku.
-
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).
Tohle umí řešit frameworky, jako např. v Pythonu by to bylo Django a v Javě thymeleaf, které mi umožní si definovat modelové třídy pro jednotlivé formuláře. Bohužel v případě Djanga přichází i řada více méně vnuceným "magic" features, jako je jejich in-built orm a další.
Jakmile ale mám podporu pro to, že si definuju modelovou třídu a ve formáři už používám tento model, tak už je to velice blízké Reactu, kde toho samého dosáhnu "přirozeně" přes JSON.
Co mě hodně sejre je to, že výše uvedené uměl ASP.NET od Micosoftu už dávno jakožto tzv. WebForms, podle robota už od roku 2003. Dělal jsem v tom jen kdysi na výšce, takže nevím, co tam harpuje nehapruje (Jak už jsem řekl, haprující podpora pro templaty v iDE mě už totálně dneska točí).
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.
Dneska už jsou ty výše uvedené technologie podle mě na odpadlišti dějin (snad možná kromě PHP), podporu pro Thymeleaf už nikdo nikdy v IDE nefixne a fragmenty nikdo nespraví, je to minulost, všechno už se zaměřilo na React a podobné JS frameworky a v JetBrains to asi moc dobře ví a soustředí podporu tady na tohle.
Bohužel ve světě těch web technologii vzniklo totální odpadiště, a jeden ze strůjců je neschopná firma Oracle a komunita kolem. To co se dělo za těch 30 let v Javě to je totální šílenství a binec.
-
Pokud framework vnucuje styl chybně, jde o chybně vybraný framework.
Když se jedná o Nette, tak nikoho nezajímá, že je špatně vyprojektován.
-
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ší.
-
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í.
-
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...
-
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.
-
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.
$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.
t('Drupal is great');
-
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.
$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.
t('Drupal is great');
A v čem je ta výhoda?
-
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.
$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.
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 :)
-
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.
-
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.
-
Zatímco třeba Drupal na to má funkci, čili výrazně kratší zápis.
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()
-
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)
-
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ří
-
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ě.
-
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..
-
mel bys ve svych tridach pouzit \Drupal\Core\StringTranslation\StringTranslationTrait::t()
Takže místo jedné globální funkce dávat do X tříd trait? Který navíc při každém volání vytváří novou instanci TranslatableMarkup namísto toho, aby si držel jednu statickou?
Díky za praktickou ukázku, proč se Drupalu po přechodu na Symfony nedotýkat ani dvoumetrovou tyčí.
-
Na to nemam odpoved, ale pro tyhle zpatecnici je tady Backdrop.
-
Že je to blbost.
Čistý kód je jako stavět klasický panelák a vozit si na jeho stavbu písek, cement, vodu - a beton míchat na místě - protože vozit hotové panely je podvod ;D .
Problém je, že nevieš čo ti do tých panelov namiešali a či by si si ho nenamiešal ty sám lepšie. ;D
-
mel bys ve svych tridach pouzit \Drupal\Core\StringTranslation\StringTranslationTrait::t()
Takže místo jedné globální funkce dávat do X tříd trait?
Ty určitě výš, jaký je rozdíl, výhody a nevýhody, mezi použití globální funkce a použití lokální instance, že jo? Že jo!?
-
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.
A já ho klidně použiju i v tomto případě, pokud ho mám v hlavě, a pokud se domnívám, že mi to výrazně urychlí nebo usnadní práci.
Zrovna teď jsem zkoušel nějaký triviální experiment. Ale vyžadovalo to určité netriviální minimum. A já blbec jsem si to začal psát ručně, že to stačí.
-
Že je to blbost.
Čistý kód je jako stavět klasický panelák a vozit si na jeho stavbu písek, cement, vodu - a beton míchat na místě - protože vozit hotové panely je podvod ;D .
Problém je, že nevieš čo ti do tých panelov namiešali a či by si si ho nenamiešal ty sám lepšie. ;D
Problém je, že zatímco u těch panelů to každý chápe, jaký je nesmysl myslet si, že ty panely udělám líp než betonárka, u programování to spousta lidí nechápe.
Mnozí také porovnávají „co umí cizí knihovna“ versus „co by mohla umět moje knihovna, kdybych měl neomezený čas a zdroje ji napsat“ (a někdy by to těch podmínek patřily i znalosti či schopnosti to napsat).
-
Že je to blbost.
Čistý kód je jako stavět klasický panelák a vozit si na jeho stavbu písek, cement, vodu - a beton míchat na místě - protože vozit hotové panely je podvod ;D .
Problém je, že nevieš čo ti do tých panelov namiešali a či by si si ho nenamiešal ty sám lepšie. ;D
A jakej je problém se kouknout do zdrojaku daného frameworku? Když to bude bordel v kterém se nevyznám a nebude dobrá dokumentace, tak je to dost dobrej signál se tomu vyvarovat.
-
Že je to blbost.
Čistý kód je jako stavět klasický panelák a vozit si na jeho stavbu písek, cement, vodu - a beton míchat na místě - protože vozit hotové panely je podvod ;D .
Problém je, že nevieš čo ti do tých panelov namiešali a či by si si ho nenamiešal ty sám lepšie. ;D
A jakej je problém se kouknout do zdrojaku daného frameworku? Když to bude bordel v kterém se nevyznám a nebude dobrá dokumentace, tak je to dost dobrej signál se tomu vyvarovat.
Tímto přístupem zavrhneš většinu frameworků, protože se do těch zdrojáků nedá koukat bez zvracení.
-
Tímto přístupem zavrhneš většinu frameworků, protože se do těch zdrojáků nedá koukat bez zvracení.
Já viděl tvůj kód.
-
Tímto přístupem zavrhneš většinu frameworků, protože se do těch zdrojáků nedá koukat bez zvracení.
Já viděl tvůj kód.
Nepíši frameworky.
-
Tímto přístupem zavrhneš většinu frameworků, protože se do těch zdrojáků nedá koukat bez zvracení.
Já viděl tvůj kód.
Nepíši frameworky.
Díky bohu za ty dary.
-
Tímto přístupem zavrhneš většinu frameworků, protože se do těch zdrojáků nedá koukat bez zvracení.
Já viděl tvůj kód.
Nepíši frameworky.
Díky bohu za ty dary.
Doufám, že ty taky ne.