Új JavaScript motorral érkezett meg a Firefox 18 beta

Címkék

A Mozilla tegnap bejelentette Firefox webböngészője 18-as kiadásának bétáját. Az tesztverzió érdekessége a új IonMonkey JavaScript JIT compiler, aminek segítségével a Firefox még hatékonyabban tudja feldolgozni a JavaScript-et. Említésre méltó még, hogy a Mac felhasználók még jobb képi megjelenítésnek örvendhetnek a Retina Display Support megjelenése okán.

Részletek a bejelentésben. Letölthető Windows, OS X és Linux platformokra innen.

Hozzászólások

Alakul ám a böngészők Flash Playeresítése.

Arra, hogy a HTML5 + CSS + JS alapvetően arra kell most a cégeknek, hogy ne legyenek beszorítva az Adobe platformjára a webappok. Viszont ezzel a lépéssel ugyanazok a problémák meg fognak jelenni, mint a Flash esetében is.

Igazából már most őrületbe kergetnek még a nagyobb oldalak is (Google, Facebook, stb.) az elbaszott input fókusz kezelésükkel, az elbarmolt UI-val, azzal, hogy olyan technológiára építenek appokat, ami alapvetően nem arra való (a HTML alapvetően szöveg megjelenítésre jött létre, ennek a mai napig érződik a hatása, pl. nincs kijelölhetetlen text, ami enyhén esztétikusabb lenne a tartalmon kívül kb. minden szövegre). De brutálisan sok példát lehetne még mondani, szerintem el is fogom kezdeni jegyzetelni, hogy mi az, ami bosszant.

Szóval az irány, amerre a web most halad, az egy inkozisztens trágyadomb felé mutat. Hakkolás hakkolás hátán, egyszerűen gusztustalan.

Udi említette a kommentjében a Shumway Open SWF Runtime Project-et. Ezt kellett volna pár évvel ezelőtt beindítani, Flex SDK eddig is nyílt volt, aztán annyi. Lehetne szépen, elegánsan, profi módon webappokat készíteni, amik esetleg (Air runtime-ban) még desktop appként is futnak (vö. Chrome, FF hasonló taknyolásai).

A tökéletes mindig az lenne, hogy kompromisszumok nélkül lefejleszteni egy új dolgot, amely az aktuális igényeknek meg fog felelni. De aztán telik az idő, és saját régebbi verzióival kompatibilisnek kell maradnia, meg az igények is változnak. Sőt, ha valamiért egy adott megoldás nagyon elterjed, akkor annak támogatása nagyobb súlyt kell hogy kapjon, és egyre jobban belebetonozottnak fog tűnni. Stb.

És a végén megint ugyanott vagy. Szerintem ez nehezen kiküszöbölhető hosszú távú kompatibilitás tartásánál bármilyen megoldásnál.

Viszont ezzel a lépéssel ugyanazok a problémák meg fognak jelenni, mint a Flash esetében is.

pont az a lényeg, hogy nem, mert a HTML5 az szabvány -> nincs vendor lock.

A többi amit írtál pedig vagy lényegtelen (szar UI-t bármilyen technológiával lehet fejleszteni), vagy lejárt lemez.

--
CyclonePHP

A html5 nem szabvány, legfeljebb az lesz valamikor. Az sem igaz, hogy nincs vendor lock, mert gyakorlatilag nincs olyan böngésző, amelyik a html5 jelenlegi változatát 100%-osan implementálná. Vagyis akármilyen kis subsetet is használsz, minden böngészőt nem fogsz tudni támogatni.

Ebből a szempontból a flash még jobb is, mert ott legalább 1 vendor dönti el, hogy mi legyen a saját szabványában és mi nem, vagyis fejlesztőként pontosan tudod, mit használhatsz és mit nem. Ha pedig akarsz egy saját flash playert, pontosan tudod, mit kell támogatnod egy 100%-os implementációhoz.

Szar ui-hoz annyit, hogy egy normális fejlesztői környezet ad eszközöket arra, hogy könnyen alakíthass ki jól használható ui-t. Vagyis rossz ui létrehozásához vagy direkt kell rosszul csinálni a designerben (több munka), vagy a designer nélkül kell csinálni (még több munka).

Szvsz a fókuszkezelés egyértelműen az appokat fejlesztők hibája, ugyanúgy, ahogy flash-ben is el lehet rontani _bármit_.

Kijelölhetetlen szöveg pedig minimum 4 éve van.

A hakkolás a sok delphi kóderből php kóderré vált, majd flash-ben, most pedig jquery/társai-val "fejlesztők" "munkájának" az eredménye. Olyan sok "web"fejlesztőt ismerek, aki alapvető dolgokkal nincs tisztában, hogy ihaj - tisztelet a kivételnek.

De még1x: ez rohadtul nem a google/mozilla/egyebek hibája. Egy eszközt lehet jól és rosszul is használni.

Nana.
A W3C még vitatkozik, hogy része legyen-e (újra) a specifikációnak, vagy sem. Régebben része volt egy draftnak, azóta kivették a jelenlegi specifikációból, de most megint filóznak, hogy kell-e vagy nem.
http://lists.w3.org/Archives/Public/www-style/2012Jul/0573.html

Kísérleti funkciót nem használunk máshol, csak kísérleti projekten. Persze a webpistikéknek jó dolog az, hogy napról napra változik a specifikáció, így aztán a böngészőt készítők gyakorlatilag teljesen szabad kezet kapnak abban, hogy mit lehet és mit nem. Persze az IE-t azért fikázzuk a saját dolgai miatt, de a többi böngészőt nem. Pedig azok is pontosan ugyanígy viselkednek.

Várj, én úgy tudom, ez a user-select már nem része az ajánlásnak, superseded.
Lásd:
http://www.w3.org/TR/css3-userint
Ennek a része volt a user-select anno, http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select itt látható is.

Azonban a helyére lépő CSS3 Basic User Interface Module (http://www.w3.org/TR/css3-ui/ ) már nem tartalmaz ilyen propertyt.

Ez az igazi gányolás, amikor még a "szabványügyi testület" sem tudja mit akar, a böngészők már megint nem szabványkövetők, mert nem lehetnek azok.

Ezek szerint úgy gondolod, teljesen helyénvaló az egyes böngészőkben a vendorspecifikus funkciók megléte. Végülis, a Netscape és IE által vívott első böngészőháborúban meg pont az volt a baj, hogy az IE és az NS egyedi funkcionalitásokat implementált, amit a versenytársa nem. Most akkor nem értem, mi is kell igazán nektek? Egyedi funkció, csak ne a MS csinálja? Nem baj, ha az Apple csinálja? Vagy a Google? Elárulom: ugyanakkora baj.

Szerintem helyénvaló, amíg egyértelmű, hogy vendor-specifikus és nem arról van szó, hogy egy adott dolog másképp viselkedik mint a többiben (ld. IE6) vagy olyan kiterjesztést nem implementál, amit a versenytársak a szabadalmak vagy a technológiai korlátok miatt (ld. ActiveX vs multiplatform böngészők) nem tudnak implementálni.

A web organikusan fejlődik, ezek a vendor specifikus kiterjesztések segítenek felmérni azt, hogy egy technika a gyakorlatban működik-e vagy nem, tökéletesíteni lehet, ha pedig életképesnek bizonyul, be lehet emelni a szabványba. Sokkal életképesebb szabvány jön így létre, mintha a széles körben ki nem próbált, elméleti dolgokat vetnének a papírra.

Vannak itt, akik egy ceruzával és papírral egy ültő helybe megalkotnák a HTML6-ot is, de a világ már csak ilyen igazságtalan; aki nem ért hozzá az tanítja és az szabványosítja. :P

"ld. ActiveX vs multiplatform böngészők"
Még jó, hogy az ActiveX egy nyílt specifikáció 1996 óta, a specifikációs az az Open Group kezeli, akinek a felelőssége a UNIX specifikálása is (SUSv4) és a UNIX trademark is az övék. Nem hiszem, hogy az MS rosszhiszeműségén múlna, hogy implementálja más is az ActiveX-et.
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.js…

"A web organikusan fejlődik"
Éppen ez a baj. Ez technológia, nem biológia. Ez mérnökség. Az pedig nem organikus. Nincs olyan, hogy szabvány, nem tudsz hosszú (5 év) távra normálisan megtanulni/megtanítani bármit is, így idővel egyre drágább lesz ez a technológia, ahelyett, hogy olcsóbb lenne. 2020-ra várható az első teljesen kompatibilis HTML5 böngésző.
"Sokkal életképesebb szabvány jön így létre"
Nem, nem jön létre szabvány. 2014-re saccolja a W3C a HTML5 szabványt, addig ki tudja, menyire fognak divergálni a böngészők.

Ezek nem egyedi funkciók, és épp a közös nevező megtalálása a cél. Az activex, a filterek, a scripttelt css funkciók, htc és tsai meg mind a ms egyéni elgondolása a webről, miközben telibesz.rta, hogy ki mit gondol erről. A dart már inkább mondható hasonló elgondolásnak, bár a dart implementálásához nincsen szükség arra, hogy a teljes win32 API alatta álljon.

Nem. Ha tiltod a kijelölhetőséget, akkor eleve nem tudod textként értelmezni az adott szöveget, ergo más se fogja tudni. Legalábbis olvastam ilyet. Viszont most logikusan belegondoltam: ezt javarészt javascriptel lehet elérni, a google azt meg úgy sem ismeri. Szóval tévedtem.

csak gondolkodom, de ha css-sel tiltod, akkor elvileg az megjelenés, nem tartalom, azt nem kellene figyelembe vennie a böngészőnek. Ha js-sel tiltod egyértelmű hogy nem fog tudni arról a kereső, ha pedig html-ben tiltod (mint ha az IE úgy találta volna ezt fel korábban hogy egy html attribútumot lehetett megadni - lusta vagyok rákeresni most)... na akkor lehet hogy azzal foglalkozna a keresőmotor is.

Bár nem tűnik logikusnak az összefüggés a kijelölhetőség és a tartalomként értelmezés között.

Te meg nem lattal valodi MVC-t desktop alkalmazasban, Observer patternnel megvalositva

de láttam, és a fentebb felsorolt javascript frameworkök pontosan ezt csinálják. Pontosan ezért preferálom ezeket, mert rendes UI architektúrát eredményeznek, és nem találják fel újra a kereket, hanem a klasszikus desktop MVC rendszert valósítják meg, csak más nyelvi/technológiai környezetben.
A struts-szerű szerver-oldali MVC (amit átvett kb az összes PHP framework) tényleg nem sokban hasonlít a desktop MVC-re (max. annyiban, hogy van benne M meg V meg C), de most nem erről van szó.

Es ne keverjuk az n-tier architekturat meg az MVC-t, mast jelent. Hasonlo, de mast jelent.

ilyenről szó sem volt

--
CyclonePHP

"de láttam, és a fentebb felsorolt javascript frameworkök pontosan ezt csinálják."
Oh, tehat kepesek arra, hogy ha az adatmodell modosul, akkor minden kliens azonnal kapjon rola ertesitest. Peldaul van egy egyszeru szamlalo, nevezzuk online userek szamanak. persicsb beloginol, es ekkor mindenki azonnal, felhasznaloi interakcio nelkul latja, hogy nezd mar, 5 helyett 6 user van online?
Mert en ilyet meg nem lattam. 1-1 kliensre mukodik az, hogy egy felhasznalo altal kezdemenyezett HTTP roundtrip alapjan frissulnek az oldal elemei, de erre keretrendszert meg nem lattam. A periodikus polling pedig nem MVC.

Oh, tehat kepesek arra, hogy ha az adatmodell modosul, akkor minden kliens azonnal kapjon rola ertesitest

félreértettél. Csak JS-ről beszéltünk, tehát ha egy adatelem változik, akkor az azt reprezentáló UI elem is változik (kap eseményt) böngészőn belül.
A szerver-kliens kommunikációt nem érinti a dolog. Én Hevi-nek a "js = taknyolás" felvetésére reagáltam, hogy vannak már normális JS MVC keretrendszerek. Az más kérdés, hogy ezek nem oldják meg a webfejlesztés összes problémáját.

--
CyclonePHP

"ha egy adatelem változik, akkor az azt reprezentáló UI elem is változik "
Es ez hol a feneben MVC? Ez egy alap dolog minden alkalmazasban :)

Adatelem az is, amit a szerver a sajat allapotabol allit elo az oldalon.

Pont webes 'alkalmazasoknal' szokas azt emlegetni, hogy a szerveroldalon van az allapot, egy helyen, es te akarhonnan belepsz, ugyanazt latod, mert nem a geped tarolja az allapotot. Erre varj gombot.

Ertsd meg, weben valodi MVC-t a HTTP half-duplex jellege miatt nem lehet csinalni.

Es ez hol a feneben MVC?

miért, akkor az observer-megközelítés alatt te mit értettél?

más: az MVC az nem alkalmazás-architektúra hanem GUI architektúra. Ha nekem a javascriptes felületem MVC szerint működik, akkor az MVC.
mégegyszer: maradjunk a "csak js" kontextusnál, http meg szerver nem igazán érdekel
Pontosabban, a kliensoldali adatmodellemet megfelelő felhasználói interakció esetén (save gomb onclick, akármi) szinkronizálom a szerver-oldallal, de ettől még a GUI adatmodellje mindig a böngészőben marad. Mi is maradjunk ott, mert ez volt a vitaindító. A "weben valodi MVC-t a HTTP half-duplex jellege miatt nem lehet csinalni" dologgal természetesen tisztában vagyok, de - immáron harmadjára - pls maradjunk a kliensoldalon.

--
CyclonePHP

A weben nem létezik olyan, hogy csak kliensoldal. Ha létezne, léteznének offline is működő webes alkalmazások, azonban pont az a mondás, hogy mivel az alkalmazás a szerveren van, egyszerűbb frissíteni, minden user azonnal a legfrissebb változatot látja, nem kell külön kliensoldali update-mechanizmusról gondoskodni stb.
"miért, akkor az observer-megközelítés alatt te mit értettél?"
Az Observer csak előfeltétele az MVC-nek, de máshol is jó.

"maradjunk a "csak js" kontextusnál, http meg szerver nem igazán érdekel"
Akkor az nem webes alkalmazás. Én is tudok olyan, kizárólag JS-sel működő HTML oldalt készíteni, aminek nem lesz köze a HTTP-hez, a user szépen megnyitja lokálisan, file:// protokollal és örül. De akkor az nem webalkalmazás. Gondolj egy lokális, intelligens súgóra. Abban hol van meg a webalkalmazások összes előnye? A központi frissítést szokták nagy előnynek tekinteni.

Akkor az nem webes alkalmazás.

szemléld másképp a dolgot: van egy kliensoldali javascriptes mvc kisalkalmazásod (egy felület), ami kommunikál egy szerver-oldalon futó webservice-el (jellemzően json alapú), amit különálló alkalmazásként kezelsz. Én arra szerettem volna rámutatni, hogy a kettő közül a kliensoldali alkalmazásban megvalósítható normális, letisztult, desktop-szerű mvc architektúra, innentől kezdve a "js taknyolás"-ról van szó. Ennyit mondtam, semmi többet, és ebben szerintem igazam van.

Te azt mondod, hogy attól, hogy a kliensoldalon van MVC, attól még az egész együtt nem lesz normális MVC. Ebben meg neked van igazad.
Ámen

--
CyclonePHP

Itt azért még hozzátenném, hogy a kliensoldali kód csak akkor tud a szerver-oldali WS-sel kommunikálni, ha az a kliensoldali kód is ugyanonnan származik, a Same Origin Policy miatt. Persze most már ennek a security képességnek a kikerülésére is vezetnek be új 'szabványokat', mint Cross-Domain Resource Sharing és társai, de ez meg méginkább jelzi a böngészőalapú alkalmazások esetében azt, hogy a taknyolás bizony helyes kifejezés.

Same-origin policy-ről tudok, de ritkán szokott zavaró lenni (legalábbis nekem eddig ritkán volt az).

A fenti megközelítésnek (js mvc + json ws) egyébként van egy olyan előnye is, hogy az lesz belőle, hogy minden, amit a szerver-oldali alkalmazásod tud, elérhető nem csak a kliensoldali js app számára, hanem más alkalmazások számára is, így veszettül könnyen integrálható lesz. Ez ugyanaz az elv, mint mikor egy c program úgy van megírva, hogy függvénykönyvtárként is használható meg van hozzá egy parancssoros frontend is. Ugyanezt az ötletet alkalmazzuk ebben az esetben, csak weben. Ez nekem veszettül bejön =)

--
CyclonePHP

Hogyne tudnál. Külön HTML fileok, amiket iframe-ként beemelsz mindenhova. Szükség esetén a HTML file-nak paramétert is megadhatsz, amit a fileban található JS dolgoz fel. Persze mivel beépített funkcionalitás nincs arra, hogy a megadott oldal query paramétereid elérd, ezért itt is taknyolni kell.
Szép, nem? :)

Döntsd már el, hogy szerveroldal vagy kliensoldal közül melyik az, ami igazán olyan jó. Mert ha csak szerveroldalon tudsz normális komponenseket kialakítani, akkor az előbbi beszélgetésünk, ami a kizárólagos kliensoldali MVC-ről szólt, megintcsak értelmét vesztette. Döntsd el, hogy akkor most a webes alkalmazás működik-e szerveroldal nélkül, vagy nem.

Közben felmerült bennem a kérdés, hogy miért para ha afelé haladnak a böngészők, hogy képesek legyenek a flash player képességeit pótolni? A flashban nem az volt a rossz, hogy gazdag ui-t lehetett vele csinálni, hanem az ahogy muzsikált teljesítmény szempontjából, az, ahogy elzárja a tartalmat a keresők elől, az hogy nem free...

Jópár esetben nem is volt baj, hogy nem tudtak vele mit kezdeni a keresők, gondoljunk például a flashjátékokra. Azért meg kár volt erőltetni a html5-öt, hogy most abban csináljunk olyat, amiben nem talál semmi érdekeset a kereső. A fullflash oldalak nekem se tetszettek, de mindent lehet szarul is, meg jól is csinálni. A többi felvetésbe nem tudok belekötni.

Btw, a JavaScript önmagában is egy elég csúnya, gusztustalan nyelv és jelenleg valahol az ActionScript 2.0 környékén tanyázik, amit már ugye évek óta leváltott a végre rendesen használható 3-as verzió.

Új motor, új bugok. Ráadásul a telepítését átlaguser nem is fogja elhalasztani mert települ kérdés nélkül. De jó is lesz...

--
Gábriel Ákos
http://i-logic.hu

Ehhez kell az emberi zsenialitás, hogy alkossunk egy szinte teljesen optimalizálhatatlan dinamikus nyelvet, majd a legragyogóbb elmék összes erőforrását arra pazaroljuk, hogy megpróbálják ezt optimalizálni :-).