Framework vs. čistý kód

[Kit]

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.

[Reklama]

[BlackMagic]

Ještě jednou pro méně chápavé, takto vypadá "Šablona je kód". Mám v PHP (JSP,ASP) tohle:

Kód: [Vybrat]

<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:

Kód: [Vybrat]

<?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

[registrovany123]

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.

[Kit]

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?

[oss]

A presne kvoli takymto diskusiam uz takmer vobec nechodim na root. 5 stran, infromacna hodnota nula.

[Reklama]

[Kit]

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?

[oss]

Napriklad, ze sa tu nebude traposit z XSD

[Ondrejjj]

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.

[Kit]

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.

[Ondřej Surý]

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 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í.

[snugar_i]

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)

[Kit]

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ě.

[Vít Šesták (v6ak)]

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

[Filip Jirsák]

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.

[registrovany123]

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.