Az XAML is lényeges (nem csak a HTML5)

Az XAML is lényeges (nem csak a HTML5)
2011-06-24T14:51:50+02:00
2011-07-20T12:36:42+02:00
2022-10-26T10:30:34+02:00
  • Még annyit, hogy adni kell még ennek a HTML5-nek 1-2 évet, hogy igazán kinőjje magát. Most még annyira az elején vagyunk, hogy amikor esténként olvasgatom ezt a doksit:

    HTML5 Canvas Living Standard

    akkor egy este folyamán akár többször is real-time feljön egy popup, hogy az előző másodpercben változott a standard, frissítem-e? Ok, a Canvas már elég mature, csak jelentéktelen módosítások vannak általában a doksiban, de azért ez mutatja, hogy eléggé az elején vagyunk a dolgoknak.
    Mutasd a teljes hozzászólást!
  • Szvsz.:

    A demo azért ennyire lassú, mert szirul van megírva.

    Ugye a HTML5 gyüjtőfogalom, marketing-fogalom.
    Egy GUI prezentációt technikailag ugye meg lehet valósítani 'hagyománoysan' DOM-al, meg tisztán Canvassal, vagy lehet keverni a kettőt. A DOM-osdi sebességét szvsz. profi 'production' cuccoknál kell lemérni, mint a Google cuccai: gmail, google docs, stb...

    A canvas nem mérhető más RIA rendszerekhez, hiszen ez csak egy rajzoló API. Amúgy egy normáls tisztességes modern rajzoló API: vonalakkal, körívekkel beziergörbékkel logikailag path-okat definiálsz, amiket aztán stroke-olsz, vagy fillezel. Fillezhetsz és strokeolhatsz is gradienttel, patternnel, vagy sima színnel. Ugyanígy szövegeket is úgy rajzolhatsz, hogy gradientet, patternt, vagy színt használsz, és minden fontot használhatsz, amit CSS-ből elérnél. Lehet image-eket is kirajzolni, strechelni, lehet pixelenként módosítani a cuccot byte-tömb jelleggel, lehet image-be renderelni (cacheléshez jó). Van transzformációs mártix, transzparencia kezelés, alpha operációk, clipping region definiálás, blurred-árnyék megadás. Kezdik ezt a cuccot hardvegyorsítani is, nem lesz ezzel gond, (egyelőre a fontrajzolás minőségénél látok kisebb problémát, a böngészők nem pont úgy rajzolják ki a fontokat a canvason mint html-ben. Félreértés ne essék, van antialisaing (minden canvas operáció anti-aliased), de 2011-ben már nagyon magasak az elvárások, és ha jól láttam subpixel-rendering vagymi nincs.)

    Lehet a neten találni benchmarkokat az API sebességéről, itt messze nem arról van szó, hogy olyan lassú lenne, ami pl. a fenti demo-t indokolná. (A Canvas API is azon a szinten mozog, hogy 30-40-50 FPS-el viszonylag összetett cuccokat lehet kinyomni fullscreenre, ami ha lassabb is egyes natív technikáknál, messze nem a lenti demo szintje.)
    Szvsz jelenleg még valamivel lassabb mint a Flash, de ez böngészőfüggő is és állandóan változik: mindenesetre itt 2-szeres szorzónál nagyobb különbség nincs, sok helyen már fej fej mellett vannak. Példa benchmark:

    Flash vs HTML5 Performance (Updated January 2012)

    A Canvas-ra még kevés kód épül. Namost ha valaki felépít egy GUI frameworköt rá, akkor a sebesség nagyon azon múlik, hogy ez a framework hogyan van megírva. Gondold el pl., hogy mennyire nem mindegy, hogy egy nagyobb szöveg scrollozásakor újrarajzolja egyesével minden frameben az összes látható betűt, vagy időnként image-be renderel, majd annak a megfelelő range-it rakja ki scrollozáskor. stb...

    Namost a legtöbb ember szerint eleve őrültség Canvas felé GUI frameworkot írni. Ez egy rizikós terület, egyelőre 'toy'-ként tekint rá mindenki. Ebből következik, hogy nincs még komolyanvehető ilyen rendszer (kezdemények vannak). Ez egy űr, és ebből következik, hogy én elkezdtem egy ilyet csinálni szabadidőmben.
    Mutasd a teljes hozzászólást!
  • Ez így van!
    Mutasd a teljes hozzászólást!
  • Üdv Mindenkinek!

    Tudom, hogy most kapok a fejemre, de akkor is...

    Az MXML is legalább olyan jó, mint vetélytársai!
    Mutasd a teljes hozzászólást!
  • A böngésző nem csinál gyorsítótárazást ezekre az ikonokra? Mert hogy elég lassúcska ez akkor is amikor másodszor mész rá.

    Idézek magamtól: "úgy néz ki elég szutyok módon van megírva ez a dolog, így még akkor is generál oldalletöltéseket, ha már jártál a menüben (és így elvileg nincs letöltendő új erőforrás)."

    Valami eseményeket küld vissza a szerveroldalnak POST kérésekben. Nem látom, hogy ez tényleg szükséges lenne - de ő mindenesetre visszaküldi, így csinálja, és emiatt jó lassú is még a menüben kolbászolás is. Nyilván valami igen kényelmesen programozható, csak éppen a kliensoldali élményre abszolút nem optimalizált frameworkre épül, vagy ki tudja. A lényeg mindenesetre, hogy ez egy nagyon rossz példa a HTML+JS oldalakon elérhető teljesítményre. Mert ennél már egy évtizede is tudtunk reszponzívabb oldalakat fejleszteni az akkori technológiákkal és böngészőkben (pl. IE6) is - a HTML5 (amihez egyébként nagyjából nulla köze van ennek a demónak) pedig még sokkal tovább gyorsított ezen igen sok területen.

    A classic-cal már elmegy, kb. hozza azt a szintet amit 10 éve egy desktop levelező progi, csak kicsit lassabb mint azok az akkori gépeken. Ja, és ez itt a fejlesztői gépem...

    Ismét idézek magamtól: "ez önmagában 200-250ms minimum, amitől már eleve elveszik a desktop reszponzivitás érzése. De nem azért, mert HTML+JS-ben működik a dolog - hanem mert távolról tölti le az erőforrásokat".

    Lehetne a világ legnagyobb szuperszámítógépe is amin futtatod, azon is ugyanilyen lassú lenne. És ugyanilyen lassú lenne akkor is, ha C#-ban lenne megírva. Mert hogy a késleltetést amit tapasztalsz a hálózati elérés lassúsága okozza - nem a kliensoldali nyelvek/eszközök (HTML+JS) lassúsága. De ezt is legalább kétszer leírtam már.

    Persze ha valakinek lövése sincs a témához, soha a büdös életben nem írt webalkalmazást (max. FrontPage-ben szerkesztett egy honlapot, vagy felrakott egy Drupalt), az nehezen érti miről van szó...
    Mutasd a teljes hozzászólást!
  • A böngésző nem csinál gyorsítótárazást ezekre az ikonokra ?
    Mert hogy elég lassúcska ez akkor is amikor másodszor mész rá. A flow view meg igen hülye vicc. A classic-cal már elmegy, kb. hozza azt a szintet amit 10 éve egy desktop levelező progi, csak kicsit lassabb mint azok az akkori gépeken. Ja, és ez itt a fejlesztői gépem...
    Mutasd a teljes hozzászólást!
  • Meg azt is tedd hozzá, hogy ezzel milyen produktivitással tudod megírni az ügyviteli rendszeredet egy winforms/LINQ-hoz viszonyítva.

    Ez tisztára csak kódgenerátor kérdése.

    Ez az ötlet már Android-on is megbukott, visszatérnek lassan a C++ ra.

    Nem igazán látom ezt a visszatérést. Más kérdés, hogy adnak natív C/C++ API-t is, ami leginkább azért jó, mert így szépen lehet portolni a linuxos projekteket, lásd DosBox, GemRB, Open Heroes2, stb. Más kérdés, hogy ez aztán cserébe jó procifüggővé is teszi a robotot, az alkalmazások nagy része csak arm-on fut.
    Mutasd a teljes hozzászólást!
  • Nézd meg mielőtt osztod!

    Mert gondolod nem néztem meg, mi? Magadból indulsz ki?

    A UI sebességről beszélek, nem arról, hogy milyen gyorsan jönnek le a levelek.

    Nem beszélhetsz az UI sebességéről, mert hogy minden kattintás generál legalább egy új oldalletöltést. Még a menük megnyitása is - hiszen azokhoz is le kell tölteni pl. a kis ikonokat. Sőt, úgy néz ki elég szutyok módon van megírva ez a dolog, így még akkor is generál oldalletöltéseket, ha már jártál a menüben (és így elvileg nincs letöltendő új erőforrás). Ez önmagában 200-250ms minimum, amitől már eleve elveszik a desktop reszponzivitás érzése. De nem azért, mert HTML+JS-ben működik a dolog - hanem mert távolról tölti le az erőforrásokat.

    Nyilván szarul is van megírva az egész, de még ennek ellenére is teljesen egyértelmű, hogy ha ugyanilyen szuboptimális módon megírva, de helyben futna teljesen, lokálisan töltené be az erőforrásokat, már az önmagában felgyorsítaná egy desktop alkalmazás szintjére. És hogy ezzel összefüggésben egy C# desktop alkalmazás is ugyanilyen szutyok lassúnak és unreszponzívnak tűnne ha neki is mindig távolról kellene lehúznia még a menüikonokat is.

    Ott van ez a lapozóka nézet, vagy mi a bánat.

    Na ez az a mód amit soha senki a büdös életben nem fog használni. Nyilván eye-candy-nek rakták be, de a jelentősége nulla. Vagy annyi kb. mint Aero-ban a 3D-s Task Switchernek.

    HTML5 Canvas.

    Nem HTML5 Canvas, hanem -moz-transform meg -webkit-transform. Utóbbiaknak semmi köze előbbiekhez. Na, akkor ki is az aki nem nézi meg a dolgokat mielőtt elkezdi osztani?

    Iszonyat tetű lassú, össze se lehet hasonlítani egy SL vagy ne adj' Istend WPF programmal, pedig a Firefoxban van hardveres gyorsítás.

    Mindenki tudja, hogy a Firefox hardveres gyorsítása egy nulla. Azt még a Chrome is leveri. IE9-ben - a "milyen gyors lehet a hardveresen gyorsított megjelenés" kérdésben egyetlen relevánsnak tekinthető böngészőben - meg ez a funkció nem megy.

    Szóval még a fentitől elvonatkoztatva is - hogy ti. ennek semmmi köze egy normális levelezőhöz, és épeszű ember a büdös életben nem használná ezt a nézetet, mert egyszerűen használhatatlan így egy levelezőprogram - is nyugodtan kijelenthetjük, hogy az ebben a módban tapasztalt sebesség nem tekinthető reprezentatívnak abban a vonatkozásban, hogy mi érhető el webes technológiákkal ezen a téren. Mert ennél sokkal gyorsabbra is meg lehet csinálni ezt is, már ma is.

    Vagy ott van egy egyszeri lista (a levelek). Szinte látni a pixeleket, ahogy rajzolja ki egymás után, ahogy görgetem.

    Hát, ha nálad ez így néz ki, akkor megint csak azt tudom mondani, hogy nyilván egy szutyok böngészőt használsz. IE9-ben teljesen sima; ránézésre meg nem mondom, hogy böngészőben vagy natív alkalmazásban látom. Csúnya is lenne ha lassú lenne, lévén teljesen alap HTML-elemekből van felépítve az egész.

    Az egyetlen dolog ami rontja az élményt az a levelek első megnyitása, amikor lehet látni ahogyan felépül az előnézeti ablak - de ennek megint az az oka, hogy távolról húzza le a képeket, nem pedig lokálisan éri el. Ez ugyanilyen lassú lenne C#-ban megírva is ha így működne - és ugyanolyan gyors lenne HTML5-ben is, mint egy natív Outlookban ha helyileg lennének elérhetők ugyanazok az állományok. Főleg ha pl. előtöltené legalább a fix képeket ez a szutyok.

    Szóval a fentiek alapján nyugodtan kijelenthetjük, hogy ennek a demónak a lassúsága nem a HTML-nek és a JS-nek, hanem annak köszönhető, hogy minden erőforrást távolról ér el. Ezen kívül elég láma módon is van megírva - de jó eséllyel még ennek ellenére sem tudnád különböztetni pusztán reszponzivitás alapján egy natív levelezőklienstől ha ő is helyben tárolná azokat az adatokat amiket egy natív kliens is. Amit HTML5-ben mellesleg szintén simán meg lehetne már csinálni (hiszen van local storage, van web sockets, minden ami egy nem kifejezetten vékony-kliens normális levelezőklienshez kell).
    Mutasd a teljes hozzászólást!
  • Ennek köze nincs a HTML5-höz. Egyszerűen nem lokálisan éri el a leveleket. Ilyen körülmények között aztán csinálhatnál akármit és akármiben, ugyanilyen lassú lenne, SL-ben, C#-ban, bármiben.

    Ha lokálisan blablablabla blabla blabla bla blabla blabla


    Nézd meg mielőtt osztod! A UI sebességről beszélek, nem arról, hogy milyen gyorsan jönnek le a levelek.

    Ott van ez a lapozóka nézet, vagy mi a bánat. HTML5 Canvas. Iszonyat tetű lassú, össze se lehet hasonlítani egy SL vagy ne adj' Istend WPF programmal, pedig a Firefoxban van hardveres gyorsítás.

    Vagy ott van egy egyszeri lista (a levelek). Szinte látni a pixeleket, ahogy rajzolja ki egymás után, ahogy görgetem.

    Mutasd a teljes hozzászólást!
  • LC: "Nézd, ha én mint fejlesztő nekiállok html5/js alapon fejleszteni, akkor gyakorlatilag 100%-os biztonsággal multiplatformot fogok csinálni"

    Na, na! Még tedd hozzá a CS3-at is és azt, hogy extensionökkel részben böngészőfüggetlen (és nem platformfüggetlen) alkalmazás írható, ami távolról közelíti a desktop szintjét, de elérni nem nagyon fogja. Meg azt is tedd hozzá, hogy ezzel milyen produktivitással tudod megírni az ügyviteli rendszeredet egy winforms/LINQ-hoz viszonyítva.

    "a .NET-et, akkor szvsz annak legalább olyan általánosan elfogadott technológiának kell lennie mint a C++, azaz le kell választani a MS-től - úgy hogy azért az MS-féle .NET legyen az "igazi". Szvsz még így maradhatna leginkább életben a MS hosszabb távon."

    Ez az ötlet már Android-on is megbukott, visszatérnek lassan a C++ ra.

    Nacsa Sándor:
    "
    MS egyetlen igazi esélye az lenne, ha azt csinálná amit a 90-es években - azaz a saját pályájára terelné a játékot.


    Lehet, hogy éppen erre megy ki a HTML5 játék."

    Azért egy Angry Birds-öt ne tekintsük a windows-os játékok zászlóshajójaként. Inkább a Rage és a Crysis van ezen a szinten az a szint meg igen messzi van a WebGL JS-től.
    Mutasd a teljes hozzászólást!
  • Találtam egy fafa HTML 5 desktop "like" demot. Azé ezen nagyon látszik, hogy ez a HTML5 még igen-igen messze van mind sebességben, mind reszponzivitásban, mind pedig krosszplatformságban attól, amit ma egy igazi desktop program (+ SL, +AIR) tudogat.

    Ennek köze nincs a HTML5-höz. Egyszerűen nem lokálisan éri el a leveleket. Ilyen körülmények között aztán csinálhatnál akármit és akármiben, ugyanilyen lassú lenne, SL-ben, C#-ban, bármiben.

    Ha lokálisan tárolná a leveleket, ahogy egy normális desktop levelező teszi, biztos vagyok benne, hogy meg nem lehetne különböztetni sem sebességben, sem reszponzivitásban egy hagyományos asztali programtól.

    Ez (ti. pl. egy levelező) tipikusan az a dolog amit nagyon effektíven ls hatásosan meg lehet csinálni HTML+JS alapokon is.
    Mutasd a teljes hozzászólást!
  • Nem működne lassabban az extjs-el
    Mutasd a teljes hozzászólást!
  • Még ennél is 72x lassabban.

    Messze még a desktop quality ...
    Mutasd a teljes hozzászólást!
  • A középső résztől (ahol kattintgatni kell a lapokra, és ami marha lassú is ff alatt) eltekintve meg lehetne csinálni extjs-el is ezt a demót, nem kell ehhez html5. És úgy még több böngészőben is működne....
    Mutasd a teljes hozzászólást!
  • Találtam egy fafa HTML 5 desktop "like" demot. Azé ezen nagyon látszik, hogy ez a HTML5 még igen-igen messze van mind sebességben, mind reszponzivitásban, mind pedig krosszplatformságban attól, amit ma egy igazi desktop program (+ SL, +AIR) tudogat.

    IE9-ben nálam képes lefagyni. De amúgy brózertől függetlenül - hardveres gyorsítás ide vagy oda - betegesen tetű az igazi Outlookhoz képest.
    Mutasd a teljes hozzászólást!
  • Más források szerint meg nem.

    IDC: Windows Phone 7 Will Surpass iOS As Number 2 Platform By 2015

    Osztán a disznó, mennyit fog fialni ? Mióta van piacon a WP7 ? Mennyit adtak el eddig ?

    Ennek a felvetésednek semmi értelme, hiszen pont a natív játékpiac az egyik, ahol gyakorlatilag nincs versenytársa a Windows-nak - és ahol amúgy sem tudná belátható időn belül utolérni senki, egyik nagy (?) konkurense közül sem.

    Ja. Csak amikor elkezdtek terjedni a benzinmotorok, nem sokat ért az hogy kinek nincs versenytársa a gőzautók piacán.

    Ennek sincs semmi értelme. Nem csak azért, mert pont azt a kérdést ill. problémát vetné, amit állandóan nyomatsz (igaz, te teljesen téves kontextusban, és ott teljesen hamisan), hogy ha más platform is tudja ugyanazt, mint a Windows, akkor miért venné meg bárki a Windows-t és miért kötné magát bármilyen MS-implementációhoz

    Lásd wine vs XP. Ha megnézed a wine appdb-t akkor láthatod hogy igen sok minden tökéletesen fut - de azért a userek inkább XP-n futtatják a win32-es programjaikat.

    de azért is, mert pont a Mono/Moonlight bizonyítja, hogy a gyakorlatban nulla a jelentősége annak, hogy elméletileg más platformokra, alternatív implementációkban is megvalósítható, sőt, elérhető egy olyan dolog, mint a .NET és a Silverlight. Mert ennek ellenére nem valósul meg a gond nélküli hordozhatóság a platformok között (ehhez túl átfogóak és sokrétűek ezek a frameworkök, és túl nagyok a különbségek a befogadó gazdarendszereik között)


    A mono pont annyival rosszabb mint a .net mint a gnu classpath volt a SUN-os javához képest. Winformsos app simán elmegy amíg nem használsz valami elvetemült code obfuscationt, illetve vagy databindinget (az nem teljesen jól van implementálva) vagy natív windows dll-t. WPF nincs, WCF részben van, Moonlight hulladék, ASP.NET webforms van, MVC 1-2 van, újabban állítólag 3 is. És ami a lényeg: C# 4.0 van. Ami nagyon hiányzik az egy normális ORM, bár elvileg az NHibernate működik vele.

    Azaz elvileg a mono képes labdába rúgni - gyakorlatilag viszont belátható időn belül nem fogja beelőzni a microsoftos .NET-et, addigra viszont a MS tud valami olyat lépni amit aztán a mono-nak követnie kell.

    Viszont egy hosszú távú fejlesztési döntésnél nagyon sokat nyom a latba hogy az általam használt technológia alapjai openszorszosak-e vagy nem. Nem véletlenül használnak a bankok javát - arról tudni lehet hogy bármi történik bármivel, a java motor forráskódja már ott van a széfjeikben, azaz véges sok erőforrás felhasználásával portolni lehet a cuccot ahová akarják. A létük nem függ a MS lététől - legalábbis elméletben.

    A másik dolog pedig az, hogy ha sikerülne a mono-t *nix körökben elfogadott technológiává tenni, akkor onnan is sok fejlesztőt csábíthatna át a MS a saját térfelére - akik most python, java, C++, stb. nyelvekben nyomulnak linuxon. Ha a MS talpon akarja tartani a .NET-et, akkor szvsz annak legalább olyan általánosan elfogadott technológiának kell lennie mint a C++, azaz le kell választani a MS-től - úgy hogy azért az MS-féle .NET legyen az "igazi". Szvsz még így maradhatna leginkább életben a MS hosszabb távon.
    Mutasd a teljes hozzászólást!
  • Nézd, ha én mint fejlesztő nekiállok html5/js alapon fejleszteni, akkor gyakorlatilag 100%-os biztonsággal multiplatformot fogok csinálni, mivel a desktopon is több mint 50% a nem IE-t használók száma

    Ezt jól kiszámoltad. Még mobilt beleszámolva is 53.68%-a az IE részesedése (csak desktopon nyilván még nagyobb). Így el nem tudom képzelni, hogy hogyan maradhat "több mint 50% a nem IE-t használók" részére a 100%-ból. De te majd biztos elmagyarázod.

    Ezzel szemben a WP7 valahogy sehogyan sem akar terjedni

    IDC: Windows Phone 7 Will Surpass iOS As Number 2 Platform By 2015

    Szvsz az MS egyetlen igazi esélye az lenne, ha azt csinálná amit a 90-es években - azaz a saját pályájára terelné a játékot.

    Ennek a felvetésednek semmi értelme, hiszen pont a natív játékpiac az egyik, ahol gyakorlatilag nincs versenytársa a Windows-nak - és ahol amúgy sem tudná belátható időn belül utolérni senki, egyik nagy (?) konkurense közül sem. Tehát ez az egyik (ha nem egyetlen) olyan terület, ahol abszolút nincs nyomás alatt a Microsoft - vagy legalábbis nem a szoftverfronton.

    Ehhez persze engedményeket kell(ene) tennie, Pl. a .NET tájékán (különféle garanciák a mono/moonlight projekt felé, a C#4.0 szabványosítása és a szabvány használatának ingyenessé tétele, stb).

    Ennek sincs semmi értelme. Nem csak azért, mert pont azt a kérdést ill. problémát vetné, amit állandóan nyomatsz (igaz, te teljesen téves kontextusban, és ott teljesen hamisan), hogy ha más platform is tudja ugyanazt, mint a Windows, akkor miért venné meg bárki a Windows-t és miért kötné magát bármilyen MS-implementációhoz, de azért is, mert pont a Mono/Moonlight bizonyítja, hogy a gyakorlatban nulla a jelentősége annak, hogy elméletileg más platformokra, alternatív implementációkban is megvalósítható, sőt, elérhető egy olyan dolog, mint a .NET és a Silverlight. Mert ennek ellenére nem valósul meg a gond nélküli hordozhatóság a platformok között (ehhez túl átfogóak és sokrétűek ezek a frameworkök, és túl nagyok a különbségek a befogadó gazdarendszereik között), amelyek közül a Windows-on kívüliek amúgy is elenyészőek fizetőképes kereslet szempontjából.
    Mutasd a teljes hozzászólást!
  • az MS egyetlen igazi esélye az lenne, ha azt csinálná amit a 90-es években - azaz a saját pályájára terelné a játékot.


    Lehet, hogy éppen erre megy ki a HTML5 játék. Ahhoz ugyanis semmi kétség sem fér, hogy a már kiforrott XAML szabványként való keresztülvitelére a W3C révén csak akkor van esélye, ha egy ilyen lépés előtt maximalizálja a HTML5 melletti elkötelezettségét.

    Egyébként, vajha miért nyilvánítja a WebGL-t még nem elég érettnek ahhoz, hogy megjelenjen vele az IE-ben?

    ... a részletek és mélységek egészen más Microsoft előnyszerzési törekvéseket mutatnak, szvsz.

    Várjuk meg a szeptembert ...
    Mutasd a teljes hozzászólást!
  • Nézd, ha én mint fejlesztő nekiállok html5/js alapon fejleszteni, akkor gyakorlatilag 100%-os biztonsággal multiplatformot fogok csinálni, mivel a desktopon is több mint 50% a nem IE-t használók száma + ott van az IOS, az IPhone/IPad, az Androidos telefonok és tabletek. Ezzel szemben a WP7 valahogy sehogyan sem akar terjedni - pedig tényleg nem rossz kis cucc. Ezzel együtt, szvsz annak a realitása hogy a MS az IE kapcsán platformspecifikus API-kkal meg tudja fogni a fejlesztőket, lényegében 0.

    Azért pedig hogy az IE-n _esetleg_ lesznek dolgok amik jobban működnek mint Pl. Chrome alatt kétlem hogy tömegesen arra csábítanák a népeket hogy win8 alapú gépeket vegyenek ChromeOS alapú helyett - de szvsz még arra sem hogy a win8-on ne Chrome-ot használjanak. Ahogy most is egyre több a Chrome és egyre kevesebb az IE felhasználó.

    Szvsz az MS egyetlen igazi esélye az lenne, ha azt csinálná amit a 90-es években - azaz a saját pályájára terelné a játékot. Ehhez persze engedményeket kell(ene) tennie, Pl. a .NET tájékán (különféle garanciák a mono/moonlight projekt felé, a C#4.0 szabványosítása és a szabvány használatának ingyenessé tétele, stb). Akkor kb. ugyanaz menne mint a wine vagy a jdk vs gnu classpath esetén. Ez persze nem garancia a sikerre, de egy nyílt pályán ahol az ellenfél egy multik által agyontámogatott FOSS megoldás szvsz a windowsnak nem sok esélye lesz.
    Mutasd a teljes hozzászólást!
  • felületesen lehet csak ilyen véleményt mondani -- a részleteket és a mélységeket kell tanulmányozni
    Mutasd a teljes hozzászólást!
  • Kétlem hogy annyival jobbak tudnának lenni hogy azért vegyen valaki win8-as tabletet mondjuk Apple vagy Android vagy Chrome helyett mert jobb az IE mint a Chrome vagy a Safari.

    Viszont egy új bóngészőháború - és ezzel a böngészők további fejlődése - csak a windows pozícióit gyengíti. Ezért mondom hogy a legjobb húzás az lenne ha kidobnák az egész IE projektet a fenébe, illetve csinálnának egy KParts alapú, openszorsz javascript motoros cuccot hogy mégis legyen valami IE néven, vagy openszorszosítanák az egészet és hagynák a francba. Böngészőfronton a MS nemigen nyerhet.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy igazad van, és úgy érezték, hogy már nincs más választásuk. Valszeg a 'dupla vagy semmi' stratégiát választották: nyomják bele az erőforrásokat, és megpróbálják valóban a legjobb böngészőt elkészíteni. (szabvány API-val, de mondjuk a leggyorsabbat, a legszebben fontot rajzolót stb...)
    Lehet, hogy az a jelszó, hogy ha az emberek az IE mellett maradnak, akkor windowson maradnak.
    A Microsoftnál nem az első eset, hogy katonákat csoportosítanak egy jó kis böngészőháborúba. Úgy tudom, hogy amikor a web hajnalán végre észbekaptak, és megkezdődött az első böngészőháború, akkor rengeteg szenyor fejlesztőt állítottak böngészőfejlesztő-csatasorba.
    Mutasd a teljes hozzászólást!
  • A html5 jövője soha nem volt bizonytalan. A weben már rég nem a MS az úr hanem a google. Vagy implementálja a html5-öt az IE-ben vagy még többen váltanak Chrome-ra.

    Szerintem volt egy olyan naiv elképzelésük, hogy ok legyen html5 és javascript, de tegyünk bele MS-specifikus dolgokat. Ezzel csak az a gond, hogy ha valaki html5/js-sel szívatja magát, akkor az bizony már nem fog MS specifikus dolgokat használni csak azért hogy csak ie alatt működjön a mutatvány.

    Ahogy már írtam: az MS nyugodtan akár le is állíthatná az IE fejlesztését. A chrome és a fox és az opera mindig is elérhető lesz windows alatt, a html5-ön pedig úgy sem fognak tudni túllépni, mert a legtöbb tartalom esetén a multiplatform (IPad és társai) lényegesebbek mint a csilli-villi.
    Mutasd a teljes hozzászólást!
  • Ez az egész ügy vicces: a Microsoft marketingesei nyomatnak valami felhasználóknak szóló marketingrizsát, mi fejlesztők, akik megérdemelnénk a konkrétabb szakmai információkat, meg találgatjuk, hogy a marketingesek mire is céloztak...

    Szvsz. arról van csak szó, hogy az IE9-et ésaz IE10-et úgy próbálják marketingelni, hogy szabványkövető, de egyben 'jól kihasználja a hardvert és a oprendszert'.
    Pl. mondok egy példát, mert nyakig vagyok a Canvas-ban: pl. a canvas.filltext függvény tekintetében valóban az IE9 a legfejlettebb böngésző jelenleg, a leggyorsabban rajzolja a szövegeket és a legjobb minőségben. Láthatóan, egyértelműen jobb minőségben, mint a többi böngésző.
    Esetleg azt tudom még elképzelni, hogy valamiféle windowshoz kapcsolódó js API-kat is benyomnak a böngészőbe. (mittudomén clipboard elérés API vagy ilyesmiket tudok elképzelni, bár valami clipboard elérés már van az IE-ben, sokmindenre meg van HTML5 szabvány, szal a franc tudja, csak találgatok én is.)

    Ami hosszútávú trendként igaznak tűnik és engem érint: az MS valamiért elég komolyan veszi a HTML5-öt (talán meg akarja nyerni a második böngészőháborút azzal, hogy a legfejlettebb, legjobban programozható böngészőt akarja nyújtani) ezért a HTML5-nek van jövője. Ez persze nem jelenti azt, hogy nem fogja nyomni tovább a WPF-et, meg a Silverlightot is, de amíg nem volt biztos, hogy a HTML5-öt komolyan veszi, addig a HTML5 jövője bizonytalan volt szvsz.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Install Ubuntu on my PC
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Azt hiszem, hogy 3.0+ (ami egyelőre még csak tabletre van) már igen. Viszont az említetthez hasonló hardverrel szerelt telefonomon teljesen sima a scrollozás.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd