Új hozzászólás Aktív témák

• #8 Feruendios aktív tag dragon1993 #5

  Új Válasz 2017-05-12 08:00:43 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Feruendios

  aktív tag

  válasz dragon1993 #5 üzenetére

  Osztom, nincs ma hatékony Webfejlesztés Frameworkok nélkül.

  Sajnos mar nincs magyar billentyuzetem :(

• #9 gabor.79 aktív tag dragon1993 #5

  Új Válasz 2017-05-12 08:22:34 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  gabor.79

  aktív tag

  válasz dragon1993 #5 üzenetére

  Ha nincs keretrendszer, akkor te mindent százszor megírsz? Saját kódot te nem szoktál dokumentálni?

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

  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?

  "Nézted mostanában a Laravel doksit, az ott lévő dolgokat mennyiért csinálnád meg?"

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

  Kiváló példa a problémára az Elittárs nevű társkereső. Az átlag oldalbetöltése négy és hat másodperc, ebből a http forgalom öt egész kilobájt egy profil oldalnál, a többi képek, ezek össz betöltési ideje pártized másodperc, a többi az oldal renderelése, amit kliensoldalon végeznek, hisz Angularban valósították meg.

  Hasonló a Facebook, ami a saját fejlesztésű React-et használja, bárhova kattintasz, több másodperces renderelési idők vannak, az adatforgalom itt is minimális - és mit látsz cserében? Egy poszt pár logikai elemből áll (szerző, dátum, publikusság, szöveg, kép, érzelmek, hozzászólások), de érdemes megnézni a HTML kódját, több tízszer annyi HTML elemből áll össze, mint amennyi szükséges lenne, és ez részben a hozzá nem értésük, részben a keretrendszer működése miatt van így. És utána csodálkoznak, hogy lassú.

• #10 Egon nagyúr dragon1993 #5

  Új Válasz 2017-05-12 08:40:02 #10

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Egon

  nagyúr

  válasz dragon1993 #5 üzenetére

  Na ja.
  Tegyük hozzá azt is, hogy biztonsági szempontból pont a saját gányolásokban szokott a legtöbb lyuk lenni (ez nem (csak) az én véleményem: ismert hazai, sérülékenységvizsgálattal foglalkozó cég szakemberei mondták).

  "Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

• #13 gabor.79 aktív tag dragon1993 #12

  Új Válasz 2017-05-12 09:59:06 #13

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  gabor.79

  aktív tag

  válasz dragon1993 #12 üzenetére

  "Melyik funkcióra gondolsz a HTTP2 estén a push-ra a multiplexelésre"

  Természetesen a multiplexelésre gondoltam, a push teljesen más.

  "Ha így leszűkítve kéred, mely funkciók érdekelnek akkor Queues, Collections és az Eloquent érdekelne első körben."

  Queues: mi is használunk ilyet, 11 kilobájt a bruttó kód.

  Collections: idézet a dokumentációból: "The Illuminate\Support\Collection class provides a fluent, convenient wrapper for working with arrays of data."

  Mi tömböket a PHP beépített tömbkezelő függvényeivel manipulálunk.

  Eloquent: az ORM-ek rendkívül erőforrászabálóak, soha eszembe nem jutna ilyet használni.

  "A jQuerynél meg nem kell eszetlenül használni 1000 plugin-t a hello world-nél."

  Mindenki annyi plugint használ, amennyi szükséges.

• #23 hcl félisten dragon1993 #22

  Új Válasz 2017-05-13 19:23:40 #23

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  félisten

  LOGOUT blog

  válasz dragon1993 #22 üzenetére

  A hozzáállást mondtam. Sajnos amióta "van" teljesítmény, azóta pazaroljuk is.
  Nem feltétlen kell assemblyre gondolni, de amikor meglátom, hogy egy MS Lync telepítő 1 giga, akkor röhögök. Érted, nem az a baj, hogy vannak új feature-k, és gyors fejlesztést lehetővé tevő környezetek, hanem hogy manapság már hírből sincs optimalizáció a legtöbb helyen.

  Volt egy szép cég ahol egy adatbázishoz fejlesztettek többféle klienst. .net és webes kliens is volt.
  Változatos géppark volt a gyártósorokon, de főleg roncsokból állt. A sor ugye minél jobban kellett , hogy pörögjön. Volt mondjuk 2008, 2009? Volt egy rakás VIA C7 / 1GHZ-es tetű gép, 1GB RAM + WinXP. Na ezeken mindenki szidta a webes klienst. A .net-es pörgött, mint atom, ugyanezeken. Mondjuk a webes klienssel a sokkal erősebb P4-es gépeken is volt elég baj.
  Mivel új gépek nem nagyon voltak, nem volt rossz dolog, hogy a régebbi gépeket be lehetett fogni így, és ez elég sok kiadást feleslegessé tett.

  [ Szerkesztve ]

  Mutogatni való hater díszpinty

Új hozzászólás Aktív témák