Webové řešení – jak zase nenaletět a mít větší svobodu

Napsal oldchoolwt;1660917

Jiříček a kojot jsou prostě mistří v oboru, a proto zaserou celé téma spamem o tom, jak ví vše nejlépe a ostatní jen trolluji nebo nemají zkušenosti.

a tak jsi pridal trochu osobniho spamu o nicem, sorry, ale narozdil od tebe v tom oboru delam 15+ let fulltime a ne zrovna nakej trash development... kdyz mi chces oponovat, muzes, ale chce to vic fakticky, vsechno cos psal dychalo tim, ze uplne nevis... 

Napsal Pavel Janků;1660903

Strhla se tady těžká válka o volbě technologie. Bohužel, mám pocit, že kojot6 neví, která bije. JS je super - na frontendu. Dát JS na backend je čisté diletantství, kterého se bohužel dopouští spousta samozvaných vývojářů.

To je takové nepodložené tvrzení a debata postavená na vodě. Prvně, výhoda javascript frontend + backend je jedna technologie, tudíž menší nároky na vývojáře, já vím že to asi hodně lidem přijde bezvýznamné, ale ono to je významné. Výhoda Next.JS je v té integraci, deployment na Vercel je jedním kliknutím, bez libovolného psaní CI/CD pipelines atd, dokonce to přidá i monitoring. Chápu, že děláš ve firmě, která kombinuje několik řešení, a jsi na to zvyklý, nicméně to pravděpodobně vzniklo tak, že firma měla spoustu expertů na různé technologie, tak to nějak historicky namixovala, to neznamená, že kdyby to dneska stavěla na zelené louce, udělá to tak znovu. Je to takové, jakože máš staré auto, na který si zvyklý, ale je 20 let staré, ale co, přidáš si tam multimediální centrum se zadní kamerou, domontuješ si tam alarm, přidáš si tam bluetooth handsfree, přidáš si tam kamerku, přemontuješ si světla na xenony a říkáš si, ano super auto, stálo to pár korun a má to vše co potřebuji, proč si kupovat nové. Ale pak si sedneš do nového, kde je toto vše integrované, funguje každý detail, vše spolu nádherně spolupracuje, když couváš, přepne se ti navigace na zadní kameru, když telefonuješ, vypne se ti zvuk navigace, atd. Všechno spolu funguje dohromady, a přestože všechny ty technologie můžeš nainstalovat do starého auta a nějak je zprovoznit, nikdy je takhle nesladíš. A ta integrace všeho dohromady je obrovský plus NEXT JS. Píšeš v jednom prostředi, od frontend po backend, máš integrovaný deployment, CDN a vše. V jednom člověku uděláš kompletní moderní apku včetně všeho, komplet full stack. Ty tu vychvaluješ řešení vaší firmy, ale to nedělá jeden člověk, to je nějak složený historický tým. A možná, že v nějakých detailech je to lepší, ale ta celková integrace, ten celkový pocit je horší. Je to argumentace blízká tomu, že ty máš lepší foťák, protože máš zrcadlovku, a ne ten v mobilu, ale nevidíš, že ten foťák v mobilu sice možná parametrově o něco horší, ale má lepší integraci, co se týká zálohování a upravování fotek, tagování, sdílení na sítích apod., a v tom je ta hodnota, ne v lepším rozlišení zrcadlovky.

Me treba prijde, ze kdyz potrebujes mit obsahovej web, co bude generovat dostupnej content pro vyhledavace a zaroven chces dynamickej front end kterej nebude vsechno reloadovat a bude mit dynamicky komponenty, tak se stejne backendu a frontendu - oboji v javascriptu nevyhnes (nemusi byt nutne next tech alternativ je vic, i kdyz next je uz hodne vepredu), respektive se budes zbytecne strilet do nohy kdyz se tomu budes za kazdou cenu vyhybat... Jina vec jsou SPA, kde je vcelku fuk co bezi na backendu a uz se da o tom premyslet trochu jinak - ja treba si oblibil vyslovene psat celej backend v postgre a mit do nej jen graphql vrstvu a v podstate se vyhnes uplne jak nodu tak cemukoliv jinymu... 90% projektu by takhle s klidem fungovalo :) no ma to zas svy jiny niche problemy... nicmene je to dost elegatni. no a pak jsou blogisky-style weby a tam je to asi fuk, wordpress je easy pro kazdyho tak asi proc ne :)) 

Napsal kojot6;1660920

To je takové nepodložené tvrzení a debata postavená na vodě.

Prvně, výhoda javascript frontend + backend je jedna technologie, tudíž menší nároky na vývojáře, já vím že to asi hodně lidem přijde bezvýznamné, ale ono to je významné.

Výhoda Next.JS je v té integraci, deployment na Vercel je jedním kliknutím, bez libovolného psaní CI/CD pipelines atd, dokonce to přidá i monitoring.

Chápu, že děláš ve firmě, která kombinuje několik řešení, a jsi na to zvyklý, nicméně to pravděpodobně vzniklo tak, že firma měla spoustu expertů na různé technologie, tak to nějak historicky namixovala, to neznamená, že kdyby to dneska stavěla na zelené louce, udělá to tak znovu.

Je to takové, jakože máš staré auto, na který si zvyklý, ale je 20 let staré, ale co, přidáš si tam multimediální centrum se zadní kamerou, domontuješ si tam alarm, přidáš si tam bluetooth handsfree, přidáš si tam kamerku, přemontuješ si světla na xenony a říkáš si, ano super auto, stálo to pár korun a má to vše co potřebuji, proč si kupovat nové.

Ale pak si sedneš do nového, kde je toto vše integrované, funguje každý detail, vše spolu nádherně spolupracuje, když couváš, přepne se ti navigace na zadní kameru, když telefonuješ, vypne se ti zvuk navigace, atd. Všechno spolu funguje dohromady, a přestože všechny ty technologie můžeš nainstalovat do starého auta a nějak je zprovoznit, nikdy je takhle nesladíš.

A ta integrace všeho dohromady je obrovský plus NEXT JS. Píšeš v jednom prostředi, od frontend po backend, máš integrovaný deployment, CDN a vše. V jednom člověku uděláš kompletní moderní apku včetně všeho, komplet full stack.

Ty tu vychvaluješ řešení vaší firmy, ale to nedělá jeden člověk, to je nějak složený historický tým. A možná, že v nějakých detailech je to lepší, ale ta celková integrace, ten celkový pocit je horší. Je to argumentace blízká tomu, že ty máš lepší foťák, protože máš zrcadlovku, a ne ten v mobilu, ale nevidíš, že ten foťák v mobilu sice možná parametrově o něco horší, ale má lepší integraci, co se týká zálohování a upravování fotek, tagování, sdílení na sítích apod., a v tom je ta hodnota, ne v lepším rozlišení zrcadlovky.

To, co označuješ za výhodu je právě těžká nevýhoda. Nechceš, aby ti frontenďák psal backend. Proč? To už jsem tu psal. Tihle brouci Pytlíci jsou nejhorší. Ten mix je výhoda, ne nevýhoda. Utilizuješ výhody jazyka a potlačíš tím nevýhody, které jednotlivé platformy mají. Proto i řešení na zelené louce jdou do takového mixu. Argumentace s autem se dá přirovna k existující platformě, kterou dovyvíjíš, argumentace s mobilem ti přesně dokazuje, že je rozdíl, když použiješ vhodný jazyk vs. univerzální jazyk. Takže jsi spíše podtrhl mé argumenty, děkuji. Mj. deployment na Vercel je super pro test, když nemáš k dispozici kapacity a prostředí pro deployment u sebe. Na produkci bych to fakt nepoužíval.---------- Příspěvek doplněn 03.04.2023 v 15:46 ----------

Napsal Aleš Jiříček;1660923

Me treba prijde, ze kdyz potrebujes mit obsahovej web, co bude generovat dostupnej content pro vyhledavace a zaroven chces dynamickej front end kterej nebude vsechno reloadovat a bude mit dynamicky komponenty, tak se stejne backendu a frontendu - oboji v javascriptu nevyhnes (nemusi byt nutne next tech alternativ je vic, i kdyz next je uz hodne vepredu), respektive se budes zbytecne strilet do nohy kdyz se tomu budes za kazdou cenu vyhybat... Jina vec jsou SPA, kde je vcelku fuk co bezi na backendu a uz se da o tom premyslet trochu jinak - ja treba si oblibil vyslovene psat celej backend v postgre a mit do nej jen graphql vrstvu a v podstate se vyhnes uplne jak nodu tak cemukoliv jinymu... 90% projektu by takhle s klidem fungovalo :) no ma to zas svy jiny niche problemy... nicmene je to dost elegatni.

no a pak jsou blogisky-style weby a tam je to asi fuk, wordpress je easy pro kazdyho tak asi proc ne :)) 

Jasně, stejně tak můžeš mít redaction-grade CMS jako např. Superdesk (mj. psaný v Pythonu) a data jednotlivým webům cpát přes API. Jednotlivé weby máš v JS a řešíš SSR. To je naprosto v pořádku use-case. Ale v JS bych už prostě neřešil nějakou logiku.

Ja bych tak nezobecnoval, fullstack vyvoj jde delat uplne stejne kvalitne, tam fakt strasne zalezi na tom koho si zaplatis. Fullstackar co dela veci kvalitne samozrejme neco stoji, protoze musi mit dostatek zkusenosti s obojim, ale zase ma ten vyvoj zajimavou vyhodu, kdy se nemusi domlouvat dva ruzny teamy a proste si ten clovek udela back end i front end na ty jedny veci kterou zrovna dela kompletne sam - dost se tam snizuje cas za kterej se daji shipovat jednotlivy veci, kdyz tam neni tenhle komunikacni overhead, kterej u rozdelenych teamu vzdycky chte nechte bude. Neni to asi vhodny uplne vsude, ale odmitat to uplne je opet spis takovy prehlizeni, protoze ty jsi nezazil cloveka co by delal oboji dobre, tak jako asi neexistujou :) to neni uplne good... 

Prosím, vyhněte se osobním útokům, je to naprosto zbytečný a jen to shazuje vaši argumentaci. Stejné diskuze jsme vedli v devadesátkách, když web začínal, byli jsme stejně chytří, ale nic jsme s tím nevyřešili. Člověk si pak poptá firmy a je odkázán na to, v čem dané firmy dělají.Většinou se mi neosvědčilo míchat dohromady frontend a backend, ne že by to teoreticky nešlo, ale obě části mají diametrálně odlišné nároky na způsob fungování, debugování, logování a udělat nějakou abstrakci, která tohle překryje je prostě drahé, programátoři, které mám na projektech k dispozici nejsou supermani a architektura řešení musí zohledňovat i schopnosti týmu, zažil jsem zatím málo projektů, kde spojení dávalo smysl.Node.js (a obecně javascript) na backendu má obrovskou nevýhodu v tom, že se nedá snadno udržet stabilní odezva (klasicky třeba TTFB 500 ms u 99 % dotazů), u malých webů to nevadí, u velkých to dost výrazně zvedá náklady. Debugovat to je docela peklo, svého času jsem udržoval v node.js větev, která implementoval dtrace proby, využívali jsme na Solarius pro realtime monitoring, dnes je s tímhle konec, s příchodem eventual completion (aka Promise) a JSX je nemožné sledovat latence jednotlivých volání v callstacku a debugovat proč se mně event loop zasekla a kterou operaci zrovna zpracovává. To je samozřejmě problém i u next.js, u složitějších aplikací se to prostě dříve nebo později dostane do stavu, kdy nikdo neví proč to je pomalé. Mikroservisky, které javascriptu hodně sedí, zase nelze použít vždy.

Dostal jsem mimo webtrh nabídku na laravel front i back, případně ohnout Joomlu, co vy na to? Mám svůj názor, ale nechám vás zareagovat. Díky. Pro upřesnění náš firemní systém jede na Karátu (CRM) > CM (čistě pro produkty a soubory) > produkty na web + texty píšeme v adminu webu.

Napsal contik;1660963

Dostal jsem mimo webtrh nabídku na laravel front i back, případně ohnout Joomlu, co vy na to? Mám svůj názor, ale nechám vás zareagovat. Díky.

Pro upřesnění náš firemní systém jede na Karátu (CRM) > CM (čistě pro produkty a soubory) > produkty na web + texty píšeme v adminu webu.

Jedna rada nad zlato - ohýbat cokoliv je vždy bolestné (pain in ass) a nakonec to ani nestojí za to (má to své limity). Joomla je jako wordpress, na mini weby se to hodí, ale na větší systémy ne, protože ty mají jiné požadávky než všeobecný cms. Volil bych laravel, jelikož je dost použivaný a není problém nájmout lidi i mimo čr. Pokud se udělá dobře back end, tak skrz api můžeš posílat data kamkoliv (apka, třetí strana atd). Ale to říkám podle toho, co si psal na úvod, že chceš jeden systém napojený na eshop, mark. weby a info. systém. Btw Ať ti píše dokumentaci ke kódu. Nemusí být cool s detaily, ale v budoucnu se bude hodit.

Napsal contik;1660963

Dostal jsem mimo webtrh nabídku na laravel front i back, případně ohnout Joomlu, co vy na to? Mám svůj názor, ale nechám vás zareagovat. Díky.

Pro upřesnění náš firemní systém jede na Karátu (CRM) > CM (čistě pro produkty a soubory) > produkty na web + texty píšeme v adminu webu.

To je moc obecné na odpověď, obecně co se CMS týká, kort firemně, pokud to alespoň trošku jde napasovat na firemní řešení s podporou (Wedos Website, Squarespace), přikláněl bych se tímto směrem. Já osobně jsem si vlastní web udělal na NEXT, pro mě děsná výhoda je generování statických stránek, a na kontaktní formulář jsem použil 3rd party pro React a úplně outsourcoval, takže celý web je vlastně 100% statický, a tudíž odezva je nádhera. Existují i jiné systémy na statické weby, ale pokud jde o prezentační web, který může být statický, přimlouval bych se za tento směr, protože ti odpadá velké množství problémů s řešením výkonu a zabezpečení, jednou to zkompiluješ a pak to běží extrémně rychle a nedá se to hacknout. Někteří webdesignéři ti třeba také navrhnou statickou prezentaci a jen odesílací formulář a pár drobností dají sami v PHP a CMS ani nepotřebuješ. WordPress není špatný a funguje mi roky dobře, ale je to velmi základní systém. Jakmile ho začneš různýma pluginama hodně rozšiřovat a tunit, tak se z toho stává Tamagochi. Pokud si nainstaluješ WordPress na defaultní šabloně a dáš si tam jeden plugin, tak je to skvělý systém.---------- Příspěvek doplněn 04.04.2023 v 10:56 ----------Jinak ještě dodám svojí zkušenost s WP asi 5 let, protože ono ty technologie vždy jinak fungují okamžitě, a jinak v dlouhém horizontu. Nainstaloval jsem web, přidal 5 pluginů, pro neziskovku, každý rok web na nějakém pluginu přestane fungovat - protože pluginu skončí podpora, kompatibilita atd., a já odstraním nějaký plugin, a pak si uvědomým, že snad ani tak podstatný nebyl, co se týká vzhledů, tak to jsou pluginy na entou, kort z themeforest. Po 5 letech web skončil na defaultním šabloně, a tuším že mi tam furt jen funguje plugin pro automatickou aktualizaci, a jinak jsem vše povypínal.

Dovolím si nesouhlasit s tím, že by PHP bylo mrtvé (nebo problémové, pomalé, atp.) a že JS na serveru je naopak ta jediná správná progresivní cesta. Custom řešení postavené na obecném frameworku je zbytečné vymýšlení kola, WP je z hlediska dlouhodobé udržitelnosti problematický. Komplikace při změně vývojáře budou myslím vždy, a to i když řešení bude víceméně standardizované. Neumím si představit, že by někdo řekl "fajn, tohle znám, je to OK a tak nebudu účtovat žádný čas na seznámení s tím, jak to je udělané". Osobně vždy horuji (kromě eshopů) za CMS/CMF Processwire, který má nulový problém se zpětnou kompatibilitou při příp. upgrade,  je mimořádně flexbilní, rychlý a bezpečný. Běhají mi na něm hladce weby co mají řádově stovky tisíc stránek. Nemám ambici tuhle zakázku chtít (to bych letos už nestihl), tak mohu alespoň prezentovat názor, že skutečně dobrý PHP OpenSource CMS může být dobrá volba i když ho třeba málokdo (v Čechách) používá. Důležité je, jakou má historii, záruku zpětné kompatibility a jak se mu daří eliminovat zásahy nekompetentní komunity. Naučit se chápat základní logiku ProcessWire tak, aby rozuměl co a proč ten předešlý dělal, je pro chytrého vývojáře otázka max. dvou týdnů. Podstatná je domyšlenost toho systému, ne jeho popularita. Popularita vůbec nemusí korelovat s kvalitou, pokud má třeba dobrý marketing (viz WP).

Umíte ještě podnikat bez eshopu?  Mlaďoši si to neumí představit ...

Napsal hermanek;1661554

Dovolím si nesouhlasit s tím, že by PHP bylo mrtvé (nebo problémové, pomalé, atp.) a že JS na serveru je naopak ta jediná správná progresivní cesta. Custom řešení postavené na obecném frameworku je zbytečné vymýšlení kola, WP je z hlediska dlouhodobé udržitelnosti problematický. Komplikace při změně vývojáře budou myslím vždy, a to i když řešení bude víceméně standardizované. Neumím si představit, že by někdo řekl "fajn, tohle znám, je to OK a tak nebudu účtovat žádný čas na seznámení s tím, jak to je udělané". Osobně vždy horuji (kromě eshopů) za CMS/CMF Processwire, který má nulový problém se zpětnou kompatibilitou při příp. upgrade,  je mimořádně flexbilní, rychlý a bezpečný. Běhají mi na něm hladce weby co mají řádově stovky tisíc stránek. Nemám ambici tuhle zakázku chtít (to bych letos už nestihl), tak mohu alespoň prezentovat názor, že skutečně dobrý PHP OpenSource CMS může být dobrá volba i když ho třeba málokdo (v Čechách) používá. Důležité je, jakou má historii, záruku zpětné kompatibility a jak se mu daří eliminovat zásahy nekompetentní komunity. Naučit se chápat základní logiku ProcessWire tak, aby rozuměl co a proč ten předešlý dělal, je pro chytrého vývojáře otázka max. dvou týdnů. Podstatná je domyšlenost toho systému, ne jeho popularita. Popularita vůbec nemusí korelovat s kvalitou, pokud má třeba dobrý marketing (viz WP).

Díky za podnětný příspěvek a proč ne pro e-shopy, chtěli bychom možná přilepit menší e-shopík...

Napsal contik;1661935

Díky za podnětný příspěvek a proč ne pro e-shopy, chtěli bychom možná přilepit menší e-shopík...

Dobrý den, ProcessWire má samostatný robustní komerční modul pro eshop, který se jmenuje Padloper 2. Ten navazuje na předchozí "baby" verzi Padloper. Jeho vývojář je jeden z nejchytřejších chlapů v komunitě, předpokládám, že Padloper bude domyšlený dobře, neměl jsem ale dosud důvod jej koupit a tedy ani testovat. Tento modul autor vyvíjel několik let, a vydání ostré verze dlouho odkládal, ladil na základě podnětů vybraných členů komunity a autora jádra systému různé funkcionality. Ostrá verze byla vypuštěna cca v roce 2022, tedy už bylo asi dost času, aby dozrála. Do ruky se mi osobně dostala jen ona předchozí verze, běží na ní jeden eshop, jehož správu jsem kdysi převzal. Ten byl technicky v pohodě (a i výrazně levnější), jen toho mnoho sám o sobě neuměl. ProcessWire i Padloper je třeba chápat spíš jako robustní a modulární účelový framework, navíc s připravenou pokročilou administrací. Pro menší e-shopík, jak zmiňujete, by jistě vyhověl, koneckonců cokoli lze dodělat (tak jako v celém ProcessWire), pokud by nějaká funkcionalita chyběla. Tato první verze využívá pro položky shopu klasické "pages" (= cosi jako "node" v Drupalu), tedy shop je jen další funkcionalita nad vlastní webovou prezentací. Každopádně by bylo při použití Padloperu nutné dodělat přinejmenším doplněk pro Zásilkovnu (příp. Balíkobot), doprecizovat XML exporty pro české porovnávače, napojení na české platební brány, aj. technicky by to problém jistě nebyl, jen to je práce, kterou by někdo musel zaplatit :-(. Pouštět se do toho na vlastní pěst by pro mě bylo neefektivní, když tu je tak silný přetlak všech těch v Čechách populárních pronajímaných řešení se silným marketingovým tahem na branku a k tomu (poněkud problematický) PrestaShop, OpenCart a WooCommerce. Trh s e-shopy je bohatě nasycen ;-) ProcessWire češi (ke své škodě) neznají a znát nechtějí ;-) Pokud by Vás to zajímalo, zde jsou odkazy na dokumentaci a příslušné diskuzní vlákno: https://docs.kongondo.com/ https://processwire.com/talk/topic/26944-padloper-2-released/

Napsal Pavel Janků;1660903

Ještě nemohu přehlédnout plivání na Sulu a vyzdvihování Wordpressu. To může napsat jen člověk, který nerozumí vývoji. Wordpress má možná spoustu pluginů, ale pořád je to jen h***o, které se snažíte leštit. A vždycky, když se o to pokusíte, jen ho rozmažete :) Wordpress je prostě zbastlené řešení a většina vývojářů na něm jsou jen lepiči kódu. 

haha