Firefox 3 a podpora offline webových aplikací

Robert O’Callahan z Mozilly se zmínil o offline podpoře webových aplikací v Mozille Firefox 3. Konkrétně jmenoval možnost offline použití služeb Google, jako jsou Gmail, Google Docs & Spreadsheets a Google Calendar. Více informací na ReadWriteWeb.com.

13.2.2007 07:18 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Filip Jirsák]

Mozilla bude za chvíli samostatný operační systém. Bude mu chybět jediné – dobré a rychlé renderovací jádro

[zill]

mozilla je od pocatku koncipovana jako aplikacni platforma, gecko je dobre jadro s dostacujici rychlosti a to se pocita

[Filip Jirsák]

mozilla je od pocatku koncipovana jako aplikacni platforma

A od počátku se ukazuje, že to pro internetový prohlížeč nebyla nejšťastnější volba.

gecko je dobre jadro s dostacujici rychlosti a to se pocita

Není náhodou ze čtveřice Presto (Opera), KHTML (Konqueror, Safari), Gecko (Mozilla, Firefox) a Trident (Windows MSIE) Gecko nejpomalejší? Třeba browser speed a podobně to vychází i jinde… No a že je to dobré jádro – v podpoře standardů je lepší než MSIE, ale to znamená pouze to, že je lepší než ten nejhorší…

[Daniel Kvasnička ml.]

Mluvite o enginech, ale odkazujete na test browseru, ve kterem jsou s Geckem zastoupeny pouze ty multiplatformni postavene na XUL. Abychom mohli porovnat rychlost enginu, museli bychom postavit jeden prohlizec a v nem testovana jadra postupne rotovat. Treba takovy Epiphany je o poznani sviznejsi nez FF (a umi dost veci, nektere veci ma i o generaci lepe resene nez FF).

Otazkou take je, zda je rychlost vykreslovani browseru to nejdulezitejsi. Opera si muze byt rychla jak chce, ale kdyz mi neni schopna nabidnout to co Flock (dokonale integrovanou podporu del.icio.us, search-as-you-type vyhledavani v zalozkach, obsahu stranek v zalozkach a prohlednutych strankach a dostupna rozsireni pro FF), je pro me pomala. Pro me je dulezity celek, ne zabomysi valky o rychlostech enginu.

[cezz]

Mozilla bude za chvíli samostatný operační systém. Bude mu chybět jediné – dobré a rychlé renderovací jádro

Renderovacie jadro je IMHO dobre a sledujuc vyvoj zlepsuje sa pomerne rychlym tempom, to ze je pomalsie je ciastocne aj dan za prenositelnost. (jednak samotneho browsera a tiez aj jeho extensions, co sa mi zda dolezite, lebo osobne si myslim, ze by ich vacsina bola win-only) Je to aplikacna platforma a osobne sa mi tento system vyvoja paci viac, ako keby to bolo nejake "browser_only" jadro. (viz. napriklad celkom zaujimavy projekt songbird)

Co sa tyka rychlosti, nie je to ziadna slava, ale na beznom PC je to naozaj jedno. Navyse mam taky pocit, ze jadro sa postupne optimalizuje aj co sa tyka rychlosti, ma tiez pribudnut akcelerovane renderovanie (cairo - BTW: skusal to uz niekto, je to skusatelne? ) a podobne, takze zlepsuje sa aj tato stranka. Nehovoriac o tom, ze rychlost HW rastie..

Strucne a jasne, na dnesnom beznom pc na bezne ucely je jadro dostatocne rychle a viac nez dostatocne dobre. Nevidim dovod na plac.

[Michal Vyskočil]

Renderovacie jadro je IMHO dobre a sledujuc vyvoj zlepsuje sa pomerne rychlym tempom, to ze je pomalsie je ciastocne aj dan za prenositelnost.

Mám to chápat tak, že KHTML, nebo jádro Opery jsou, narozdíl od Gecka, nepřenositelné?

[cezz]

Ako som pisal, mal som na mysli prenositelnost browsera a extensions. Nehovoriac o dalsich aplikaciach na gecku zalozenych. Obaja vieme, ze KHTML a gecko su dve uplne odlisne veci

[Filip Jirsák]

Těžko říct, zda je Gecko pro přenositelnost rozšíření plus nebo mínus. Na jednu stranu je snadné splácat nějaké rozšíření, na druhou stranu je dost složité napsat rozšíření tak, aby bylo napsané dobře, a bylo opravdu přenositelné a nezávislé na jedné konkrétní verzi.

V tomto ohledu je to jako přístup MSIE k webovým stránkám a dřívější postupy tvůrců webu – autor nějak splácal webovou stránku a MSIE mu jí zobrazil podle jeho představ (i přes chyby v kódu atd.), ale při trochu jiné konstelaci (ať už jiný prohlížeč, jiná verze, jiné rozlišení monitoru) to dopadne katastrofálně. A prostředky pro odladění prakticky žádné.

[Michal Vyskočil]

Renderovacie jadro je IMHO dobre ...

Ako som pisal, mal som na mysli prenositelnost browsera a extensions.

Nevím, co jste měl na mysli, ale napsal jste renderovací jádro

Obaja vieme, ze KHTML a gecko su dve uplne odlisne veci

Přiznávám že nevím, jak mohou být dvě renderovací jádra úplně odlišné věci? KHTML sice nemá nic jako XUL (ale to je stejně založené na Javascriptu) a mnoho věcí navíc nechává na KDE pluginech, ale to nic nemění na tom, že velká část funkcionality (rendering stránek, parsování html, xml, css, interpretace skriptů, ...) je u obou stejná.

[cezz]

Renderovacie jadro je IMHO dobre ...

Ako som pisal, mal som na mysli prenositelnost browsera a extensions.

Nevím, co jste měl na mysli, ale napsal jste renderovací jádro

Co moze byt zle pochopene, bude zle pochopene. Takze pre objasnenie. Renderovacie jadro sa mi javi ako IMHO dobre, netvrdim, ze je rychle - viz. nizsie.

Přiznávám že nevím, jak mohou být dvě renderovací jádra úplně odlišné věci? KHTML sice nemá nic jako XUL (ale to je stejně založené na Javascriptu) a mnoho věcí navíc nechává na KDE pluginech, ale to nic nemění na tom, že velká část funkcionality (rendering stránek, parsování html, xml, css, interpretace skriptů, ...) je u obou stejná.

No pre mna podstatny rozdiel je ten, ze zatial co napr. Konqueror pouziva KHTML na rendering webstranok, tak Firefox je cely renderovany jadrom samotnym. XUL je zalozene na javascripte a je celkom pochopitelne, ze aplikacia v podstate napisana v JS bude pomalsia ako aplikacia napisana v C. Co sa tyka samotneho jadra, tak nemam odskusane, ktore jadro je rychlejsie, nakolko vsak oboje povazujem za dostatocne rychle, neratam to medzi dolezite parametre. Khtml ani browser na nom zalozeny nepouzivam, ale nikomu ho neberiem. Je to fajn vec, urcite renderuje tabulky o niekolko ms rychlejsie..

[Filip Jirsák]

Cairo je knihovna pro vektorovou grafiku, která může používat různé backendy (např. OpenGL), takže její použití může urychlit vlastní vykreslování případně některé vektorové výpočty, ale renderovací jádro internetového prohlížeče toho dělá daleko víc.

Na rychlosti vývoje Gecka mám jiný názor, ale možná je to zkreslené tím, že chyby, které mne u Gecka zajímají, jsou průměrně cca 5 až 6 let staré

Problém webového prohlížeče jako platformy je v tom, že veškeré zobrazené stránky, GUI, rozšíření a pluginy jsou jeden monolit. Chování internetového prohlížeče bych si představoval tak, že v jednom vlákně běží UI, v dalších vláknech s nižší prioritou běží jednotlivé stránky (takže např. zacyklený skript ohrozí maximálně stránku samotnou, ne celý prohlížeč), jednotlivé pluginy (např. Flash) běží zase v samostatných vláknech, buď s nižší prioritou než ovládání stránky samotné, nebo s uživatelem definovatelnou prioritou (takže bláznivý Flash nebo otevírání PDF dokumentu nezablokuje celý prohlížeč). A tohle udělat v aplikaci, která má pouze jednu instanci renderovacího jádra a jednu instanci skriptovacího motoru by bylo dost těžké.

(Požadavek, aby se prohlížeč nenechal sestřelit pluginem nezmiňuju, to už by znamenalo nejspíš nějaký virtuální stroj.)

[Josef Kufner]

Mno, zrovna flash bych radši viděl jako samostatný proces. Stejně tak otevřené PDF. A s vláknama to není dobré přehánět.

[cezz]

Spominane PDF sa mi otvara v evince a nie priamo v browseri, takze tam uz to samostatny proces je

[Jiří (BoodOk) Kadeřávek]

Já myslím, že i flash běží jako samostatný nspluginviewer.

[Filip Jirsák]

Jako samostatný proces je to samozřejmě nejlepší, pak jde zajistit i to, aby plugin (kdo, co) neodstřelil prohlížeč (koho, co). Ovšem nejsem si jist, zda třeba ve Windows jde zařídit, aby jeden proces maloval do okna jiného procesu a přijímal z něj události klávesnice a myši. S vláknama je nutné opatrně, ona taky nejsou všespasitelná, ale v okamžiku, když člověk kvůli zacyklenému skriptu (nejlépe vlastnímu) v jedné záložce musí odstřelit prohlížeč se čtyřiceti záložkama, odstřelil by nejradši ještě někoho jiného, a zpravidla ne autora skriptu

[deda.jabko]

:-]] nevim jak v novejsich verzich windows... (opravdu to neni muj salek caje) bylo dokonce mozne, aby jeden proces spustil vlakno v jinem, aby jine vlakno alokovalo jinemu pamet a podobne zverstva....

jinak na tech 40 zalozek je vhodna opera... ta mela kolem verze 4.x a 5.x nehorazne problemy se stabilitou, tak do ni implementovali vcelku slusnou obnovu po padu, ktera tam je do ted ;-]

[Filip Jirsák]

:-]] nevim jak v novejsich verzich windows... (opravdu to neni muj salek caje) bylo dokonce mozne, aby jeden proces spustil vlakno v jinem, aby jine vlakno alokovalo jinemu pamet a podobne zverstva....

Možné to bylo (spuštění threadu v jiném procesu) a je stále, ale stále ten thread běží v paměťovém prostoru toho cílového procesu – takže pokud tam potřebujete spustit nějaký svůj kód, musíte jej ještě nějak dostat do adresního prostoru toho cílového procesu. A hlavně ten thread pak zase běží v rámci cílového procesu a pokud bude dělat neplechu, shodí ten cílový proces. Dělat co se mu zlíbí (a ovlivňovat jiné procesy) program ve Windows (NT a výš) nemůže, tedy pokud někde není nějaká chyba v implementaci nebo v nastavení práv.

[cezz]

Cairo je knihovna pro vektorovou grafiku, která může používat různé backendy (např. OpenGL), takže její použití může urychlit vlastní vykreslování případně některé vektorové výpočty, ale renderovací jádro internetového prohlížeče toho dělá daleko víc.

Suhlas, ale tiez je to ista forma zlepsovania. (IMHO) Dalo by sa diskutovat, nakolko je schopne neoptimalizovane cairo v pomerne rannom stadiu vyvoja schopne nieco urychlit

V podstate s tebou suhlasim, pre browser je monoliticky pristup dost nevhodna volba.. Su to rozumne argumenty, s ktorymi sa viem stotoznit narozdiel od povykov typu "je to pomale a zle". Kazdopadne mi browser ako taky pripada velmi usable a gecko zas velmi zaujimavy kus kodu.

[Filip Jirsák]

Oceňuju, že se podařilo z toho, co kdysi opensourcoval Netscape vytvořit internetový prohlížeč, který je použitelný. O prohlížeči jako je Firefox se nám před pár lety ani nesnilo. Jenže dnes není před pár lety a nelze usínat na vavřínech. Navíc internetový prohlížeč je dnes patrně nejdůležitější desktopovou aplikací – já sám ráno prohlížeč zapnu a celý den v něm mám otevřeno alespoň pár záložek. Navíc ještě dělám webové aplikace, takže relativně často používám Firefox i pro vývoj pro odladění výstupu té webové aplikace. Takže nároky na webový prohlížeč mám vysoké a „docela použitelný“ prohlížeč mě neuspokojí. A z prohlížeče, jeho jedinou ambicí je nebýt tak špatný, jako MSIE, zrovna nadšený nejsem.

On ten monolitický přístup má ještě jedno úskalí, ne technické, ale spíš manažerské. Mozilla má velké problémy s tím, jak je populární mezi uživateli, ale na druhé straně má evidentně nedostatek vývojářů. Pokud by existovalo ohraničené vykreslovací jádro „nezávislé“ na zbytku, mohou se tito vývojáři věnovat vývoji jádra, a věci jako GUI, řízení pluginů nebo síťování může programovat někdo jiný – a přeci jen programovat GUI může daleko víc lidí, než programovat optimalizované vykreslovací jádro. A dnes se ještě k evšemu ti lidé, kteří dokážou programovat vykreslovací jádro, rozptylují nesmysly typu canvas, off-line aplikace atd.

Přitom i současný stav se stávajícím kódem by se dal zlepšit – každou chvíli někde čtu, že je někdo ochoten pomoci s OSS, ale neumí programovat. Ale takoví lidé by Mozille hodně pomohli, pokud by pro ně existovala nějaká infrastruktura. Mozilla používá bugzillu, která je možná dobrá pro vývojáře, ale pro uživatele je nepřehledná, při množství chyb jaké je v nejrůznějších produktech se ta nepřehlednost násobí. Snad u každé chyby najdete několik, které jsou označeny jako duplicitní (což znamená, že uživatel neměl sílu hledat nebo nenašel tu správnou chybu a zadal jí znova), spousta chyb je v různých stavech, že se jimi nikdo nezabývá – buď chyba ani není potvrzena, nebo je potvrzena ale vůbec se neví, zda se bude řešit, nebo se pod ní vášnivě diskutuje, že by se řešit měla, že to závisí na tom a tom a neví se vůbec kdy by asi tak mohla přijít na řadu. Přitom by mohl existovat nějaký jednoduchý systém na zadávání chyb, které by pak dobrovolníci-neprogramátoři zpracovávali do podoby Bugzilly – zařadili by jí do správné kategorie a komponenty, přiřadili související chyby v Bugzille atd. Tím by se taky uvolnili ruce programátorům, kteří by se zabývali už technickými aspekty chyby a nemuseli by chyby označovat za duplicity, zkoušet, zda popsané je opravdu chyba nebo pouze nejasnost u uživatele atd. Současný stav, kdy už není důležité chybu najít a popsat, ale napasovat jí na nějaké mediálně vděčné téma (třeba Acid2), aby se tou chybou někdo vůbec začal zabývat, je dost špatný.

To že kritizuju produkty Mozilly neznamená, že bych si nevážil práce lidí, kteří na tom dělají. Já ty lidi oceňuji, programovat vykreslovací jádro internetového prohlížeče není žádná legrace. Ale mám pocit, že dnes Mozilla nesměřuje zrovna nejlépe, a pokud by došlo k nějakému zádrhelu s Geckem 1.9 a zároveň se MS pochlapil, vytvořil pořádný vývojářský tým a vydal zbrusu nový MSIE 8, může taky být z té čtveřice Gecko snadno poslední – tím by i obrovsky utrpěl kredit OSS jako takového, protože Mozilla je dnes vlajkovou lodí OSS. Firefox ve Windows už má dnes kde kdo a považuje se to za normální – otázky typu „proč něco jiného“ nebo „vždyť to prý nefunguje“, které běžně uslyšíte třeba o OOo už jsou v souvislosti s Firefoxem minulostí.

[deda.jabko]

vetsina puvodniho kodu netscapu byla uplne vyhozena a gecko vznikalo na zelene louce... nejvetsi pruser je, ale v tom, ze mozilla je prohlizec v prohlizeci, cele gui je vlastne "webova" aplikace... ma to sice uzasny benefit v prenositelnosti jadra a hlavne pluginu, ale vykoupeny nehoraznymi naroky na vykon.

[Daniel Kvasnička ml.]

Jo, ta narocnost je treba hezky videt u Komodo IDE, ktere je na XUL postavene...je jeste linejsi nez Eclipse. Ale je docela slusne.