mloc.js 2014 – JS ninjas about upcoming JavaScript & Browser features?

A mloc.js második előadását Daniel Steigerwald tartotta. Elsősorban az ES6 volt a téma, de sok más érdekes dolog is előkerült. Így elsőre nekem az ES6 (ECMAScript 6) kevésbé tetszik. Nagyjából a CoffeScript pár finomságát vette át, viszont — ahogyan Daniel is említette — sokkal nagyobb teret ad nekünk, hogy csúnya kódot tudjuk írni. Amitől beszélt az tulajdonképpen a JavaScript idénre várható dolgai. Számomta ez volt az egyik legfurább eddig az egész mloc.js konferencián.

(tovább…)

Kapcsolódó cikkek:

mloc.js 2014 – Release the Kraken

(A képet köszönjük Gábor Török)

Elérkezett idén is a mloc.js konferencia is, amiről korábban már írtam. Szép számmal vagyunk jelen, nagyon sok országból. Van itt amerikai, iráni, osztrák, norvég és már nagyon sok más országból tudásra vágyó ember. Az összes jegy elkelt, amiből volt aki nem jött el, de nem sok biléta maradt az asztalon. Csak a fele magyar a többi valahonnan máshonnan jött, ez is mutatva, hogy nem kis eseményről van szó.

(tovább…)

Kapcsolódó cikkek:

mloc.js 2014

Idén is előkerült a mloc.js és már nagyon közel van. Tavaly sajnos nem tudtam ott lenni, de idén már biztosan sikerül február 13-án és 14-én ott lennem.

Van még pár óra, amíg elővételben olcsóbban meg lehet venni. Egészen pontosan $222 (~49ezer magyar forint) ma este 6-ig, míg utána $260 (~57ezer magyar forint) lesz az ára.

Közben kaptam egy kis igazítást András Bártházitól:

Tavaly a Design Terminalban volt, idén a Prezi új “House of Ideas” előadótermében lesz (az iroda épületében, de nem az
irodában)

@ba78

Tömören, röviden

It’s happening, JavaScript is one of the most popular languages and it’s conquering the server side and the internet of things as well. JavaScript is just eighteen years old, and the future is bright. But how this future looks like? How can we improve JavaScript to make it better, focusing on large scale projects with millions lines of code?

Forrás: mloc-js.com — About

Miért éri meg?

  • Nagyon hangzatos a az előadók listája:
    • Eddy Bruel — Mozilla (How JavaScript Objects are Implemented)
    • Maxime Chevalier-Boisvert — Université de Montréal (JIT compilation techniques)
    • Domenic Denicola — Lab49 (Streams for the Web)
    • Anton Ekblad — Chalmers University of Technology (Hastily Paving the Way for Diversity)
    • Alexander Fritze — OniLabs (Building real-time web applications with Stratified JavaScript)
    • David Galeano — Turbulenz (JavaScript and the browser as a platform for game development)
    • Jeff Harrell — Paypal (Release the Kraken)
    • Shriram Krishnamurthi — Brown University (JavaScript as an Intermediate Language)
    • Guillaume Lathoud (JS optimization techniques)
    • Miguel Ángel Pastor — Halfbrick Studios
    • Alessandro Pignotti — Leaning Technologies Ltd. (Duetto: C++ as the platform language for the Web)
    • Jaswanth Sreeram — Intel Corporation (Parallel Javascript)
    • Stoyan Stefanov — Facebook
    • Daniel Steigerwald (What should the average JS ninja know about upcoming JavaScript and Browser features?)
    • Ben L. Titzer — Google (New optimizations of Google Chrome’s V8)
  • A fenti felsorolásban a címek még izgalmasabbak
  • Találkozhatsz sok emberrel
  • Nagyon sokat tanulhatsz

Ízelítőnek

Hogy nagyobb rálátást kapjon mindenki mi is ez, itt egy videós összefoglaló a tavalyi évről.

Az én jegyem már megvan. Te jössz?

Kapcsolódó cikkek:

JSHint: Növeljük a Kódbázis Minőségét

Sok embertől hallottam már, hogy a szabályok hülyék, amiket ezek a kódminőség-ellenőrző eszközök adnak. Régen én is így gondoltam. Mára nagyon megváltozott a véleményem. Pár éve már azok közé tartozom, akik idegesítik az ilyen baromságokkal a többieket.

Persze teljesen jogos. Miért ne indentáljak 1 tabbal? Mitől jobb a 2 vagy 4 space? Én nem akarom letörni a kapcsoszárójelet egy PHP-s osztálydefinícónál! Valahol együtt is érzek vele, sőt, ha a csapatban mindenki 1 tabbal akar indentálni, akkor tegye. Nincs ellene semmi kifogásom, de ha az egyik ember 1 tabbal indentál, a másik 2 szóközzel, a harmadik meg 4 szóközzel, akkor az nagyon nem jó. Egyrészt olvashatatlan lesz a kód, aminek következménye, hogy nehezebben találhatóak meg a hibák.

Mindenki szája íze, hogy milyen szabályokat hoz, de ha egynél több ember dolgozik egy projekten, akkor szinte kötelező valamilyen szabályrendszer létrehozása. Ha egy ember dolgozik rajta, akkor is illik, sőt nagyon is hasznos. Rengeteg lehetőség van, különböző nyelveken. Én most elsősorban a JavaScript adta lehetőségekről fogok írni.

Mi is az a JSHint?

A JSHint egy jól konfigurálható és gyors kód-minőség ellenőrző software. Nem csak azért, mert egyszerű konfigurációs fájlt létrehozni hozzá, hanem mert sok szerkesztő észreveszi, ha van ez a fájl és követi annak irányelveit. A másik nagyon hasznos, hogy a fájlokban is akár külön-külön is módosíthatóak egy-egy érték.

A legegyszerűbben úgy telepíthetjük, hogy kiadjuk az lábbi parancsot:

npm install -g jshint

Itt ugye, ha valakinek nincs fent a Node.js és a hozzá szorosan kapcsolódó npm, akkor el is bukta a telepítést. Érdemes telepíteni, mert nagyon sok eszközt lehet így telepíteni, még akkor is, ha nem akarsz Node.js-el foglalkozni.

A -g azért kell, hogy globálisan települjön fel, mivel mi nem betölteni szeretnénk, hanem mint futtatható állomány kezelni.

Ezek után már biza van jshint megnevezésű parancsunk.

Használat

Használni nagyon egysezrű. Paraméternek simán meg kell adni a fájlt, amit rá szeretnénk ereszteni.

jshint main.js

Nézzük mit csinál? Először is hozzunk létre egy fájlt:

var myLib = (function() {
  return {
    "key": "value",
    "list": function() {
      return [1,2,3,4,5,6]
    }
  }
})

Ha most erre ráeresztjük, akkor ezt kapjuk:

(clockwork) Ξ ~ → jshint main.js
main.js: line 5, col 27, Missing semicolon.
main.js: line 7, col 4, Missing semicolon.
main.js: line 8, col 3, Missing semicolon.

3 errors
(clockwork) ↑2 ~ →

Láthatóan 3 hiba van benne és mind a három pontosvessző gondokat mutat. Ezeket azért illik javítani. Bár le fog futni a kód, de ha ezek így maradnak, akkor később hibákba futhatunk. Mondjuk egy minify után kívos lesz, hogy dev környezetben fut a kód, de az éles oldalon elhasal, mert ugye összefűzte a fájlokat és így hiányozni fog neki legalább egy pontosvessző, ami most a myLib végéről hibádzik.

Globális változók

Nah ezeket azért ritkán használunk, de simán előfordulhat, mondjuk egy jQuery, Underscore.js vagy Bacon.js használatával.

Nézzünk is egy példát.

jQuery(document).ready(function() {
  console.log('Ready');
});

Itt most szólni fog, mert semmi sem garantálja, hogy van pl jQuery nevú változó

(clockwork) Ξ ~ → jshint main.js
main.js: line 1, col 1, 'jQuery' is not defined.
main.js: line 1, col 8, 'document' is not defined.
main.js: line 2, col 3, 'console' is not defined.

3 errors
(clockwork) ↑2 ~ →

De mondjuk document sincs, ha nem böngészőben futtatjuk.

Hozzunk létre egy konfigurációs állományt, aminek a neve .jshintrc:

{
  "curly": true,
  "eqeqeq": true,
  "undef": true,
  "globals": {
    "jQuery": true,
    "document": true
  }
}

Ha most futtatjuk, akkor már csak a console.log-ra fog panaszkodni, de az nem baj, mert azt illik nem bennehagyni.

Most nézzük, hogy mit jelentenek a konfigurációs fájl kulcsai.

curly: Kötelez minket, hogy rakjunk minden block elejére és végére kapcsoszárójelet. tehát nem lehet ilyet csinálni:

if (myNumber < 10)
  console.log('omg');

Lehet, hogy egyszerűbb és lusták vagyunk kirakni azt a plusz két karaktert, de a későbbi hibák elkerülése végett, jobb ha nem marad le. Jön egy enyhén fáradt fejlesztő kollega (vagy mi magunk) és jól beszúrva még egy sort, az már a feltételtől föggetlenül lefut. Itt persze gondolhatunk egy kicsit összetettebb kódról is.

eqeqeq: Szól, ha nem === és !==-t használtunk tesztelésnél. Sok hiba forrása lehet.

+-------------+------+-------+
+ Értékek     |  ==  |  ===  |
+-------------+------+-------+
| ""     vs 0 | true | false |
| "0"    vs 0 | true | false |
| "0000" vs 0 | true | false |
+-------------+------+-------+

Láthatóan nem mindegy, hogy mit mivel hasonlítunk össze. Érdemes inkább konvertálni és úgy tesztelni, mert úgy lényleg azt kapod, amit elvársz.

undef: Szól, ha egy olyan változót használtunk, amit előtte nem dekraláltunk.

globals: itt tudjuk felsorolni, hogy milyen globális változóink vannak, amiket nem fog megtalálni a kódban, hogy hol lett létrehozva.

Mi van akkor ha…

Persze előfordulhat, hogy csak egy adott fájlhoz szeretnénk engedélyezni egy paramétert vagy egy globális változót. Ezt is megtehetjük, ha a fájl elejére felhisszük kommentben, amit majd a JSHint jól figyelembe is vesz:

/* jshint undef: true, unused: true */

Így csak erre az egy fájlra mások lesznek a beállítások és máshogyan fogja vizsgálni.

Milyen editor támogatja?

Nagyon sok szerkesztő figyelembe veszi, ha létezik ez az állomány, de nem tudom pontosan melyek és milyen mértékben. Ami biztos, hogy a SublimeText editor SublimeLinter, a Textmate-nél a JSHint míg a Brackets-hez a brackets-jshint kiegészítés figyel rá. A Vim-hez pedig van egy jshint2.vim nevű plugin.

Grunt-tal egyszerűen verhetetlen párosítás fejlesztéshez, akár frontend akár backend oldalon.

Kapcsolódó cikkek:

JavaScript hibakeresés Táblázattal?

Mindenki jól ismeri a Chrome vagy a Firefox fejlesztést segítő eszközeit. Van egy általános objektumunk, ami a console névre hallgat. A console.log talán mindenki által jól ismert. A console.error és a console.warn függvényeket is ismertek sok helyen. Ezek a kedves barátok sokat segítenek, amikor JavaScript kódunkban szeretnénk megtalálni, hogy hol a hiba.

(tovább…)

Kapcsolódó cikkek:

Array metódusok, amiket jó tudni

Ha valaki foglalkozott már egy kicsit is JavaScript-el, az legalább egy ciklust írt. A tömbök (array) nagyon fontos elemei szinte minden nyelvnek (már amennyiben létezik).

De vajon kihasználjuk a tudását és nem írunk feleslegesen ciklustokba ágyazott cilusokat, amik csak azért vannak, hogy egy másik tömböt felépítsünk vagy egy változó értékét true/false értékkel töltsünk meg? Először nézzünk olyanokat, amiket talán sokan ismernek. Később majd előveszünk ritkábban tudottakat is.

Array.forEach

Gyakran látható az alábbi kódrész:

var myArray = ["Ez", "egy", "tömb."];

for (var i = 0, _l = myArray.length; i < _l; i++) {
  if (myArray[i].length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", myArray[i]);
  }
}

Erre bizony van a tömböknek saját függvényük, amiket nyugodtan lehet használni. A forEach pont arra való, amit a neve is mutat. Végighalad az összes elemen. Egy hátránya van: Nem lehet belőle kilépni, tehát itt nincs break. Továbbmenni egyszerűen egy return-el lehet 🙂 De mint később látni fogjuk a break is megoldható. A forEach három paramétert kap, amit vagy felhasználunk vagy nem. Első az adott elem (igen nem az index-et adja először, mert a legtöbb esetben az elemre van szükség). Második az index és harmadik értéknek kompletten a tömböt kapjuk meg. Lássuk a fenti példát már az újonan megismert függvényünkkel:

var myArray = ["Ez", "egy", "tömb."];

myArray.forEach(function(item) {
  if (item.length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", item);
  }
});

De akár kitehetjük külön függvénybe is, ha a műveletet többször szeretnénk futtatnk:

var logIfLongWord = function(word) {
  if (word.length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", word);
  }
};

myArray.forEach(logIfLongWord);

Array.join

Kicsit kevesebbszer találkozunk az alábbi kódszerkezettel, de ez sem ritka:

var myArray = ["Ez", "egy", "tömb."],
    sentence = "";

for (var i = 0, _l = myArray.length; i < _l; i++) {
  if (sentence.length > 0) {
    sentence += " ";
  }
  sentence += myArray[i];
}

Egy nagyon jó megoldás van erre, amit úgy hívnak, hogy join. Megadhatjuk, hogy mivel fűzze össze a tömbünk elemeit.

var myArray = ["Ez", "egy", "tömb."],
    sentence = myArray.join(" ");

Mennyivel egyszerűbb nem? 🙂

Array.map

Ez talán az általam legtöbbet használt metódus. Szerintem többet használom, mint a console.log, console.error-on kívül minden mást. Egy egyszerű callback függvényt vár paraméterben és a forEach-hez hasonlóan három paramétert ad át neki. Az aktuális elemet, az indexét és magát a tömböt. Annyi a különbség, hogy ez egy új tömböt hoz létre kimenetként a callback függvény által visszatért érték alapján. Nézzünk is egy egyszerű példát:

var myNumbers = [4, 16, 64, 256],
    myRootNumbers = [];

for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  myRootNumbers.push(Math.sqrt(myNumbers[i]));
}

Ezek után a myRootNumbers az eredeti tömbünk értékeinek négyzetgyökét fogja tartalmazni, azaz 2, 4, 8 és végül 16. Ennek egy picit egyszerűbb formája, ha használjuk a map metódust:

var myNumbers = [4, 16, 64, 256],

    myRootNumbers = myNumbers.map(function(item) {
      return Math.sqrt(item);
    });

De talán még szebb, ha egyből a Math.sqrt-t hívjuk meg, hiszen az is (első) paraméterként az értéket várja.

var myNumbers = [4, 16, 64, 256],

    myRootNumbers = myNumbers.map(Math.sqrt);

Lényegesen egyszerűbb, rövidebb és szebb 🙂

Array.filter

Nagyon szép és nagyon jó ez a map, de mi van, akkor ha nekem nem kell minden elem. Sőt nem is akarok műveletet végezni rajta, csak simán leszűrni adott értékeket.

var myNumbers = [4, -16, 3, -4, 5, 6, 2, -5, -10],
    myNegativeNumbers = [];

for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  if (myNumbers[i] < 0) {
    myNegativeNumbers.push(myNumbers[i]);
  }
}

Mostmár szépen le tudtuk szelektálni a negatív számokat. De miért szenvednénk ilyen hosszan, ha a filter metódus tud nekünk ebben segíteni. Szintén egy callback függvényt vár paraméterként és a jól megszokott érték, index, tömb hármassal hívja meg azt. Ez hasonlóan a map-hez végigmegy az elemeket és kimenetnek felépít egy tömböt, de csak azokból az elemekből, amiknék a callback igazként tért vissza.

var myNumbers = [4, -16, 3, -4, 5, 6, 2, -5, -10],
    myNegativeNumbers = myNumbers.filter(function() {
      return (myNumbers[i] < 0);
    });

Sokkal, de sokkal szebb 🙂

Array.every

Ez egy érdekes függvény. Ennek a kimenete igaz vagy hamis. A jól megszokott callback, ami megkapja a három paramétert, használat van itt is érvényben. Sőt nagyon hasonló a filter-hez, annyi különbséggel, hogy nem a true visszatérésű elemeleket pakolja be a kimeneti tömbbe.

Ha minden (every) callback igaz értékkel tért vissza, akkor igaz, minden más esetben hasmis lesz a kimeneti érték. Bár a lenti példa elég bugyuta, de arra jó, hogy látható legyen a működése.

var me = { "id": 9 },
var messages = [
  { "recipient": 9, "content": "Üzenet 1" },
  { "recipient": 9, "content": "Üzenet 2" },
  { "recipient": 7, "content": "Üzenet 3" },
  { "recipient": 9, "content": "Üzenet 4" }
];

var eachMessageForMe = messages.every(function(message) {
  return (message.recipient === me.id);
});
// return value: false

Ez a szépség nekünk elment az eachMessageForMe változóba, hogy minden üzenet nekem szól-e vagy sem. Egyszerű false értékkel fog visszatérni, lévén van egy ami hamisat ad.

Array.some

A neve is jól mutatja és tulajdonképpen lehetne együtt említeni az every metódussal is, mert ez akkor tér vissza igazzal, ha van olyan elem, amire igaz a callback tartalma.

var me = { "id": 9 },
var messages = [
  { "recipient": 9, "content": "Üzenet 1" },
  { "recipient": 9, "content": "Üzenet 2" },
  { "recipient": 7, "content": "Üzenet 3" },
  { "recipient": 9, "content": "Üzenet 4" }
];

var mentioned = messages.some(function(message) {
  return (message.recipient === me.id);
});
// return value: true

Hiszen van olyan érték, amire igaz. Viszont ígértem, hogy a forEach megoldáshoz egy break működést is mutatok. Ezt pontosan a some-al lehet megcsinálni, mivel a ez a metódus az első igaznál megáll.

var myNumbers = [4, 16, 3, -4, 5, 6, 2, -5, -10],

var isInvalid = false;
for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  if (myNumbers[i] < 0) {
    isInvalid = true;
    break;
  }
  // Csinálhatunk egyéb mást is még...
}

if (isInvalid) {
  alert("Negatív számot nem fogadunk el...");
}

Ezt egyszerűen a some felhasználásával meg tudjuk valósítani, csak annyi a dolgunk, hogy mindig false-al térünk vissza és amikor meg szeretnénk állítani a folyamatot, akkor visszatérünk egy true értékkel.

var myNumbers = [4, 16, 3, -4, 5, 6, 2, -5, -10],

var isInvalid = myNumbers.some(function(value) {
  if (value < 0) {
    return true;
  }
  // Csinálhatunk egyéb mást is még...
  return false;
});

if (isInvalid) {
  alert("Negatív számot nem fogadunk el...");
}

Vége?

Nagyon sok metódus van, amit az emberek nem ismernek, mert gyorsan logikával (nagyon helyesen) megalkottak az általuk ismert módokon, de vajon az a legoptimálisabb időben, energiában vagy processzorban? Te milyen egyéb olyan megoldásokat használsz, amit ritkán látsz mások munkáiban? Objektumokra, számokta, tesztekre vagy bármi másra.

Kapcsolódó cikkek:

Egyedi form elemek JavaScript nélkül

css-bitches

Bizonyára mindenki találkozott már azzal, hogy egy kedves munkatárs úgy dönt, hogy az oldalon minden form legyen egyedi megjelenésű. Ez minden programozó álma, főleg, amikor a formunk checkbox, radio és select elemekkel van tarkítva. Van pár trükk, amiket jobb ha tud az ember ilyen esetekben. De a legjobb, ha nem kerülünk ebbe a helyzetbe.

A fentebb felsoroltakat leszámítva a többit egyszerű módosítani CSS-el. A legtöbb esetben JavaScript használata kerül előtérbe. van ahol jogosan. Mint később látható lesz van amit nagyon egyszerűen meg lehet oldani, de persze van amit meg lehet, ám nem biztos, hogy van értelme 🙂

Checkbox és Radiobutton

Először is tudni kell, hogy a sima width, height, padding és társai nem igazán működnek ezzel a két elemmel. Sokra legalábbis nem megyünk vele. A label elem viszont nagyon hasznos tud lenni, mert ha az össze van kötve egy form elemmel, akkor a label-re kattintva aktiválódik a formelemünk is. Ez a checkboxnál és a radiogomboknál a státuszváltást jelenti.

<form>
  <label class='custom-form-element'>
    <span>Szeretsz dolgozni?</span>
    <input type="checkbox" />
    <div class='answer'></div>
  </label>
  <label class="custom-form-element">
    <span>Kérsz hírlevelet?</span>
    <input type="checkbox" />
    <div class='answer'></div>
  </label>
</form>
<hr />
<form>
  <strong>Szeretsz dolgozni?</strong>
  <label class='custom-form-element radio-element'>
    <span>Igen</span>
    <input type="radio" name="stuff" value="1" />
    <div class='answer'></div>
  </label>
  <label class="custom-form-element radio-element">
    <span>Nem</span>
    <input type="radio" name="stuff" value="0" />
    <div class='answer'></div>
  </label>
  <label class="custom-form-element radio-element">
    <span>Talán</span>
    <input type="radio" name="stuff" value="-1" />
    <div class='answer'></div>
  </label>
</form>

Nagyjából így néz ki egy form. Az .answer elemek azok, amiket mi most fel fogunk használni. Van egy olyan CSS tulajdonság, ami az ilyen elemek checked állapota alapján szűr.

Ehhez most akkor adjunk egy kis sminket.

.custom-form-element {
  display: block;
  font-size: 32px;
}

.radio-element span {
  width: 100px;
}

.custom-form-element span {
  display: inline-block;
  vertical-align: top;
  font-size: 0.8em;
  line-height: 35px;
}

.custom-form-element input {
  display: none;
}

.custom-form-element input + div.answer {
  display: inline-block;
  background-image: url(cross.png);
}
.custom-form-element input:checked + div.answer
{
  background-image: url(accept.png);
}

div.answer {
  width: 32px;
  height: 32px;
}

Így máris jobban néz ki. Mit is csináltunk? Minden formelemet elrejtettünk, ami jelen esetben ugyebár a radio és a checkbox elemekre vonatkozik. Ezek után az .answer háttérképe legyen az a kép, ami akkor jelenik meg, ha nincs kijelölve az adott formelem. És most jön a lényeg. Ha egy .answer elem egy olyan input után van, ami checked állapotú, akkor legyen a háttérképe egy zöld pipa 🙂

A label miatt, ha a képre vagy a szövegre kattintunk a formelemünk aktiválódik.

Select

Először is leszögezném, hogy elég gánynak tűnik. Őszintén szólva az is 🙂 De nem ez a lényeg. Sokkal inkább az, hogy JavaScript nélkül is működik.

<form>
  <div class="custom-form-element select-element">
    <label class="selector">
      <span>V</span>
    </label>
    <label class="custom-form-element option-element">
      <input type="radio" name="stuff" checked />
      <span>-- válassz egyet --</span>
    </label>
    <label class="custom-form-element option-element">
      <input type="radio" name="stuff" value="1" />
      <span>Igen</span>
    </label>
    <label class="custom-form-element option-element">
      <input type="radio" name="stuff" value="0" />
      <span>Nem</span>
    </label>
    <label class="custom-form-element option-element">
      <input type="radio" name="stuff" value="-1" />
      <span>Talán</span>
    </label>
  </div>
</form>

Adjuk hozzá a css-hez az alábbi sorokat:

.custom-form-element.select-element {
  border: 1px solid;
  padding: 5px;
}

.custom-form-element.select-element:hover label span {
  display: block;
}

.custom-form-element.select-element:hover input:checked + span {
  background-color: #afa;
}

.custom-form-element.select-element:hover input + span:hover {
  background-color: #ffa;
}
.custom-form-element.select-element .selector {
  float: right;
}

.option-element input + span {
  display: none;
  cursor: pointer;
}

.option-element input:checked + span {
  display: block;
}

Lényegében hover eseményre megjelenítűnk egy radiobutton listát, amiből választhat a kedves delikvensünk 🙂

Természetesen egyszerűbb megoldás valami jó kis JavaScript segítséget kérni, mert rengeteg ilyen lib van, ami hasznos. Van ezek között szép is, meg van talán optimális is. 🙂 Ez inkább csak érdekesség volt, de annak elég elmebeteg. A radio és a checkbox valós és nagyon is használható. A selectbox-os megoldás az már csak ilyen “Akkor is megcsinálom” kategória. De sikerült és ez a lényeg.

Az itt elkészültek demó elérhető jsFiddle-n

Kapcsolódó cikkek:

Hogyan lett 10 ponttal jobb a Mobile PageSpeed?

Manapság a mobil netezők száma igen nagy, ezért fontos, hogy gyorsan töltődjön be az oldal. Mobil felületen még inkább szembetűnő, ha nem gyors a weboldal. Ott jobban fáj mindenkinek. Tudjuk jól, hogy a tartalom felszolgálása az elsődleges és hogy annak minél előbb ott kell lennie a kijelzőn. Pár napja írtam egy cikket JavaScript: Google mondja! De igaza van? címmel, ahol azt taglalom, hogy milyen megoldások vannak JavaScript kódunk betöltésére. Hogy néz ki ez a valóságban? Éles példán keresztül nézzük most meg.

Úgy gondoltam, ha már ilyen szépen összeszedtem és bemutattam, hogy melyik módszer milyen hatással van a betöltési sebességre, ami ugyebár a keresők számára sem utolsó, akkor ránézek a [Dev] Folyam.info és a Folyam.info oldalakra is. Olyan 72 és 75 körül mozgott az átlagos Mobile PageSpeed index, ami nem mondom, hogy rossz, de azért nem is jó.

Első lépésben ami nagyon piros volt, mi lett volna, ha nem a JavaScript állományok betöltése. Ezek durván megfogták a böngészőt. Írtam, hogy az onLoad eseményre való betöltés sokat segíthet az oldal sebességének drasztikus növelésében. Legalábbis érzetre, mivel ugyan annyi idő lesz betöltenie a böngészőnek, de a különböző JavaScript fájlokat már csak akkor tölti be, ha az oldal betöltődött. Végülis milyen igaz, amíg nincs ott a tartalom minek Google+ komment, +1, Facebook like meg minden egyéb.

Alap JavaScript struktúra

Mivel a legkevesebb ACK-t akarom elérni az oldal betöltéséig, így a legfontosabb scriptrészeket egyből beágyaztam az oldal aljába. Ez nem más, mint egy nagyon alap Application objektum, aminek van egy delegate és egy init függvénye. Ezen kívül pedig az onLoad lekezelését valósítja meg. A delegate függvénnyel lehet új kódrészt hozzáadni az oldalhoz. Amik ide bekerülnek, azok csak azután futnak le, miután az onLoad esemény elsütését követően betöltődött az összes előre megadott JavaScript fájl. Ezek után szépen végighalad és meghívja mindegyiket.

0

Delegáció

Ezek után szépen felsoroltam a nekem kellő JavaScript kódokat, melyeket nem pakoltam külső fájlba, mert éppen nem érte meg nekem ezért a pár sorért. Lehet Egyszer kikerülnek, így nem is lesz használva, de az mindegy is most. Egy pár példa:

1

Töltsünk be mindent, ha kész az oldal

Már csak az egészet elindító onLoad esemény figyelését kell beállítani és kész is vagyunk. Ez hasonlóan egyszerű kód, hiszen hova bonyolítsuk. Itt gyorsan bele is futottam, hogy az én delegált kódjaimnak csak azután szabad lefutnia, miután már az összes külső fájl betöltődött, így logikusan a scriptek onLoad-ját is figyelni kell, de ezután jött, hogy nekem az összes után kell nem az első után. Nomeg aztán eszembe jutott, hogy a betöltésük sorrendje sem mindegy, mert ha például a jQuery-t használom és akarok hozzá egy kiegészítőt, akkor annak utána kell betöltődnie. Gyorsan el is mentem a Require.js oldalára, de mire betöltődött már fel is fogtam, hogy nem akarom ezzel is lassítani a rendszert. Csak azért, hogy a jelenlegi alacsony számú fájlomat kezeljem felesleges.

Nem maradt más, mint a rekurzió. Imádom és talán őrültje is vagyok, mert ahol lehet használom. Lehet néhe nem kellene, de akkor is. Tehát mikor elsül az oldal onLoad eseménye, akkor meghívok egy függvényt. Ez meghív egy újabb függvényt, ami kiszedi az első elemét a fájllistát tartalmazó tömbből és azt betölti. Beállítja onLoad-ra önmagát, így ha betöltődött az első elem, akkor betölti a tömb első elemét újta, de ugye az előzőt kiszedtem már, így az eredetileg második elem lesz most az első. Az egész függvény persze úgy indul, hogy ha üres, akkor meghívja a paraméterben kapott callback függvényt, amit jelen esetben az eredetileg meghívott downloadJSAtOnload definiált és nem más, mint az Application.init meghívása.

2

Mi történt ezután?

Tulajdonképpen nem lesz gyorsabb a teljes oldal betöltése és nem lett kisebb sem tőle az egész, de túlzottan nagyobb sem. Viszont most nem szórakozik a böngésző a Google, a Facebook vagy a jQuery betöltésével, amíg be nem töltött a tartalom, aminek köszönhetően az oldal betöltési ideje drasztikusan csökkent. Az eredetileg 72/75 pont helyett immáron 85 és 87 pont között mozog.

Egy kis plusz

Az összes képet, amit feltoltam a cikkekhez S3-ra optimalizáltattam az ImageOptim nevű ingyenes alkalmazással. Így nagyon sokat spóroltam az adatmennyiséggel.

imageoptim

Így végül elértem (Heroku ingyenes használattal belassíthatja néha neki) a 91/95 pontos éréket is. Így végülis 20 pont növekedést értem el vele. De a cikk elsősorban a JavaScript részről szólt 🙂

Te milyen praktikákat követsz? Mi az ami szerinted nagyon sokat ronthat az oldal betöltési sebességén és mégis sokan elkövetik a hibát?

Kapcsolódó cikkek:

Git Hooks: Automatikus generálás

preview-150x150 Manapság teljesen bevett szokás, hogy a CSS és JavaScript fájlokat tömörítjük.

Mikor a branchek között mozog az ember, akkor le kell futtatni egy plusz scriptet, hogy ezeket legenerálja. Ugyan így a CSS generáló nyelvek használata, mint a StylusLESS vagy az Sass. Az, hogy ki mit preferál az teljesen egyén és projektfüggő. Én például ha lehet Stylus-t használok, de Bootstrap használatánál sok esetben Less-t használok inkább, mert elérhető hozzá és könnyebb így testre szabni. De miként lehet egyszerűsíteni a folyamaton a Git segítségével?

(tovább…)

Kapcsolódó cikkek:

JavaScript: Google mondja! De igaza van?

Rengeteg ajánlás van arra, hogy miként dolgoztassuk fel a böngészővel JavaScript kódunkat. De vajon melyik a leghasznosabb? Google ajánlás alapján a teljes oldal betöltése után, azaz onLoad esemény elsütésekor. Milyen változatok terjengenek?

(tovább…)

Kapcsolódó cikkek: