ugrás a tartalomhoz

Mire figyeljünk a webfejlesztésben 2006-ban?

Hojtsy Gábor · 2005. Szep. 12. (H), 09.32
Anil Dash vette nemrég a billentyűzetét, hogy megjósolja, milyen trendek várhatóak a webfejlesztésben a következő évben, mire kell felkészülnünk, ha versenyképesek akarunk maradni a profik között is. Az ilyen jóslatok megfogalmazásakor ugyanakkor érdemes óvatosnak lenni, hiszen bizonyos divatos megoldások éppenhogy eltűnhetnek idővel, más hasznos technológiáknak viszont nem jelenhet meg kellő támogatása a kliens vagy szerver oldalon. Jóslatai mindenesetre igen érdekesek.

Blog bejegyzésében Anil elsősorban a felhasználói felületen tapasztalható trendekre tért ki, hiszen ez az, amit a végfelhasználó is érzékel, és ez alapján választ terméket, ugyanakkor egyáltalán nem feledkezett meg a szerver oldali megoldásokról sem. Lássuk mit tart fontosnak.
  • Diszkréten dinamikus effektek: A felhasználói felületek AJAX-osodásával, a hirtelen változások helyett fokozatosan el- és feltűnő elemekre kell felkészülnünk, hiszen ezek jobban érthető felületi változásokat jelentenek a felhasználó számára.

  • Az E4X megállíthatatlan terjedése: Az XML-t jelentősen könnyebben kezelhetővé tevő E4X a JavaScript megoldásainkat sokkal egyszerűbbé teheti, amennyiben XML feldolgozást kell végeznünk. Mind a Firefox következő kiadásában, mind a Flash lejátszóban érkezik E4X támogatás, a Microsoft részéről csak idő kérdése az alkalmazkodás, ha nem szeretnének lemaradni.

  • A JSON térhódítása: Sok esetben túlzás az XML adattovábbítás használata, ilyenkor jöhet jól a JSON, melyhez számos nyelvre elérhető támogatás, ráadásul a JavaScript natív objektum jelölését használja az adatok továbbítására, így webes környezetben különösen könnyen alkalmazható.

  • XHTML és CSS korrekt használata: Még mindig sokan vannak, akik akár XHTML akár HTML formátumban nem készítenek érvényes weblapokat. Egy igazán programozható, Greasemonkey barát weboldal létrehozásakor azonban mindenképpen fontos, hogy jól struktúrált szerkezetet hozzunk létre. Ezen a területen még mindig van tér a fejlődésre.

  • A betöltést jelző üzenetek visszatérnek: A Betöltés... illetve Loading... feliratok, melyeket nagy Flash mozik betöltésekor már megszoktunk a kiterjedt JavaScript kódok betöltési időszükséglete miatt ismét visszatérhetnek. Bár ez nem válik a fejlesztő dícséretére.

  • Atom API támogatás: Az Atom tartalommegosztó formátum szabványosításával megnyílt a lehetőség az Atom programozói felület véglegesítésére, melynek előzetes verzióit már támogatja számos webalkalmazás. Ennek ismeretével helyzeti előnybe kerülhetünk a jövő évben.

  • Ruby on rails előnyszerzés: Sok területen élveznek előnyt azok, akik időben felismerték egy technológia hasznosságát, és profira fejlesztették magukat a témakörben. A Ruby on Rails sokak szerint hasonló helyet foglalhat el, de számos terület van, ahol még nem teljesít jól, vagy nem is próbálták ki az alkalmazását.

  • Okosabb önmarketing: És végül mit sem ér, ha mindezeket a technológiákat ismerjük és profin használjuk, ha nem tudjuk ezt kommunikálni a potenciális megrendelők, munkaadók felé. Tanuljunk meg okosan és hatásosan beszélni és írni arról, hogy mire vagyunk képesek!

Kíváncsi vagyok olvasóink mit gondolnak, a fentiek közül mi csupán az aktuális divathullám sugallata, és mivel egészíthetnénk ki a listát.
 
1

Okosabb önmarketing

sajt · 2005. Szep. 12. (H), 09.47
Ez a resze mar regi tema. Elvileg errol szolna az iranyelvek dolog nem?

--
Ámon Tamás - http://amon.hu
3

csak érintőlegesen

Hojtsy Gábor · 2005. Szep. 12. (H), 10.14
Az írányelvek nem arról szól, hogy a fejlesztőknek jobb legyen a marketingje, hanem hogy kapjanak egy dokumentumot arról, hogy most mi az irányadó a szabványokat, elérhetőséget stb. figyelembe véve. Az, hogy ez segíti a marketingjüket, ha arra hivatkoznak, hogy eszerint fejlesztenek az egy melléktermék, mondjuk igaz, hogy éppen ez segítheti az elfogadottságát.
2

<Nincs cím>

-zsolti- · 2005. Szep. 12. (H), 10.02
A fokozatosan mozgó dinamikus elemek már most elkezdtek terjedni, egyre több új webhelyen látni CSS-megoldásokat szép beúszó menüpontokra, ami nekem kifejezetten tetszik, mert kicsit "flashessen dinamikussá" teszi az oldalt, viszont még sem. Az XHTML és a CSS alkalmazása szeritnem már-már kötelező, ez az mit nem a divathullámok hoznak magukkal, hanem egyszerűn kell. Amit én nem 2006-ra tennék, hanem későbbre, az az Atom és a Ruby. Az Atom-megoldások szeritnem még az RSS-nél is lassabb terjedést fognak produkálni, a Ruby pedig a kevés hosztolási lehetőség miatt marad meg egyenlőre szűk rétegen. A másik meg, hogy akik ASP, JSP, JSF és/vagy valamilyen webes .NET-es megoldást használnak, azok "elvi okokból" nem igazán fognak Ruby-ra áttérni, közel hasonló okokból pedig a PHP-sek sem fognak tömegesen átnyergelni egy új nyelvre, és "eldobni" egy több éves PHP-gyakorlatot. <= Ha PHP-ről kell már váltani, akkor inkább ASP.NET.
(Megelőzve a flamet: a leírt dolgok erősen SZVSZ jellegűek...)

Üdvözlettel: Liebig Zsolt
SWEN Internet
4

PHP alapon is lesz

Anonymous · 2005. Szep. 12. (H), 13.18
A Ruby olyan divatos mostanában. De pár hónap kell, hogy php alapon is kikristályosodjon egy hasonló framework. Aztán a Ruby mehet a süllyesztőbe.
5

Háát.

Bártházi András · 2005. Szep. 12. (H), 14.34
Van igazságtartalma a dolognak, de én nem mernék egy ilyen kijelentést tenni. Alaposan átrágtam magam a Ruby és a Ruby on Rails lehetőségein, és nem csak a megoldásai miatt olyan amilyen (bár azok is jók), hanem maga a Ruby is olyan megoldásokat biztosít, melyek nincsenek meg olyan tömören más nyelvekben. Meg lehet írni PHP-ben és más nyelven is ugyanazokat a funkciókat, de a Ruby on Rails-ben használható angol "mondatok" nem nagyon utánozhatóak le. Magyarországon egyelőre a te álláspontodat vallják az emberek (szerintem mert még nem jelent meg elég sok ismertető, kész weblap RoR alapon, s nem látják a lehetőségeket), de külföldön nagyságrendekkel többen választják és kötelezik el mellette magukat. Én nagy Perl imádó vagyok, s létezik egy *nagyon jó* és nagyon sokat tudó, a Ruby on Railshez hasonló megoldás Perlben (Catalyst), de szerintem a Ruby on Rails veri.

Ez a helyzet bár nyilvánvalóan nem olyan, de emlékeztet arra a vitára, amikor az emberek a régi táblázatos layout mellett kardoskodtak két-három évig (lásd különböző levlista archívumaink). Az ellenérv akkor az volt, hogy bonyolult, a régi bevált, és különben sem éri meg váltani, mert ez egy divat. Azóta bebizonyosodott, hogy nem így van.

-boogie-
6

Rubyra még várni kell

Kérésre törölve 10. · 2005. Szep. 12. (H), 19.58
Szerintem a Ruby egyenlőre még nem az a nyelv (a Ruby on Rails pedig nem az a keretrendszer) amit minden programozó reflexből elővesz a webalkalmazásokhoz. És szerintem nem ez lesz 2006 scriptnyelve. Szerintem a Rubynak még el kell jutnia a "rajtmezőhöz".
Az Atom is szerintem várni fog még egy kicsit, szerintem az RSS is olyan helyzetben van, hogy el kell terjednie. Remélem nem mondtam marhaságot:-).
___________
by ChaTeve
7

Betöltés...?

Anonymous · 2005. Szep. 12. (H), 20.11
A betöltést jelző üzenetekre azért kiváncsi lennék. Szerintem ez baklövés.
13

csak ha tényleg preloader...

Kérésre törölve 10. · 2005. Szep. 13. (K), 15.40
Egyébként, hogy lehet megoldani a preloadert (tehát tényleg csak addig maradjon kint az üzenet, amíg az oldal letöltés alatt van)? Mert én csak annak látom értelmét, ha tényleg azért van kint, mert az oldal betöltödik (ahogyan a flashes alkalmazásoknál szokott lenni). Mert sok esetben láttam már olyat, hogy csak kirakott egy "Betöltés..." feliratot és egy meta refresht az illető...
___________
by ChaTeve
14

Preloader

attlad · 2005. Szep. 13. (K), 15.53
Gondolom pl. valahogy így: alaphelyzet: egész oldalas DIV elem minden fölé pozicionálva, de display értéke none-ra rakva.

Ezután a HTML kód elején JavaScripttel megjeleníted (display -> block) majd onload eseményre ismét eltünteted.

Szerintem nem célszerű ilyet, max. speciális esetben.

Amúgy a backbase.com oldalon (Firefox-szal nézve) van ilyen Loading felirat.

Attila
9

korai alkalmazók

Hojtsy Gábor · 2005. Szep. 12. (H), 22.13
A korai alkalmazók (early adopters) lesznek helyezetelőnyben legalább egy ideig. A fenti lista ha jobban megnézed, nem feltétlenül arról szól, hogy a többség mit fog csinálni, hanem arról, hogy mivel lehet nagyot alkotni, és nagyot szakítani. Lehet szkeptikusnak lenni vele szemben, lehet, hogy sok esetben magyar megrendelőknél nem ezek fogják a szimpátiát kiváltani, bár az is elképzelhető, hogy más megrendelőkkel érdemes akkor dolgozni :)
10

<Nincs cím>

-zsolti- · 2005. Szep. 12. (H), 22.37
Konkrétan a betöltés jelzőn épp ma agyaltam, hogy miért is nem használunk ilyesmit sima weblapoknál, és miért kell végignézni, ahogy a firefox darabokban tölti be az oldalt, és egyenként varázsolja elő a képeket a helyőrzőkbe. Erre rá fél órával látom ezt a cikket... :)

Üdvözlettel: Liebig Zsolt
SWEN Internet
11

Nem tartom jó ötletnek a preloadert

saxus · 2005. Szep. 13. (K), 08.17
Szerintem igen elhibázott ötlet lenne bevezetni a html-s oldalakhoz a preloadert. Láttam már egy-két ilyen megoldással készített oldalt, és nem győzött meg túlzottan az ötlet megvalósítása. Ráadásul, ha nincs javascript, az ilyen oldalak jó része használhatatlanná válik. (Beragadt preloader felirat, meg se jelenik az oldal, stb.)

Egy normálisan megtervezett tableless designet használó oldalon a lényeges tartalmi rész előbb jelenik meg, mint a többi sallang. Így már az oldal akkor használhatóvá válik, amikor a többi sallang (pl reklámok, képek) még csak töltődnek. Akkor miért várakoztassunk meg mindenkit?

És mi van azokkal, akik például nem kívánják az egész oldalt letölteni? Például nem akarják a képeket megnézni? Ebben az esetben akadjon ki a preloader? Láttam már rá példát.

Inkább a gzip-l tömörített adattovábbítás nagyobb térhódítását várnám el. Nagyobb terhelés a szervernek, viszont csökkenit az igényelt sávot és gyorsabb a letöltés. Az átlagfelhasználót meg nem érdekli a szerver, csak az, hogy gyors legyen.
15

Szerver terhelés - sebesség

-zsolti- · 2005. Szep. 13. (K), 16.58
Nagyobb terhelés a szervernek, viszont csökkenit az igényelt sávot és gyorsabb a letöltés.
Én ezt pont ellenkezőleg gondolom: egyre nőnek a sávszélek, ma már nem ritka, hogy valaki 150-200Kbps-os sebességgel rohangál, mindemellett a technológiák is egyre gyorsabb betöltődést tesznek lehetővé (ajax, css, dinamikus oldalak cache-elése, stb), tehát akkor miért kéne megint visszanyúlni a gyökerekhez, és kvázi a "néhány" modemesre optimalizálni, holott a fejlődés pont az ellenkező irányba mutat? Szerintem a legjobb sebességet pont nem a szerver dolgoztatásával kell elérni, ellenkezőleg: a lehető legjobban tehermentesíteni kell (lásd: az előbb már említett példák).
Egyébként a szerver terhelések kérdése pedig hazánkban pont olyan szinten van, hogy kevés webhely tulajdonos mondhatja azt: rendben, terheljék csak a vasat, majd veszünk nagyobbat, de legalább marha gyors oldalunk lesz. De elég csak megnézni a hazai hosting piacot, hogy egyesek milyen gépekkel képesek webtárhelyet szolgáltatni, na hát ott inkább ne terheljen senki semmit.

A preloadra pedig a fentebb már belinkelt backbase.com szerintem nagyon jó példa.

Üdvözlettel: Liebig Zsolt
SWEN Internet
16

<Nincs cím>

saxus · 2005. Szep. 13. (K), 17.40
Igen, látom én is a BIX statisztikán, hogy szépen növekszik a használat, de jobban örülnék, ha nem mindenki az én netemet akarja terhelni. Esetleg mást is szeretnék rajta használni.

A backbase.com -mal csak egy nagy gond van: és ha nincs javascript, akkor hogy navigálunk rajta?
17

Próba?

attlad · 2005. Szep. 13. (K), 18.06
A backbase.com kikapcsolt JavaScripttel is használható.

Attila
18

Tényleg

saxus · 2005. Szep. 14. (Sze), 06.21
Sorry, én néztem el egy kicsit. Akkor kapcsoltam ki a js-t, amikor már betöltődött az oldal.

Csak arra leszek kíváncsi, hányan veszik majd a fáradtságot/lesz ideje, hogy a hagyományos egyszerűbb helyet összetettebbet készítsenek.
8

Web API-k

attlad · 2005. Szep. 12. (H), 22.02
Szerintem meg a Web 2.0-val szinte minden webalkalmazáshoz (amelyikhez van értelme) API készül majd mint annak idején az RSS megjelent a weboldalaknál.

Szóval:
Weboldalhoz Atom és RSS feed.
Webalkalmazáshoz meg API felület kell hogy tartozzon.

Ha van ilyen felület, akkor egyszerű beépíteni pl. asztali alkalmazásokba, pl. Google Sidebarhoz plugint írni, Firefoxhoz kiterjesztést írni vagy Greasemonkey scriptet, Dashboard, Konfabulator, Superkaramba widgetet készíteni, stb.

Attila
12

JavaScript nem lesz annyira nyerő

aries · 2005. Szep. 13. (K), 13.49
Véleményem szerint 2006-ban a fentebb említett JS alapú megoldások (leszámítva az AJAX-ot) nem kerülnek nagymértékben alkalmazásra. Ennek oka a technológiák tisztázatlan volta (a legtöbb vmi hack megoldás), illetve egy újabb, n+1 -edik technológiát kell elsajátítatni az amúgy is leterhelt webgeek-eknek. Kevés szakterület van, ami ennyi tanulást és készséget kíván, és idehaza fizetőképes kereslet sincs rá.

Személy szerint 2006-ra az AJAX és az (x)html+css szemantikailag is helyes használatát jósolom, ha már az egyik teljesül, már nagyott léptünk előre.
--
Aries
http://aries.mindworks.hu
19

Ruby effekt :)

yaanno · 2005. Szep. 16. (P), 15.26
Jó ideje figyelem a Ruby fejlesztést, és meg kell mondanom, hogy - amatőr programozóként - igencsak megtetszett a tömörsége, a kód átláthatósága, "érthetősége". Ha jól tudom, pill. a WISH-nél van csak Ruby támogatás, bár jó lenne újabb és újabb dolgokat megvalósítani itthon is; gondolok itt pl. a lighttpd+fastcgi-re, amely szintén olcsó és kitűnő technológia.

Nekem kifejezetten bejön a preload; nem feltétlenül kell ezt kizárólag egyes oldalak/aloldalak betöltődésére érteni; szuper dolog pl. az is ha látom, hogy egy adott csatolmány feltöltése hol tart, vagy meddig kell várnom egy keresési folyamat végéig.

Atom - hát: na végre :) Bővebben csak annyit, hogy az Atom+RSS2+XML csatorna fenntartása egy oldalon nem okoz jelentős terhelést, de legalább a felhasználó választhat a kínálatból.

XHTML+CSS: sokáig úgy gondoltam, hogy az olyan intézmények, mint a Magyar Elektronikus Könyvtár, nem engedhetik meg maguknak, hogy oldaluk "szétszórt kódtöredékekből hirtelen" felhasználóbarát webhellyé álljanak össze - és: de, ez van. El is határoztam, hogy kb. megcsinálom azt, amit Douglas Bowman csinált a M$ címoldalával, megkísérlem centiről-centire modernizálni úgy, hogy a kinézet (ami, hát nem a legszebb) ne változzon.