A Google után a Mozilla is egy új, általa kidolgozott programozási nyelvvel ill. az ahhoz készült fordítóval rukkolt elő. A Rust ugyanakkor - szemben a Google Dart-jával - nem egy kliens-oldali környezetbe tervezett dinamikus, hanem egy erősen típusos, fordított nyelvet képez, amelyet a cég elsősorban böngészőjének fordítására hozott létre.
.. »tovább...
Visszaolvastam. Egyedül a te hozzászólásodban szerepel az, hogy "bytekód az ActiveX".
Én írtam: Én azt bizonygattam, hogy ennek nem a bytekód az oka, hanem üzleti-politikai okai vannak.
Erre te írtad: Aha. Ezért írtad, hogy biztonsági problémás volt az ActiveX. Hiszen mint mindannyian tudjuk, a biztonsági probléma az "üzleti-politikai" ok.
Én bytekódról beszéltem, te ActiveX-ről. Ez utóbbi biztonsági problémájának a bytekód elterjedésének üzleti-politikai akadályaival való összefüggését ezek után sem értem, de te biztosan elmagyarázod majd...
A dolog ugyanis a Flash kapcsán nem úgy nézett ki, hogy az Adobe dobta a Flash-t és erre mindenki elkezdte hanyagolni azt, hanem fordítva: mindenki elkezdte hanyagolni a Flash-t, helyette HTML5-re fejlesztett, és ezek után döntött az Adobe úgy, hogy nem úszik árral szemben, hanem ő is ráfekszik a HTML5 vonalra.
Nem. A dolog úgy nézett ki, hogy a gugli és a mozilla elkezdte nyomni a html5-öt, az Apple kitiltotta a flash-t, és ennek hatására kezdett ez utóbbi kevésbé népszerű lenni. De ez megint csak nem technológia hanem üzletpolitika. Ha az Adobe jól csinálja a flash-t (hangsúlyt fektet a mobil platformra és jobb kapcsolatot ápol az almával) akkor ma is ők a nyerők.
Még akkor sem tudnám elképzelni, ha elfogadnám - amit amúgy nem gondolok -, hogy te tényleg hiszed is azt amit írsz, és nem csak az ellentmondás kényszere miatt írod le ezeket az egyre vadabb zöldségeket.
Majd csak nézd meg, mekkora bukfenc lesz a winRT.
Így ha történetesen még tényleg alacsonyabb is lenne a futási sebessége, mint a bájtkód alapú Java-é (mint ahogy a benchmarkok szerint nem az)
Ha utánaolvasol a dolognak akkor viszont azt látod hogy de. Mi az hogy, nagyon is. Az ipse csak hosszas fáradozás után tudott olyan java kódot összerakni, ami kb. hasonló funkcionalitás mellett lassabbnak bizonyult mint a JS.
Mivel a Java a fentiek miatt 5 másodpercen belül semmit sem tud prezentálni (még egy egyszerű UI-t se), ezért nyilvánvalóan teljesen alkalmatlan a mai webes igények kielégítésére. Ez pedig pontosan az amiről beszéltem. És ami ugyanígy igaz lenne minden vele összehasonlítható bájtkód-alapú technológiára.
Nem. Ez akkor igaz, ha kismillió más libet töltenél be induláskor. De ennek semmi köze a JVM-hez, ennek az osztályokhoz van köze. Ha csinálnál egy pici libet ami csak annyi funkcionalitást ad mint amit ma Pl. egy JQuery biztosít akkor a JVM indulását észre sem vennéd.
Arról már ne is beszéljünk, hogy a .NET, amelyet architektúrálisan a Java-hoz szokás hasonlítani (beleértve a bájtkód-alapú köztes formátumot, a standard runtime-ot, stb), pontosan ugyanettől a problémától szenved. Ti. az is bűn lassúan indul még modern gépeken.
Ez is csak attól függ, hogy mit töltesz be és mit nem. A konzolos helló világ igen gyorsan elindul mono alatt. A monodevelop már nem annyira. Másfelől, ha a monodevelopot átírnád javascriptre, az még lassabban indulna. Ezek a scriptelések addig gyorsak, amíg lényegében nem csinálsz semmit. A gond az, hogy minél inkább utánozni akarod a vastag klienst, annál több dolgot kell megtenned - és ekkor egyre kevésbé lesz előnyös a csak azt töltjük be amit kell. Másrészt, ha a bytekód alapú rendszerben is csak azt töltöd be amit kell, akkor nem lesznek sebességgondjaid. Ne feledd el, hogy a bytekódnak azért vannak előzményei: így mentek a Clipperes progik a 4 Mhz-es PC-ken, így fordított a HP4T pascal ZX-Spectrumon, így működött a FoxBase, és a régebbi Visual Basic-ek (mielőtt natív fordítót kaptak). Egyikkel sem volt olyan gond, hogy várni kellett volna a betöltésre. Na ja - nekik sem voltak sokkal nagyobb a betöltött könyvtáraik mint max. pár száz kilobyte - azaz kb. a mai javascriptes kliens könyvtárak mérete.
Egyrészt ez így, ebben a formában nem igaz ill. féligazság. Mert hogy automatikus határellenőrzések, leszármazás-ellenőrzés, és számtalan egyéb, futásidejű ellenőrzés még szigorúan típusos, fordított nyelvek esetében is van, akkor is, ha azok végig statikus típusokkal dolgoznak.
Ez így ebben a formájában nem teljesen igaz. Nézd meg, mit csinál Pl. egy C# JIT egy for (i=0;i<100;i++) Console.Write("A"); végrehajtása során. _Nem_ csinál i-vel semmi ilyesmit.
Azaz, hiába is tudna az alkalmazási kódod statikus típusokkal dolgozni, mert mivel a DOM dinamikus, az adatok szöveges formában (HTML, XML, JSON, stb.) utaznak ide-oda a szerver és a kliens között, és mert minden webes erőforrás maga is dinamikus entitást képez (aminek típusa, mérete csak futásidőben dől el és állapítható meg), ezért végső soron ezt a statikus típuskezelést csak a kód igen kis részében tudná kihasználni, és végső soron a két végen ugyanúgy dinamikus inputtal és outputtal kellene dolgoznia.
Statikus nyelvekkel ezeket a dolgokat elég szépen lehet kezelni. Na jó, az xml-t annyira nem szépen, de amennyire nem szépen pont annyira nem szép ugyanez dinamikusan sem - maga az egész architektúra pont emiatt a sok dinamikus szerkezet miatt alapvetően elég instabil.
Írta a fene. Olvass már vissza légyszíves.
Visszaolvastam. Egyedül a te hozzászólásodban szerepel az, hogy "bytekód az ActiveX". De ha tudsz tőlem is idézni olyant ahol azt állítottam, hogy az ActiveX bájtkód-alapú, akkor csak hajrá!
>>Te se nagyon fejlesztenél egy olyan platformra aminek a fejlesztője bedobta a törülközőt.<<
"Ennek megint mi köze a bájtkódhoz, natív kódhoz, JavaScript-hez?"
Csupáncsak annyi, hogy valami Sting nevű illető érvként hozta fel a JS mellett hogy mindenki erre fejleszt a flash helyett.
"Apró" tárgyi tévedés részedről, hogy az Adobe - a Flash fejlesztője - "nem dobta be a törülközőt".
Ráadásul itt megint - nyilván szándékosan, mert ennyire dilettáns nem lehetsz - kevered az okot és az okozatot. A dolog ugyanis a Flash kapcsán nem úgy nézett ki, hogy az Adobe dobta a Flash-t és erre mindenki elkezdte hanyagolni azt, hanem fordítva: mindenki elkezdte hanyagolni a Flash-t, helyette HTML5-re fejlesztett, és ezek után döntött az Adobe úgy, hogy nem úszik árral szemben, hanem ő is ráfekszik a HTML5 vonalra.
"Internet Explorer 9: 31 darab (ezek 67%-a volt "extremely critical" vagy "highly critical")"
És mi a helyzet a Firefox-szal ?
Miért? Mi a helyzet vele?
"Na ja. Ezért hasít és hódít a HTML5 is, annyira, hogy még a MS is kénytelen volt beállni mögé."
Ez leginkább azt mutatja hogy a MS-nél sem tudja a jobb kéz hogy mit csinál a bal. Ez kb. annyira volt jó döntés a részükről, mint a Borlandtól amikor lelőtték a C++ Buildert.
Ha te mondod. Akkor biztos így is van. Ennyi szakmai tapasztalattal és pontos tényismerettel amit itt hozzászólásról hozzászólásra megvillantasz, el nem tudom képzelni, hogy neked valamiben ne legyen igazad. Még akkor sem tudnám elképzelni, ha elfogadnám - amit amúgy nem gondolok -, hogy te tényleg hiszed is azt amit írsz, és nem csak az ellentmondás kényszere miatt írod le ezeket az egyre vadabb zöldségeket.
Csak én látom, hogy most meg a futási sebességet kevered az inicializálás sebességével ?
Csak te látod - mert nem tudod ill. akarod megmondani, hogy miről beszéltem. Ez pedig az volt, hogy míg egy Java-ra épülő weboldallal webalkalmazással - még a letöltése után is - minimum 5-10 másodpercig nem tudsz semmit se csinálni és az nem tud eredményt szolgáltatni részedre, addig egy JavaScript-alapú weblap vagy webalkalmazás azonnal indul.
Így ha történetesen még tényleg alacsonyabb is lenne a futási sebessége, mint a bájtkód alapú Java-é (mint ahogy a benchmarkok szerint nem az), akkor is 5-10 másodperce van annak kompenzálására - azaz, ha 5-10 másodperccel tovább is tart neki a tényleges futás amíg eredményt tud szolgáltat, akkor is effektív a letöltéstől, a weblap megnyitásától számítva ugyanannyi időn belül tudja azt prezentálni a felhasználó részére, mint a Java.
Ugyanakkor a gyakorlatban és a weben nincs olyan alkalmazás ami akár csak 5-10 másodpercig is számítgatna valamit - hanem legtöbb kód a másodperc tört részéig fut csak.
Arról közismert webes tényről már nem is beszélek, hogy kb. 3-5 másodperced van arra, hogy megfogd az oldaladra beeső felhasználót. Ha ez ennyi időn belül nem sikerül, akkor az illető nagy eséllyel elnavigál az oldaladról, és máshol kezdi el keresni azt amiért hozzád érkezett. Mivel a Java a fentiek miatt 5 másodpercen belül semmit sem tud prezentálni (még egy egyszerű UI-t se), ezért nyilvánvalóan teljesen alkalmatlan a mai webes igények kielégítésére. Ez pedig pontosan az amiről beszéltem. És ami ugyanígy igaz lenne minden vele összehasonlítható bájtkód-alapú technológiára.
A java azért indul lassan, mert kismillió - a webezéssel nem feltétlenül összefüggésben lévő - könyvtárat beizzít.
Senkit nem érdekel, hogy miért lassú. Lassú és kész. A focit is gólra játsszák.
De ez nem igazából a bytekód problémája, hanem a jvm böngészős implementációjáé.
Ha ez így lenne akkor nyilvánvalóan már régen megoldották volna, hogy gyorsabban induljon. Kérdésem tehát, hogy ha ez tényleg könnyen leküzdhető lenne, akkor miért nem oldották meg - miközben igény nyilván lenne rá, és idő is bőven volt az a másfél évtized alatt, amióta ez a technológia létezik? Szerinted?
Arról már ne is beszéljünk, hogy a .NET, amelyet architektúrálisan a Java-hoz szokás hasonlítani (beleértve a bájtkód-alapú köztes formátumot, a standard runtime-ot, stb), pontosan ugyanettől a problémától szenved. Ti. az is bűn lassúan indul még modern gépeken. Nyilván ez is csak véletlen egybeesés, és még véletlenül sem az említett architektúrális sajátosságokból adódó, szinte elkerülhetetlen szükségszerűség, hátrány.
Egy dinamikus típuskezeléses nyelvnek mindig meglesz az a hátulütője, hogy minden változón végrehajtott művelet esetén meg kell bizonyosodnia a változó típusáról, és ennek függvényében dönthet arról hogy az adott műveletet hogyan kell végrehajtani. Ennek pedig elég komoly erőforrásigénye van, amit nemigen tudsz megúszni.
Egyrészt ez így, ebben a formában nem igaz ill. féligazság. Mert hogy automatikus határellenőrzések, leszármazás-ellenőrzés, és számtalan egyéb, futásidejű ellenőrzés még szigorúan típusos, fordított nyelvek esetében is van, akkor is, ha azok végig statikus típusokkal dolgoznak. Ehhez képest az, hogy a változó típusáról (is) meg kell győzödni (ami kb. egyetlen bájt vizsgálatát jelenti) mielőtt feldolgozást végeznénk rajta, nem annyira egyértelműen biztosan lassít olyan sokat a program futásán.
Másrészt itt van ez a dolog, amit sajnos nem értesz meg (pedig már már vagy ötször elmagyaráztam ebben a topikban is): az, hogy a dinamizmus és dinamikus feldolgozás a weben elkerülhetetlen és a web architektúrájából, szerkezetéből, működési módjából adódik. Azaz, hiába is tudna az alkalmazási kódod statikus típusokkal dolgozni, mert mivel a DOM dinamikus, az adatok szöveges formában (HTML, XML, JSON, stb.) utaznak ide-oda a szerver és a kliens között, és mert minden webes erőforrás maga is dinamikus entitást képez (aminek típusa, mérete csak futásidőben dől el és állapítható meg), ezért végső soron ezt a statikus típuskezelést csak a kód igen kis részében tudná kihasználni, és végső soron a két végen ugyanúgy dinamikus inputtal és outputtal kellene dolgoznia. Ami egyrészt önmagában meghatározná a feldolgozás sebességét (nagyjából jelentéktelenné tenne minden a belső rutinokban megspórolt időt, amik egyébként se meghatározóak dinamikus típuskezelés esetén sem), másrészt azt jelenti, hogy hajadra kenheted a statikus típusosságot a program egyes részeiben, mert mivel a program egészében ez nem garantálható, megvalósítható, és mivel minden lánc csak annyira erős, mint a leggyengébb láncszeme, ezért az egész program továbbra se lenne kicsit se szigorúan és statikusan típusos, nem lenne futásidőben úgymond biztonságosabb (bolondbiztosabb), mint a teljesen dinamikus kód, és ugyanúgy, mint utóbbi, csillió helyen halhatna el futásidejű hibával az olyan evidenseken túl is, mint pl. a zéróval osztás.
Ezért nincs értelme a webre nem csak kliens, de szerver oldalon se statikus nyelvekkel, technológiákkal dolgozni. Mert ti. csak az ezekből adódó korlátok maradnának meg belőlük, de a feldolgozás nagy részének és az I/O-nak teljesen dinamikusnak kellene lennie ezekben is.
Nem. Volt időszak amikor némelyik videó nem flash-sel jelent meg - legalábbis nálam.
Maximum ha bejelentkeztél a bétába. A YouTube-on soha a büdös életben nem volt (még) alapértelmezett a HTML5-ös videólejátszó a Flash helyett.
Ezek szerint mégsem minden olyan szép a szép új html5 világban ?
Ezek szerint megint elbuktad egy állításod, és terlésként megint valami más témára akarsz átlovagolni?
Ezért mondtam, hogy minden eszközre saját felület kell.
Igen. Én meg erre mondtam, hogy ez
1. kivitelezhetetlen, mert fizikai korlátoknál (idő, pénz, energia) fogva nem készíthetsz felületet minden egyes internet-képes eszközre
2. ha még az 1. pont nem is lenne igaz, akkor is legkésőbb a program kiadásának pillanatában bukta lenne ez a koncepció, hiszen az 1 perccel azután megjelenő eszközökre már megint nem lenne felület a programodban.
Sőt, légy erős, de még nem is feltétlenül ugyanazt a funkcionalitást kell megvalósítani egy desktopon mint a mobil eszközödön.
Ez érdekes, hiszen az előbb még azt bizonygattad, hogy mobil és desktop eszközökre nem is kell más felület, hiszen előbbiről utóbbira egyszerűen csak fel kell skálázni a dolgokat. Ezek szerint éppen megint tökéletesen cáfoltad magad, két hozzászóláson belül.
Kettőnk közül egyedül te írtad le azt, hogy "bytekód az ActiveX".
Írta a fene. Olvass már vissza légyszíves.
Pl. csak a Facebook-nak havonta jelenleg 425 millió mobilos felhasználója van.
A fészbúknak nincs véletlenül natív kliense mobilra ? Én nem tudom - nem igazán fészbúkozok se weben se mobilon.
Ennek megint mi köze a bájtkódhoz, natív kódhoz, JavaScript-hez?
Csupáncsak annyi, hogy valami Sting nevű illető érvként hozta fel a JS mellett hogy mindenki erre fejleszt a flash helyett.
Internet Explorer 9: 31 darab (ezek 67%-a volt "extremely critical" vagy "highly critical")
És mi a helyzet a Firefox-szal ?
Na ja. Ezért hasít és hódít a HTML5 is, annyira, hogy még a MS is kénytelen volt beállni mögé.
Ez leginkább azt mutatja hogy a MS-nél sem tudja a jobb kéz hogy mit csinál a bal. Ez kb. annyira volt jó döntés a részükről, mint a Borlandtól amikor lelőtték a C++ Buildert.
Téged igazol az is, hogy míg egy weboldalon a JavaScript kód a másodperc törtrésze alatt elkezd tudni futni és akár ennyi idő alatt be is fejezi azt amit csinálnia kell neki, addig egy mai gépen pl. a szigorúan típusos Java VM elindulása még mindig 5-10 másodpercbe tellik - azaz legalább ennyi ideig tart akár egy Hello world kiíratása is.
Csak én látom, hogy most meg a futási sebességet kevered az inicializálás sebességével ? A java azért indul lassan, mert kismillió - a webezéssel nem feltétlenül összefüggésben lévő - könyvtárat beizzít. De ez nem igazából a bytekód problémája, hanem a jvm böngészős implementációjáé.
Biztosan. Hiszen LC megmondta. Akkor pedig úgy van
Bizony. Amúgy ezt már szerintem valami Sting nevű fazon is elismerte pár tucat hozzászólással ezelőtt - és kivételesen igaza is volt neki. Egy dinamikus típuskezeléses nyelvnek mindig meglesz az a hátulütője, hogy minden változón végrehajtott művelet esetén meg kell bizonyosodnia a változó típusáról, és ennek függvényében dönthet arról hogy az adott műveletet hogyan kell végrehajtani. Ennek pedig elég komoly erőforrásigénye van, amit nemigen tudsz megúszni.
Igen, erről már lassan harmadik éve szó van.
Nem. Volt időszak amikor némelyik videó nem flash-sel jelent meg - legalábbis nálam. Ezek szerint mégsem minden olyan szép a szép új html5 világban ?
Hol? A dilettáns C#-fejlesztők körében? Egyetértek
C#-ban még nem láttam ilyet. De a linuxos C/C++-os API-k környékén elég gyakori volt az ilyesmi, legalábbis amikor még aktívan linuxoztam. Ha valami nem volt csomagban Pl. Mandrake alatt, akkor nekiállhattál forrásból feltenni. Aztán azt vetted észre, hogy neked nem a libakármi.N.so van meg, hanem a libakármi.N-1.so vagy N+1.so, és sok-sok függvény panaszkodik hogy nem 3 paramétere van neki hanem 4, és a második különben sem int hanem char *.
Hát persze. Az nem gond ha egy 21 colos, egérrel felszerelt desktop gépen is ugyanúgy a képernyő egy negyedét foglalja el egy gomb, görgetősáv vagy bármilyen más interaktív elem, mint egy 3.5 colos érintőkijelzőn (ahol azért kell ekkorának lennie, hogy ujjal is egyértelműen és biztonságosan ki lehessen választani).
Ezért mondtam, hogy minden eszközre saját felület kell. Ugyanerre az érintőkijelzőre eleve más felületet kell tervezni, pont az ujjal húzogatás (és még számos más szempont miatt). Sőt, légy erős, de még nem is feltétlenül ugyanazt a funkcionalitást kell megvalósítani egy desktopon mint a mobil eszközödön.
Mióta bytekód az ActiveX ?
Kettőnk közül egyedül te írtad le azt, hogy "bytekód az ActiveX".
Mivel a Linux a böngészőpiac 1%-át teszi ki, ezért ez nyilván teljesen irreleváns volt a Flash sikere szempontjából.
Na most, akkor fontos az eszközfüggetlenség vagy nem fontos ?
Ezt most miért kérdezed?
Mert azért azt sem hiszem, hogy a net használói közt sokkal több androidos vagy IOS-es van mint linuxos.
Mint már többször kifejtettem: a te hited és tudásod, meg a valóság két különböző dolog - mondhatni diszunkt halmazok. Pl. csak a Facebook-nak havonta jelenleg 425 millió mobilos felhasználója van. Ez nem, hogy a webezők, de az emberiség legalább 6-7 százaléka. Ehhez képest a Linux-ot használók száma még pusztán a webezők között is csak 1%-ra tehető - az egész emberiségre vetítve pedig még ennek is töredéke. Tehát mobilról minimum 6-7-szer (de reálisan inkább úgy 30x) többen webeznek, mint Linuxról.
Te se nagyon fejlesztenél egy olyan platformra aminek a fejlesztője bedobta a törülközőt.
Ennek megint mi köze a bájtkódhoz, natív kódhoz, JavaScript-hez?
Lúfütty. Nem mondom hogy a flash-ban nem találnak időnként egy-két lyukat, de a mezei böngészőkben azért gyakrabban hallani ilyesmiről.
Secunia szerint sebezhetőség 2011-ben:
Adobe Flash Player 10.x: 45 darab (ezek 88%-a "extremely critical" vagy "highly critical" volt)
Internet Explorer 9: 31 darab (ezek 67%-a volt "extremely critical" vagy "highly critical")
Arról, hogy az a sebezhetőség ami az egyik böngészőben megy, a másikban jellemzően nem, miközben a Flash sebezhetőség értelemszerűen gyakorlatilag az összes az adott verziót futtató telepítést érinti - tehát sokkal könnyebb vele nagyobb számban megtámadni a webezőket a homogénebb célkörnyezet miatt - már nem is beszélek.
És bármilyen nem bytekód alapú rendszer esetén is. Azaz amíg a MS nem múlik ki a böngészőpiacról, addig bizony elég nehezen fog előre menni bármi is.
Na ja. Ezért hasít és hódít a HTML5 is, annyira, hogy még a MS is kénytelen volt beállni mögé.
A MS nem fogja támogatni a gugli újírásait, a gugli meg a MS-ét.
Csak az idézőjeleket hiányolom a megállapításaim körülről.
Más kérdés, hogy ha tényleg a sebesség vagy a biztonság a gond, akkor a javascriptet is tiltania kellene. A js-ben is volt már lyuk
Aha. Tehát nem a hibák aránya és súlyossága számít, hanem az, hogy volt -e egyáltalán, valaha, akár egyetlen is. Logikus, szakmailag megalapozott érvelés.
és sebességben biztosan mindig is lassabb lesz mint egy natív szigorúan típusos nyelv - de még egy bytekódos szigorúan típusosnál is.
Biztosan. Hiszen LC megmondta. Akkor pedig úgy van.
Téged igazol az is, hogy míg egy weboldalon a JavaScript kód a másodperc törtrésze alatt elkezd tudni futni és akár ennyi idő alatt be is fejezi azt amit csinálnia kell neki, addig egy mai gépen pl. a szigorúan típusos Java VM elindulása még mindig 5-10 másodpercbe tellik - azaz legalább ennyi ideig tart akár egy Hello world kiíratása is.
A maps ha jól tudom javascript alapú.
Bizonyos részei már azok. Ugyanakkor pl. a Street View nézetre választ benne, vagy akár csak fotókat hívsz fel, azokat Flash applettel jeleníti meg.
A youtube valóban flash - de arról volt szó, hogy a gugli ezt is le fogja cserélni html5-re.
Igen, erről már lassan harmadik éve szó van. Ehhez képest még mindig Flash az alapértelmezett lejátszó. Ebből is látszik, hogy mennyire igazad van abban, hogy a Google ahol csak tudja direkte gonoszságból, politikai okokból nyírja ki a Flash-t, ott ahol akarja, akár a felhasználói élmény rovására is. És még véletlenül sem az van, amit én mondtam, hogy nem a Google és mondvacsinált politikai indokok, hanem a felhasználók diktálnak, és az, hogy pillanatnyilag mivel lehet a legjobb élményt nyújtani számukra.
Ezek szerint visszatértek flash-re ?
Igen. Nem soha nem is tértek át HTML5-re, hanem visszatértek Flash-re. Logikus. Megint.
És persze ott a gmail, a google docs, és a többi cucc is.
Amik sosem voltak Flash alapúak, tehát teljesen irrelevánsak ebben a kérdésben. Nem mellesleg bőven van azért még Flash más Google szolgáltatásokban is. Pl. Book Search.
Sőt, pl. a Chrome-ban eredetileg nem is volt Flash. Viszont a gonosz Google politikai okokból, és hogy merényletet kövessen el ellene, valamint demonstrálandó, hogy mennyire ők diktál (és nem a felhasználók), kicsit több mint egy évvel ezelőtt (és két évvel a Chrome első verziójának kiadása után) belerakta. Közvetlenül azután, hogy az Adobe megcsinálta neki, hogy sandboxban legyen.
Ebből is látszik, hogy tök igazad van, hogy 1. a Google mindent elkövet a Flash kinyírására ok nélkül is, 2. hogy ő diktál, és nem a felhasználói igények diktálnak neki, 3. hogy még véletlenül sem technológiai (pl. biztonsági) megfontolások állnak részéről is a Flash nélkülözése mellett ahol lehet és indokolt, hanem mondvacsinált, politikai okok.
Azt hiszem megint mélyen meg kell hogy hajoljak érveid, logikus és rendszerezett látásmódod, valamint átfogó tényismereteid széles köre előtt.
"Épeszű API gyártó olyant se csinál amit te állítottál (ti. hogy felülről inkompatibilis módon módosítja a már bevezetett API-jai metódusainak paraméterezését). "
Azért én már láttam karón pingvint.
Madarat tolláról, embert barátjáról.
Arrafelé azért előfordul az ilyesmi.
Hol? A dilettáns C#-fejlesztők körében? Egyetértek.
A nagyobb felbontás nem gond - jelenleg is elég sokféle TFT monitor van, és a desktop progik és a weboldalaknak semmi gondjuk nincs vele.
Hát persze. Az nem gond ha egy 21 colos, egérrel felszerelt desktop gépen is ugyanúgy a képernyő egy negyedét foglalja el egy gomb, görgetősáv vagy bármilyen más interaktív elem, mint egy 3.5 colos érintőkijelzőn (ahol azért kell ekkorának lennie, hogy ujjal is egyértelműen és biztonságosan ki lehessen választani). Sőt, az se gond ha 1920x1080-as felbontásban jelenítünk meg egy 320x400-as mobilkijelzőre tervezett képet vagy képrészletet, ami így egyáltalán nem lesz elmosódott, és egyáltalán nem lesz pazarlás, hogy nem jelenítjük meg az egészet, pedig megtehetnénk. Ezek mind kifejezetten elősegítik a kényelmes és kellemes használatot, amiről beszéltél.
Én azt bizonygattam, hogy ennek nem a bytekód az oka, hanem üzleti-politikai okai vannak.
Aha. Ezért írtad, hogy biztonsági problémás volt az ActiveX. Hiszen mint mindannyian tudjuk, a biztonsági probléma az "üzleti-politikai" ok.
Ejnye-bejnye Sting! Mióta bytekód az ActiveX ? Csak nem keverjük a dolgokat, ahogy én szoktam ?
Mivel a Linux a böngészőpiac 1%-át teszi ki, ezért ez nyilván teljesen irreleváns volt a Flash sikere szempontjából.
Na most, akkor fontos az eszközfüggetlenség vagy nem fontos ?
Mert azért azt sem hiszem, hogy a net használói közt sokkal több androidos vagy IOS-es van mint linuxos. Bár a tabletek talán változtattak valamit ezen az arányon.
HTML5 meg minimum 10x annyi gépen nincs mint ahányon Flash nincs. Ennek ellenére mindenki utóbbira fejleszt, a Flash-t meg hanyagolja ahol csak lehet.
Te se nagyon fejlesztenél egy olyan platformra aminek a fejlesztője bedobta a törülközőt.
Itt megint el vagy keveredve. Ez nem oka, hanem következménye volt a Flash hátulütőinek. Hogy ti. lassú volt, nem volt biztonságos, zárt volt, lassan fejlődött, stb.
Lúfütty. Nem mondom hogy a flash-ban nem találnak időnként egy-két lyukat, de a mezei böngészőkben azért gyakrabban hallani ilyesmiről. Arról nem is szólva, hogy az OSX minden hackerverseny kedvenc célpontja. Pont a biztonság miatt rúgnák ki szegény flasht, és pont az alma...
Persze lehettek és nyilván részben voltak is üzleti okai ennek a döntésnek - de ezzel meg az a baj, hogy ezek az üzleti megfontolások bármilyen más natív vagy bájtkód-alapú technológia esetén is ott lesznek.
És bármilyen nem bytekód alapú rendszer esetén is. Azaz amíg a MS nem múlik ki a böngészőpiacról, addig bizony elég nehezen fog előre menni bármi is. A MS nem fogja támogatni a gugli újírásait, a gugli meg a MS-ét. Róka fogta csuka. Szerencsére a win8-cal szerintem lőnek akkorát a saját tökükbe ami elég lesz ahhoz, hogy a MS-nél eltakarítsák az egész OS-IE részleget, de legalábbis a vezetést.
Tehát ez megint nem érv amellett, hogy egy bájtkód alapú vagy natív technológiával jobban járnánk mint a JavaScripttel, hiszen azon megfontolások mentén ami alapján a Flash-t kiltotta, bármilyen más bájtkód alapú vagy natív bővítőtechnológiát is tiltana az Apple.
Tilt is. Nem a flash az egyetlen ami belefutott ebbe. Más kérdés, hogy ha tényleg a sebesség vagy a biztonság a gond, akkor a javascriptet is tiltania kellene. A js-ben is volt már lyuk, és sebességben biztosan mindig is lassabb lesz mint egy natív szigorúan típusos nyelv - de még egy bytekódos szigorúan típusosnál is.
Jaja. Ezt bizonyítja pl. - ha már a közösségi oldalakat említetted - az iWiW példája is amihez nem is kellett Java csak egyszerűen lassú volt, és nem fejlődött semmit. Ezért aztán a felhasználók elkezdtek róla átvándorolni a Facebookra. De magyar térképszolgáltatások is voltak szép számmal már 2000 óta, mégis áttértünk mind a Google Maps-re. Nem azért, mert akkoriban jobb vagy frissebb volt, hanem mert sokkal gyorsabban működött és mert nem kellett egyedi és lassú ActiveX komponenst telepíteni, mint a magyar cuccokhoz.
Ez inkább arról szól, hogy a weben a multik szép lassan felzabálják a kisebb cégek piacát. Az iwiw nyilván nem tudott sem szerverben, sem szoftverfejlesztésben (Pl. játékok) sem másban egy csapatban játszani a fészbúkkal. Térképszolgáltatóban meg volt nem activex-es is, az is kimúlt a gugli mapsszel szemben. Itt is az erősebb kutya élt nemi életet - egy kis cég sem szerverben sem szolgáltatásban (Pl. nagyfelbontású műhold képek, earth, világtérkép, stb) nem tudja felvenni a versenyt a guglival.
Nézd, arról nem én tehetek, hogy abszolút tájékozatlan vagy, és még olyan alapvető dolgokkal sem vagy tisztában, hogy a Google Maps, a Google Earth vagy a YouTube is máig is Flash-alapokon működik
A maps ha jól tudom javascript alapú. A youtube valóban flash - de arról volt szó, hogy a gugli ezt is le fogja cserélni html5-re. Sőt, ha jól emlékszem volt olyan bétája is ami már html5-öt használt. Ezek szerint visszatértek flash-re ? És persze ott a gmail, a google docs, és a többi cucc is.
Épeszű API gyártó olyant se csinál amit te állítottál (ti. hogy felülről inkompatibilis módon módosítja a már bevezetett API-jai metódusainak paraméterezését).
Azért én már láttam karón pingvint. Arrafelé azért előfordul az ilyesmi.
hanem arról, hogy más méretű, képarányú, beviteli módokkal rendelkező, eltérő sebességű, stb. eszközök jelenhetnek meg a jövőben, amikre (lévén nem ismered pontos paramétereiket) nem optimalizálhatod a GUI-dat.
A nagyobb felbontás nem gond - jelenleg is elég sokféle TFT monitor van, és a desktop progik és a weboldalaknak semmi gondjuk nincs vele. A gond akkor van, ha gyufásdoboznyi méretű eszközön kell valamit megjeleníteni.
biztos baj van az angolommal is, de az általad beidézett részek szerintem nem válaszolják meg a kérdéseimet, meg szerintem nem támasztják alá az általam kifogásolt kijelentéseid valódiságát,
például az általad idézett e) pont az én fordításom/értelmezésem szerint arról szól, hogy: "elfogadod azt, hogy a te terméked olyan SWF vagy FLV fájl(oka)t állít elő, amelyeket az Adobe saját belátása szerinti gyakorisággal frissített ... oldalon megjelenő Adobe Flash Player legutolsó verziója hiba nélkül lejátszik", stb.,
de bizonyára mint mindig, most is neked van igazad, legyen úgy,
köszönöm a válaszod, megkésve bár, de törve nem...
szbzs:biztos én vagyok a funkcionális analfabéta, vagy csak nem értem Sting mondanivalóját, de az általa felhozott oldalon is gyorsabb a Flash a legtöbb böngészőn
Sting:Nem az adott oldalon szereplő számokat kellene nézegetni (mert - bár biztos nem tűnt fel -, de lassan két éves az adott blogposzt, amióta bekerült egy s más a böngészőkbe), hanem rákattintani tudni az ott szereplő első négy linkre és futtatni a HTML DIV, HTML Canvas, SVG és Flash alapú benchmarkokat,
szerinted csak a számokat néztem? nyilván kipróbáltam (több böngészőben megnéztem, kivéve persze IE9-ben, az XP miatt) és veled ellentétben nálam a html5 lemaradt, ugyanúgy ahogyan vivo-nál sem volt egyértelmű a helyzet,
értem én, hogy te a saját tapasztalataidból indulsz ki, de azt , hogy a te mérési eredményeid erősen korrelálnálak az internet felhasználók átlagos eredményeivel csak a te szavadat figyelembe véve nem tudom elfogadni;
de legyen igazad, ha ettől jobban alszol, legyen a html5(js) sokkal gyorsabb, mint egy flash alkalmazás (már amennyiben összehasonlítható a kettő),
Én azt bizonygattam, hogy ennek nem a bytekód az oka, hanem üzleti-politikai okai vannak.
Aha. Ezért írtad, hogy biztonsági problémás volt az ActiveX. Hiszen mint mindannyian tudjuk, a biztonsági probléma az "üzleti-politikai" ok.
A bájtkód alapú Java esetén meg egyszerűen nem volt igaz, hogy üzleti-politikai lett volna a bukás oka, hiszen minden böngészőben ott volt.
Az hogy az Adobe nem csinált normális flash-t linuxra
Mivel a Linux a böngészőpiac 1%-át teszi ki, ezért ez nyilván teljesen irreleváns volt a Flash sikere szempontjából. Windows-on biztosan több gépen nincs Flash ma sem, mint ahány linuxoson nincs. HTML5 meg minimum 10x annyi gépen nincs mint ahányon Flash nincs. Ennek ellenére mindenki utóbbira fejleszt, a Flash-t meg hanyagolja ahol csak lehet.
vagy hogy Jobs anno kitiltotta a flasht az IOS-ről hogy több fingós programot lehessen az IPhone-ra eladni ugyanúgy nem technológiai kérdés
Itt megint el vagy keveredve. Ez nem oka, hanem következménye volt a Flash hátulütőinek. Hogy ti. lassú volt, nem volt biztonságos, zárt volt, lassan fejlődött, stb. Nem amiatt bukott a Flash, mert Jobs kitiltotta, hanem azért tiltotta ki Jobs, mert zsákutcává vált: előnye már nem lett volna a támogatásának, viszont jó sok hátránnyal járt volna.
Persze lehettek és nyilván részben voltak is üzleti okai ennek a döntésnek - de ezzel meg az a baj, hogy ezek az üzleti megfontolások bármilyen más natív vagy bájtkód-alapú technológia esetén is ott lesznek. Tehát ez megint nem érv amellett, hogy egy bájtkód alapú vagy natív technológiával jobban járnánk mint a JavaScripttel, hiszen azon megfontolások mentén ami alapján a Flash-t kiltotta, bármilyen más bájtkód alapú vagy natív bővítőtechnológiát is tiltana az Apple. Sőt, pusztán üzleti megfontolások alapján a Dartot sem érdeke támogatni, mert hogy az a Google fia-borja.
Szóval megint nem sikerült helytálló érvet felhoznod.
"Ilyenekről nem az Apple meg a Google dönt (ill. ők maximum a felvásárlással nyírhatták volna ki), hanem a felhasználók és a fejlesztők."
Lúfütty. A megrendelők döntenek.
Megrendelők=felhasználók+más fejlesztők.
Mondom, hogy nem is gondolkozol, csak mindenáron ellen akarsz mondani.
A felhasználó arra az oldalra megy ahol az a tartalom van ami neki kell. Ha a fészbúkot holnaptól átírnák java appletre, akkor sok-sok millió java applet felhasználó keletkezne máról holnapra.
Jaja. Ezt bizonyítja pl. - ha már a közösségi oldalakat említetted - az iWiW példája is amihez nem is kellett Java csak egyszerűen lassú volt, és nem fejlődött semmit. Ezért aztán a felhasználók elkezdtek róla átvándorolni a Facebookra. De magyar térképszolgáltatások is voltak szép számmal már 2000 óta, mégis áttértünk mind a Google Maps-re. Nem azért, mert akkoriban jobb vagy frissebb volt, hanem mert sokkal gyorsabban működött és mert nem kellett egyedi és lassú ActiveX komponenst telepíteni, mint a magyar cuccokhoz.
A felhasznált technológiák alapvetően meghatározzák a felhasználói élményt. Ami ha szr, akkor a felhasználók a konkurens, jobb felhasználói élmény biztosítására képes technológiákra épülő szolgáltatásokra térnek át. Ezért hal ki a Flash, a Java és a Silverlight. Nem azért, mert gonosz, koordinált összeesküvés született ezekkel szemben.
Szóval itt sem sikerült helyesen meglátni a dolgokat.
"Az persze kérdés, hogy mit és hogyan vesz figyelembe a kifejtett tartalomból - de ez ugyanígy elmondható a tisztán HTML-es oldalak esetében, ahol ugye szintén nem lehet pontosan tudni, hogy mi szerint rangsorol a Google, pontosan miket vesz pozitívumnak és negatívumnak."
Bizony. És a megrendelőnek elég az is, ha azt _hiszi_ hogy a flash vagy a SL hátra van sorolva.
Erre hivatkozni semmi értelme, mert ha meg azt hiszi amit te, hogy a HTML5 és a JavaScript az ördögtől való, akkor meg nem abban fogja megírtani. Magyarul ezzel nem mondtál semmit. Csak azt, hogy "ha...akkor". Nem azt, hogy mi a tényleges helyzet.
"Ők legfeljebb az általuk kontrollált platformokon kényszeríthettek volna rá bármit is a felhasználókra - de itt meg elmondhatjuk, hogy a Google máig nem kényszerít ki semmit, sőt, a fókuszában még mindig a Flash áll és a HTML5 csak amolyan second class citizen."
Na ne viccelj. A gugli mindig is a javascriptet nyomta.
Nézd, arról nem én tehetek, hogy abszolút tájékozatlan vagy, és még olyan alapvető dolgokkal sem vagy tisztában, hogy a Google Maps, a Google Earth vagy a YouTube is máig is Flash-alapokon működik, még azokban a böngészőkben is, amelyek támogatják a HTML5-öt (beleértve a <video> taget, a Canvas-t, WebGL-t, stb). Van amelyikből van HTML5-ös változat, de csak experimental jelleggel és külön kell átkapcsolni rá. Erre mondtam, hogy second class citizen. Ha a Google annyira megfontolt és mániákus módon nyomatná a HTML5-öt mint ahogy állítod (és amely szintű kényszeredettség legfeljebb a Google+ nyomatásával kapcsolatban érthető tetten a cég esetében), akkor ez pont fordítva lenne.
Ők indították el a kinek a js motorja a leggyorsabb című háborút
Persze ezt is rosszul tudod. Pl. az első JIT technológiára épülő JavaScript motort a Mozilla dolgozta ki a Firefox számára TraceMonkey néven. A Chrome eleve csak első TraceMonkey-s Firefox után jelent meg, ráadásul akkor még lassabb is volt a JavaScript motorja a Firefox-énál.
"Egy függvény a szignatúra változtatása nélkül is átírható úgy, hogy tök mást csináljon"
Azért ilyet épeszű API gyártó általában nem csinál.
Épeszű API gyártó olyant se csinál amit te állítottál (ti. hogy felülről inkompatibilis módon módosítja a már bevezetett API-jai metódusainak paraméterezését). Mégis bedobtad. Újabb ügyes, hiteles érvelés.
He egy program így fut, akkor régen rossz.
Szerinted. De a te véleményed figyelembe véve tapasztalataid és ismereteid szerény körét nem különösebben releváns, főleg nem webes témákban. Innentől kezdve lapozhatunk.
És inkább szálljon el a program, mint hogy kiszámíthatatlanul csináljon esetleg olyan marhaságokat aminek aztán ki tudja milyen következményei vannak, a biztonsági lyuktól a hibás adatokig.
Az előbb már elmagyaráztam, hogy ettől hülyeséget nem csinál a program, biztonsági rés sem keletkezik rajta, stb. Ezen nem változtat semmit sem az, hogy te ezt nem érted meg vagy fogadod el.
"Ha és amikor fontos a feldolgozás szempontjából, hogy az X paraméter sztring -e vagy integer, akkor a program hatást dob."
Nem dob.
Szerinted. Valójában meg igen.
Azért én arra nem igazán számítanék, hogy záros határidőn belül túl sok olyan eszköz kerül a piacra, ami a mai mobilok alatti felbontást tesz lehetővé.
Hát, erre mondjuk valóban annyi esély van, mint hogy te ne valami orbitális, az általam írtakkal köszönő viszonyban sem lévő hülyeséget írj válaszként. Mint pl. most is, amikor szó se volt kisebb felbontásról - hanem arról, hogy más méretű, képarányú, beviteli módokkal rendelkező, eltérő sebességű, stb. eszközök jelenhetnek meg a jövőben, amikre (lévén nem ismered pontos paramétereiket) nem optimalizálhatod a GUI-dat. De te jól megcáfoltad ez utóbbi érvet azzal, hogy közölted: nem valószínű, hogy a jövőben a mai mobilok alatti felbontású eszközök jelennek majd meg. Gratula! Megint fantasztikusan érveltél.
Most meg pont azt bizonyítod, amit én mondtam, hogy oka volt annak, hogy ezek a technológiák mind elbuktak, és hogy újabb reinkarnációik sem kellenek már senkinek.
Nem. Én azt bizonygattam, hogy ennek nem a bytekód az oka, hanem üzleti-politikai okai vannak. Az hogy az Adobe nem csinált normális flash-t linuxra, vagy hogy Jobs anno kitiltotta a flasht az IOS-ről hogy több fingós programot lehessen az IPhone-ra eladni ugyanúgy nem technológiai kérdés, ahogy az sem hogy a guglinak az az érdeke hogy mindenbe gond nélkül belelásson a weboldalakban, és ezt könnyebben elérheti javascripttel mint mindenféle bytekód alapú cuccokkal. Más kérdés, hogy azt is átlátták hogy a js a web gyenge pontja, ezért is próbálkoznak a darts-szal. Az pedig már megint más lapra tartozik, hogy a MS pedig jól keresztbe tesz nekik, mert nehogy már a guglinak (vagy a webfejlesztőknek) jó legyen. És persze ott van még az opera, a fox - bár ez utóbbi szvsz a gugli jó pénzéért COBOL interpretert is tenne a foxba. Az igazán kemény dió az IE. De ez színtiszta politika.
Ilyenekről nem az Apple meg a Google dönt (ill. ők maximum a felvásárlással nyírhatták volna ki), hanem a felhasználók és a fejlesztők.
Lúfütty. A megrendelők döntenek. A felhasználó arra az oldalra megy ahol az a tartalom van ami neki kell. Ha a fészbúkot holnaptól átírnák java appletre, akkor sok-sok millió java applet felhasználó keletkezne máról holnapra. Ugyanez igaz persze a Silverlight-ra és bármilyen más webes technológiára is.
A fejlesztő se nagyon van döntési helyzetben - ha a megrendelő javascriptes oldalt kér akkor olyat kap, ha flasheset akkor olyat. Van az a pénz amiért vbscriptet is ír az ember... Aki dönt, az a megrendelő. Azt pedig bizony olyan szempontok vezérlik, hogy látszik-e az oldal IOS-en, vagy hogy a gugli vajon nem sorolja-e hátra ha silverlightos oldala van és nem html5.
Az persze kérdés, hogy mit és hogyan vesz figyelembe a kifejtett tartalomból - de ez ugyanígy elmondható a tisztán HTML-es oldalak esetében, ahol ugye szintén nem lehet pontosan tudni, hogy mi szerint rangsorol a Google, pontosan miket vesz pozitívumnak és negatívumnak.
Bizony. És a megrendelőnek elég az is, ha azt _hiszi_ hogy a flash vagy a SL hátra van sorolva.
Ők legfeljebb az általuk kontrollált platformokon kényszeríthettek volna rá bármit is a felhasználókra - de itt meg elmondhatjuk, hogy a Google máig nem kényszerít ki semmit, sőt, a fókuszában még mindig a Flash áll és a HTML5 csak amolyan second class citizen.
Na ne viccelj. A gugli mindig is a javascriptet nyomta. Ők indították el a kinek a js motorja a leggyorsabb című háborút, és ők azok akik a kezdetektől js alapra helyeztek amit csak tudtak. Az más dolog, hogy a flash-t is nyomatják - a gugli mindig ügyelt a látszatra. Ennek ellenére még ma is a weben a "vastagkliens" tartalom nagy részét a flash adja. Ha elmész egy random olyan webhelyre ami csinál is valamit azon kívül hogy szép 10-ből 9x, jobbclickre az about flash player fog megjelenni, legyen az játék, reklám, vagy Pl. rajzolóprogram.
Egy függvény a szignatúra változtatása nélkül is átírható úgy, hogy tök mást csináljon
Azért ilyet épeszű API gyártó általában nem csinál.
A különbség a dinamikus és a statikus típuskezelésű ill. futtatókörnyezetek között, hogy dinamikus esetében mindaddig működni fog továbbra is ez a kódhalmaz és a program amíg nem használod olyan részét, olyan ágát ami a konzisztenciaprobléma által érintett (azaz pl. kompatibilitásmegtörés esetén a törés által nem érintett funkciói továbbra is működnek), addig egy statikus, előre fordított kódhalmaz esetében még az amúgy továbbra is helyesen működni képes részek sem lesznek futtathatók, pusztán azért, mert formálisan a teljes program (beleértve a nem is használt kódrészleteket) nem érvényes.
He egy program így fut, akkor régen rossz. Az ugyanis, hogy egy adott osztályban egy általad nem használt függvény N. paramétere megváltozik a statikus típuskezelésnél sem érdekli a kutyát sem. De ha az általad használt függvényben van ilyen változás, akkor az bizony időzített bomba. És inkább szálljon el a program, mint hogy kiszámíthatatlanul csináljon esetleg olyan marhaságokat aminek aztán ki tudja milyen következményei vannak, a biztonsági lyuktól a hibás adatokig.
Ha és amikor fontos a feldolgozás szempontjából, hogy az X paraméter sztring -e vagy integer, akkor a program hatást dob.
Nem dob. És pláne nem ott dob, ahol a hiba keletkezik, hanem csak esetleg fél év múlva amikor összesíted az az idő alatt felrögzített adatokat.
Ráadásul ha még úgymond "skinezhető", eszközfüggő alternatív layoutokkal is látható el a pixelpontos megoldásod (amit amúgy a desktop környezetek jellemzően nem tesznek lehetővé), akkor is ott van a probléma, hogy csak korlátos számú és csak a program elkészítésekor már ismert eszközformátumra tudod elkészíteni ezt az ideális pixelpontos designt. Minden később megjelenő ill. általad nem ismert és kezelt eszközön viszont (többé-kevésbé) "nem lesz jól érhető" a felületed, mert nem lesz "az adott eszközhöz készítve".
Azért én arra nem igazán számítanék, hogy záros határidőn belül túl sok olyan eszköz kerül a piacra, ami a mai mobilok alatti felbontást tesz lehetővé. Felfelé meg lehet skálázni az olyan eszközökkel mint Pl. az xaml.
Az ActiveX komoly biztonsági lyuk volt, nem csoda hogy kivégezték.
Erről beszélek. Hogy ti. nem véletlen, hogy ezek a technológiák elbuktak. Mert mindegyik komoly hátrányokkal rendelkezett az a kevés előny mellett amit felkínált, és amely előnyök mára semmissé váltak.
Szóval mondhatnám, hogy örülük, hogy kezded visszhangzani azt amiről eddig meséltem neked - de sajnos tudom, hogy te nem ismered fel, hogy ezt csinálod. Sőt, a jelek szerint már nem is tudod mit akarsz bizonygatni - hiszen ez pár hozzászólással korábban még az volt, hogy a natív, a VM-en fordított kód (mint pl. Java) - über alles, ez a jövő. Most meg pont azt bizonyítod, amit én mondtam, hogy oka volt annak, hogy ezek a technológiák mind elbuktak, és hogy újabb reinkarnációik sem kellenek már senkinek. Mert hogy minen a témához kicsit is értő fejlesztő tudja, hogy ezek sosem olyan biztonságosak, gyorsak, nem olyan könnyű fejleszteni rájuk, mint ahogy azt ígérik ill. amilyen gyors, biztonságos és könnyen programozható a JS.
A java applet anno jó ötlet lett volna, de a megvalósítás terén kihívásokkal küzdött, ezért aztán nem is nagyon tudott soha elterjedni.
Fenéket nem. Már az ezredfordulón ott volt minden böngészőben alapból (hiszen egészen az IE6-ig beépített Java-val érkezett minden IE, amik akkor a piac >90%-át uralták, de jelenleg is szinte teljesen automatikusa a telepítése FF-ban, Chrome-ban is), és azóta is kb. a Flash-sel összemérhető a penetrációja. Csak egyszerűen nincs igény rá, már senki, sehol nem használ Java appleteket, csak maximum legacy alkalmazásokban.
A flash viszont eléggé bejött, egészen a mai napig uralja a webes "vastag kliens" a piacot, és ez így is maradt volna ha a gugli és az apple úgy nem döntenek hogy kivégzik.
Ilyenekről nem az Apple meg a Google dönt (ill. ők maximum a felvásárlással nyírhatták volna ki), hanem a felhasználók és a fejlesztők. Ha a Flash-t nem lehetett volna ekvivalens vagy jobb technológiákkal kiváltani, akkor mindenki maradt volna mellett - teljesen függetlenül attól, hogy akár a Google, akár az Apple mit akar. Ők legfeljebb az általuk kontrollált platformokon kényszeríthettek volna rá bármit is a felhasználókra - de itt meg elmondhatjuk, hogy a Google máig nem kényszerít ki semmit, sőt, a fókuszában még mindig a Flash áll és a HTML5 csak amolyan second class citizen.
Ennek ellenére előbbi az ami haldoklik és a HTML5 ami hódít. Ennek oka pedig az, hogy a HTML5+JS ma már bőven képes legalább arra, amire a Flash - csak ugyanazt gyorsabban, hatékonyabban és kevesebb buggal csinálja meg. Ráadásul vannak olyan fícsörei amik a Flash-ben nincsenek (pl. Indexed DB). Ezért támogatja mindenki őket - nem azért, mert síkhülyék a webfejlesztők és nem tudják, hogy mi a jó nekik (ami szerint a C# és a .NET, mindig, mindenhol, mindenre).
Az megint egy másik történet, hogy az Adobe nem kimondottan verte magát a földhöz a flash fejlesztésén nem windowsos környezetben - a linuxos flash mindig problémákkal küzdött.
Szóval a Flash is problémás? Dehát ezzel megint engem visszhangzol és az én álláspontom igazolod.
A Silverlightnak is hasonló gondja van - szintén igazán csak win32-n jó. A linuxos portja vicc, Android, IOS nincs. Ráadásul ugyanaz a telepítési mizéria van mint a sima .NET esetén.
Dettó mint az előbb. Akkor mit is akarsz mondani?
De ami a legnagyobb gond vele - és a flash-sel is - hogy nem tudod hogy a gugli hova sorolja az így készült lapokat.
Ezt csak te nem tudod. Aki ért kicsit is a webfejlesztéshez az tudja, hogy a Google már lassan fél évtized óta teljes értékű Flash indexelést csinál. Az persze kérdés, hogy mit és hogyan vesz figyelembe a kifejtett tartalomból - de ez ugyanígy elmondható a tisztán HTML-es oldalak esetében, ahol ugye szintén nem lehet pontosan tudni, hogy mi szerint rangsorol a Google, pontosan miket vesz pozitívumnak és negatívumnak.
Azzal hogy nem kényszeríted ki a származási viszonyt, már jól tökön is lőtted az OOP-t. Az hogy nem kényszeríted ki a típusegyezést, azt kockáztatod hogy egy függvény szignatúra változás esetén teljesen kiszámíthatatlanul fog viselkedni a programod - ami rosszabb mint az elszállás.
Jézusom micsoda hülyeség. Egy függvény a szignatúra változtatása nélkül is átírható úgy, hogy tök mást csináljon, mint eddig - tehát statikus típusellenőrzés mellett is elérhető, hogy úgymond "kiszámíthatatlanul viselkedjen" az adott metódust használó kód, program.
A másik oldalon ugyanakkor ha az ember nem felülről kompatibilis módon módosít egy függvényt, akkor vagy átnevezi, vagy törli teljesen. Pl. ha az intToStr()-t átírom úgy, hogy a lemezt is leformázza, akkor átnevezem minimum intToStrAndFormatDisk()-re, nem hagyom intToStr()-en. Innentől kezdve teljesen kizárt, hogy "kiszámíthatatlanul viselkedjen" a program, és egy sztring-integer konverzió részeként leformázza a merevlemezt is.
Aki nem így csinálja, az egyrészt sajnos hülye programozó, másrészt az ugyanúgy statikus típuskezelésű nyelvben is gond nélkül megcsinálja, hogy egy sztring-integer konverzió leformázza a lemezt.
Persze az igazán korrekt a lib verziójának a kikényszerítése, mivel egy függvényszignatúra változás nem jelent feltétlenül eltérő típust a megváltozott paraméterekben, lehet olyan is hogy az X. paraméter ugyanúgy int marad csak mást jelent.
Ha te így tartod karban a kódjaid, akkor persze érthetők az aggodalmaid. De mint mondtam kicsit is hozzáértő programozó ilyent nem csinál, ha meg mégis, akkor a statikus típuskezelés sem védi meg a saját hülyeségétől.
De a legrosszabb az, ha még annyi védelem sincs hogy hátast dob a program ha az X paraméter string helyett integer.
Ha és amikor fontos a feldolgozás szempontjából, hogy az X paraméter sztring -e vagy integer, akkor a program hatást dob. Ha és amíg ez nem fontos (mert pl. nem végzel feldolgozást az adott paraméteren, hanem csak átadod egy másik, hívott eljárásnak, vagy generikus feldolgozásnak veted alá, mint pl. megnézed, hogy nem null -e, meg lett -e adva), addig viszont teljesen felesleges egyáltalán csak törődni is a típussal.
Az üveggömbbe nézve sok-sok kiszámíthatatlan run-time errort látok...
Ez már csak így működik, hogy ti. ha úgy módosítasz egy kódhalmazt, hogy az elveszti belső konzisztenciáját, akkor az nem lesz futtatható a jövőben. A különbség a dinamikus és a statikus típuskezelésű ill. futtatókörnyezetek között, hogy dinamikus esetében mindaddig működni fog továbbra is ez a kódhalmaz és a program amíg nem használod olyan részét, olyan ágát ami a konzisztenciaprobléma által érintett (azaz pl. kompatibilitásmegtörés esetén a törés által nem érintett funkciói továbbra is működnek), addig egy statikus, előre fordított kódhalmaz esetében még az amúgy továbbra is helyesen működni képes részek sem lesznek futtathatók, pusztán azért, mert formálisan a teljes program (beleértve a nem is használt kódrészleteket) nem érvényes. Ez nem, hogy óriási, de leküzdhetetlen, kompenzálhatatlan hátrány egy olyan erősen elosztott rendszerben, mint a web és az internet általában.
Lásd 1. pont, az OOP és az ő tökén lövése. Az OOP-nek ugyanis az egyik fontos tényezője az öröklődés.
De itt nem arról volt szó, hogy nem LEHET örököltetni, hanem arról, hogy nem KELL örököltetni. Nem mellesleg pont azért találták ki az interface-eket és delegate-eket a statikusan típusos nyelvekben, mert igenis gyakran szükség van arra, hogy az objektum-hierarchia öröklési vonalán kívül, megfelelően magasszintű közös bázisős is lehessen azonos és egységes módon kezelni objektumokat, amelyekből ott és akkor csak az érdekes, hogy egy adott metódust vagy metóduskészletet mindannyian támogassanak, és nem érdekel senkit, hogy kitől és honnan származnak.
Ezek szerint a statikus nyelvek, köztük a C# is tökön lövik az OOP-ot. Vagy csak megint zöldséget beszéltél és arról adtál tanúbizonyságot, hogy még az általad használt, preferált és istenített eszközök alapkoncepcióit sem érted.
Azt pedig hogy csak az általam használt dolgok kódját töltöm le meg lehet(ne) csinálni bytekóddal is. Már a Delphi is csak azt tette be a progiba a VCL-ből ami kellett - pedig az nem is bytekód volt hanem gépi.
Kevered a szezont a fazonnal. Itt nem arról van szó, hogy nem kerülnek bele a tárgykód-halmazba az adott kódhalmaz által soha, sehol nem hivatkozott forrásból származó részek, hanem hogy elég csak akkor letölteni és lefordítani a teljes kódhalmaz bizonyos részeit ha és amikor ténylegesen szükség van rá, azaz amikor a kód többi része ténylegesen meg akarja hívni azt. Ez a lehetőség egy statikus, monolitikus bináris esetében nem adott, legyen az .exe vagy egy köztes bájtkód, hanem ott csakis abban az egyetlen, megbonthatatlan egységben kezelhető a teljes kódhalmaz ahogyan össze lettek fordítva, állítva. Ez még a mai tipikus sávszélességek mellett is igen komoly faktor.
Egyébként meg azzal amiről te beszélsz, nem hogy a Delphi, de már a TP is rendelkezett, és szakszóval halott-kód kizárásnak (dead code elimination) hívják.
Egy felület akkor lesz jól érthető, ha az adott eszközhöz van elkészítve
Ez nagyon igaz. Csak amit nem látsz meg ebben a kijelentésben az az, hogy ebből eredően egy fix, pixelpontos felület nem lehet jól érthető és kezelhető bármely eszközön, hanem csakis azon az egyen amelyen ill. amire tervezve lett. Minden más, picit is eltérő eszközön már - többé-kevésbé - nem lesz érthető és jól kezelhető, a nagyon eltérőkön meg abszolút nem lesz kezelhető.
Ráadásul ha még úgymond "skinezhető", eszközfüggő alternatív layoutokkal is látható el a pixelpontos megoldásod (amit amúgy a desktop környezetek jellemzően nem tesznek lehetővé), akkor is ott van a probléma, hogy csak korlátos számú és csak a program elkészítésekor már ismert eszközformátumra tudod elkészíteni ezt az ideális pixelpontos designt. Minden később megjelenő ill. általad nem ismert és kezelt eszközön viszont (többé-kevésbé) "nem lesz jól érhető" a felületed, mert nem lesz "az adott eszközhöz készítve".
Pont ezért lényeges, hogy a prezentációs és szemantikus tartalom ill. a funkcionalitás egymástól el legyen választva és hogy az eszköz saját hatáskörében választhassa meg - nyilván bizonyos értelmes korlátok között - bizonyos elemek prezentációját és működést. Mert így az eszköz - ami a saját paramétereivel nyilván tisztában van - a saját sajátosságaihoz igazíthatja a megjelenést a program és az interfész működése szempontjából lényegtelen, nem meghatározható ill. a programozó által direkt nem rögzített jellemzők vonatkozásában. Ez biztosítja, hogy a ténylegesen megjelenő interfész mindig "az adott eszközhöz legyen készítve" (abban a mértékben ahogy ez értelmes és nem veszélyezteti a program funkcionalitását), és ennek megfelelően "jól érthető" és kényelmes legyen a használata.
Azaz csinálsz egy desktop verziót mondjuk 1024x768-ra, és ha kell csinálsz egy mobil verziót - a mobil UI-ra kihegyezve. A különbség abban van a szemléletmódunk közt, hogy szerintem ezt igazán jól csak úgy lehet megcsinálni, ha mindkét felületre nem csak pixelpontosan megcsinálod az UI-t, de ezen túlmenően figyelembe veszed a beviteli mód sajátosságait is.
Ha ezt valóban így gondolnád, akkor megint nem mondanád azt, hogy az előre definiált pixelpontos felület a jó koncepció egy alapvetően heterogén eszközkészlet megcélzására, hiszen a beviteli módoknak is rendkívül sok fajtája van. Pl. lehet érintőképernyős a bevitel, amely esetén azonban szintén lehet stylus vagy ujj a mutatóeszköz (amik pontossága azonban alapvetően eltér, így pl. alapvetően meghatározza, hogy mondjuk egy scrollbarnak mekkorának kell lennie ahhoz, hogy egyik oldalon kényelmesen használható legyen, a másik oldalon viszont ne vegyen el feleslegesen helyet a lényegi tartalom elől); de lehet, hogy nincs is érintőképernyő, csak iránygombok vannak a navigációra (amely esetben pl. csak egy igen vékony scrollbar az értelmes, mert a vastag csak pazarolja a helyet, és rábökni úgysem kell tudni). De ugyanez elmondható pl. a szövegbevitelről is. Ha ugyanis van fizikai billentyűzet, akkor a szövegbeviteli mező kitöltheti az egész képernyőt is - ha viszont nincs, akkor a felületet úgy kell megtervezni, hogy a virtuális billentyűzet is kiférjen a beviteli mező mellé. Stb.
Szóval mint látod, még ugyanakkora felbontás, színmélység mellett, pusztán a beviteli eszközökből is számtalan kombináció képzelhető el - ami azt jelenti, hogy ha pixelpontosan előre rögzített megoldásokban gondolkozol, akkor csilliárd fajta ilyen "skint" kellene definiálnod ugyanahhoz a programhoz. Akkor a különböző képernyőarányokról, orientációkról, felbontásokról, színmélységekről, stb. még nem is beszéltünk. Ez egyszerűen kivitelezhetetlen.
Heterogén eszközkörnyezetekbe egyértelműen csak nem pixelpontos, hanem inkább csak amolyan - lehetőleg megválasztható részletességű - "iránymutatásokra" épülő, végleges formájukat azonban csak az eszközön, az utóbbi által befolyásolt módon elérő UI-definíciók ill. ezekre épülő keretrendszerek, futtatókörnyezetek lehetnek hatékonynak, kényelmesek, jól használhatók. A pixelpontos UI-tervezés csak desktopon működik, ami gyakorlatilag homogénnek tekinthető mind a beviteli eszközök körét, típusát, mind a megjelenítő eszközök méretét, színmélységét, felbontását tekintve is.
Erre mondtam az előbb, hogy a sztori nem ott kezdődik, hogy erre nem is volt próbálkozás, hanem bizony volt (ti. volt olyan, hogy a böngészőpiac >90%-án elérhető volt egy-egy natív, bájtkód alapú ill. virtuális gépen alapuló futtatókörnyezet, mint pl. az ActiveX, a Java, a Flash és a Silverlight), nem is egy.
Az ActiveX komoly biztonsági lyuk volt, nem csoda hogy kivégezték. A java applet anno jó ötlet lett volna, de a megvalósítás terén kihívásokkal küzdött, ezért aztán nem is nagyon tudott soha elterjedni. A flash viszont eléggé bejött, egészen a mai napig uralja a webes "vastag kliens" a piacot, és ez így is maradt volna ha a gugli és az apple úgy nem döntenek hogy kivégzik. De e mögött sokkal inkább üzletpolitika volt mint technológia. Az megint egy másik történet, hogy az Adobe nem kimondottan verte magát a földhöz a flash fejlesztésén nem windowsos környezetben - a linuxos flash mindig problémákkal küzdött.
A Silverlightnak is hasonló gondja van - szintén igazán csak win32-n jó. A linuxos portja vicc, Android, IOS nincs. Ráadásul ugyanaz a telepítési mizéria van mint a sima .NET esetén.
De ami a legnagyobb gond vele - és a flash-sel is - hogy nem tudod hogy a gugli hova sorolja az így készült lapokat. Igazából a sima html esetén sem tudod, de így meg pláne. Márpedig az oldalak 90%-ánál a gugli besorolás nagyjából a cég sorsát dönti el.
1. csakis a ténylegesen használt azonosítók, metódusok, paraméterek, stb. vonatkozásában követeli meg a kompatibilitást, nem ír elő semmiféle elvont, formális, öncélú típusegyezést vagy -kompatibilitást, nem kényszerít ki származási viszonyt, nem követel meg felesleges és redundáns típusdeklarációkat, stb. (lásd duck typing)
Azzal hogy nem kényszeríted ki a származási viszonyt, már jól tökön is lőtted az OOP-t. Az hogy nem kényszeríted ki a típusegyezést, azt kockáztatod hogy egy függvény szignatúra változás esetén teljesen kiszámíthatatlanul fog viselkedni a programod - ami rosszabb mint az elszállás. Persze az igazán korrekt a lib verziójának a kikényszerítése, mivel egy függvényszignatúra változás nem jelent feltétlenül eltérő típust a megváltozott paraméterekben, lehet olyan is hogy az X. paraméter ugyanúgy int marad csak mást jelent. De a legrosszabb az, ha még annyi védelem sincs hogy hátast dob a program ha az X paraméter string helyett integer.
. esetében nem kell egy monolitikus egésszé, vagy ugyan moduláris, de egymással pontosan meghatározott kapcsolati rendszert alkotó halmazzá összekapcsolni az összes kódot, mint statikus, fordított megoldások esetében, hanem a kódhalmazon belüli viszonyok a futtatás helyén és idején dőlnek el, hiszen akkor és csak akkor kerülnek feloldásra a kódrészek közötti esetleges egymásra hivatkozások
Az üveggömbbe nézve sok-sok kiszámíthatatlan run-time errort látok...
3. ami azt jelenti, hgoy jellemzően kevesebb kódot kell letölteni, gépi kódra fordítani, stb. mint egyébként, és a teljes kódhalmaznak mindig csak az éppen ténylegesen használt részeit (és pl. nem kell egy közös bázisős deklarációját betölteni, értelmezni, csak azért, hogy aztán elmondhassuk, hogy X meg Y is ebből származik)
stb.
Lásd 1. pont, az OOP és az ő tökén lövése. Az OOP-nek ugyanis az egyik fontos tényezője az öröklődés. Azt pedig hogy csak az általam használt dolgok kódját töltöm le meg lehet(ne) csinálni bytekóddal is. Már a Delphi is csak azt tette be a progiba a VCL-ből ami kellett - pedig az nem is bytekód volt hanem gépi.
A különböző autómodellekben sincs halálpontosan ugyanannyi milliméterre a szélvédtől, az ajtótól, a padlótól és az üléstől se a kormány, se az index, se a világításkapcsoló - se ezek az elemek egymástól -, (hanem ezek mind a jármű egyedi jellemzőinek figyelembevételével kerülnek elhelyezésre), mégis kiválóan tudják az emberek kezelni ezeket a vezérlőelemeket, egyik autóból gond nélkül át tudnak ülni egy másikba, és el tudják vezetni azt is.
Ja. De az egyes modellekben pixelpontosan meg van tervezve hogy mi hol van. És szorgos emberek dolgoznak főállásban azon hogy egy-egy modellen mi hova kerüljön - és nem véletlenül, az ilyen "apróság" sok mindenbe beleszámít az eladásoktól a baleseti statisztikákig.
Egy felület ill. egy vezérlőelem ugyanis nem attól lesz jól érthető és kezelhető, hogy minden környezetben tökéletesen identikus, hanem attól, hogy bár fő jellemzőiben rendkívül hasonlít, de részleteiben és alapvető funkcióját nem befolyásoló elemeiben a mindenkori működési környezethez van igazítva.
Egy felület akkor lesz jól érthető, ha az adott eszközhöz van elkészítve. Azaz csinálsz egy desktop verziót mondjuk 1024x768-ra, és ha kell csinálsz egy mobil verziót - a mobil UI-ra kihegyezve. A különbség abban van a szemléletmódunk közt, hogy szerintem ezt igazán jól csak úgy lehet megcsinálni, ha mindkét felületre nem csak pixelpontosan megcsinálod az UI-t, de ezen túlmenően figyelembe veszed a beviteli mód sajátosságait is. Azaz más felületet adsz egy tabletnek vagy egy mobilnak mint egy desktopnak (legyen az webes vagy asztali). Ez akár még BL szinten is eltérhet, nem hogy el tudnád intézni egy css átírásával.
Miért van szükség akármilyen nyelvben elkészített - akár saját, akár valamilyen közösségi, akár kereskedelmi - könyvtárakra, rutin-gyűjteményekre, keretrendszerekre? Miért nem tartalmaz minden nyelv minden elkészített csomagot gyárilag?
Érzed, hogy egy kicsit értelmetlen a nyelv hibájának felróni ezt?
Szerintem, a jQuery-ben amúgy "sokkal több" a népszerűség mint az átgondoltság - ha érted mire gondolok. Én pl. a RightJS-t klasszisokkal jobb "csomagnak" tartom. Természetesen, ez csak az én véleményem (nem kell vele egyetérteni, nem fogom cáfolni, ha másvalaki más véleményen van - mindenki azt használ, amit akar).
... amennyiben a Javascript a jelenleg elérhető lehető legjobb megoldás a kliens-oldali scriptelésre, miért van szükség olyan bővítményekre, mint pl. a jQuery?
Miért? A jQuery micsoda? JS nyelven készített "kollekció".
Miért még mindig a JavaScriptet használjuk és miért dinamikus nyelvekben készül a webalkalmazások túlnyomó része - sőt, miért egyre inkább ebbe kerülnek átírásra még azok a megoldások is, amelyek korábban előfordított nyelvekre, VM-ekre, stb. épültek?
A válasz persze az, hogy azért, mert ezek a nyelvek és eszközök a legmegfelelőbbek a feladatra, és mert minden más nyelv és technológia (beleértve a fordított nyelveket és a bájtkód alapú környezeteket is) nem hoznak szinte semmit előnyt, hátrányt viszont annál többet ebbe a környezetbe.
Nem vagyok nagy Javascript-szakértő, de amennyiben a Javascript a jelenleg elérhető lehető legjobb megoldás a kliens-oldali scriptelésre, miért van szükség olyan bővítményekre, mint pl. a jQuery?
Ugyanakkor a böngésző oldal - pont azért mert sem nyelvfüggetlen bytekód, sem natív gépi kód nem elérhető egységesen minden böngésző platformon csak a szöveges javascript fut le, így a nyelv leváltására nincs lehetőség.
Erre mondtam az előbb, hogy a sztori nem ott kezdődik, hogy erre nem is volt próbálkozás, hanem bizony volt (ti. volt olyan, hogy a böngészőpiac >90%-án elérhető volt egy-egy natív, bájtkód alapú ill. virtuális gépen alapuló futtatókörnyezet, mint pl. az ActiveX, a Java, a Flash és a Silverlight), nem is egy. Csak nem mutatkozott igény a tényleges használatára, vagy kiderült, hogy amit ígér azt nem tudja beváltani, vagy ha igen, akkor óriási hátrányokat von maga után a másik oldalon, stb. Szóval egyszerűen már számos ilyen próbálkozás elbukott a JavaScripttel szemben, minden helyzeti potenciális ellenére.
Erre jössz megint azzal, mint a lemezen visszaugró fej, hogy dehát nem érhető el minden böngészőplatformon semmi más a JavaScript mellett. De elérhető (pl. Java, Flash, Silverlight még ma is), és még több volt elérhető a megelőző időszakokban. Csak már akkor sem tudtak versenyezni a JavaScripttel, és ma sem tudnak.
Ezek közül mi az, amit dinamikus típuskezeléssel jobban tudsz kezelni ?
Itt már megint össze-vissza kevered a fogalmakat. Nem a dinamikus típuskezelés, hanem a dinamikus nyelv és a dinamikus futtatókörnyezet az ami mindegyik eset kezelését nagyban erősíti, azon keresztül, hogy
1. csakis a ténylegesen használt azonosítók, metódusok, paraméterek, stb. vonatkozásában követeli meg a kompatibilitást, nem ír elő semmiféle elvont, formális, öncélú típusegyezést vagy -kompatibilitást, nem kényszerít ki származási viszonyt, nem követel meg felesleges és redundáns típusdeklarációkat, stb. (lásd duck typing)
2. esetében nem kell egy monolitikus egésszé, vagy ugyan moduláris, de egymással pontosan meghatározott kapcsolati rendszert alkotó halmazzá összekapcsolni az összes kódot, mint statikus, fordított megoldások esetében, hanem a kódhalmazon belüli viszonyok a futtatás helyén és idején dőlnek el, hiszen akkor és csak akkor kerülnek feloldásra a kódrészek közötti esetleges egymásra hivatkozások
3. ami azt jelenti, hgoy jellemzően kevesebb kódot kell letölteni, gépi kódra fordítani, stb. mint egyébként, és a teljes kódhalmaznak mindig csak az éppen ténylegesen használt részeit (és pl. nem kell egy közös bázisős deklarációját betölteni, értelmezni, csak azért, hogy aztán elmondhassuk, hogy X meg Y is ebből származik)
stb.
Ha nem teszed, akkor nem beszélhetünk user interface tervezésről.
Hanem akkor miről beszélünk? Bikkamakka-tervezésről? Vagy früty-frütyről?
Az adott dolog nem ott jelenik meg ahová tervezted, ahol a user számára egyértelmű infót jelent.
Ott jelenik meg ahová tervezted - csak ez nem pixelpontosan egy adott hely minden eszközön. És pláne nem feltétlenül viselkedik ugyanúgy az adott vezérlő - ami esetében azonban megint nem arról van szó, hogy random módon viselkedik, hanem arról, hogy az eszköz és a környezet sajátosságaihoz legjobban illeszkedő módon működik.
A különböző autómodellekben sincs halálpontosan ugyanannyi milliméterre a szélvédtől, az ajtótól, a padlótól és az üléstől se a kormány, se az index, se a világításkapcsoló - se ezek az elemek egymástól -, (hanem ezek mind a jármű egyedi jellemzőinek figyelembevételével kerülnek elhelyezésre), mégis kiválóan tudják az emberek kezelni ezeket a vezérlőelemeket, egyik autóból gond nélkül át tudnak ülni egy másikba, és el tudják vezetni azt is.
Ez pontosan ugyanígy működik a nem pixelpontos UI-definíciók esetében is. Amik pont azért, mert bizonyos részleteikben a futtatókörnyezet sajátosságaihoz idomulnak, sokkal jobb és hatékonyabb módját adják az információk prezentálásának és a vezérlésnek, mint azok a felületek, amik minden - akár jelentősen eltérő - futtató- és eszközkörnyezetben is pontosan ugyanazt az egyetlen és mindenhol tökéletesen indetikus megjelenítést és működést akarják kikényszeríteni. Ami éppen csak akkor hülyeség, mint a biciklitől kezdve a teherautón át a repülőig minden járműbe ugyanazt a tökéletese indentikus mondjuk Opel Astra kormányt akarni szerelni.
Egy felület ill. egy vezérlőelem ugyanis nem attól lesz jól érthető és kezelhető, hogy minden környezetben tökéletesen identikus, hanem attól, hogy bár fő jellemzőiben rendkívül hasonlít, de részleteiben és alapvető funkcióját nem befolyásoló elemeiben a mindenkori működési környezethez van igazítva.
Ez elmondható az összes asztali fejlesztőeszközről is - érdekes módon ott mégis volt generációváltás, nem egy is, illetve számos technológia versenyez jelenleg is egymással.
Egyrészt ez sem teljesen igaz - az asztalon van alapvetően a win32 API aminek a tetejére aztán különféle más dolgok (GTK, Qt, VCL, wxWidgets, MFC, stb) tudnak költözni. Ezért lehet az asztali platform sokféle. Amúgy ez weben is megvan - jó sok különféle javascript lib szaladgál a neten.
Ugyanakkor a böngésző oldal - pont azért mert sem nyelvfüggetlen bytekód, sem natív gépi kód nem elérhető egységesen minden böngésző platformon csak a szöveges javascript fut le, így a nyelv leváltására nincs lehetőség.
Nézd meg a darts-t. A gugli kihozta - ugyanakkor az elterjedése ugyancsak kétséges. Hogy miért ? Mert IE, Opera, Fox alatt nincs. Márpedig, ha te webet fejlesztesz, akkor nyilván olyan lapot kell csinálnod ami a lehetőségekhez képest böngészőfüggetlen. A legtöbb amit megtehetsz hogy a forrást javascriptre fordítod (lásd Darts) amivel viszont gyorsabb garantáltan nem lesz a kódod mint a "natív" javascript. Lassabb viszont jó eséllyel igen.
hanem hogy olyan 3rd party komponenseket, külső hivatkozásokat használ, amik anélkül változhatnak egyik pillanatról a másikra, hogy ő erről tudhatna
Nézd. Mi tud változni ?
1. Egy osztályt nem igy hívnak hanem úgy.
2. Egy osztály a továbbiakban már nem létezik.
3. Egy függvénynek nem ez a neve, hanem az.
4. Egy függvény már nem létezik.
5. Egy függvény paraméter szignatúrája megváltozik.
Ezek közül mi az, amit dinamikus típuskezeléssel jobban tudsz kezelni ? Max. az 5. elemet, mert esetleg eddig a függvény 3. paramétere az X koordináta volt, most pedig a user neve, és mivel dinamikus típuskezelés van, így a függvény simán megeszi a Kovács Józsi helyett a 123-at. Kérdés az, hogy ez kinek jó...
Ezek szerinte nem tudod, hogy mit jelent az, hogy háromrétegű alkalmazás.
Dehogynem. Naponta csinálok ilyet. Alkalmazásszerver megkapja az SQL-től az adatokat, ott objektumot csinál belőle, az üzleti logika is teszi a dolgát, majd (tipikusan webservice-ként) továbbítja azt a desktop proginak. Ő ott odaadja a usernek, az csinál vele valamit, esetleg némi validity, cache, stb) majd a kliens továbbítja azt a webservice-en át az alkalmazás szervernek. Ez pedig szépen SQL utasításokat csinál belőle, és irány az SQL szerver. Ez már 10 éve is így ment, sőt 15 éve is, csak akkor nem webservice volt a köztes réteg, hanem CORBA vagy DCOM.
Hiszen az általad írt állítás csak akkor igaz, ha a desktop eszközökben megszokott módon a felület felépítését teljes egészében és maximális részletességig (úgymond pixelpontosan) határozod meg.
Ha nem teszed, akkor nem beszélhetünk user interface tervezésről. Az adott dolog nem ott jelenik meg ahová tervezted, ahol a user számára egyértelmű infót jelent. Nem úgy tudja a user kezelni a progit ahogy te tervezted, hanem ahogy esik úgy puffan. Lehet ilyet csinálni (egyébként desktopon is), csak ekkor nem beszélhetsz ergonómiáról.
(*) a bytekód képes böngészőkön ugyanazok a kódok gyorsabban és biztonságosabban (ugyi' a lesajnált típusbiztonság) futnak.
Mihez képest? A rollerhez képest?
Egyébként a bájtkódnak és a típusbiztonságnak nincs semmi köze egymáshoz, ezek tök független fogalmak és jellemzők. A bájtkód csak azt jelenti, hogy a program a jellemzően szöveg alapú forrásból a futtatás előtt valami köztes, erősen struktúrált állapotra került átalakításra, amiből már gyorsabban és könnyebben generálható a ténylegesen futó tárgykód és/vagy gyorsabban értelmezhető, mint az eredeti forrás. De önmagában a bájtkódok használata semmiféle típusbiztonságot nem jelent és von maga után.
Nem csak tíz soros JS eseményeket meg JQuery állításokat tételezve fel, hanem a világ más területein ismert soktízezer soros kódokat használva -- ha komolyan vesszük, hogy a böngésző át akarja venni a konzol app. megjelenítési réteg feladatát is
Látom, te nagyon nem értesz a webes fejlesztéshez, a web működéséhez. Na akkor tegyük helyre pár dolgot, szájabrágósan:
1. A prezentációs réteget legnagyobb részben asztali alkalmazásokban akár soktízezer soros programozás esetében sem a te alkalmazási kódod, hanem az adott platform és fejlesztői eszköz által biztosított futtatókörnyezet biztosítja, működteti. Ti. utóbbiak definiálják és határozzák meg a vezérlők kinézetét, azok végzik kirajzolását, működését, azok kezelik az elemi beviteli eseményeket bennük, stb. Te gyakorlatilag abból a tízezer soros alkalmazási kódodból csak betöltöd és kiveszed az adatokat ezekből az elemi vezérlő és bevitel elemekből. Hasonló módon webes alkalmazások esetében is ezt a prezentációs infrastruktúrát meghatározó módon a böngésző és az annak otthont adó operációs rendszer biztosítja és működteti - amik azonban nem JavaScript-ben íródtak és közük nincs a jQuery-hez. Tehát a prezentációs réteg működésének sem sebességén, sem biztonságosságán, sem semmijén biztosan nem változtat az, hogy amúgy az alkalmazáskódod kliensoldali része milyen nyelven íródott, milyen formában és megoldáson fut.
2. A fentivel összefüggésben a soktízezer soros asztali alkalmazásod kódjának legnagyobb része nem a prezentációs és beviteli réteg üzemeltetését végzi, hanem a mögöttes feldolgozó logikát adja. Webalkalmazások esetében ez azt jelenti, hogy a többtízezer soros webalkalmazás kódjának legnagyobb része nem a kliensoldali kód lesz és nem a kliens oldalon a böngészőben fut, hanem marad a szerver oldalon. Mivel azonban itt és most arról beszélünk, hogy a böngészőbe mi kellene és mi nem (bájtkód alapú futtatás és hasonló hülyeségek egyesek szerint) ennél fogva a jelenleg tárgyalt kérdés vonatkozásában teljesen irreleváns, hogy a szerveroldali kódok milyen nyelven íródtak. Mivel viszont ezek a kvázi "backend kódok" teszik ki a tízezer soros alkalmazásból kb. 9900 sort - desktopon és weben is - ezért a kliensoldalra csak kb. 100-200 sor marad a még tízezer soros, viszonylag nagy alkalmazás esetében is. Az pedig, hogy 100-200 sor miben és milyen gyorsan fut, majdnem teljesen mindegy, főleg, hogy...
3. ... a tipikus webalkalmazások esetében a legszűkebb keresztmetszet nem a kliens oldali számítási kapacitás, hanem a hálózat maga ill. a halmozódó terhelés miatt a szerver oldali feldolgozókapacitás. Mivel ezek határozzák meg alapvetően az egész rendszer reszponzivitását és mivel utóbbiak teljesen függetlenek és nem befolyásoltak az által, hogy kliens oldalon, a böngészőben milyen nyelven és formában futnak a kódok.
A fentiekkel összefüggésben az, hogy a böngészőben futó kódok milyen nyelven íródnak és milyen módon futnak, a webalkalmazások 99%-a esetében teljesen irreleváns, mind fejlesztői energiabefektetés mind futási sebesség szempontjából.
A fejlesztők meg nem veszítenek semmit, mert pl. egy web-server plugin automatikusan a JS-et vagy a bytekódot küldi, igény szerint.
Mondom, hogy nem érted te, hogy mit jelent a bájtkód és milyen előnyökkel jár. A JS kód futásán az, hogy bájtkódra fordítva kerülne elküldésre és egy bájtkódot futtató VM-en kerülne futtatásra a böngészőben, semmit nem segítene, gyorsítana, és a biztonságán sem növelve (sőt, csökkentene). Nem mellesleg a mai modern böngészőkben mind VM-en futnak a JavaScript kódok a JIT fordítást követően, csak éppen ez egy nyelvi szintű VM, ami ennél fogva sokkal biztonságosabb és gyorsabb, mint egy generikus, bájtkód alapú VM. Tehát pont annak az ellentetje igaz, mint amit te tudni vélsz erről - persze igazából úgy, hogy nem is tudsz igazán semmit a web és a böngészők működéséről.
Persze ha nem képesek megegyezni, akkor mindenki sütögeti a pecsenyéjét a káosz tetején ücsörögve és az egyik jobban jár.
De hiszen szó sincs erről. Sem arról, hogy kétfelé húznának, sem arról, hogy káosz lenne születőben. Sőt, káosz pont eddig volt a millió plugin (Flash, Gears, Native Client, Java, ActiveX, stb.) révén, és ez a káosz most oszlik fel azon keresztül, hogy mindenki egy standard és egységes technológiát kezd el támogatni a millióféle plugin helyett: a HTML5-öt és a JavaScriptet. Ebbe integrálnak minden új dolgot és ezekben kerül megírásra a webalkalmazás minden része, funkciója.
Szerintem itt annyi csak a kérdés, hogy a Googli mennyire gondolja komolyan. Mennyi pénzt, és fejlesztést akar beletenni és meddig tart ki, ha nem jön azonnal eredmény. Mert az idő keményen a Dart-nak dolgozik!
Persze. Hiszen míg Dart-ra naponta átlagban születik mondjuk kb. 100 sornyi kód ami sehol nem kerül bevetésre a kísérletező kedvű fejlesztők gépein kívül, addig JavaScript kódsorok milliószám születnek naponta és kerülnek bevetésre élő oldalakon. Így aztán minden nap saccperkábé 10.000x annyival több JavaScript-kód és JavaScript-re épülő webalkalmazás lesz, mint amennyi Dart. Ezek alapján aztán tényleg elmondható, hogy az idő a Dart-nak dolgozik...
Pl. azért mert itt nem egy gyártó egy adott termékéről van szó, hanem sok gyártó van, és egy-egy gyártónak eléggé radikálisan más-más érdekei vannak.
Ez elmondható az összes asztali fejlesztőeszközről is - érdekes módon ott mégis volt generációváltás, nem egy is, illetve számos technológia versenyez jelenleg is egymással. Böngészőben nem. Na vajon miért nem, ha asztalon igen? Hát természetesen azért, mert nem az az elsődleges ok amit írtál.
Ami pedig a .NET futtatókörnyezet betöltését illeti, az valóban sok idő - de webre nem kellene a teljes .NET, elég egy (a SL-nál jóval kisebb) subsetje. Az ami kb. azt tudná mint ma a JS, kb. annyi idő alatt is töltődne be.
Ha csak ugyanazt tudja mint a JS akkor mi a büdös fenének váltanánk le? Hiszen nem nyernénk vele semmit. Mármint mi emberek: felhasználók és fejlődni is képes fejlesztők.
Mert értem, hogy az a fejlődésben lemaradt fejlesztő, aki csak a .NET-hez, C#-hoz ért (úgy-ahogy) és sose tanulta meg a JavaScript-et, a dinamikus technológiákat, stb., az sokat nyerne azzal ha ráerőszakolnák az asztali platformoktól alapvetően és minden téren eltérő webre is a .NET-et, C#-ot és azok paradigmáit, hiszen akkor hirtelen behozná lemaradását, ill. úgymond webre is tudna hirtelen fejleszteni. De valójában mindenki más (ill. felhasználói oldalon ő is) veszítene egy ilyen megoldással, és azzal, hogy az ilyen tanulni és a feladatok, platformot eltéréseit felismerni képtelen fejlesztőket is ráengedünk a webre. Mert ugye az világos, hogy nincs olyan kabát aki mindenkire ugyanúgy illik - az aki pedig mégis mindenkire ugyanazt az egyenkabátot akarja ráerőltetni amit ő tud gyártani, az ugye tudjuk micsoda és mit csinálnak vele.
A desktop progik nagy része szintén használ 3rdparty komponenseket, az pedig hogy ezek mennyire gyakran változnak, leginkább attól függ hogy a szállító mennyire értett a programtervezéshez, illetve hogy mennyire érdekli a visszafelé kompatibilitás.
Na de nem arról volt szó, hogy használ 3rd party komponenseket, hanem hogy olyan 3rd party komponenseket, külső hivatkozásokat használ, amik anélkül változhatnak egyik pillanatról a másikra, hogy ő erről tudhatna. A klasszikus (fordított) desktop alkalmazások esetén ilyen nincs, hiszen minden felhasznált komponens bele van fordítva egyetlen monolitikus futtatható állományba, és nem változik egyik pillanatról a másikra.
Ezzel szemben a webnek egyetlen szerves egészként kell működnie, pedig minden egyes domainje (sőt, sokszor azon belül is egyes alágai vagy akár oldalai) más-más személyek irányítása alatt állnak, és értelemszerűen egymástól függetlenül változhatnak és változnak is. Ez a problémák teljesen másfajta megközelítését igényli, ahol a dinamikus feldolgozásból adódó nagyobb rugalmasság, magasabb adatbiztonság, megkerülhetetlen futásidejű ellenőrzések, robosztusság és hibatűrés mind nélkülözhetetlenné válnak.
Ja. És ez mennyire jelent csak dinamikus nyelveken megoldható új programozási feladatokat ?
Ez nem "csak dinamikus nyelveken megoldható új programozási feladat", hanem egyrészt olyan feladat, ami desktop környezetben nem fordul elő, másrészt aminek megoldására a dinamikus technológiák a hatékonyabbak.
"van egy külön futtatókörnyezeted a prezentációs rétegben/hez meg van egy külön a backend alkalmazási logikádban/hoz, és ezek között kell eldöntened, hogy melyik feladatokat melyik oldalra szervezed, figyelembe véve a két réteg közötti korlátos áteresztőképességből és a halmozódó backend-oldali terhelésből adódó megfontolásokat is"
Naponta. A 3 rétegű desktop progi már jó pár éve nem újdonság.
Ezek szerinte nem tudod, hogy mit jelent az, hogy háromrétegű alkalmazás.
Nos, nem is nyújtják, és nem is nyújthatják. Egy komplex beviteli képernyőt normálisan, ergonomikusan csak fix felbontásra és adott beviteli formára tudsz megcsinálni. Lehet olyat csinálni ami minden felbontáson megy, de az minden lesz csak kényelmesen használható nem.
Ezt persze megint csak azért hiszed így, mert nem tudsz a desktop technológiák dobozán kívül gondolkodni. Hiszen az általad írt állítás csak akkor igaz, ha a desktop eszközökben megszokott módon a felület felépítését teljes egészében és maximális részletességig (úgymond pixelpontosan) határozod meg.
De a HTML-nek és a hasonszőrű webes technológiáknak pontosan az a lényege, hogy elválasztják - ill. csak lazán kötik össze - az egyes beviteli, információs és vezérlő elemek tartalmát és funkcióit, valamint azok megjelenését és elrendezését egymástól. Így a HTML oldalakat megjelenítő eszköz - bizonyos keretek között - saját hátáskörben az egyedi jellemzőihez (pl. képernyőfelbontásához, bevitel módjához, számítási kapacitásához, stb.) alakíthatja a megjelenítés és bevitel tényleges megvalósítását.
Ráadásul lehetőséget ad arra, hogy a fejlesztő a különböző eszköztípusokhoz, felbontásokhoz, beviteli módokhoz eltérő iránymutatásokat adjon neki annak vonatkozásában, hogy miként lenne praktikus az adott képernyőt vagy tartalmat megjeleníteni - megint csak azon keresztül, hogy a prezentációs réteg szemantikus tartalmát (HTML) és prezentációs attribútumait (CSS) elválasztja egymástól. Ami desktop környezetben megint nem megszokott, azaz ott a legtöbb platform és fejlesztőeszköz esetében jellemzően nem lehet pl. különböző layoutokat, prezentációs attribútumkészletet definiálni ugyanahhoz az egy formhoz, ablakhoz.
Egyébként ez az eszközfüggetlenség weben nem áll meg a prezentációs rétegnél, hanem még a weblapokba épített egyedi feldolgozó kódra is igaz, hogy annak működése bizonyos keretek között automatikusan a futtatóplatform egyedi sajátosságaihoz igazodik - anélkül, hogy a futtatókörnyezetről bármit is ki kellene derítenie és ettől függővé tennie a saját működését. Lásd pl. a Canvas requestAnimFrame()-je!
És ehhez még csak nem is kell túl komplex dolgot csinálni, elég egy mezei hírportál - a legtöbb fix felbontáson megy
Szép megállapítás - csak kár, hogy ezzel a mondatoddal mindjárt mindjárt duplán cáfolod megelőző állításod, ami szerint ergonomikus felületeket csak fix felbontásra lehetne készíteni.
Egyrészt azért, mert ha ez valóban így lenne akkor nem csak az oldalak egy speciális típusának egy részcsoportjára (ti. a hírportálok egy részére) lenne igaz, hogy fix hasábszélességet alkalmaznak, hanem mindegyikre. Minden híroldalra és minen más weboldal- és webalkalmazástípusra is. Mivel azonban utóbbi nincs így, ezért nyilván eredeti állításod sem igaz általánosságban.
Másrészt mert ha a weboldalak egy része valóban ilyen fix layoutot is alkalmaz, akkor nyilván azért teszi, mert az is elég jól használható marad a legkülönbözőbb felbontásokon, eszköztípusokon. Mert hogy ezeket az oldalakat is különböző felbontású, bevitel módú, feldolgozási kapacitású eszközökről látogatják az emberek.
Itt megint ott tévedsz, hogy nem ismered fel, hogy míg a típikus asztali alkalmazásplatform és fejlesztőeszköz esetében valóban elmondható, hogy annak megjelenése pixelpontosan ugyanúgynéz ki minden eszközön és minden - adott eszközzel, technológiával készült - asztali alkalmazás vezérlőelemei gyakorlatilag pixelpontosan ugyanúgy néznek ki, mint minden más az adott eszközökkel készült másik alkalmazásé is, addig weboldalak esetében ilyen általánosítások nem tehetők. Nem csak azért, mert a weboldalak különböző megjelenési sémákat definiálhatnak ugyanazon szemantikus tartalomra az eszköztípus függvényében, de azért is, mert gyakorlatilag minden weboldalon más, a célhoz és az adott környezethez igazított lehet a vezérlőelemek megjelenése. Más lehet (és más is) a linkek, felsorolások, táblázatok közölése, színe, mérete, igazítása és reakciója a felhasználói interakcióra.
és külön csinálnak hozzá mobil verziót.
Aha. Ennek tökéletes példája a prog.hu mobil verziója, aminek - a nyitóoldalt leszámítva - gyakorlatilag pontosan ugyanazzal a HTML kódja, mint az asztalinak minden oldalon. (Az egyetlen különbség, hogy praktikus okokból az oldalsávok már elküldésre sem kerülnek a mobil oldalakon - de ez nem azért van így, mert azokat ne lehetne elrejteni az elküldés ellenére is, azaz, mert ez a prezentációs réteg korlátossága miatt lenne így, hanem csakis azért, hogy a korlátos és lassú mobilcsomagokat ne terheljük feleslegesen).
"Egyrészt a MS nyilván nem venné át a Google megoldását ... Google és a Firefox meg nem venné át a MS megoldását"
Ez természetes. Senki nem is tételezte fel
A Google (saját üzleti érdekei szerint!) nyomni akarja a Dart + byte-kódot. Pénzzel, hatalommal és sikerrel(*) benyomhatja a technologiát a piacra.
(*) a bytekód képes böngészőkön ugyanazok a kódok gyorsabban és biztonságosabban (ugyi' a lesajnált típusbiztonság) futnak.
[Nem csak tíz soros JS eseményeket meg JQuery állításokat tételezve fel, hanem a világ más területein ismert soktízezer soros kódokat használva -- ha komolyan vesszük, hogy a böngésző át akarja venni a konzol app. megjelenítési réteg feladatát is]
Vagyis a felhasználó csak nyer a bytekód képes böngészővel, míg ha ragaszkodik a sajátjához, azzal bizonyos esetekben sokat veszíthet (pl. játékélmény böngészős/canvasos játékkal; ügyvitel böngészőbe tolása; speciális grafika/tárolás/kalkulálás igényes feladatok (3D modellezés?) böngészőbe csúszása).
A fejlesztők meg nem veszítenek semmit, mert pl. egy web-server plugin automatikusan a JS-et vagy a bytekódot küldi, igény szerint. A fejlesztő nem tesz ezért sokat, nem kell a kliens kódján változtatnia, ez a kliens oldali böngésző dolga [valamilyen annotációval jelezve neki, hogy ez a JS cserélhető bytekódra].
Vagyis technologiai siker esetén, ha a MS részesedése csökken vagy más okból veszélyben érzi magát, akkor a MS sem maradhat ki a biznicből. Ha meg megegyezik a Googlival, hogy az IE is támogatja a bytekódot, ha a bytekód motor olyan, hogy egyenrangú félként fogadja a C#/.Net kliens oldali dolgokat... na akkor számoljunk ezen ki is nyer? Mindenki?
Ebből a szituációból szoktak a jó döntések kijönni.
Amikor mindenki nyer (elhiszi hogy nem járt jól) vagy ellenkező esetben mindenki bukik valamit, az elég meggyőző tud lenni.
Persze ha nem képesek megegyezni, akkor mindenki sütögeti a pecsenyéjét a káosz tetején ücsörögve és az egyik jobban jár.
Persze a nagy kérdés, hogy a fejlődést visszafogó MS nyer-e, mert a Google megint eltaknyolt valamin, vagy a Google mert bevezetett egy sikeres technologiát és talált hozzá támogatást, miközben a MS megint lemarad a vonatról és nem tud mit felmutatni helyette (vagyis a weben tovább csökken az ereje).
Nem tudjuk mi van a tarsolyukban, de a tábla szerintem a Dart felé billen, neki van esélye jobban kijönni. A MS meg gondolkozzon...
Szerintem itt annyi csak a kérdés, hogy a Googli mennyire gondolja komolyan. Mennyi pénzt, és fejlesztést akar beletenni és meddig tart ki, ha nem jön azonnal eredmény. Mert az idő keményen a Dart-nak dolgozik!
Az ami kb. azt tudná mint ma a JS, kb. annyi idő alatt is töltődne be.
Mielőtt belekötnél - azt tudná mint a js körüli infrastruktúra - azaz ajax, jquery, és nem lenne benne a teljes Silverlight, Pl. az xaml-lel.
Na de a helyes kérdés az, hogy miért még mindig csak JavaScript van, mikor böngészőink már olyan régóta vannak, amióta a Windows-t kb. 4x írták újra szinte teljesen, legalább négy (de inkább öt) mobiloperációs rendszer generáció tűnt fel és múlt el, és kb. 500 új programozási nyelv született meg.
Pl. azért mert itt nem egy gyártó egy adott termékéről van szó, hanem sok gyártó van, és egy-egy gyártónak eléggé radikálisan más-más érdekei vannak. Itt keresztülvinni egy új dolgot egy-egy gyártónak nem igazán egyszerű. Lásd google és a darts. Ráadásul az idő nagy részében az IE dominálta a piacot, márpedig az MS-nek sok minden volt az érdeke, de egy normális böngészőoldali architektúra a legkevésbé. Neki a minél rosszabb annál jobb volt az érdeke - márpedig a MS nélkül még ma sem lehet csinálni semmit a weben, nemhogy 5 vagy pláne 10 éve. Ma ehhez képest annyival rosszabb a helyzet, hogy van még legalább egy szereplő, a gugli ami nélkül semmit sem lehet csinálni - igy a MS innovációit a gugli öli meg, a gugliét meg az MS. És persze ott van még az Apple, Opera...
De ennek semmi köze holmi technológiai megfontolásokhoz.
Ami pedig a .NET futtatókörnyezet betöltését illeti, az valóban sok idő - de webre nem kellene a teljes .NET, elég egy (a SL-nál jóval kisebb) subsetje. Az ami kb. azt tudná mint ma a JS, kb. annyi idő alatt is töltődne be. Ha nem rövidebb idő alatt - elvégre előre fordított kódról van szó.
Ez persze abszolút nem így van. Pl. asztali környezetben elég ritkán van, hogy
- egy harmadik felek által biztosított, bármikor változó klienskönyvtárakat kell tudni online le- és betölteni, és azzal a saját kódod összegyúrni, működtetni; weben pedig minden második weboldal használ ilyent, pl. a Facebook JS API-ja vagy valamilyen 3rd party JS framework személyében
Ez azért így ebben a formájában egyrészt nem teljesen igaz. A desktop progik nagy része szintén használ 3rdparty komponenseket, az pedig hogy ezek mennyire gyakran változnak, leginkább attól függ hogy a szállító mennyire értett a programtervezéshez, illetve hogy mennyire érdekli a visszafelé kompatibilitás.
több, egymástól tök független alkalmazás/-szolgáltatás együtt kombinálva hoz létre egyetlen egységként működő prezentációs réteget anélkül, hogy ehhez adataikat hozzáférhetővé tennék egymás számára; weben ugyanakkor rendkívül sok ilyen mashup alkalmazás van
Ja. És ez mennyire jelent csak dinamikus nyelveken megoldható új programozási feladatokat ?
van egy külön futtatókörnyezeted a prezentációs rétegben/hez meg van egy külön a backend alkalmazási logikádban/hoz, és ezek között kell eldöntened, hogy melyik feladatokat melyik oldalra szervezed, figyelembe véve a két réteg közötti korlátos áteresztőképességből és a halmozódó backend-oldali terhelésből adódó megfontolásokat is
Naponta. A 3 rétegű desktop progi már jó pár éve nem újdonság.
hogy ugyanannak a programnak kell a legkülönbözőbb működési környezetekben, processzorarchitektúrákon, feldolgozási kapacitás, valamint szintén eltérő képernyőméretek és beviteli módok mellett ugyanazt az magasfokú interaktív élményt biztosítani, és valóban képes is erre;
Nos, nem is nyújtják, és nem is nyújthatják. Egy komplex beviteli képernyőt normálisan, ergonomikusan csak fix felbontásra és adott beviteli formára tudsz megcsinálni. Lehet olyat csinálni ami minden felbontáson megy, de az minden lesz csak kényelmesen használható nem. És ehhez még csak nem is kell túl komplex dolgot csinálni, elég egy mezei hírportál - a legtöbb fix felbontáson megy, és külön csinálnak hozzá mobil verziót. És ez persze még csak a layout - az egyes platformok eltérő beviteli módjairól még nem is beszéltem.
Szóval ennek a magasfokú interaktív élménynek nem kicsit van marketing bullshit szaga. Lehet ilyet csinálni weben is, de az majdnem annyira platformfüggő lesz mint desktopon - azaz ami mögött van 1GB RAM, 1-2Ghz-es proci, 1024x768 pixel az nagyjából hozni fogja a felhasználói élményt. De a mobilon finoman szólva nem lesz a dolog ugyanaz, és nem csak a desktophoz képest, de a natív mobilos apphoz képest sem.
Azért ebbe a dologba az is belejátszhat, hogy a böngészőkben - hacsak nem használsz valami plugint (flash, silverlight, java applet, stb) csak a javascript az ami elérhető.
Na de a helyes kérdés az, hogy miért még mindig csak JavaScript van, mikor böngészőink már olyan régóta vannak, amióta a Windows-t kb. 4x írták újra szinte teljesen, legalább négy (de inkább öt) mobiloperációs rendszer generáció tűnt fel és múlt el, és kb. 500 új programozási nyelv született meg. Miért még mindig a JavaScriptet használjuk és miért dinamikus nyelvekben készül a webalkalmazások túlnyomó része - sőt, miért egyre inkább ebbe kerülnek átírásra még azok a megoldások is, amelyek korábban előfordított nyelvekre, VM-ekre, stb. épültek?
A válasz persze az, hogy azért, mert ezek a nyelvek és eszközök a legmegfelelőbbek a feladatra, és mert minden más nyelv és technológia (beleértve a fordított nyelveket és a bájtkód alapú környezeteket is) nem hoznak szinte semmit előnyt, hátrányt viszont annál többet ebbe a környezetbe. Hiszen még azt se lehet mondani, hogy nem voltak próbálkozások ezekre. Hiszen ott volt az ActiveX, a Java, a Native Code, stb. - és egyik se kellett a kutyának se. Ennek oka volt. És bár tudom, hogy az istendesktop-komplexusod azt mondatná veled, hogy ennek oka az volt, hogy a webfejlesztők mind hülyék és aki web közelébe kerül az mind elhülyül - de a valóság ezzel szemben az, hogy ezek a technológiák azért buktak mind el és szorultak vissza ha valaha is volt jelentőségük, mert azok a problémák amikre megoldást kínáltak vagy gyakorlatilag eltűntek (pl. teljesítményproblémák), vagy nem voltak képesek a problémák megoldására ígérteket beváltani (pl. Java VM folyamatosan sebezhető maradt, hiába volt bájtkód-validálás benne, és a csillió csava verzió - J2SE, J2ME, stb. - miatt nem volt igaz az egyszer megírom, mindenhol fut sem, stb.), vagy ugyan valóban jól oldottak meg egyes problémákat, cserébe azonban 1000x másikat keletkeztettek a JavaScript és a hasonló dinamikus megoldásokkal szemben (pl. a külön fordítási menet szükségessége, a futtatókörnyezet lassú indulása, nagy memóriaigénye, más forrásból származó komponensekkel történő összefűzés nehézségei, zártság, piaci érdekeknek alárendeltség, stb.)
Szóval a sztori nem ott kezdődik, hogy nincs lehetőséged a JavaScripten kívül bármi más technológiára építeni (bár egyébként van) - hanem, hogy miért nincs? Hát azért, mert ezen technológiák használatának komoly ára lenne az adott környezetben. És itt nem csak arra kell gondolni, hogy azért egy JavaScript motorhoz képest egy .NET futtatókörnyezet betöltése és beindítása a böngészőben mennyivel több erőforrást és időt enne el - de egyéb, abszolút nem technológiai megfontolásokra is, amiket azonban nem lehet az egyes technológiáktól elválasztani.
Pl. a C#-tól és a .NET-től nem lehet leválasztani azt, hogy a a MS technológiája, és hogy emiatt se a Google, se a Mozilla, de még az Opera és az Apple sem fogja a büdös életben soha támogatni. De ugyanez igaz visszafelé a Native Code-ra is. Vagy mondhattam volna a már óriási meglévő kódbázist, mint befolyásoló faktort, ami desktopon éppen úgy meghatározó abban, hogy a C/C++, egy lassan fél évszázados és ma már minden szempontból túlhaladott nyelv még mindig a legnépszerűbbek között van, mint ahogy weben is hiába jön egy hipercsúcsszuper új nyelv és hiába kerül be minden böngészőbe, ha nincsenek hozzá se frameworkök, se komponensek, se fejlesztőeszközök, se csillió kódrészlet és megkérdezhető szakember, akkor se lesz jobb megoldás a programok írására, mint a JavaScript, még nagyon de nagyon hosszú ideig.
Szóval - mint mondtam - oka van annak, hogy még mindig a JavaScript van a böngészőkben és hogy PHP-ben írják a legtöbb webalkalmazást. És ez az ok az, hogy ezek az eszközök ezekre a feladatokra és mindent egybeszámítva 100x jobb megoldást képesek kínálni (a szóban forgó feladatoknál felmerülő elsődleges prioritások vonatkozásában), mint a .NET, a C#, a Java, vagy akármi más új, egyesek által istenített és minden mások felett levőnek tekintett "csodafegyver". És ez nem fog máról holnapra sem nagyon változni.
Amúgy meg teljesen felesleges ezt a webes dolgot misztifikálni - lényegében semmi különleges nincs benne, semmi olyan programozási feladat nem jön szembe weben ami desktop környezetben nincs.
Ez persze abszolút nem így van. Pl. asztali környezetben elég ritkán van, hogy
- egy harmadik felek által biztosított, bármikor változó klienskönyvtárakat kell tudni online le- és betölteni, és azzal a saját kódod összegyúrni, működtetni; weben pedig minden második weboldal használ ilyent, pl. a Facebook JS API-ja vagy valamilyen 3rd party JS framework személyében
- több, egymástól tök független alkalmazás/-szolgáltatás együtt kombinálva hoz létre egyetlen egységként működő prezentációs réteget anélkül, hogy ehhez adataikat hozzáférhetővé tennék egymás számára; weben ugyanakkor rendkívül sok ilyen mashup alkalmazás van
- van egy külön futtatókörnyezeted a prezentációs rétegben/hez meg van egy külön a backend alkalmazási logikádban/hoz, és ezek között kell eldöntened, hogy melyik feladatokat melyik oldalra szervezed, figyelembe véve a két réteg közötti korlátos áteresztőképességből és a halmozódó backend-oldali terhelésből adódó megfontolásokat is; miközben minden webalkalmazás pontosan így működik és ilyen döntések elé állítja a fejlesztőt, minden egyes részfeladat, és az alkalmazás egésze vonatkozásában is
- hogy ugyanannak a programnak kell a legkülönbözőbb működési környezetekben, processzorarchitektúrákon, feldolgozási kapacitás, valamint szintén eltérő képernyőméretek és beviteli módok mellett ugyanazt az magasfokú interaktív élményt biztosítani, és valóban képes is erre; miközben webalkalmazásoknál ez elvárás, és viszonylag könnyen meg is oldható még a legextrémebb végletek vonatkozásában is,
- stb, stb, stb.
De te honnan is tudhatnál ezekről amikor webre még szinte semmit sem készítettél? Bár a helyes kérdés inkább az lenne, hogy ha ez így van, akkor miért akarod mindig osztani erről témáról (is) az észt, nulla tapasztalat mellett?
És annak az oka, hogy weben és webre senki nem C++-ban, C#-ban és Java-ban fejleszt, nem az, hogy a webre (is) dolgozó fejlesztők nem érik fel ésszel utóbbi nyelveket, hanem az, hogy az adott környezetben ezen nyelvek és technológiák használata sokkal, de sokkal kevésbé célszerű (sőt, egyenesen hátrányos és kontraproduktív), mint a dinamikusoké.
Azért ebbe a dologba az is belejátszhat, hogy a böngészőkben - hacsak nem használsz valami plugint (flash, silverlight, java applet, stb) csak a javascript az ami elérhető. Innentől kezdve hiába akarnál te bármilyen statikus előre fordított nyelvet, csak a javascript az ami minden böngészőben elérhető. Hiába használnék én C# nyelvet, ha csak js van.
Amúgy meg teljesen felesleges ezt a webes dolgot misztifikálni - lényegében semmi különleges nincs benne, semmi olyan programozási feladat nem jön szembe weben ami desktop környezetben nincs. Az hogy te aszinkron hívásokat használsz, hogy xml-ben érkező adatokat kezelsz már ezer éve létező dolog desktopon is. Ami a weben nehezítés az a bénácska html formátum, és a javascript. De maga a feladat ettől ugyanaz, csak a megoldásra használható eszközök választéka szűkösebb.
Már csak az kéne (visszatérve az alaptémához), hogy a Dart bytekód motorja bekerüljön a böngészőkbe, és a MS is csináljon egy C# --> kliens-byte-kód megoldást kliens oldali mini .Net környezettel (mint Dart lib készlet), aztán már kerek is lehetne az egész.
Már bocs, de ez újabb orbitális tudodmi.
Egyrészt a MS nyilván nem venné át a Google megoldását (mert az ő érdeke nem a nyílt web, hanem a Windows-függés), a Google és a Firefox meg nem venné át a MS megoldását (mert azzal a MS megoldását hozná helyzetbe és a Windows-függést erősítené a saját agendájával szemben). Tehát lehetne két platformra fejleszteni - ami mellesleg már most is adott. Ehhez nem kell se új szkriptnyelv, se bájtkód-motor.
A másik dolog, hogy bájtkód-alapú futtatásra te nyilvánvalóan úgy tekintesz, mint valami megváltóra - amitől minden automatikusan jobb lesz. Nyilván azt gondolod, hogy ha valami bájtkódban van, az sokkal gyorsabb, hordozhatóbb, biztonságosabb - ennél nagyobb tévedésben azonban nem is lehetnél. Attól ugyanis nem lesz se gyorsabb, se hordozhatóbb, se biztonságosabb semmi (mármint a dinamikus megoldásokhoz képest), hogy bájtkódra van fordítva. A bájtkód egyedül az előfordított nyelvek esetében teszi hordozhatóbbá, biztonságosabbá a kódot (a natív kódra fordításhoz képest), ill. magát a forrás tárgykóddá fordítását spórolja meg a futtatás helyén, ami azonban csak statikusan típusos, előfordított nyelvek esetében aktuális.
Dinamikus nyelvek esetében azonban egyedül a tokenizáció spórolható meg bármiféle előfeldolgozással, ami viszont nem tétel amúgy sem - pláne nem a weben, ahol nagyságrendekkel lassabban áramlanak lefelé az adatok a kábelen, mint ahogyan azokat tokenizálni lehet. Tehát dinamikus szkriptnyelvek esetében bármiféle bájtkód és arra történő előfordítás beiktatása teljesen felesleges lépés lenne, mert a nyelv maga nem igényli, a feldolgozás és a letöltés pedig nem lenne észlelhetően gyorsabb tőle. Akkor meg minek?
Ráadásul hiába is lehetne (mint ahogy nem az) bármiféle előfordított bájtkód a JIT értelmezett és fordítottnál gyorsabb, mert az adatkezelésének továbbra is dinamikusnak kellene lennie. Hiszen a webnek a dinamikusság a lényege, és az, hogy a teljes webes élmény egymástól teljesen függetlenül fejlesztett, elért, terjesztett és kiszolgált tartalmak kombinálásából áll össze. Ez meg (ti. hogy az adatfeldolgozásnak továbbra is dinamikusnak kellene lennie) azt jelentené, hogy a statikus, előfordított nyelvek és technológiák minden az előre eldöntött ill. eldönthető típusokkal kapcsolatos előnye, optimalizációs lehetősége itt nem lenne kihasználható. Tehát hiába írnánk meg a kódot C#-ban és fordítanánk le bájtkódra, majd natívra, mert ettől egy dinamikus JSON válasz feldolgozása vagy egy JSON kérés összeállítása, a DOM fa bejárása, a HTML elemek attribútumainak állítgatása, stb. ugyanannyi időt igényelne, mint ha pl. JavaScript-ben írjuk meg ugyanezt. Mert a sok időt ezen dinamikus adathalmazok manipulálása emészti fel, ami attól még ugyanígy dinamikus maradna és ugyanígy dinamikusan kellene feldolgozni, ha a kód maga esetleg statikus lenne.
Pont ezek az okai annak, hogy a Google maga is úgy döntött, hogy a Dart sem bájtkód alapú "binárisokkal" fog dolgozni, hanem a Dart programok forrásban fognak áramolni a gépekre - és csak ott kerülnek majd feldolgozára, JIT fordításra, és egy a nyelv-specifikus VM-en futtatásra -, pont úgy, mint ahogy az a JavaScript (vagy akár szerveroldalon bármelyik hétköznapi PHP installáció) esetében is történik.
---
Tudom, hogy itt minden JavaScript-fóbiás - annak ellenére, hogy lófüttyöt sem fejlesztett még webre - meg van róla győződve, hogy ő mindenkinél mindent jobban tud, általában és persze ezen a specifikus területen is; de sajnos az az igazság, hogy ennek nagyjából kb. a fordítottja igaz. És annak az oka, hogy weben és webre senki nem C++-ban, C#-ban és Java-ban fejleszt, nem az, hogy a webre (is) dolgozó fejlesztők nem érik fel ésszel utóbbi nyelveket, hanem az, hogy az adott környezetben ezen nyelvek és technológiák használata sokkal, de sokkal kevésbé célszerű (sőt, egyenesen hátrányos és kontraproduktív), mint a dinamikusoké. Mert utóbbiak illeszkednek jobban a web szerkezetéhez és az ott felmerülő feladatokhoz. Értelmes fejlesztő meg feladathoz választja az eszközt, tetszik tudni, kedves kalapácsos emberek...
Ez az egész, a .NET, a C#, a fordítás, a statikus típuskezelés, a bájtkód és hasonló - adott célra - őrültségek a webre erőltetésével kapcsolatos vágyálmaitok arról szólnak, hogy ti nem tudtok vagy legalábbis nem akartok más technológiákkal dolgozni, azokhoz érteni, azokat megtanulni, ezért legyen szíves valaki más az általatok megszokottakat ráerőltetni a webre - meg mellesleg minden arra fejlesztő emberre és azt elérő felhasználóra is. Mindezt csak azért, hogy még véletlenül se csökkenjen esetleges piaci, szakmai értéketek annak ellenére sem, hogy az elmúlt egy-másfél-két évtizedben is alig tanultatok valamit azon a szűk területen és platformon kívül amin éppen dolgoztok- és most meg már pláne nem akartok még újabb dolgokat megtanulni.
A dolgok azonban nem így működnek. A világ abba az irányba megy, amerre azok viszik akik tudnak és hajlandóak tanulni, energiát fektetni az új dolgok felfedezésébe és megalkotásába. Akik meg nem, azok lemaradnak és egyre kevesebbet fognak (piaci értelemben) érni - egészen addig, amíg már senkinek sem fognak kelleni. Az hogy ez a két csoport közül melyikbe fogtok tartozni, az rajtatok múlik. Azzal ugyanakkor, hogy elutasítotok minden új irányt és általatok nem ismert technológiát, automatikusan a második útra kárhoztatjátok magatokat.
Ha a MS és a Google képes lenne közös érdekből összefogni ebben (persze mindketten a saját térfelüket preferálva/megtartva és saját érdekükben), akkor az gyakorlatilag eldöntött tény lehetne...
Már csak az kéne (visszatérve az alaptémához), hogy a Dart bytekód motorja bekerüljön a böngészőkbe, és a MS is csináljon egy C# --> kliens-byte-kód megoldást kliens oldali mini .Net környezettel (mint Dart lib készlet), aztán már kerek is lehetne az egész
De remélhetőleg új asp.net alapú rendszert már csak mvc/razor alapon indítanak (ha a hozzáértőknek van szava a cégnél )
Tisztább, biztosabb, szárazabb érzés
Valahogy csak sikerült a MS-nál is visszakanyarodni a web lényegéhez, nem megerőszakolva azt (vagyis az előnyeit kihasználni), miközben a .Net és C# világ előnyeit is élvezhetjük.
Én is még csak ismerkedem vele, belekapkodok dolgokba, de tetszetős...
Már csak az kéne (visszatérve az alaptémához), hogy a Dart bytekód motorja bekerüljön a böngészőkbe, és a MS is csináljon egy C# --> kliens-byte-kód megoldást kliens oldali mini .Net környezettel (mint Dart lib készlet), aztán már kerek is lehetne az egész.
Nekem is nagyon tetszene, de sajnos ahol most melózom webforms van - szerencsére nekem viszonylag ritkán jut belőle, én jellemzően inkább desktop cuccokat faragok. Ahol máshol néztem ASP.NET-es melókat ott sem mvc volt.
Elég sok webformsos projekt készült amiket persze nem dobnak ki, ráadásul sokan csak ezt ismerik.
