Jaký webový framework zvolit?

[Miloslav Ponkrác]

jano7: Ano, a přesně takový bordel vzniká, když jazyk nemá svůj standard. Pak se vyvíjí pouze stylem nalepovák na nalepovák, a ve výsledku je jazyk plný nelogičností a nekonzistence.

[Reklama]

[agent]

Kód: [Vybrat]

int x = 100;
double y = x + 0.0e0;
System.out.println(x == y);

Java vráti true.
C# vráti True.
Perl vráti 1.
...
JavaScript vráti true true.

Pro "==" vrátí true i PHP.
Celou dobu šlo o "===" sledující shodu hodnoty i typu operandů.
Javascript se u "===" zachová jinak než PHP, protože pro čísla zná pouze jediný datový typ Number, na rozdíl od PHP rozlišujícího int a float.
Takže vše se chová dle očekávání příslušného jazyka.

[Honza]

Jen tak pro zajímavost (Javascript)

Kód: [Vybrat]

typeof NaN === 'number'
/*
true
*/

[Jano7]

Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.

Áno, to je rozumný predpoklad. Nedá sa však na neho spoliehať vždy. Napríklad Java a databázové drivery. Tie by sa mali správať podľa nejakého štandardu, ale v praxi to často neplatí. Našiel som v zdrojáku Spring JdbcTemplate (nadstavba nad JDBC) takýto koment: We don't trust the JDBC driver: It might throw RuntimeException or Error. Preto som chcel nájsť niekde explicitne proste napísané -- netreba uzavierať connection object. Nič také som nenašiel.

Pro výjimky platí to co všude.

a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.
b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.
c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.

V mojom prípade by to malo byť a. Ale mne sa jednoducho nepáči kód "zasvinený" try/catch blokmi. Preto by som rád to nechal plávať vyššie. Neviem či sa dajú priamočiaro preniesť best practices z Javy to PHP; Java zásadne vždy robí všetko komplexne a zložito. Rád by som našiel aj k výnimkám niečo ako the PHP way, ale nepodarilo sa. Pozdával sa mi názor z PHP delusions, ktorý som uviedol, avšak to je názor len z jedného zdroja a tak som opatrný.

[Jano7]

Jen tak pro zajímavost (Javascript)

Kód: [Vybrat]

typeof NaN === 'number'
/*
true
*/

Kód: [Vybrat]

<?php

echo FALSE == NULL;
ECHO FALSE == NULL;
eCHo FALSE == NULL;

Vypíše 111.

[Reklama]

[Miloslav Ponkrác]

Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.

Áno, to je rozumný predpoklad. Nedá sa však na neho spoliehať vždy. Napríklad Java a databázové drivery. Tie by sa mali správať podľa nejakého štandardu, ale v praxi to často neplatí. Našiel som v zdrojáku Spring JdbcTemplate (nadstavba nad JDBC) takýto koment: We don't trust the JDBC driver: It might throw RuntimeException or Error. Preto som chcel nájsť niekde explicitne proste napísané -- netreba uzavierať connection object. Nič také som nenašiel.

Pokud nic nenajdete, tak nic nezavírejte. Pokud máte něco zavřít, tak to bude zmíněno.

Je dost neobvyklé, aby podprogram likvidoval objekty a zdroje, které dostane jako parametr. Patří to ke špatným způsobům. Pokud je to nutné či účelné či očekávané, aby podprogram zavřel/zlikvidoval objekt, většinou se o tom píše, protože to intuitivně nikdo nečeká.

[Miloslav Ponkrác]

Pro výjimky platí to co všude.

a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.
b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.
c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.

V mojom prípade by to malo byť a. Ale mne sa jednoducho nepáči kód "zasvinený" try/catch blokmi. Preto by som rád to nechal plávať vyššie. Neviem či sa dajú priamočiaro preniesť best practices z Javy to PHP; Java zásadne vždy robí všetko komplexne a zložito. Rád by som našiel aj k výnimkám niečo ako the PHP way, ale nepodarilo sa. Pozdával sa mi názor z PHP delusions, ktorý som uviedol, avšak to je názor len z jedného zdroja a tak som opatrný.

PHP si samo se sebou neví moc rady. Doporučuji prostě přenést obecné best practices, jen tak dáte PHP štábní kulturu.

Java některé věci dělá dobře, jinými věcmi zase spíše kompenzuje to, že jazyk nic neumí, je příliš jednoduchý. Ale ve výjimkách to dělá spíše dobře.

Osobně se nevyhýbám kódu plnému try/catch, když to má smysl. Myslím, že nejlepší co se dá udělat je vyřešit chybu/výjimku co nejblíže místu, kde vznikla. Tedy, pokud umím na nějakém místě ošetřit chybu/výjimku, tak to udělám.

1) Pokud mohu šíření výjimky zcela zastavit a převést program do stabilního stavu, je to moje první snaha.

2) Pokud chytám výjimku, jejíž typ a popis je příliš low level, a směrem nahoru se nehodí, tak výjimku zachytím a vyhodím vhodnější. Například pro funkci getCachedImage() se příliš nehodí vyhodit výjimku FileNotFoundError(), ale je lépe ji změnit na CachedImageNotFoundError(). Funkce výše nemusejí vědět, jak je kešovaný obrázek uložen, je zajímá, že ho nelze získat.

Cílem je posílat nahoru co nejméně chyb a výjimek. Pokud je možné něco vyřešit na místě, nechť je to vyřešeno. Ošetřování chyb je vždy "nehezké", nehledím proto na počet try/catch, či počet if/elseif či dalšího. Nejlepší možný stav je mít kód, který generuje co nejméně chyb směrem nahoru, a posílá chyby/výjimky jen tehdy, když to nejde řešit jinak.

Dalším cílem je posílat nahoru (volajícím) chyby, kterým "hořejšek" (volající) rozumí. Viz ad 2).

Každý framework/program by měl mít na úrovni funkce main() zachytávač všech nezpracovaných výjimek, které převede do nějakého rozumného hlášení uživateli a případně zaloguje. To je ale věc frameworku, to by uživatel řešit neměl.

***

Co by se nikdy dít nemělo, je zachycovat všechny výjimky bez ošetření. Toto je prasárna hrubého zrna, za kterou by měl jít programátor klečet na hrách:

try { ... } catch (Throwable/Exception $e) {} # PHP 7 = Throwable, PHP 5 = Exception

***

Nejtěžší je u projektu vymyslet vlastní strom tříd výjimek, aby byl logický a dobře, přitom jednoduše, vyjadřoval možné chyby v kódu.

[karel]

Už výjimky nevycházejí z \Exception, ale z \Throwable.

Výjimky stále vycházejí z \Exception. Throwable je jen interface, které \Exception implementuje.

Protože PHP nenabízí ani kompilaci do binárního/p-kódu, při každém HTTP requestu se znovu a znovu kompiluje jako u pitomců

To není pravda už od verze 5.5 (před 6 lety). Načtení, parsování a kompilování php skriptu proběhne jen při prvním požadavku na něj. Při každém dalším požadavku Zend Engine už jen provádí zkompilovaný opcode z opcache - obrázek.

[Miloslav Ponkrác]

Výjimky stále vycházejí z \Exception. Throwable je jen interface, které \Exception implementuje.

A proto existuje v PHP 7 řada tříd výjimek, které nejsou potomky třídy \Exception. To je velice skvělé, doporučuji tyto kraviny dělat tvůrcům PHP co nejčastěji. PHP je historicky první programovací jazyk, který programátorům pod rukou změnil prapředka tříd výjimek.

Zvláště je třeba ocenit, že PHP udržuje bdělost programátorů. Změnit tak rozsáhle způsoby oznamování chyb v jazyce i knihovnách - to je na popravčí četu.

To není pravda už od verze 5.5 (před 6 lety). Načtení, parsování a kompilování php skriptu proběhne jen při prvním požadavku na něj. Při každém dalším požadavku Zend Engine už jen provádí zkompilovaný opcode z opcache

Aspoň jedna pozitivní zpráva. Třeba to příště na druhý pokus dokáží kompilovat do souboru jako běžné programovací jazyky.

[blahblablah]

a tak bych byl rád kdyby mi zde raději někdo porovnal Python a Node.js (a to jak z technické stránky tak i po stránce uplatnění těch technologií v praxi apod...)
Případně navhrněte i nějakou další alternativu.

Mám čerstvou zkušenost z firmy, kde se postupně použily všechny 3 zmiňované technologie.

Začalo to 2 vzájemně propojenými projekty v Nette (web a api zvlášť, ale nad stejnou db), které z různých (i netechnických) důvodů doiterovaly do hrůzy, kterou nikdo neuměl dát do kupy. Kromě jiných faktorů tam ale hrálo i roli to, že Nette je takové trochu nedodělané a věci, které jiné frameworky (nejen Django, ale třeba i Laravel) mají vyřešené, se řešily ručně.

Tým na to reagoval tak, že začali tlačit Node.js. Vzniklo dost microservices, které se nasekaly rychle, ale problém byl ve dvou věcech:
1) neexistence jasných standardů vedla k tomu, že každá služba byla udělaná jinak
2) velká rychlost jakou se proměňuje JS ekosystém - zažili jsme přechod npm -> yarn, kterým se rozbilo pár věcí nečekaným způsobem, callbacky -> Promise (různými způsoby: es6-promisify, bluebird a já nevím co ještě) -> async/await. i neustálé náhrady nějakých knihoven (node-uuid -> uuid, apod.).

Výsledkem bylo to, že na můj vkus se příliš energie věnovalo neustálým přepisům a refaktorům místo přidávání fíčur.

Nakonec jsme se dostali k tomu, že jsme jak zastaralé Nette, tak progresivní Node.js nahradili Pythonem, kde databázová a webová část se udělala v Djangu, na což se velmi hodí a to, co se hodilo řešit pomocí microservis se udělalo v asynchronním Pythonu (aiohttp).

Neříkám, že tahle zkušenost se dá doslova zobecnit, ale pát poučení bych si z ní vzal:

1) Na web použít vyspělý framework, jedno ve které jazyce (RoR, Django nebo Laravel mi přijdou ok), Nette má jedinou výhodu, že je v Česku populární

2) Node.js vyžaduje disciplínu, aby se člověk neutopil v možnostech, které nabízí a je třeba počítat, že se neustále mění

3) Použití nejnovějších technologií nevede k lepším výsledkům než staré, ale osvědčené nástroje (třeba nasazením GraphQL jsme si dost užili a vše se zlepšilo návratem k trapnému RESTu)

z toho co pisete, to zni jako kdyby ste tam byla parta 20 letych programatoru, kteri se snazi implementovat jakoukoliv novou cool vec jen proto ze je to cool. pouzivat yarn misto npm, k tomu neni absolutne zadny objektivni duvod, mohl bych pokracovat....

[xxx]

z toho co pisete, to zni jako kdyby ste tam byla parta 20 letych programatoru, kteri se snazi implementovat jakoukoliv novou cool vec jen proto ze je to cool. pouzivat yarn misto npm, k tomu neni absolutne zadny objektivni duvod, mohl bych pokracovat....

Tak fakt je, že většina týmu byla o dost mladší než já, někde 22-26, ale největší propagátor tady těch JS novinek a přepisů do nových frameworků měl blíž ke 40 než 30.

Na druhou stranu, zrovna přechod na yarn, v době kdy se objevil, přinesl zrychlení buildu v řádu minut, což bych jako objektivní důvod bral (to že npm se potom taky zlepšilo je další věc).

[Andrej Ramašeuski]

mojo https://mojolicious.org/

[xxx]

mojo https://mojolicious.org/

Odpověď na

 

Navíc se zabývám myšlenkou jakým směrem se dál vyvíjet abych měl do budoucna na trhu práce co nabídnout

asi nebude perl.