20 éves születésnapját ünnepli a JavaScript programozási nyelv
2015-05-18T11:25:57+02:00
2015-05-30T01:23:07+02:00
2022-07-22T08:41:46+02:00
  • En ezt magamban olyan hangsullyal olvastam fel, mint amikor az Eszak-Koreai hiradoban bejelentik, hogy ujabb raketat lottek fel :D

    (Amugy most be vagyok nyomva, es elvezem :D)
    Mutasd a teljes hozzászólást!
  • Akkor meg az a kérdés, hogy miért nincs egy mindent elsöprő, nagyszerűen megírt HTML+JS megoldás sem a placcon?

    Biztos lemaradtál róla, de van egy ilyen megoldás. Úgy hívják: web. Történetének két évtizede alatt legalább 5 nagyságrenddel több alkalmazást írtak rá, mint az összes többi platformra és keretrendszerre összesen az elmúlt 70 év alatt. Az utóbbi fél évtizedben pedig már gyakorlatilag minden új alkalmazást elsődlegesen vagy kizárólagosan rá írnak meg - kivéve azokat amiknél adatvédelmi vagy konnektivitási megfontolások ezt nem teszik lehetővé.

    Nem találsz nála univerzálisabb UI-t és frameworköt, amire több fajta programot írtak volna, mint rá, és ami több use case-t tudna hatékonyan kiszolgálni. A vele és benne kezelt adatok mennyisége és sokfélesége pedig szintén sokszorosan meghaladja a bármilyen másik rendszerben kezelt adatok mennyiségével és sokféleségével.

    Több fejlesztő dolgozik rá és több ember, több időt használja a rá írt alkalmazásokat, mint bármilyen más operációs rendszerre, hardverre, nyelvre vagy keretrendszerre, illetve az azokra írt programokat. Manapság már gyakorlatilag nincs olyan vállalkozás, amely közvetlen vagy közvetett módon ne függne tőle, és megkockáztatom, hogy az elmúlt két évtized valódi gazdasági teljesítménynövekedésének túlnyomó többségét ő adta.

    Milyen más technológiát tudsz említeni, amire nem hogy jobban, de akár csak olyan szinten is igaz az, hogy "mindent elsöprő" megoldást képez, mint a web?

    Te egyszerűen nem látod a fától az erdőt, amikor "mindent elsöprő, nagyszerűen megírt HTML+JS megoldás" követelsz, és nem veszed észre, hogy ott van az orrod előtt. Téged valójában pont az zavar meg, hogy a web maga annyira népszerű, univerzális és rugalmas, hogy minden másnál több dologra tud hatékony megoldást nyújtani - amiből eredően a rá és vele készült megoldások minden más eszközzel készültnél szélesebb spektrumon helyezkednek el, és így összességükben ugyanennyire szélsőségesen kevés közös dolog is van bennük. Leszámítva persze azt - és ezt itt a lényeg -, hogy mindannyian HTML+JS-re épülnek.
    Mutasd a teljes hozzászólást!
  • Azért nincs, amiért nincs úgy általában egy mindent elsöprő programozási nyelv, hanem van JS, Java, C,C++, Python, Perl és ezer más....

    Egyébként nekem személyes véleményem az (nem vitaindítónak szánom), hogy ilyen téren még mindig a GWT vagy a GWT módon működő dolgok lennének a jók. Tehát generált JS, mivel szerintem(ez sem vitaindító) a generált kód a legjobb. Illetve nem a legjobb, de a leginkább stabil minőség. Mivel a sokmillió soros kódok világában fontosabb az, hogy a kód állandó(elfogadható) minőségű, minthogy a leginkább kihegyezett legyen. (Pár extrém esetet kivéve)

    Másrészt meg vannak király frameworkok, bizonyos feladatokra.
    Mutasd a teljes hozzászólást!
  • Akkor meg az a kérdés, hogy miért nincs egy mindent elsöprő, nagyszerűen megírt HTML+JS megoldás sem a placcon?

    A technologiai előnye vitathatatlan (nem kell telepíteni, minden platformon megvan, egyszer kell megírni, stb, stb)

    Ha ekkora lehetőséget kihagy a kimeríthetetlen méretű tőke (google, ms, apple, stb), akkor ez miért van?
    Miért nincs egy startup sem, aki azt mondja: na itt a nagy lehetőség, viszem az egész piacot, a google jövőre jöhet kölcsönkérni, mert király frameworkot alkotok?
    Mutasd a teljes hozzászólást!
  • Nos a JavaScript  nekem sem a szívem csücske, Java fejlesztő vagyok, de sokat kell dolgoznom JS-tel is (vanilla és Jquery) és azt kell mondjam, hogy Stingnek szerintem most maximálisan igaza van.

    Nyilván az architektúrának is vannak korlátai, de nem attól lesz a JS lassabb, a "natív" meg gyorsabb, mert JS és "natív", hanem attól, hogy rendesen van-e megírva, figyelembe véve az eszköz lehetőségeit vagy sem...

    JS-ben is lehet korrekt, kiváló user élményt adó GUI-t írni és "natív"-ban is lehet borzalmas hulladékot előállítani..és visszafelé is...és nem a nyelvtől lesz egy alkalmazás lassú vagy gyors, hanem a rendelkezésre álló, kvázi külső erőforrások (hálózati kapcsolat, db kapcsolatok, stb) megfelelő vagy nem megfelelő kezelésétől.
    Mutasd a teljes hozzászólást!
  • A gyakorlat ezzel szemben az, hogy:
    - nyilván volt azóta fejlődés, de a Chrome alapú WebView csak Android 4.4-től van, ami jelenleg még csak 50%-os elterjedtségű, a megrendelő meg azt akarja, hogy az eszközök 90%-án szépen menjen az animáció, ha már egyszer 3 éve is szépen mentek egy natív appban az animációk (technikai dolgok nem érdeklik) -> tehát a gyakorlat: csak 2 év múlva tudsz ezekre építeni, ha legalább az aktív userek 90%-át el akarod érni.
    - a frameworkok is le vannak maradva: a Sencha Touch azért tölt indulásnál több másodpercet, mert az egész libraryt tartalmazza a JS fájl, amit be kell rántani indulásnál (több mint 900kB-t kell beparszolni), ez sok más library-nél is így van. Nemrég óta van requirejs, és nem is minden framework támogatja. Ez szintén nem a böngésző hibája, de attól még gyakorlatban az van, hogy bénák a frameworkök, emiatt te sem tudsz "A" kategóriás appot letenni az asztalra. -> tehát a gyakorlat: át kell írnod a frameworkod, hogy egyes részei tudjanak dinamikusan betöltődni, vagy vársz pár évet, vagy használsz olyat, ami fel van erre készítve
    - imádkozol, hogy a megrendelő, akinek gőze sincs az egész mögötti technológiáról, ne jöjjön valami hasonlóval (a szereplők kitaláltak, de megtörtént esemény alapján :D):
    "Most láttam XY appban ezt a tutti animációt, be tudnád tenni? Szomszéd Pistike azt mondta, hogy neki kb 2 óra lenne" és akkor szépen magyarázhatod el, hogy nem, mert te HTML, JS alatt csináltad az egészet, és:
    1/ott nincs erre hardveresen gyorsított CSS animáció, és jelenleg még draft sem jött ki róla.
    2/Android 4.4-től fog csak menni ez az animáció (megrendelő: - De méér? ez az (natív) app gyönyörűen megy Android 2.3-on is ezzel az animációval)

    Következmények HTML5/JS esetén: nem kapsz több megrendelést, mert Pistike megcsinálta szebbre, jobbra. :)
    Mutasd a teljes hozzászólást!
  • Sting, látszik, hogy közöd nincs a mobilos HTML5/JS alapú mobilfejlesztéshez.

    Meggyőző ezt a kritikát attól hallani, aki még a JS, a CSS és a DOM közötti különbséget sem ismeri, illetve nem tudja, hogy egyenként, "típusosan" is lehet a CSS attribútumokat a DOM-ban állítgatni.

    Ha egy komolyabb helyen előadod, hogy te HTML5/JS környezetben ugyanazt a szintet tudod hozni, mint az adott platform natív UI-jával, akkor nem fognak komolyan venni.

    Mennyire nem fognak komolyan venni? Kevésbé vagy jobban, mint ha nem tudom azt, hogy a JS, a CSS és a DOM nem egy és ugyanaz?

    Sencha Touch: két éve próbáltam, iOS-en, és Androidon

    Hát, akkor a mai helyzet vonatkozásában éppen csak olyan 500-1000%-ban lehetnek irrelevánsak a megfigyeléseid, már csak az azóta a szoftveres és a hardveres téren bekövetkezett teljesítménynövekedés miatt is.

    - lassú betöltési idő (3-4) másodperc, egyszerűen ez túl sok (egy WebView a telefonról töltötte be a cuccokat)

    Ahol és amit egy WebView 3-4 másodpercig tölt, ott ugyanazt egy natív alkalmazás is 3-4 másodpercig tölti. Vagy nagyon rosszul van az betöltés megírva. Ami persze simán elképzelhető, ha valaki nem tudja és érti a különbséget a JS, a CSS és a DOM között sem.

    - iOS-en egész jó, de azért érezhető, hogy nem natív UI-jal van dolga az embernek, néha megakad az animáció, apró visual artifactok, egyébként elég jó
    - Android: kicsit több visual artifact, animációk diavetítésbe mennek át, 1-2fps, visual glitchek, lassú, valahol félúton a használhatatlan és a használható között

    Ez maximum a már korábban említett, nem hardveresen gyorsított / nem natív CSS animációk esetében fordulhat elő. Ez persze ugyanígy van natív alkalmazásoknál is, hogy ti. ha saját vezérlőt csinálsz és olyant animálsz, amit natívan nem támogat az UI és/vagy a grafikus rendszer, akkor nyilván bármikor megakadhat az. Sőt, utóbbi nélkül is akadnak random módon natív appok, napi szinten, mindegyikünk készülékein - nyilvánvalóan a HTML/JS-től teljesen függetlenül okokból kifolyólag, amiktől igen, nyilvánvalóan a HTML/JS sem fog megvédeni. Szóval itt-ott az is akadni fog, valóban.

    Persze lehet felhozni, hogy ez nem a JavaScript hibája, de a lényeg akkor is az, hogy böngészős környezet még messze nem tart ott, hogy "A" kategóriás appot lehessen benne fejleszteni.

    Egyrészt ebben a topikban alapvetően nem is a böngészős környezetről volt szó. Másrészt mindaz amit leírtál, semmilyen szinten sem bizonyítja, hogy ne lehetne "A" kategóriás appot (jelentsen bármit is ez) írni akár böngészős környezetben is.

    Lásd facebook mobilos weboldalának sebessége és smoothsága vs facebook app sebessége és smoothsága

    Erre mondják angolul, hogy "over your head". Az egész topik, úgy ahogy van.
    Mutasd a teljes hozzászólást!
  • Sting, látszik, hogy közöd nincs a mobilos HTML5/JS alapú mobilfejlesztéshez. Ha egy komolyabb helyen előadod, hogy te HTML5/JS környezetben ugyanazt a szintet tudod hozni, mint az adott platform natív UI-jával, akkor nem fognak komolyan venni.

    Sencha Touch: két éve próbáltam, iOS-en, és Androidon ugyanaz az app, akkori felső középkategóriás telefonon:
    - lassú betöltési idő (3-4) másodperc, egyszerűen ez túl sok (egy WebView a telefonról töltötte be a cuccokat)
    - iOS-en egész jó, de azért érezhető, hogy nem natív UI-jal van dolga az embernek, néha megakad az animáció, apró visual artifactok, egyébként elég jó
    - Android: kicsit több visual artifact, animációk diavetítésbe mennek át, 1-2fps, visual glitchek, lassú, valahol félúton a használhatatlan és a használható között

    Ionic:
    - nemrég próbáltam, Androidon (Snapdragon 800, 2.2GHz), elég jó, de sikerült bugokat előhozni.

    Persze lehet felhozni, hogy ez nem a JavaScript hibája, de a lényeg akkor is az, hogy böngészős környezet még messze nem tart ott, hogy "A" kategóriás appot lehessen benne fejleszteni. Lásd facebook mobilos weboldalának sebessége és smoothsága vs facebook app sebessége és smoothsága (tegyük fel, hogy a facebooknak megvolt az anyagi háttere, hogy mindkettőből a legjobbat hozza ki). Közelít, de nem az igazi.
    Mutasd a teljes hozzászólást!
  • Melyik a világon a leggyorsabb nem JavaScript-ben megírt UI framework? Hányszor olyan gyors, mint a világon a leggyorsabb JavaScriptben/C++-ban/C#-ban/Java-ban/stb. megírt UI framework? És mi a jelentősége ennek?

    Arról, hogy értelmetlen "JavaScript-ben megírt UI framework"-ről beszélni, illetve, hogy gyakorlatilag minden modern UI framework sebességét elsődlegesen nem az a nyelv határozza meg amiben írták, hanem egyéb jellemzők (pl. mennyire illeszkedik a gazdarendszer architektúrájához, mennyire képes a hardveres gyorsítást kihasználni, stb.) már ne is beszéljünk - hiszen ezeket pár hozzászólással korábban már részletesen elmagyaráztam.
    Mutasd a teljes hozzászólást!
  • találtál egy pár - sebesség szempontjából - előnytelenebbül/rosszul megírt UI-t

    Melyik a világon a leggyorsabb JavaScriptben megírt UI framework? És hányszor olyan gyors, mint a világon a leggyorsabb nem JavaScriptben megírt UI framework?
    Mutasd a teljes hozzászólást!
  • Ok. Szóval, a jquery-ui mobile fejlesztői bénák, a microsoftos fejlesztők dettó.

    Szerinted azok. Amúgy meg a dolognak semmi köze nincs a bénasághoz, csak pl. a jQuery Mobile egyszerűen egy fél évtizedes technológia, amit teljesen más környezetbe és teljesen más alapokon terveztek, mint ahol ma futnak a webes alkalmazások és amit a mai webes technológiák tesznek lehetővé. A Microsoft fejlesztőivel meg nem tudom mi a bajod, mert a HTML5-ös alkalmazásaik (még a webesek is) piszok gyorsak. Lásd Outlook, lásd OneDrive, stb.

    Nem mellesleg a Microsoftnál már 20 év óta használnak HTML-t és CSS-t a Windows-ban mindenhol, "natív"(-nak tűnő) alkalmazásokban, az asztaltól kezdve az intézőn át a súgóig. Amit persze te nyilván nem tudsz, pont azért, mert ez kívülről nem látszik és semmiféle problémát nem okoz. Sőt! Nyilván pont azért használják, mert sokkal jobb az adott célra, mint akármelyik valóban natív technológia.

    Akkor tudsz mondani egy olyan mobilos jquery frameworkot ami hasít, és ugyanazt a felhasználói élményt adja a usernek mint a natív felület ?

    Ja, hogy te még mindig nem érted még azt sem, hogy JavaScript!=jQuery? Hát, így nehéz lesz... Amúgy meg: Sencha Touch, LungoJS (itt egy 3 éves! videón), Ionic, stb.
    Mutasd a teljes hozzászólást!
  • Ok. Szóval, a jquery-ui mobile fejlesztői bénák, a microsoftos fejlesztők dettó. Akkor tudsz mondani egy olyan mobilos jquery frameworkot ami hasít, és ugyanazt a felhasználói élményt adja a usernek mint a natív felület ?
    Mutasd a teljes hozzászólást!
  • Nézd, a jquery mobile 1.4 demóját bárki letöltheti a play store-ból és kipróbálhatja. Én megtettem, többször, több gépen is. A mostani tabletem ugyan nem a csúcs kategória (Lenovo, 4 mag, 1.3 Cortex A7, 7 colos kijelző), de annyira gyenge vasnak sem mondanám. És ez az első olyan vas, amivel maga a demó csak annyira laggol, hogy azt merem mondani hogy ezt _talán_ már oda merném adni egy user kezébe.

    Nézd, a Crysis 3 demóját is bárki letöltheti és kipróbálhatja. Én megtettem, többször, több gépen is. A mostani gépem nem csúcs kategória, de ez az első vas, amin a demó csak annyira laggol, hogy azt merem mondani hogy ezt _talán_ már oda merném adni egy user kezébe.

    A te "logikád" alapján ez azt jelenti, hogy a natív kód, illetve UI futtatásához brutális vas kell, mert konkrétan az a program, amit néztem, az egy gyenge vason csak szenved. És ebből le kellene vonni azt a konklúziót is, hogy amin natív kóddal használható UI-t tudsz produkálni, ott lényegében bármivel képes vagy erre.

    A baj csak az, hogy ez a "logika" teljesen téves. A HTML5, CSS, JavaScript esetében is.

    Szóval írhat bárki bármit, én ezt már kipróbáltam kb. 6 különböző vason és azt kell mondjam, hogy bár a legújabb vasakon már tényleg elmegy a javascriptes UI, de bizony a natívval nem játszik egy csapatban.

    Nem. Neked azt kellene mondanod, hogy találtál egy pár - sebesség szempontjából - előnytelenebbül/rosszul megírt UI-t, ami lassabban működött, mint pár - ebből a szempontból - jobban megírt másik UI. Viszont nyilván tucatszám lehet ennek fordítottjára is példát találni.

    Persze a dolog ott kezdődik, hogy már megint tejesen egyértelmű, hogy abszolút nem ismered azt, ami felől ítélkezel, és nem tudod, hogy hogyan is működnek a dolgok a háttérben (amit ha tudnál, mindjárt értenéd, hogy miért tapasztalatod azt amit). Pl. adott esetben nyilvánvalóan nem tudod, hogy a modern webes UI-kban a JavaScript-nek szinte semmi szerepe nincs, mert az áttűnések, mozgatások, animációk, de még a felbukkanó ablakok kezelése, és nagyjából minden más is mind CSS3-as áttűnésekkel, animációkkal történik, egyetlen JavaScript sor nélkül (vagy maximum szó szerint egyetlen JavaScript sorral). Tehát semmi értelme "javascriptes UI"-nak titulálni a HTML5-ös felületeket - mert, hogy kb. JavaScript az amiből a legkevesebb van bennük, minden értelemben.

    Persze, vannak szuboptimálisan megírt felületek és keretrendszerek is használatban, amik ész helyett izomból akarják megoldani a dolgokat. Pl. JavaScriptből animálnak a helyett, hogy a CSS-re hagynák a dolgot. Amivel összefüggésben persze nem használják ki pl. a hardveres gyorsítóképességeket. Ezek nyilván lassabbak lesznek - de megint nem azért, mert JavaScript-ben vannak írva, mert hogy ugyanilyen lassú lenne az a natív kód is, ami szintén nem hagyná a grafikus magot dolgozni, és helyette processzorból és kódból akarna mindent megoldani. Utóbbi a lassúságuk oka - nem pedig az, hogy JavaScript-ben vannak írva.

    Ilyen pl. a jQuery Mobile is, ami egy őskövület, és ami tényleg igen erősen épít a JavaScriptre, miközben a CSS3-as újdonságokból pedig alig használ valamit (Web Components-ről, Custom Elements-ről nem is beszélve) - de ami éppen ezért piszkosul nem reprezentatív a HTML5+CSS+JavaScript mai állapotát, sebességét illetően, és nagyjából a lehető legrosszabb példa amit hozhattál. Kb. olyan, mint ha egy X nyelven írt szoftveres renderelőt hoztál volna egy Y nyelven írt OpenGL-es renderelővel szemben, és abból akartad volna levezetni, hogy az X nyelv milyen lassú, mert lám, a Y-os renderelő mennyivel gyorsabb. Ami nyilván teljesen téves következtetés és logika. Éppen annyira téves, mint egy jQuery Mobile-lal működő - ráadásul nyilvánvalóan az egyszerűségre és az átfogóságra, nem pedig a teljesítményre fókuszáló - demó, meg a gazdarendszer szénné optimalizált natív alapvezérlőire építő tetszőleges másik alkalmazás grafikai sebességének összehasonlításából megpróbálni következtetést levonni az adott programozási nyelvek sebességére vonatkozóan.

    Lényeg a lényeg: tök hülyeség azt állítani, hogy egy akármilyen HTML5-ös felület lassabb, mint egy akármilyen úgymond natív felület. Egyrészt, mert mint mondtam, a legtöbb esetben el sem tudod dönteni, hogy mi a natív és mi nem, és mert sok "natív" program gyors felülete valójában HTML5+CSS3+JS alapon van megírva. Amit észre sem veszel, pont azért, mert ugyanolyan gyors. Másrészt, mert egy funkcionálisan összehasonlítható és a telefon képességeit azonos mértékben kihasználó animációs réteg nyilvánvalóan semmivel sem kell, sőt, szabad, hogy lassabb legyen (illetve megfordítva: semmivel sem lehet gyorsabb), mint a másik, ugyanilyen réteg. Ha mégis jelentős sebességkülönbség van a kettő között, akkor nyilván vagy funkcionálisan nem mérhetők össze, vagy teljesen másként működnek.

    Ezzel összefüggésben evidens, hogy egy a hardveres gyorsítást ugyanolyan mértékben kiaknázó CSS3-as animáció nyilvánvalóan ugyanolyan gyors lesz, mint a natív társa. A mindent izomból megoldó felület pedig dög lassú lesz - de akkor is, ha natív kódból van megírva. Tök függetlenül attól, hogy milyen nyelvet használtál hozzá - mert hogy adott esetben utóbbi nagyjából teljesen irreleváns, és mert a sebességet nem ő, hanem az említett hardveres gyorsítást mértéke fogja elsődlegesen meghatározni.
    Mutasd a teljes hozzászólást!
  • Azt vettem észre, hogy eléggé készülék függő, hogy elfogadható minőségben működnek-e a böngészők. Pl lumia 530,630, asus (android 4.1) tablet, asus t101a készülékeken gyorsan, jól fut a winjs 4.
    Míg a 4 magos huwai csoda telefonomon(hard reset sem segített rajta) egy rakás k@ki a beépített böngésző és a Chrome is.
    Mutasd a teljes hozzászólást!
  • Nekem tetszett az a Material stílus, de ha a megvalositas ilyen _kornyezetszennyezo_, akkor inkabb hagyjuk. Pedig ezt a fajta grafika egy 20 eves gamer pcnek nem okozna gondot. Az arnyekolast leszamitva pedig mar nincs mit egyszerusiteni a design-en.
    Mutasd a teljes hozzászólást!
  • Továbbá kijött a Google Androidos material stílusú böngészős keretrendszere. Futtattam egy szerintem elég erősnek számító LG G2-n (4 mag, Qualcomm Snapdragon 800, 2.2GHz), és az oldalról beúszó menü ezen is akad. Folyamatosan fejlődnek a böngészők, rájuk is fér, hogy az adott platform natív view keretrendszerének sebességét utolérjék. A gyakorlatban az egész keretrendszer be van includeolva a html fájlban, nem csoda, hogy sokáig tart míg beparszolja az egészet, tehát lassan is indul a, de utána is lassú.
    Mutasd a teljes hozzászólást!
  • Nézd, a jquery mobile 1.4 demóját bárki letöltheti a play store-ból és kipróbálhatja. Én megtettem, többször, több gépen is. A mostani tabletem ugyan nem a csúcs kategória (Lenovo, 4 mag, 1.3 Cortex A7, 7 colos kijelző), de annyira gyenge vasnak sem mondanám. És ez az első olyan vas, amivel maga a demó csak annyira laggol hogy azt merem mondani hogy ezt _talán_ már oda merném adni egy user kezébe. De ez legalább 4x annyira erős vas mint az első droidos hardvereim (ZTE Blade és társai) voltak - és a natív droidos appok (C++-ban illetve Javában fejlesztve de a natív widgetekre támaszkodva) már a ZTE-n is 100x simábban működtek mint ez. Szóval írhat bárki bármit, én ezt már kipróbáltam kb. 6 különböző vason és azt kell mondjam, hogy bár a legújabb vasakon már tényleg elmegy a javascriptes UI, de bizony a natívval nem játszik egy csapatban.
    És nem csak a jquery nem, de Pl. a WinJS sem. Ami nem jelenti azt, hogy nem létezhet droidra valóban reszponzív JS alapú API, de amiket én láttam azok bizony jóval lassabbak mint a natív felület. És sem a JQuery Mobile demo, sem a WinJS demó nem töltött semmit a netről - direkt kikapcsoltam a wifit mielőtt teszteltem.
    Mutasd a teljes hozzászólást!
  • Ja. Szerinted. Valójában meg ez már három évvel ezelőtt sem volt igaz. Azóta meg értelemszerűen megsokszorozódott a mobilok számítási kapacitási, memóriája, grafikus teljesítménye, és a böngészőmotorok kódgenerálási hatékonysága is. Tehát bármilyen teljesítményprobléma még kevésbé lehet gond, mint akkor volt. Amivel nem akarom megerősíteni az alaptalan feltételezésed, hogy a HTML5+JS az feltétlenül nagyobb erőforrásigényt jelent - csak mondom, hogy ha még utóbbit igaznak is fogadjuk el egy gondolatmentet erejéig, akkor sincs sok teteje annak amit mondasz.

    A valóság az általad összefantizáltak helyett az, hogy egyes webes alkalmazások azért lassúbbak és kevésbé reszponzívak, mint a helyben futó, (sokszor tévesen) "natív"-nak hívott alkalmazások, mert ők az erőforrásaikat egy utóbbiakhoz képest igen korlátos sávszélességen át (ti. a neten át a helyi tároló/memória helyett) érik el. Nem pedig azért, mert az egyik HTML5-ben és JavaScript-ben, a másik meg úgymond natív kódban van megírva.

    Utóbbi megkülönböztetés azért is teljesen értelmetlen, mert manapság a helyben futó (="natív") mobilos alkalmazások jelentős része is valójában HTML5-ban és JavaScript-ben kerül megírásra. Csak te ebből végfelhasználóként semmit nem tudsz és látsz. Pontosan azért nem, mert nem ez határozza meg a működési sebességüket, képességeiket, stb.
    Mutasd a teljes hozzászólást!
  • (Ő a szerver oldalról beszél, az lehet gyenge vason is. Pont azért, mert a kliens végzi a nagyobb munkát.)
    Mutasd a teljes hozzászólást!
  • Az a vas amin a html5/js segítségével jó interaktív felületet tudsz csinálni minden csak nem gyenge. Egy gyenge vason (Pl. egy 2-3 éves droidos okostelefon) a html/js csak szenved. Lásd Pl. jquery mobile demó. Ott ahol a html5 segítségével használható UI-t tudsz produkálni, ott lényegében bármivel képes vagy erre.
    Mutasd a teljes hozzászólást!
  • Maga a nyelv csak másodlagos kérdés. Nem a nyelvet kell szeretni, hanem azokat a piaci lehetőségeket amit megnyit a programozó előtt.

    Ez teljesen igaz. Én PLC-kkel és beágyazott rendszerekkel foglalkozok, óriási segítség, hogy a JS+CSS+HTML5 kombóval egy gyenge vasról is interaktív kezelőfelületet tudok csinálni anélkül, hogy a usernek bármilyen programot kelljen telepítenie a PC-re. 
    A JS nem a kedvenc nyelvem, de rengeteget használtam (és a munkahelyen javasoltam a használatát) az elmúlt években a C/C++ és a különböző PLC-s nyelvek mellett. Az ügyfelek szeretik és kezdem én is megkedvelni. JQuery-vel meg rendesen szeparálva a HTML-kódtól teljesen korrekt kis rendszer.
    Gányolni persze lehet vele ezerrel, de hát miben nem?
    Mutasd a teljes hozzászólást!
  • Arra képes, hogy adatokat jelenítsen meg, felhasználói inputokat fogadjon dolgozzon ezeken majd a szerver felé passzolgassa az adatokat. Evvel elég nagy részét lefedi az átlag piaci igénynek. Néhány keretrendszer lehetővé teszi, hogy HTML-tagek nélkül tisztán JS kód alapján MVC struktúrában készüljenek az alkalmazások ami sokat javít a nagy mennyiségben írt kód olvashatóságán. Ennél a nyelvnél az elsődleges kérdés, hogy meddig engedheti meg egy átlag programozó azt a luxust, hogy figyelmen kívül hagyja a böngésző és az abban futó JS nyújtotta lehetőségeket. Maga a nyelv csak  másodlagos kérdés. Nem a nyelvet kell szeretni, hanem azokat a piaci lehetőségeket amit megnyit a programozó előtt.
    Mutasd a teljes hozzászólást!
  • Nézd, a style-nak is vannak dedikált mezői. Tehát a
    divElem.style = 'width: 100%, height: 200px;'
    helyett lehet ezt is mondani:
    divElem.style.width = '100%'; divElem.style.height = 200; // vagy '200px', ami ugyanazt jelenti
    Ugyanakkor a '100%' helyett a Css.widthByPercent(100)-nek nyilvánvalóan semmi értelme, mert egyszerűbbé nem teszi az ábrázolást, és mert a JavaScript, illetve a DHTML esetében nem előfordított, statikus kódbázisról beszélünk. Így a metódusokba csomagolt, látszólag statikus meg típusellenőrzött kifejezés esetleges érvénytelensége is éppen úgy, azon a ponton, csak futásidőben derülhet ki, amikor a sztringliterálisé is. Tehát az adott környezetben semmit nem nyernél vele.

    Ha nem így lenne, akkor meg a kvázi sztringliterálisban megadott kifejezés érvényességét is lehetne fordítási időben ellenőrizni.

    Persze, mint mondtam, ennek igazából semmi köze a JavaScript nyelvhez, mert egyszerűen a DOM API (illetve tágabb értelemben a CSS szintaxis) az ami így van felépítve, és amiből a dimenziók meghatározásának módja ered. Tök függetlenül attól, hogy milyen nyelvből éred el.
    Mutasd a teljes hozzászólást!
  • Poénnak szántam természetesen. 
    Lehet, hogy semmi köze a JavaScripthez, de a JS kódok több mint 90%-a böngészőben fut, és más környezetet nem ismerek, ahol hasonló böszmeséggel oldanak meg valamit. :)
    "Amiben mellesleg szerintem szintén semmi gányolás sincs"
    C++, Java, C# felől érkező emberek jobban szeretik az alábbi helyett:
    divElem.style = 'width: 100%, height: 200px;'

    inkább valami ilyesmit:
    divElem.style.add(Css.widthByPercent(100))  // factory 
    divElem.style.add(Css.heightByPixel(200))

    Persze sokkal szebb, ha csak egy CSS osztályt adok hozzá, ha kell, és akkor böszmeséget sem kell elkövetni.
    Amúgy nemrég kezdtem el JS-ezni, és már egyre kevésbé szeretek Java-zni, mert JS-ben gyorsabban haladok.
    Mutasd a teljes hozzászólást!
  • Ennek ugye semmi köze a JavaScript nyelvhez. Ez minden más nyelvben is így nézne ki, és ha valamiből, akkor a DHTML, a CSS és a DOM koncepciójából, működéséből eredő sajátosság. Amiben mellesleg szerintem szintén semmi gányolás sincs - bár ez egy másik vita tárgya lenne.

    Csak azért mondom, mert a jelek szerint még a JavaScript nyelv, meg az abból bizonyos környezetekben elérhető API-k, illetve az azok által képviselt paradigmák között se tudsz különbséget tenni. Aminek tekintetében nyilván a nyelvről alkotott véleményed, értékeítéleted is igen megalapozottnak és hitelesnek hat.
    Mutasd a teljes hozzászólást!
  • régebben nagyon utáltam a JS-t, mert nem tetszenek az ilyen gányolások:
    divElem.style = 'width: 100%;'
    ja, várj, most is utálom :D.
    Mutasd a teljes hozzászólást!
abcd