Kispad

Kispad: közös blog
4230 cikk, 53876 hozzászólás
Szerzők | Tudnivalók | Feedek


A Web halott, az AJAX meg csak ront rajta

eszpee cikke a Torokgeek rovatból, 2005. november 24. csütörtök, 12:02 | 14 hozzászólás

Elég morcos vitaindító a Slashdoton, első ránézésre még lehet is valami alapja, de érdemes azért az ellenérveket is végigrágcsálni. Én leginkább azokkal értek egyet, akik szerint lehet, hogy nem ez a legjobb, de bármi más eleve hátránnyal indulna, és az elterjedése brutálisan hosszú időt venne igénybe.

» Ugorj a hozzászóló ablakhoz

Megosztások Facebookon

Eddigi hozzászólások (14)

1

NagyGa1, 2005. november 24. csütörtök, 12:23 (#)

Igen, igen, szerintem is! :)
Az Ajax olyan, mint a ráolvasás.

Persze csomó mindenre jó, pl Sesblog rádió, de azért egy nagyobb projektben erősen mellőzném.

2

eszpee, 2005. november 24. csütörtök, 12:29 (#)

Konkrétan ha egy földönkívülinek kéne elmagyaráznom a sesblog rádió számkiíró részének működését, az első teljesen logikus kérdése az lenne: "Miért a kliens nézi 15 másodpercenként, hogy változott-e az éppen játszott szám? Ahelyett, hogy a szerver szólna pont akkor, amikor változik?" És persze igaza lenne, "azért, mert ilyen a web." :)

3

sztahanov, 2005. november 24. csütörtök, 12:33 (#)

Szerintem elrontottátok a címet, mert az helyesen 'A Web 2.0 halott, az AJAX meg csak ront rajta' lenne!

4

darthwalk, 2005. november 24. csütörtök, 13:19 (#)

Már megint...kicsit kezd már tele lenni a hócipőm at egész webkettőpontnulla-ajaksz csámcsogással.

van ilyen egyáltalán vagy nincs? nevezzük e másnak vagy ne? podcasting e a podcasting vagy csak rss+mp3? ajax e az ajax vagy csak javascript?

filozófia a web2.0 vagy csak egy unatkozó szakértő agyszüleménye?

túl sok a szövegelés szvsz.

ha eddig mindenki hideg vízzel mosott volna és most rájött vki hogy melegvízzel is lehet akkor aztmondom, hogy ez egy másik korszak.

de mi volt a web1.0 ha ez most hirtelen a 2.0 lett?

marhaság.

5

eszpee, 2005. november 24. csütörtök, 13:22 (#)

darthwalk, elolvastad a linkelt hozzászólást? az illető magát a webet ("ahogyan azt ma ismerjük") fikázza, ez nem a szokásos web2.0 topik.

6

Dimi, 2005. november 24. csütörtök, 13:27 (#)

Ajax az fontos, de humorerzek fontosabb.

7

Boca, 2005. november 24. csütörtök, 14:05 (#)

Azért az Ajaxot nem véletlenül használják olyan 'kis' projektekben is, mint a Gmail.
Sztm ez nem kicsi és nagy projekt kérdése, hanem alkalmas feladaté. Ha a feladat megkívánja, az ajax adott esetben tud komoly pluszt nyújtani. Más esetben meg nem jó semmire. Ez így van sok technológiával, ezért én úgy tekintek rá, mint egy új lehetőségre.
Nemsokára át is írom az eddig iframe-mel gányolt megoldásomat ajaxosra és a végén megmondom, megérte-e.

Ami pedig a vitaindító slashdotos hozzászólást illeti, megint azt látom hibának, hogy nem veszi észre a vitaindító, hogy nem ideális világban élünk, hanem olyanban, ami evolúciós módszerrel építkezik. Ebből nem csak az következik, hogy fejlődünk egy irányba, részletekben mindig kicsit jobb technikákat alkalmazva, hanem egyúttal cipelni kell magunkkal sok régi szart, amit nem lehet csak úgy eldobni. Miután a világ elég jól befogadta az amúgy statikus lapokra kihegyezett WWW-t, most valóban nehéz lenne egycsapásra fasza állapottartó, lekerekített technológiát bevetni, nem megy. Próbálkoztak már sokszor az x86-kompatibilitás levetkőzésével is, de a kritikus felhasználói tömeg miatt ez sem sikerült.
Talán akkor lehetne Web 2.0ról beszélni, ha ezt meg lehetne tenni. Előállna egy olyan pillanat, amikor kis ráfizetéssel egyszerre oldalon lehetne upgrade-elni a komponenseket.

8

pblue, 2005. november 24. csütörtök, 14:22 (#)

szerintem nemhiányzik olyan sok ahhoz, hogy ez a platform jó legyen. én jópárhónapja egy másik fórumon corba-s brózerekről álmodoztam, javascript proxy objektumokkal. ezzel például túl lehetne lépni a http problémákon. (úgy értem persze, hogy a brózer beszéljen httpül is, de mittudomén mondjuk iiopül is.)
aztán van egy csomó w3c kezdeményezés (pl. xforms, meg számtalan egyéb), amik a valódi "platformfüggetlen" gui létrehozását célozzák meg - ezek túllendítenek a html szabta szűk kereteken.
szóval korábbi radikális álláspontomat felülbírálva, én nem ostoroznám az egész platformot úgy ahogy van. viszont a web service, rpc és hasonló technológiákat (pl az ajax ezen aspektusát, mint ws klienst), mint egyfajta újrafeltalált corbát csak http alapokon, nos ezt zsákutcának tartom. ha valamire, mint amilyen az "elosztott rendszerek" (vagy hogyvanez magyarul) koncepció, létezik már régóta működő megoldás, akkor miért ne használnánk azt?
azt viszont nemértem végképp, hogy az xmlbe miért rúgott bele. én pl oo hívő vagyok, de (sőt, nemis de, hanem pont ezért) lelkesen dolgozom xmlel.

9

Pepito, 2005. november 24. csütörtök, 16:09 (#)

Szvsz a vitaindító csak a nyulat akarta kiugrasztani a bokorból. Azt nem mondanám, hogy nem tudja, mit beszél, mert ki tudja ki ő... Mindenesetre állításai nagyon erős csúsztatások és kontextusukból kiragadott példák.

Hasonló módon lehetne fikázni a trabantot, csak mert nem fér el a csomagtartóban két köbméter homok.

10

Boca, 2005. november 24. csütörtök, 16:20 (#)

Pblue, szeretném akkor a brózeremben egy nem-zsákutca, már régen meglévő technológiával ugyanazt elérni, mint egy ajaxos hívással.
Mit kell tennem, beállítanom, letöltenem, stb?

11

nix, 2005. november 24. csütörtök, 17:34 (#)

"In other words, 1970s technology with pictures."

12

NagyGa1, 2005. november 25. péntek, 02:15 (#)

Boca:
A GMail szerintem kis projekt.
Komplexitás szempontjából számítva értettem kis meg nagy projektet, nem adatmennyiség vagy felhasználók száma szerint.
De a te megfogalmazásod azt hiszem pontosabb ("Alkalmas feladat).

Az iFrames gány átírása valszeg meg fogja érni, de ez még mindig nem lesz az az eredmény, mintha lenne egy szolid platform.
Szóval persze, az Ajax előrelépés, de igazából valami teljesen újra lenne szükség.

Azért volt már ami nem evolúciós termékként jött létre:
a kilencvenes években néhányan leültek, és definiáltak egy Java nevű dolgot, ami szvsz az összefoglalása az elmúlt ötven év programozási tapasztalatainak, és az eddigi non-plus-ultra.

(Mielőtt valaki félre szeretné magyarázni: nem gondolom hogy pl adatbázis kezelőt javában lenne célszerű írni.)


Nem Boca, de:
Szvsz ma megcsinálni újra egy GMailt pl egy Ajaxot felhasználva nem egy nagy durranás.
Ezért sem hiszem hogy ilyen jellegű technikai invenciók önmagukban sokáig versenyelőnyt tudnának biztosítani.

PBlue:
"corba-s brózerekről álmodoztam, javascript proxy objektumokkal"

Jézusmária... :)

Pepito:
Elolvastam még 2x, nem látom mi a kiragadott példa / csúsztatás.

13

Boca, 2005. november 25. péntek, 20:14 (#)

NagyGa1, webes értelemben a Gmail nagy projekt. Azzal tisztában vagyok, hogy ha a komplexitását egy komoly desktop alkalmazással hasonlítjuk, akkor nem az.
Az ajaxot továbbra sem tartom csodaszernek, nincs is benne nagy tapasztalatom, de pl. ha azt veszed, hogy a Gmailt ajaxos technikák nélkül kell megcsinálni, akkor ugyanúgy megoldható, csak otrombább lesz. Mondjuk úgy hogy olaj a gépezetbe.

14

Pepito, 2005. november 27. vasárnap, 16:42 (#)

NagyGa1:
Tudod, a probléma az, hogy műkedvelő programozócskák két fél PHP/MySQL projekt után szólnak hozzá olyan dolgokhoz, amihez lövésük sincs.

Az ARPANET-et mérnökök tervezték és építették meg, és eredményük kimagasló mérnöki alkotás.
Nem mennék bele nagyon mélyen, mert kiderülne szakmai sovinizmusom. ;)

Vegyük az első állítás példaképp:
"Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http."

Ha bárki az említett protokollok közelébe került valamikor, akkor tisztában kell(ene) lennie az ISO 7 szintű hálózati modelljével (OSI model).

http://en.wikipedia.org/wiki/OSI_model
Itt teljesen tisztán látszik, hogy a TCP egy transfer protokoll, a HTTP pedig az applikációs réteghez tartozik. A kettőnek nincs köze egymáshoz: A TCP-t lehet másra is használni, a HTTP protokolt meg lehet valósítani más transzfer protokollal is.
Továbbá, a HTTP 1.1 támogatja a kapcsoltorientált transzfert (ld. keep alive.) Az idézett mondat egyszerűen csak sületlenség, úgy ahogy van.

Nem is ez a lényeg...
Itt egy fajta gondolkodási médszertanról van szó.

Hadd meséljek nektek a kapcsolat fenntartásának kérdésköréről. Ez a kedvenc mostanában, mert a poll rendszerű megközelítések valahogy olyan alantas lúzer megoldásnak tűnnek. (2 eszpee)

Leül a mérnök és elkezd gondolkodni, hogy no most akkor kapcsolatorientált legyen a protokoll vagy sem. Kiket is kötünk össze? Mi lesz a kapcsolat élettartma? Mi történik, ha a kapcsolat megszakad valamilyen külső ok miatt? Mennyire lesz megbízható az így kialakított kapcsolat? Mennyi időre tartható fenn optimális esetben? Mennyibe kerül kiépítni? Mennyibe kerül fenntartani? Hogyan veszem észre, ha megszakadt? Mennyibe kerül észrevenni, hogy megszakadt? Hány kapcsolatot kell fenntartani szerver oldalon egy időben? Mi az erőforrásigénye a kapcsolat fenntartásának, kiépítésének? Hogyan változik a hálózat? Hogyan változik a környezet? Hogyan változnak a peremfeltételek? Hány évig kell a most megtervezett rendszernek működnie? Mekkora a gyakorisága a kiépített kapcsolat újrafelhasználásának? Milyen jellegű az adatforgalom?....
És még vagy 157 további kérdés, mielőtt egyetlen válasz is rendelkezésre állna.
Szóval a mérnök leült és az ismert peremfeltételeknek megfelelően úgy döntött, hogy nem éri meg fenntartani a kapcsolatot. Döntése nem ad hoc volt. Kiszámolta, hogy egy kapcsolat kiépítése x cent, ugyanennek a kapcsolatnak a fenntartása minden további másodpercben y cent. Ha várhatóan a t másodpercig nem történik semmi és t*y>x, akkor el kell dobni a kapcsolatot azonnal, amint a transzfer végetért. Ez egy nagyon durva modell volt, amit itt mutattam, ezt lehet finomítani a végteleségig, persze csak addig érdemes finomítani, amí még van várható gazdasági haszna, pl. különbséget teszünk ismert kliensek vagy a továbbított adat jellege alapján. Persze ezt nem csinálják, mert az sokkal többe kerülne. Viszont azt is kiszámolták.

Valamit a UDP-ről, ami teljesen off, csak hogy a költségszemléletet érzékeltessem: az UDP egy nagységrenddel kevesebbe kerül, mint a TCP. Illetve a költségeket áttolja egy réteggel felljebb, ahol más mérnökök más peremfeltételekkel kiszámolhatják, nekik mi a jó.

Az akkori időben fajlagosan a kapcsolat kiépítése és fenntartása, egy bit továbbítása sokkal többe került, mondjuk 3-4 nagyságrenddel, mint ma. (nb. a kapcsolat kiépítése CPU-, fenntartása memóriaigényes. Sok kapcsolat fenntartása egyszerre mindkettő, és akkor a routerekról nem is beszéltünk...)

Tessék a mérnök munkáját megfelelő perspektívába helyezni. Milyen kellemetlen, hogy a Szabadság híd nem bírja a villamosok és a teherautók súlyát... Akkor most a Szabadság híd tervezője egy idióta volt?

Egyébként pedig TCP alapokon nagyon sok alternatíva létezik a HTTP hiányosságainak áthidalására. Egyik kedvencem ezek közül: http://www.beepcore.org

Tessék gondolkozni és nem hőbörögni egy idióta miatt, aki azt sem tudja, hogy mi a TCP és a HTTP közötti különbség.


Hozzászólsz?

Igen

Hozzászólást csak névvel együtt fogadunk el. Ha linket írsz be, akkor előtte és utána hagyj egy szóközt, főleg akkor, ha zárójelbe teszed.


Az oldal tetejére | Szerzők, tudnivalók, feedek | sesblog és Kispad © 2003-2010 ervin, eszpee, stsmork