ugrás a tartalomhoz

Project Spartan is Microsoft's new way to browse

kuka · 2015. Jan. 26. (H), 04.07
A Microsoft új böngészője
 ■
1

Fölösleges erőlködés

Hidvégi Gábor · 2015. Jan. 26. (H), 12.14
Azok alapján, amit a Microsoft az utóbbi tizenöt évben művel, zéró elvárásunk lehet a programmal kapcsolatban. Aztán majd legfeljebb pozitívan csalódunk : ) (de ebben nem hiszek).
2

Feature-ök tekintetében az IE

MadBence · 2015. Jan. 26. (H), 12.20
Feature-ök tekintetében az IE dev verziója azért elég szépen teljesít.
4

Kevés

Hidvégi Gábor · 2015. Jan. 26. (H), 12.28
A felhasználókat ez abszolút nem érdekli. Egy újabb táblázat, amit bújhatunk fejlesztés közben, hogy mit használhatunk és mit nem? Akkor inkább maradok a jó öreg ES 1.3-nál, ott nem kell ilyenen agyalni, legfeljebb nem egy, hanem két sorban oldom meg a feladatot. Nem oszt, nem szoroz.
5

Nyilván nem a felhasználóknak

MadBence · 2015. Jan. 26. (H), 13.25
Nyilván nem a felhasználóknak van. Viszont jó látni, hogy lassan bekerülnek a nyelvbe a régen várt dolgok (natív Promise, generátorok, Object.observe, stb). Nyilván ezek nélkül is lehet működő alkalmazásokat írni, de produktivitás szempontjából nagyon nem mindegy.
7

Akárhogy nézem a táblázatot,

Hidvégi Gábor · 2015. Jan. 26. (H), 15.47
Akárhogy nézem a táblázatot, alig pár sor van benne, ami minden böngészőben meg lett valósítva, így viszont tele kell pakolni if-ekkel a kódot, hogy ha tudni akarom, az adott böngésző mit tud és mit nem.

Produktivitásban sem látok olyan egetrengető különbséget, ami miatt tényleg érdemes rájuk várni.
Iterators and generators
handleResults( i for ( i in obj ) if ( i > 3 ) );
 
function handleResults( results ) {
  for ( let i in results )
    // ...
}

versus
for (var i in obj) {
  if (i > 3) {
    handleResults(i);
  }
}
 
function handleResult( result ) {
  // ...
}
8

tele kell pakolni if-ekkel a

Poetro · 2015. Jan. 26. (H), 15.48
tele kell pakolni if-ekkel a kódot

Ezért vannak a design patternek, mint a Facade, Proxy, Adapter valamint JS esetén Polyfill, hogy ne kelljen.
9

Tehát nem if-eket használsz,

Hidvégi Gábor · 2015. Jan. 26. (H), 15.56
Tehát nem if-eket használsz, hanem patterneket (amik mondjuk függvényekbe ágyazott if-ek), ugyanott vagy, ahol a part szakad.
10

Egyszer

Poetro · 2015. Jan. 26. (H), 16.00
De mivel egy helyen van csak a feltétel, ami csak egyszer van vizsgálva, nem kell telerakni a kódot, akár hányszor is hasznánám az adott szolgáltatást.
11

A fenti generátoros példát

Hidvégi Gábor · 2015. Jan. 26. (H), 16.01
A fenti generátoros példát hogyan oldod meg polyfillel?
12

Sehogy

Poetro · 2015. Jan. 26. (H), 16.15
Mivel a generatorokat korábbi nyelvi eszközökkel jelenleg nem lehet helyettesíteni, de azért az ES3 óta kijött változások legalább 50%-át lehet.
13

A fenti táblázatból nagyjából

Hidvégi Gábor · 2015. Jan. 26. (H), 16.36
A fenti táblázatból nagyjából csak a beépített objektumok kiterjesztéseit lehet polyfillel megvalósítani. Amit meg nem, azt addig nem érdemes használni, amíg legalább 90-95%-os elterjedtsége nem lesz a megvalósításnak. De ha ezek meg nagyjából ugyanolyan vicc-kategóriájúak, mint a generátorok vagy az iterátorok, akkor jogosan merülhet fel a kérdés, hogy minek áldozunk rájuk időt? Nincsenek ezeknél égetőbb problémák? Vagy ez is csak a böngészőgyártók marketingje, hogy lehessen szidni a konkurenciát, mert azok még nem valósítottak meg valami látszatdolgot?
14

Generátor

Hidvégi Gábor · 2015. Jan. 26. (H), 16.42
handleResults( i for ( i in obj ) if ( i > 3 ) );
 
function handleResults( results ) {
  for ( let i in results )
    // ...
}

Ez pontosan annyira átlátható, mint a következő:
for (i in obj) if (i > 3) handleResult(i);

function handleResult(result) {
  //
}

Ráadásul még többet is kell gépelni (két for ciklus). Ez tényleg előrelépés. De végülis illeszkedik a <div id="footer"> -> <footer> átmenetbe.
15

A két példa nem ekvivalens,

MadBence · 2015. Jan. 26. (H), 17.31
A két példa nem ekvivalens, az array/generator comprehension egy filter + map-nek felel meg.
Egyébként a különböző transpilerek/compilerek pont arra valók, hogy elfedjék a böngészők közti különbségeket, így gyakorlatilag nem kell megvárni amíg a különböző nyelvi elemek natív támogatást kapnak a böngészőkben (ami sajnos alsó hangon is jópár év).
Produktivitás szempontjából pedig igenis számít (már amennyiben lehet egy ilyen szubjektív területen állást foglalni), hogy map, filter, fold, stb konstrukciókat, vagy összekuszált for ciklusokat használsz.
16

Egyébként a különböző

Hidvégi Gábor · 2015. Jan. 27. (K), 12.11
Egyébként a különböző transpilerek/compilerek pont arra valók, hogy elfedjék a böngészők közti különbségeket
Ez hogy működik, a fejlesztői környezetben a mentésnél ráakasztod egy hook-ra, vagy pedig kézi hajtányos?
17

Ráakasztod

Poetro · 2015. Jan. 27. (K), 12.21
Ráakasztod a fájl mentésére. Fut egy folyamat, például Gulp vagy Grunt vagy hasonló, ami figyeli a fájlokat, illetve könyvtárakat. Amikor egy fájl megváltozik, akkor lefut a fordító, teljesen automatikusan.
3

Inside Microsoft’s New

Poetro · 2015. Jan. 26. (H), 12.25
Inside Microsoft’s New Rendering Engine For The “Project Spartan”
In the coming months, swathes of IE legacy were deleted from the new engine. Gone were document modes. Removed was the subsystem responsible for emulating IE8 layout quirks. VBScript eliminated. Remnants like attachEvent, X-UA-Compatible, currentStyle were all purged from the new engine.
6

Multiplatform

Gixx · 2015. Jan. 26. (H), 15.42
Díjazom a Microsoft igyekezetét, ugyanis hibái ellenére az utóbbi időben tényleg összekapta magát, és sok esetben jobban teljesít, mint a vetélytársai. A Firefox a memóriát zabálja, a Chrome a háttértárat, stb.

Egy teljesen újragondolt böngésző a hitelét vesztett márkát elhagyva újra az élvonalba tudna kerülni, feltéve hogy hajlandóak végre multiplatformra dolgozni. Linuxon nekem nagyon hiányzik egy megbízható böngésző. A Firefoxot robosztusnak és lassúnak érzem, a Chromium meg sokszor bugosnak mutatkozik. Bár lehet, hogy ez a Xubuntu hibája.

A lényeg, hogy már várom, és kíváncsi vagyok.