A Microsoft vesztett, a web nyert (?)

Elgondolkodtató és sztem korrekt a cikk. Ugyan az eredeti angol verziót még nem olvastam (csak a weblaboros magyar verziót), de meg fogom nézni.

Az IE háttérbe szorítása sztem nem csak a szerzőnek tűnt fel... Aki weben dolgozik, arra fejleszt, az már egy ideje szenved az IE nyűgjeivel. :-( A Mozilla/Firefox páros egyszerűen verhetetlen jelenleg..

Szerintem azért nem fejlesztik az IEt mert tökéletes ;)))

A M$ mikor megnyerte a Netscape ellena browser haborut teljesen leallitotta a explorer fejleszteset, es mashova vitte a fejlesztoket.

Valami feleszu meg az opensource-tol feltette az innovaciot. A monopolium _teljesen_ megszunteti a fejlesztest, mivel nincs ra szukseg.

elég jó az eredeti cikk, bár kissé bő lére van eresztve.

megjegyzéseim, mint egyszerre több projekten is dolgozó alkalmazásfejlesztő:

- teljesen áll a szerző megfigyelése, hogy a Microsoft által a windows-hoz biztosított c++ eszközkészlet idáig igen silány volt /MFC = rémálom/. nem értek teljesen egyet azzal, hogy ez a c++ nyelv miatt volt így főleg, hiszen ott van N éve a Borland c++-os eszközkészlete, az gyönyörű, és nagyon jól, egyszerűen használható

- meglepő, hogy a .NET-et máris temeti, pedig az egy igen ígéretes dolognak tűnt számomra. de hát a piaci szempontok néha ütik a racionalitást... emiatt lehet hogy halasztok új fejlesztést .NET-ben elkezdeni...

- határozottan NEM értek egyet azzal a véleményével, ami szerint a webes alkalmazás fejlesztés lefedi az igények 95%-át. mi 2 olyan projekten is dolgozunk, ami erősen számításigényes /képfeldolgozás, spektrumfeldolgozás/. a power userek által igényelt programokat csak akkor lehetne kiváltani teljesen vékony kliensekkel, ha az internet kapcsolat rendkívül elterjedt, és legalább 100 Mbit szintű lesz. ez viszont sokkal később következik be, mint a Microsoft következő fejlesztései, hiszen még legalább 15 évet kell erre várni. Szóval ebben egyenlőre nem hiszek, és így a cikk végkövetkeztetése sem feltétlenül igaz.

A szabad szoftverek rohamos elterjedésével és az asztali gépek teljesítmény növekedésével ugyanis teljesen reális alternatíva a kliens-szerver modell mellett vagy inkább helyett a peer-to-peer /grid/ alkalmazás is. szerintem inkább ez lesz az egyeduralkodó kb 10 év múlva. A power user desktop pedig soha nem fog kihalni, tehát kellenek ilyen alkalmazások is.

Ezt mostanaban egyre tobbet hallom, hogy az explorert igy lehuzzak.

Kerlek mondjatok mondjuk 3 peldat miert eri meg gecko vagy opera rendering enginre, vagy rhino-ra (opera js tamogatasarol nem tudok sokat, csak azt, hogy az elmult 2 evben egyszeruen nem tudott eleget) atterni?

Megrprobalok osszeszedni a legbosszantobb dolgokat, amit nagyon hianyoltam eddig a gecko/rhino parosbol, vagy csak nem tetszett:

1) WYSIWYG editing lehetosege (tudom, a gecko is tud modositani a megjelenitett oldalban, de az nagyon kenyelmetlen, kulon be kell kapcsolni, nem lehet kikapcsolni, illetve bugos, mert neha barmire bedobja az editkurzort)

2) egy bonyolultabb CSS-sel vezerelt layoutban az explorer hiba nelkul es igen gyorsan teljesit, a gecko sokszor hibazik, nem azt teszi amit kellene neki es lassu.

3) borzaszto lassu. peldanak okaert vegyunk egy tablat mondjuk 5 oszloppal, es 2000 sorral. a sorok utolso ket mezojebe rakjunk CSS-sel style-olt input fieldeket. Na ezt a mozilla legalabb 1 percig rendereli max CPU mellett. Az IE kb. 5-10 mp-ig.

A gecko/rhino lassusaga jelentosen csokkentheto a windowsos verziokkal persze, ugyanis sok esetben az X a lassu. Ilyen pl. a flash plugin linux/gecko-ra. Ebben az esetben windowson az IE es a mozilla hasonloan teljesit, az X alatt a gecko nagyon lassu es szaggat.

A 3) ponthoz csak annyit hogy a mozilla nativan a hardveren futott, az IE vmware-ben. Ja es egymas utan vegeztem a mereseket.

Erdekelne olyan emberek velemenye, akik bonyolult DOM, CSS, DHTML strukturakkal dolgoznak.

Kosz,

Zoli

Az eredeti felvetesre csak annyit, hogy nem olvastam a cikket (nem is fogom). Ugy erzem azonban, hogy mikor valaki ilyesmiket emleget, akkor szamossagrol beszel. Sztem a jelenleg futo es fejlesztett programok tomegeben meg igen nagy szazalekban talalnank cobol, vagy fortran kodot. Es ezek nem az altalunk ismert alkalmazasok, vagy a tucatalkalmazasok, amiket egyedi alkfejlesztesek kereteben irunk.

Mindegy, a technologia folyamatosan fejlodik, es pl a kliens szerver technologia pl 3 dimenzios csigavonalban:

Kezdtuk a vekony kliensekkel. Utana jottek a vastag kliensek. Most megint a vekony kiensek vannak soron. Sztem hazudna, aki 15-evre elore josolna manapsag.

"2) egy bonyolultabb CSS-sel vezerelt layoutban az explorer hiba nelkul es igen gyorsan teljesit, a gecko sokszor hibazik, nem azt teszi amit kellene neki es lassu."

En eppen az ellenkezojet figyeltem meg. Volt mar olyan, hogy a css specifikaciok alapjan irtam meg egy oldal css-et, es az mozillaban/konquerorban/operaban olyan is volt, amilyennek lennie kellett. Explorerben teljesen szet volt esve.

2.-ra: Validáltattad azt a css-t? Mert általában pont fordítva szokott lenni; a Gecko jeleníti meg jól és az IE rosszul, de mivel sok az ie user, ezért az 'okos' webdesignerek IE specifikus css hekkeléseket szoktak tenni a weboldalakra, amik viszont sértik az specifikációt és így pont a szabványt követő engine-ek jelenítik meg rosszul. Lassúság: sajnos ez tényleg probléma, bár folyamatosan javítják a sebességet is. IMHO az sem kizárt, hogy pont a sebesség optimalizáslás miatt dönött az MS úgy, hogy eltérnek a szabványtól. Az MS sajnos az ilyesmit megteheti...

Ja had említsem meg, hogy az XHTML supportja az IE-nek nagyon nagyon gáz! (lám egy újabb példa arra, hogy a monopólium visszafogja a fejlődést/új technológia elterjedését) Emellett van egy pár olyan elem, ami egyáltalán nem jelenik meg ie alatt (a tooltip például).

Jah igen, a füles böngészés... Az egyetlen grafikus felületű böngésző ami NEM tudja ezt az pont az IE. :lol:

2.) ?????? nem tudom mire gondolsz, de nezz mar korul... Csomo problema van az IE-vel, es NEM CSAK CSS szinten, hanem HTML szinten is (pl. forms)

Zsiraf

Kedves Zoli, sajnos mind a 3 pontod ma mar teljesen hamis, nem igazak. Talan egy reszuk igaz volt masfel. Szerintem erdemes lenne haladnod a korral, nezz korul kicsit mit is tud ma mar a gecko motor, es igy a mozilla alapu alkalmazasok.

1) kilove, tokeletesen hasznalhato, sot! rengeteg mas lehetoseged is van, melyre ie-vel nincs, xml szintu editalasa az oldalnak, xul alapu editalasa az oldalnak, es persze a szokasos, ie-ben is adott lehetoseg.

2) ez mar nagyon reg nincs igy, az ie mar sehol sincs css tamogatotsagban, egyetlen akadalya a normalis css+(x)html oldalak elterjedesenek az ie, azaz az ie-t hasznalo emberek:(

3) ehhez tegyuk hozza hogy egy meglehetosen extrém pelda, de teny, hogy mozillaba valamivel tobb ido telik el amig megall. De talan nezz meg valamit: amig ie-be az egesz muvelet vegen kapod meg az eredmenyt, addig mozillaba mar szinte azonnal lathatoak a tablazat sorai. Mozilla alapu bongeszoknel lehet allitani a prefs.js-be az nglayout.initialpaint.delay erteket millisec-be. Ez hatarozza meg, mennyi ido teljen el a cuccok megjelenitese elott, illetve meddig rendereljen a hatterben. Ez eleg alacsony alapbol (~500), ennek koszonheto, hogy a bongeszes is sokkal gyorsabbnak erzekelheto, mivel egybol megjelennek a dolgok, max meg rendezodik a letoltes folyaman.

Es akkor beszelhetunk a fejlett DOM, CSS tamogatasrol, es nem utolso sorban a fejlett js ertelmezesnek, ma mar reg tulleptunk az 1.3-as js verzion, amit meg ie tamogat, es rengeteg olyan dolog van amit csak azert nem lehet altalanossagban js-ben is hasznalni, mert ie azt nem fogja erteni. Az ie specifikus activex dolgokkal pedig lehetoleg senki ne pedalozzon, mert az messze nem compatibilis semmivel, es nem is platform/bongeszo fuggetlen.

Nekem ez a velemenyen, ha mar kerdezted :)

1. "WYSIWYG editing lehetosege"

Erre már sokan reagáltak. Van benne. Hozzátenném a WYSIWYG CSS szerkeszthetőséget!!! Nagyon korrekt! :-)

2. "egy bonyolultabb CSS-sel vezerelt layoutban az explorer hiba nelkul es igen gyorsan teljesit,"

Erre is reagáltak. 1-1.5 évet le vagy maradva. Ennek a fordítottja a helyzet per pillanat.

3. Ez extrém példa. Elképzelhtő, hogy lassabb, de nem hinném, hogy szignifikánsan.

Csak a többieket tudom ismételni: Picit le vagy maradva, jelenleg ezek az állítások nem igazak, én viszont kapásból tudok Neked mondani olyan CSS-problémákat, amiket az IE nem kezel.

- fixed layer

- max/min-width/height (hekkeléssel megoldható)

Ezek, ha jól tudom CSS2-ben definiált propertyk.

És akkor itt van még az átlátszó PNG rendes kezelésének hiánya. Szintén van rá hekk, na de azért az cseppet sem korrekt megoldás...

Hirtelen ennyi. Ezek teljesen alapesetek, egy szimpla weboldalnál is belefut ilyenekbe az ember. Ennél sokkal több probléma van az IE-vel.

Még valami: pop-up blokkolás. Jelenleg NINCS benne az IE-ben. Tudom, hogy az XP SP2-től benne lesz, de az még a fejlesztők asztalán pihen... :-)

Atlatszo PNG? Sot: rendesen hasznalt alpha csatornak. Csinaltam anno probaoldalt ami teljesen erre epit: menuket, ablakokat... A sotetuveg-szeru hatast valtozo, parszazalekos opacity-ju pngkkel csinalja... Hat, valami orom megnezni, IE alatt hogy mutat... :))

Jo, persze, ezt most nem konkretan erre a cikkre irtam. Amugy itelet sem csuszott ki a billentyuzetemen.

Azert irtam, mert en meg hallottam mar affelet emberektol, hogy a hagyomanyos kliens szerver architektura halott.

Hat koszonom a kimerito valaszokat :)

Kulon orulok, hogy a fikas tarsasag nem osztott velemenyt.

Igazatok van, le vagyok maradva, ugy latom rengeteg jo dolgot tud a gecko. Ma mar inkabb szerveroldali kodot irok, a UI-t otthagytam teljesen, ezert nem vagyok kepben.