Új hozzászólás Aktív témák
-
Dezsike
tag
Egyetértek. Én is fejlesztő vagyok, épp egy web alapú szoftvert fejlesztünk egy kisebb méretű rendszerre (max 5 kliens párhuzamosan). Az oldal egyetlen (szerveroldalon generált) HTML és egy nagy CSS (itt esetleg lehetne fragmentálni, mert nem minden modul használ ki mindent, de nem vagyok benne biztos, hogy bármit is nyernénk vele). Szándékosan nem húztunk bele semmilyen keretrendszert, így van, hogy a kód nagyon ronda egy-két helyen, de működik és hasít. Az oldal betöltése a teszt szerveren (ami egy átlag "netezős" gép volt 6 éve) max 100 ms. Egy ismerősöm hobbi weboldala is hasonló értékeket produkál, ráadásul a neten keresztül, nem belső hálón. Ellenben más fejlesztők oldalai, még ha nem is túl bonyolultak, másodpercek alatt nyílnak meg. Az okát sejtem, a HTTP 2 nem fog segíteni rajta.
-
dragon1993
őstag
LoL
A keretrendszer azért van, hogy ne kelljen már mindent 100x megírni. Legtöbbször a nem használunk keretrendszert azt jelenti, hogy sajátot csináltunk és nincs hozzá dokumentáció az új kollégát lehet betanítani.
A weblap betöltésénél a legtöbb időt nem az oldal generálása hanem a css jsek képek betöltése viszi el, ilyenkor jobb ha egy fájlba összerakjuk a sok css/js fájlt és a képeket optimalizáljuk.
A HTTP2-nek a push funkción kívül nem sok köze van a fejlesztőkhöz, az üzemeltetési feladat.
Nézted mostanában a Laravel doksit, az ott lévő dolgokat mennyiért csinálnád meg?
-
dragon1993
őstag
Tényleg? Akkor ezt a HTTP2 készítőinek magyarázd el, mert van benne egy funkció, ami pont ezt valósítja meg. De ha ennyire egyszerű és triviális lenne a dolog, mint ahogy írod, akkor miért tették bele?
Tapasztalataim szerint HTTP2 estén is lassabb 500db fájlt kiszolgálni, mint 1db-t.
Melyik funkcióra gondolsz a HTTP2 estén a push-ra a multiplexelésre vagy mire, mert így elég nehéz vitatkozni, hogy van benne egy funkcióNéztem - pontosan melyik funkcióira gondolsz?
Egyébként nem tudom, miért kevered ide a Laravelt, a gyors oldalbetöltés - a tartalomgeneráláson felül - frontend probléma. Én a mostanában népszerű Angular, React és társaikra gondoltam, amikor megírtam a fentieket, de a csökkenő népszerűségű jQueryvel is nagy és lassú oldalakat készítettek a kollegák, köszönhetően az ezer pluginnekHa így leszűkítve kéred, mely funkciók érdekelnek akkor Queues, Collections és az Eloquent érdekelne első körben.
Őszintén megmondom, hogy frondend frameworkkel nem dolgoztam még, de lassan ezt is igyekszem pótolni.
A jQuerynél meg nem kell eszetlenül használni 1000 plugin-t a hello world-nél.[ Szerkesztve ]
-
Egon
nagyúr
LOL.
Biztos?
Nem. Semmi sem biztos, max. valószínű.Szerinted a nézeted osztják a prohardver lapcsalád (meg index, origo stb.) fejlesztői is?
Nem igazán értem, hogy jön ez ide, másrészt nem hat meg, hogy konkrétan az említett fejlesztők mit gondolnak. Egyébként is, tapasztalatom szerint a fejlesztők pont azok, akik leginkább tesznek a biztonságra. Ha működik a program, akkor minden oké, kb. ez az általános felfogás (persze tisztelet a kivételnek, és akinek nem inge...).Te a sajátjaidat gányolod?
Nem vagyok fejlesztő. IT biztonsággal foglalkozom.Nem tehetek róla, hogy a pici szívedre vetted az általános (megalapozott) megállapításokat. Még egyszer: akinek nem inge...
"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)
-
Kurt Hectic
tag
"ezért csak keretrendszerekkel dolgozik"
Nem ezért dolgozunk keretrendszerekkel, hanem az újrafelhasználhatóság, a kompatibilitás és az egyszerűsítés végett.
"Hogyan próbálják ezt megoldani a problémát a HTTP 2 fejlesztői?"
Sehogy, nem erről szól a HTTP2, ill. ez csak a sokadik priorítás.
Dezsike
"Az oldal egyetlen HTML és egy nagy CSS"
Merthogy a sebesség jellemzően nem a nagy fájlok miatt veszik el, hanem a TTFB (Time To First Byte), azaz a várakozás a kapcsolat felépítésére, és a fejlécadatokra. Épp ezért van az, hogy egy nagy HTML+CSS+JS fájl jóval kevesebb idő alatt töltődik le, mint több különálló HTML, CSS, JS fájl.
dragon1993
"A weblap betöltésénél a legtöbb időt nem az oldal generálása hanem a css jsek képek betöltése viszi el,"
A képek igen, de a CSS és JS fájlok rendszerint nem a méretük miatt lassítják a betöltődést, hanem a kapcsolatfelvétel idővonzata miatt.
"ilyenkor jobb ha egy fájlba összerakjuk a sok css/js fájlt és a képeket optimalizáljuk."
Igaz, de ez is a fentebb említett kapcsolatfelvételi idő, ill. a TTFB miatt van.
-
TomMusic
őstag
Abszolút egyetértek!
Bár én inkább HW oldalról tudom megközelíteni a témát, de talán pont ezért alakul ki árnyaltabb kép. Fáj a szívem, mikor látom, milyen HW-t nyomnak az okostelefonokba, és "mire képesek". Gyötrelem! Ami a weben zajlik, az meg már súrolja a felháborítás szó fogalmát. Egy hello world weblap is már csilliónyi felesleges hülyeséggel terheli a klienst. És hiába mondod nekik, hogy ez így nem oké. Erre az a válasz hogy: dehát a multiplatform, meg van sávszélesség, meg különben is, ő jobban tudja. De talán nem is a fejlesztőkkel van a baj, hanem a rendszerrel. Ugyanis a fejlesztők abból tudnak dolgozni, ami van.Állítólag az egyetemen töltött évek a legszebbek. Ezért a képzési időt próbálom a lehető leghosszabbra nyújtani.
-
Programozás fronton is ugyanez zajlik sok éve. Csodálkozunk, hogy a hardveren futó OS-en futó frameworkon futó interpretált script lassú, és így is erőmű kell hozzá. Csak azért, hogy a gagyi alkalmazást gyorsabban ki lehessen adni, ne kelljen kicsit több idő a fejlesztésre.
@TomMusic : De az erősebb hardver általában azért kell, hogy az azon futó virtuális gépen futó alkalmazás ne legyen tetű...
Meg hogy az ezer plusz folyamat, aminek a fele felesleges, is kapjon CPU időt.[ Szerkesztve ]
Mutogatni való hater díszpinty