Příspěvky

466

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 19. 02. 2021, 12:17:14 »

jQuery je sice pomalé, ale proti reactu je to sportovec; myslím, že ochota dělat stránky rychlé, paměťově a zdrojově nenáročné prostě právě s Reactem umřela.

jasně, dobrý plky. To, že někdo neumí optimalizovat React, neznamená že je špatný. Ono neoptimalizace je "přínos" dnešní doby, kdy už ani frameworky moc neřeší zdroje - procesory jsou výkonější, máme více paměti apod.

Podle vaší analogie mohu říci, že všechno co není psané v Asembleru je na ho*no.

ano, musíš ho optimalizovat a to tak, že v něm prostě data nemáš nebo vše cpeš do immutable struktur, pureComponent rulezz a celou dobu bojuješ s re-render problémem. Náklady na optimalizaci u vývoje u reactu dosahují už pěkného poměru k samotnému vývoji. Mně připadalo zajímavé na jedné straně mluvit o tom, že jQuery zbytečně zpomaluje web a pak říct, že se dá také použít React.

O ASM jsem nepsal ani slovo, stačí se podívat jak spotřeba paměti a CPU roste každým rokem, z tohohle pohledu to jQuery vlastně nebyl tak špatné . Naopak např. napsat v ASM efektivnější kód než produkují novodobé JIT kompilery není vůbec snadné. Jinak moje neoblíbenější stránka vždy byla http://microjs.com a třeba způsob jak je schopný se vypořádat s efektivitou https://github.com/mafintosh je unášející, škoda, že tak o tom nepřemýšlí jiní tvůrci frameworků. Zajímavou cestou jde Svelte, ale to už tady bylo dříve (např. třeba Google Dart, dnes již mrtvý), na první pohled dobrá efektivita je vykoupena vendor lock-inem, špatnou interportabilitou a celkovou uvězněností v jednom světě, tohle web z kolen nevytrhne, Google Closure je za mě použitelnější a pěkněji vyřešená sada nástrojů pro tvorbu.

467

Sítě / Re:Služba privátní LAN skrze VPN

« kdy: 18. 02. 2021, 20:33:44 »

možností je spousta, ale padá to s uživatelskou přívětivostí. Já používám tinc, ale nastavení je jen pro znalejší, na některé hry lze použít wireguard, ale opět nastavení není triviální.

Možná zkus https://www.zerotier.com/, je to pro vás zdarma a měli byste být schopní si takovou síť vytvořit s přímým peeringem a nízkou latencí.

468

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 18. 02. 2021, 20:30:03 »

ano, jQuery dominuje tam, kde nejsou programátoři, ale spíše lepiči, pro ně to je prostě přijatelné řešení.

jQuery je sice pomalé, ale proti reactu je to sportovec; myslím, že ochota dělat stránky rychlé, paměťově a zdrojově nenáročné prostě právě s Reactem umřela.

S vanillaJS si musím být vědom omezení a daleko více testovat mezi prohlížeči. Doporučení na čistý js tady zaznělo ve vláknu několikrát.

469

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 18. 02. 2021, 18:06:41 »

aby bylo jasno, jQuery nikomu nedoporučuji a nepovažuji to za vhodné věc, ale stejně tak nikomu nedoporučuji používat bezhlavě vanillaJs, to je zase módní věc poslední dobou a vznikají v tom chyb, viz i doporučování v tomhle vlákně.

Pro IE se pořád vyvíjí, v českém prostředí to je poměrně častý prohlížeč u bank a operátorů, takže pokud člověk pro ně dělá produkty, měl by na to prozatím myslet. Nerad zabíjím podporu něčeho jen proto, že se mi to zdá příliš staré. Fetch nefunguje na Androidu 4, koukám do statistiky a pořád existují 3 % návštěvníků u jednoho z velkých webů v ČR. U Zahraničních webů pro Maďarsko,Ukrajinu dokonce vidím i 10 % z mobilních prohlížečů.

Tohle prostě nepovažuji na dobrou náhradu. Pokud chci vyřešit podporu i pro ty starší, už to tak málo kódu není a potřebuji pomoc nějakého frameworku/knihovny, která přidá polyfill. VanillaJS je sice cool, ale těch plnohodnotných webů v tom moc není, jen se o tom mluví a píšou tutoriály na jednoduché příklady.

Už jen tyhle příklady, doteď mám jeden js soubor s aplikací, teď to najednou musím rozsekat, init volat jako defer, aninamace dát do css a přepínat třídy. To už vyžaduje trochu větší um než bylo potřeba s jQuery. Vzhledem k tomu jaká je cílovka a pozice jQuery prostě nevidím vhodné doporučovat přejít na čistý JS.

470

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 18. 02. 2021, 15:50:29 »

jQuery jsem neměl rád nikdy, ale důvod proč se používá je snadná dostupnost, jednoduchá syntaxe a zaručená kompatibilita mezi prohlížeči, v době jeho vzniku to byla obzláště velká bolístka.

Tady ukazujete jednoduché příklady, ale třeba ve vanillaJs napsat něco jako:

• .fadeIn()
• .addClass()
• .on() - tohle je obzláště těžké, protože u jQuery není potřeba, aby ten element ještě existoval (live), v čistém js si na něj musím počkat
• .ready() - takhle třeba vypadá implementace u jQuery, https://github.com/jquery/jquery/blob/025da4dd343e6734f3d3c1b4785b1548498115d8/src/core/ready.js, není to tak přímočaré

fadeIn() - stačí 2 riadky CSS nepotrebuješ ani JS. Zavolanie je len zmena classy.
addClass() - to vie JavaScript priamo - classList.add()
ready() - implementácia jeden riadok (stačí zapuzdriť do jedného ifu, kde overíš či DOM už je vyparsovaný)

resp. by ti stačil document.addEventListener( "DOMContentLoaded", completed );
to čo je v implementácii jQuery je tak dlhé len preto že je to prispôsobené pre jQuery.

on () - implementácia 3 riadky

Kód: [Vybrat]

domElement.prototype.on = function(event, callback) {
   this.eventHandler.bindEvent(event, callback, this.element);
}

Nič z toho ale reálne nepotrebuješ, pozri Svelte a vypadnú ti oči, že addClass(), on(), máš na 0 riadkov JS.

ale to jsou přesně ty špatné nedostatečné implementace, o kterých jsem mluvil. Na fadein musíš přidat nové třídy a řádky do css, nebude to fungovat s svg. U addClass je classlist super, ale pak je tady ještě IE s řadou záludností, na které musíš dát pozor, opět problém s použití u svg, kde jquery funguje dobře.

Zrovna u ready potřebuješ ještě další podmínku, viz i ten kód u jquery. Tvoje řešení on vyžaduje, aby element existoval a nepodporuje to u lazy elementu jako u jQuery.

Samozřejmě se to dá napsat i v čistém js, jen jsem chtěl říct, že to není tak jednoduchý a dobu, kdy byla půlka webů rozbitých právě kvůli nedostatečně obecné implementaci bez testů si živě pamatuji, nerad bych opakoval chyby z minulosti. Doporučování vanillaJS jako řešení nepovažuji za rozumné.

471

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 18. 02. 2021, 14:26:59 »

jQuery jsem neměl rád nikdy, ale důvod proč se používá je snadná dostupnost, jednoduchá syntaxe a zaručená kompatibilita mezi prohlížeči, v době jeho vzniku to byla obzláště velká bolístka.

Tady ukazujete jednoduché příklady, ale třeba ve vanillaJs napsat něco jako:

• .fadeIn()
• .addClass()
• .on() - tohle je obzláště těžké, protože u jQuery není potřeba, aby ten element ještě existoval (live), v čistém js si na něj musím počkat
• .ready() - takhle třeba vypadá implementace u jQuery, https://github.com/jquery/jquery/blob/025da4dd343e6734f3d3c1b4785b1548498115d8/src/core/ready.js, není to tak přímočaré

Někdy podobné nástroje mají smysl, díky jQuery se vymítilo spousty nefunkční webů a jejich JS, za to jsem rád a bojím se, že při použití čistého JS se to díky nedostatečným implementacím může vrátit do podobných kolejí. Dobře vypadá třeba UmbrellaJS jako něco, co přidává aspoň ty základní věci a je to minimální ve velikosti.

472

Server / Re:VPS hosting pro mailserver (čisté IP adresy)

« kdy: 18. 02. 2021, 09:38:52 »

to máš aktuální zkušenost? Zrovna s wedosem a spammery je to za mě na českém trhu asi snad nejhorší, dobouchat se jejich technické podpory pokud nějaký jejich zákazník masivně spamuje je obtížné, na reporty nereagují v podstatě vůbec, otrávený provoz trvá týdny i měsíce než s ním něco udělají. Ale samozřejmě mohu mít jen špatný vzorek dat.

Nebyl by nějaký vzorek spamu? Já z Wedosu zatím žádný spam nedostal. Druhá věc je, že spammeři u Wedosu využívají akce na levné .EU nebo naposledy akci s free .ONLINE nebo .LIVE a dalšími. Ale spam samotný valí přes OVH nebo AmazonSES, doména u Wedosu. Jinak doporučuji udělat si bezplatný účet u SpamCopu a všechny tyhle spamy přeposílat jim. Následně SpamCop za každý spam zašle Wedosu report, který oni řeší se zákazníkem. Pokud zákazník nereaguje (atd), je odstaven. Obecně mám dojem, že Wedosu na reputaci IP záleží.

nemám teď nic v kapse, řeší to většinou kolegové a neevidujeme to podle hostingů. Jo, s SES se roztrhl pytel a každý druhý spam jede přes ně. SpamCop používáme, ale mám pocit, že je čím dál méně účinný, na příchozí poštu je spíše neúčinný, zejména pokud jde o osobní emaily v práci velkých firem.

Jsou a byly z moji strany snahy kontaktovat hostingy/ISP přímo a dodat jim report. U Wedosu těch neplech je dlouhodobě poměrně hodně, spam je jedna věc, druhá jsou různé pokusy o skeny a útoky z jejich serverů, někdy ten provoz trvá i týdny. Je ale možné, že mám prostě malý vzorek, proto jsem se ptal, jestli se to náhodou nezměmilo k lepšímu v poslední době.

473

Server / Re:VPS hosting pro mailserver (čisté IP adresy)

« kdy: 17. 02. 2021, 14:10:47 »

Wedos dává IPv4 a k tomu /64 IPv6. Wedos si hlídá spammery a klidně je i odpojí. Myslím, že má dobrou reputaci.

to máš aktuální zkušenost? Zrovna s wedosem a spammery je to za mě na českém trhu asi snad nejhorší, dobouchat se jejich technické podpory pokud nějaký jejich zákazník masivně spamuje je obtížné, na reporty nereagují v podstatě vůbec, otrávený provoz trvá týdny i měsíce než s ním něco udělají. Ale samozřejmě mohu mít jen špatný vzorek dat.

474

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 17. 02. 2021, 09:54:48 »

jQuery není framework, a hlavně už není rok 2010, aby se jQuery používalo (na cokoli). Záleží na tom, co na frontendu chcete řešit. Jestli bude lepší použít nějaký framework/prostředí jako Vue, Svelte nebo React, nebo jestli bude lepší použít jen nějaké knihovny.

ty hranice významu nejsou moc přesně definované, pro někoho to může být knihovna, pro jiného framework. I Wiki je v tomhle zmatená, viz třeba přítomnost jquery na https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

Nevím, v jakém roce žiješ ty, ale v roce 2021 je pořád jQuery významný artefakt na webech, i třeba Bootstrap ho používá pro řadu widgetů, pokud neděláš SPA nebo RIA tak věci jako React, Vue, Svelte ti zase tolik život neušetří, naopak ti seberou spousty času.

475

Server / Re:VPS hosting pro mailserver (čisté IP adresy)

« kdy: 16. 02. 2021, 16:22:18 »

master, netio, savana a další. To ale nejsou low-cost hostingy, u nich nemůžeš moc čekat, že mají prostor se hygieně ip adres více věnovat. Případně můžeš použít služby jako Amazon SES aj.

Paradoxně nejvíce čisté ip adresy chtějí klienti, kteří pak nejvíce spamují. Ono kolikrát stačí i to, že si nechají uniknout přihlašovací údaje či mají špatně zabezpečený server a během minut rozesílají tuny spamu, řeším skoro každý měsíc nějaký takový problém.

476

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 15. 02. 2021, 23:53:22 »

Krom toho nad JVM je více zajímavých jazyků jako např. scala, kotlin, haskell, clojure.

Haskell?

aj, sorry, haskell samozřejmě není nad jvm, zkracoval jsem větu až jsem to zkrátil moc.

PanVP: rychlost jazyku je chiméra, zpravidla největší brzda je stejně sám programátor a spíše vyber jazyk, který ti vyhovuje z pohledu použití, funkcí a tvých znalostí. Pomalý kód dokážeš napsat v čemkoliv, stejně tak rychlý. Stejně tak bude nějakou dobu trvat než se dostaneš do situace, kdy ti rychlost bude vadit, málokdy děláme optimalizace rychlosti dříve než je napsaná nějaké funkční část.

477

Vývoj / Re:Náhrada PHP nebo ASP.NET Core

« kdy: 15. 02. 2021, 20:42:27 »

hm, divný dotaz.

php je slušný jazyk, zlepšuje se a dá se v něm něco dělat.

Python má spoustu rychlostního kódu pro práci s daty nebo sítí v C, jeho pomalost je spíše teoretická. Můžeš použít i jiný interpret, např. cpython, ironpython aj.

ASP.NET s .NET 5.0 vypadá dobře, WPF také není špatné, netuším odkud bereš informaci, že na to potřebuješ 8 lidí. Spousta projektů vč. např. hlidacstatu.cz dělají skoro jednotlivci.

V Javě začínáme projekty každý půl rok, ten jazyk pořád žije. Krom toho nad JVM je více zajímavých jazyků jako např. scala, kotlin, haskell, clojure.

V nginx si můžeš programovat přímo v js nebo v lua, jen bacha, není to thread safe.

Zrovna zmíněné Mongo je dost kontroverzní databáze. Vypadá to, že vlastně nechceš dělat v ničem a jen si potřebuješ najít důvod a trochu zabít čas na fóru.

478

Software / Re:Linuxový klient pro Google Drive

« kdy: 14. 02. 2021, 01:51:53 »

a daří se vám někomu stáhnout z drivu více dat? Po cca 50 GB mě to vždy odstřihne a skončím na nějakém ratelimitu. Zkoušeno rclone a insync před pár měsíci naposledy.

479

Desktop / Re:videokonference - spotřeba CPU extrémní, Macbook Pro

« kdy: 14. 02. 2021, 01:49:45 »

podle jejich fóra to vypadá, že ten problém nemáš jako jediný https://community.jitsi.org/t/high-cpu-utilization-on-client-end/25764/19, doporučují tam udělat pár změn v konfiguraci, vyměnit prohlížeč nebo přejít na zoom .

Očividně to nemají dostatečně optimalizované. Mobily mají výhodu, že tam lze třeba jednodušeji přehrávat videa přes sdk, zatímco u desktopu takové možnosti nemáš, takže si to každý musí psát sám, to může být důvod.

480

Server / Re:Docker a hosting bez námahy

« kdy: 13. 02. 2021, 19:31:49 »

Předpoklad, že kontejner něco z výše zmíněného vyřeší, je podle mě zcela chybná. Kontejner řeší snadné spuštění projektu v předem specifikovaném runtime. Je sice oddělený od hostujícího os, ale svoji vlastní bezpečnost a snadnou správu neřeší.

V kontejneru ale máte typicky jen jednu aplikaci a pár knihoven, které ta aplikace potřebuje. To je na správu mnohem jednodušší, než celý OS.

slovo typicky bych určitě nepoužil, drtivá většina těch veřejný takový nejsou a obsahují OS, stejně tak drtivá většina vývojářů neumí vytvořit takhle minimalistický kontejner (osobní zkušenost).