Přejít k navigační liště

Zdroják » JavaScript » Kdy přesuneme aplikace do prohlížečů?

Kdy přesuneme aplikace do prohlížečů?

Celá řada webových aplikací, kancelářskými počínaje a některými utilitami konče, by mohla fungovat lokálně, tedy běžet plně v prohlížeči, protože server teoreticky nepotřebují. Ve skutečnosti jej potřebují, a ještě nějaký čas potřebovat budou. Co přesně brání přesunu aplikací do webových prohlížečů?

Aplikace běžící v prohlížeči jsou v HTML5/CSS3 a JavaScriptu krásným snem. Jejich většímu rozšíření stojí v cestě celá řada problémů. Především vyšší náklady na vytvoření kvalitního UI, protože webové technologie až donedávna nebyly navrhovány pro aplikace. Technologie je ve specifikacích HTM5 téměř připravená, ale stále chybí několik věcí, spíš technicko-organizačních, bez nichž si lze představit intenzivnější vývoj aplikací pro prohlížeče jen stěží. Pojďme si probrat některé z těch nejzávažnějších, které brání zásadnímu posunu, tj. přesunu větší části logiky ze serveru do prohlížeče.

Přesun logiky mezi serverem a klientem je přírodní cyklus, který zachvacuje celý obor IT už od počátků. Střídání módy tlustých a tenkých klientů, vzývání jedné z těchto technologií a nesmiřitelný boj se zpátečníky, tj. s těmi, co stále ještě lpí na té druhé, patří k IT už neodmyslitelně. V posledních letech se zdálo, že bude rozumné vše přesunout na servery – síťová infrastruktura posilovala, přenosové rychlosti rostly a serverový čas a prostor skoro nic nestojí. Zlom přišel s mobilními zařízeními, které jsou navržené jako „webové“, ovšem musí se nějak popasovat s paradoxním faktem, že pro ně není připojení dostupné neustále. Jako jedny z prvních proto implementovaly appcache a podobné technologie a vypadá to, že se opět blíží doba zvýšené popularity aplikací, co poběží na klientské straně (tentokrát ale v prohlížeči) a server použijí jen na vzájemnou komunikaci či pro ukládání dat. Tvrzení „prohlížeč je operačním systémem zítřka“, které je leitmotivem Chrome OS, je dnes možná radikální, ale pravděpodobně se stane realitou.

Můžeme proti tomu protestovat, můžeme s tím nesouhlasit, nemusí se nám to líbit a můžeme být stokrát přesvědčení, že to je takto špatně, že by vývoj měl jít jinudy. Historie nás ale učí, že se to nestane, že vývoj půjde tou cestou, která je špatná, nepohodlná, nepraktická, ale jde po ní většina.

Kudy půjde vývoj podobných aplikací?

Zkusme si vyjmenovat největší technické překážky, které – z dnešního pohledu – na té cestě leží.

1. Otevřený JavaScript

JavaScript, který je motorem celé klientské části webové aplikace (resp. kompletní aplikací u prohlížečových aplikací), se posílá jako otevřený text. Kdokoli se do něho může kdykoli podívat a zjistit si o vašem programu vše. Čím víc bude funkcí v JavaScriptu, tím víc jich bude „veřejných“. Pokud chceme něco (know-how?) před cizími zraky skrýt, musí to být na serveru, byť i s otevřeným API. Obfuskace je jen částečné řešení.

Druhým faktorem je, že otevřený kód, který bude umět „všechno“, vám může velmi snadno někdo odcizit a provozovat na svém serveru. Dokonce i bez znalosti jeho fungování – teoreticky mu stačí použít „Uložit stránku jako kompletní HTML…“ a použít vaše API.

Chybí tedy třeba binární JavaScript? Nikoli, nechybí. Tedy minimálně ne z důvodu uzavření kódu. Převedení do binární podoby není v tomto případě nic jiného než forma obfuskace. Ztíží jeho dešifrování a posune laťku nutných znalostí o kousek výš, ale neuzavře kód.

Pomohla by nějaká metoda „podepsaného šifrovaného JavaScriptu“, jakési obálky, v níž by byl JS uložen a který by zajistil, že prohlížeč ověří původ a integritu skriptu před tím, než jej spustí, a zároveň zabrání zobrazení nebo uložení kódu? Pravděpodobně ne – vytvoření patche pro prohlížeč, který by tuto kontrolu obešel, by byla otázka hodin.

Platí, že v případě jakéhokoli programu (u interpretovaných jazyků v mnohem větší míře, u kompilovaných s obtížemi, ale také) může ten, na jehož stroji je kód vykonáván, s menší či větší námahou získat ekvivalentní zdrojový kód. Podle licenčních ujednání to většinou dělat nesmí.

Spoléhat na to, že lidé něco dělat nebudou proto, že nesmí, i když mohou, je neefektivní, a založit obchodní model jen na tom je pošetilé (a potřebuje velké výdaje na represivní nástroje). Jediná možnost, jak mohou webové aplikace přenést těžiště na klienty (prohlížeče), je změnit obchodní model tak, aby nebyl založen na tom, že nikdo nevidí zdrojový kód. Tedy defacto open source model.

Při známé setrvačnosti velkých společností je pravděpodobnější, že dřív vzniknou otevřená Windows 11 a prohlížeči budeme říkat WebKit, než že by velké IT společnosti změnily zaběhaný obchodní model „prodám škatuli za peníze“ – stále nižší výnosnost tohoto modelu pravděpodobně u mnohých nepovede k úvahám nad změnou modelu, ale k pokusům o posílení represí a restrikcí vůči všemu, co jej narušuje. Bude to stát stále víc peněz a mít stále menší účinnost, jako každá represe.

Dokud nedojde u alespoň několika významných hráčů ke změně pohledu na obchodní model, bude „otevřený JavaScript“ něčím, přes co vlak nejede, a pravděpodobně i největší překážkou pro vytváření aplikací běžících převážně v prohlížeči. Po změně obchodního modelu tento problém zmizí sám.

2. Autentizační systém

Je pěkné, že uživatel má ve svém prohlížeči editor textů, který je schopen offline práce, že si může texty ukládat na disk a otvírat je z něho, ale na to nepotřebuje aplikaci založenou na webových technologiích, na to sežene desítky, či spíš stovky desktopových aplikací, které totéž udělají bez prohlížeče. Ne, to není dobrý argument pro webové aplikace. Webová aplikace je zajímavá tehdy, když nabídne něco, co desktopová nabídnout nemůže – nejčastěji plně transparentní synchronizaci dat (ukládání v cloudu) či realtime kooperativní přístup k dokumentům.

Výše uvedené funkce a fíčury, co mohou nabídnout webové aplikace, mají společného jmenovatele: Jejich funkčnost závisí na tom, jestli lze jednoznačně ověřit přihlášeného uživatele. Zde je v současnosti další kámen úrazu, protože neexistuje bezpečná a standardizovaná metoda pro ověření uživatele, která by fungovala čistě v prohlížeči / JS.

Navíc technika pro autentizaci požadavků na serverová API, totiž OAuth, která je mainstreamem tolik milována, není s JavaScriptem či s jinými čistě prohlížečovými řešeními příliš použitelná. Současná řešení proto provozují autentizaci na straně serveru, a klient v prohlížeči má k dispozici API proxy. Čímž je problém vyřešen – ve skutečnosti pouze přibylo další místo, které je možné napadnout, problém „implementace OAuth“ se přesunul z klienta na server, a na klientské straně byl nahrazen novým: Jak se autentizovat vůči serverovému API tunelu?

Ideální autentizační metodou by byla taková, při níž by nikam neputovaly uživatelovy přihlašovací údaje, ty by zůstaly „uzamčené“ v prohlížeči, a požadavky na API různých služeb (třeba „cloud storage“) by byly podepsány a ověřeny jiným způsobem než „pošli heslo“.

Ve skutečnosti taková univerzální a standardizovaná metoda existuje, je jí HTTP Digest Authentication. Problémem je její silně nesympatická implementace, jejíž UI jako by vypadlo z poloviny 90. let, a obtížný způsob, jak rozumně skriptem obsloužit takové požadavky. Ostatně si zkuste sami zachytit HTTP status 401 při volání XHR a zabránit prohlížeči ve vyvolání onoho hnusného dialogového boxu (třeba proto, že máte heslo a jméno uložené jinde).

3. Lokální ukládání souborů

Představme si, že přesuneme většinu naší aplikace na klientskou stranu; do prohlížeče. Skript v prohlížeči bude obsluhovat UI, bude vykonávat další akce (Web Workers!), bude se starat o ukládání dat v lokálním úložišti, popřípadě se synchronizací s cloudem – to je všechno proveditelné už dnes. Ale jak uložit text (nebo obecně obsah), který vznikl v klientu a který je držen kdesi v JavaScriptové proměnné, na lokální disk? Nějak jako

var data = "Ahoj světe";
File.saveLocal (data, 'text/plain'); //nehledejte, neexistuje

Proč ukládat na lokální disk, když „vše“ bude v cloudu? Třeba k tomu, abyste mohli výsledek své práce jako prezentaci vzít na IT konferenci, kde – jak známo – internetové připojení vždy spadne.

Metoda, která by dovolila JavaScriptu přímo ukládat soubory, neexistuje, a to z pochopitelných a dobrých důvodů. Metoda, která by dovolila JavaScriptu vyvolat dialogové okno Save file as... a předat mu data k uložení, neexistuje rovněž. Nové File API nabízí několik možností, jak pohodlně data z lokálního disku číst, ale zápis neumožňuje nikdo. Funguje možnost „podstrčení“ data URI do document.location.href, kde za určitých příznivých okolností (tj. neznámý MIME typ) některé prohlížeče otevřou ukládací dialog a data uloží – pod naprosto obskurním jménem, jako třeba „PWctFwtFFz.part

Pro takové účely nezbývá než použít flashový workaround (Downloadify), který vám bude např. v iOS nanic, nebo cimrmanovský „úkrok stranou“, při němž pomocí XHR pošleme data na server, a ten nám je vrátí s hlavičkou „ Content-Disposition: attachment“. Což potěší lidi co platí za přenesená data, lidi s omezeným nebo žádným přístupem k internetu („application cache? Che che!“) a lidi, co mají zapnutou featuru „man-in-the-middle“. (A nešlo by dát content disposition do data URI? Můžete si zkusit…)

Závěr

Nic z výše uvedeného není smrtící problém, kvůli němuž by nebylo možné vytvářet aplikace běžící v prohlížeči. Vše lze obejít, nejsnáze tím, že přesuneme menší či větší část logiky na server. Ovšem pokud se rozšíří přenosná zařízení s OS postaveným právě na prohlížeči (Chrome OS), stanou se situace, kdy nebude server dostupný, statisticky významnými. Navíc se tím zbavujeme možností hostovat aplikace velmi levně v CDN / cloudech nebo např. v databázích a la CouchDB (existují webové aplikace, které mají uložené HTML/JS/CSS právě jako dokumenty v této DB, celé fungují u klienta a používají REST API ke komunikaci s databází).

Výše uvedené technické problémy nejsou zdaleka jediné, ale představují pravděpodobně největší technické překážky pro masivnější přesun aplikací do prohlížečů. Napadají vás další? Důležitější, zásadnější? Podělte se v diskusi…

Jaká je hlavní současná překážka přesunu aplikace do prohlížeče?

Ilustrace: Open Clip Art

Komentáře

Subscribe
Upozornit na
guest
33 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
oj

1. Otevřený JavaScript:
myslíte, že je to problém, já ne, vždyť stejně programy napsané v javě, c# jdou převést zpět na zdrojové kódy, jen se tam používá obfuskace, která to ztíží, podobně jakýkoli kód jde disassemlerovat…

2. Autentizační systém
ano není to příliš elegantní, ale k lokálu se hlásit nemusím, jen k serverům

3. Lokální ukládání souborů
neříkám, že je to bez problémů, ale tam kde potřebuji lokálně ukládat, můžu pustit specializivaný lokální server (např. napsaný v nějakém interpretu) a použít např. Cross-document messaging

rooobertek

3. išlo by to aj v mobiloch?

oj

to je problém :-(

pas

Periférie nebudou, budou jen cloud-ready zařízení a ty ostatní. :)

Jitka Dařbujanová

Problém je dle mého v stále nedostatečných IDE pro klienty a otevřeném kódu. Přesto je přesun na web zřejmý…

asitakhle

Můžeme proti tomu protestovat, můžeme s tím nesouhlasit, nemusí se nám to líbit a můžeme být stokrát přesvědčení, že to je takto špatně, ALE MŮŽEME TO NEPOUŽÍVAT A IGNOROVAT. (konkurence je dost, min. z linuxový strany)

„Platí, že v případě jakéhokoli programu (u interpretovaných jazyků v mnohem větší míře, u kompilovaných s obtížemi, ale také) může ten, na jehož stroji je kód vykonáván, s menší či větší námahou získat ekvivalentní zdrojový kód. Podle licenčních ujednání to většinou dělat nesmí.“
– Dle českého práva je takováto část licence neplatná. Takže lze zcela podle libosti zkoumat, co program dělá a jak to dělá, a to legálně.

X

Svět se stěhuje na mobilní zařízení. Prohlížeč->Webserver není optimální architektura pro miliony malých zařízení. takže já vsázím na P2P „desktopové“ aplikace na mobilních zařízení; žádná centralizovaná serverové řešení (ať už tomu říkáte farma nebo cloud).

Ostatně – většina dnešních aplikací pro mobilní zařízení je lokálně instalovaná.

pas

Jsou lokálně instalované, ale jsou klidně klientem cloudu. Například Google některé své aplikace šíří formou instalovaných aplikací a jiné jen jako webové aplikace, prostě jak se to zrovna hodí, a uživatel čím dál méně vnímá rozdíl mezi nimi. Diskuse „cloud vs. necloud“ (třeba „P2P“, jak říkáte) moc nesouvisí s diskusí „aplikace v browseru vs. instalované aplikace“. Podle mě je cloud jasný trend, ovšem pro klientské aplikace se bude zřejmě používat pestrá škála technologií od plně crossplatformních (HTML5) přes částečně přenositelné (Adobe AIR apod.) až po monoplatformní (iOS).

richard

Tiež to vidím tak, že v budúcnosti bude mať užívateľov mobil alebo tablet a budú skôr používať natívne aplikácie. Napríklad pre iPhone,iPad existujú špeciálne upravené webové stránky (noviny, facebook, gmail, amazon) ale užívatelia radšej pristupujú špeciálnymi iphone/ipad aplikáciami na tieto stránky.

Má to svoje výhody: lepší user interface, rýchlejšia aplikácia (prenášajú sa len data a nie celé html stránky).

pas

V HTML5 přece máme app cache, local storage, takže jakýpak přenos „celých HTML stránek“? Funkčně jsou dnes technologie pro webové aplikace ekvivalentní těm pro nativní aplikace. S určitými drobnými problémy, o kterých je tento článek, plus problém nedostatečných vývojářských nástrojů plus problém výkonu (žraní baterky).

michal

Kdy přesuneme aplikace do prohlížečů?

ja doufam ze nikdy.

sycho

+1 (text musi byt dlouhy alespon 4 znaky)

100% Lenin

vždy se ptám, komu to poslouží a jakou výhodu v tom mám já.
Řeknu vám to, milí AjTý revolucionáři.

Žádnou, ba pramalou.

Vidím spíše našlápnutí k masové spotřebě zaměřené na malinkaté poplatky.
Jenom hloupý občan si řekne – jé to je levné.
Chytrý, si uvědomí:
Kdepak že ta data jsou, copak se s nimi mohlo stát?
A proč neplatí mně – když ta data mohou používat.

jo jo jo, kdo chce kam, pomozme mu tam.

— kdo to kdy pochopí? ………….­……..

pas

Já ne. :)

Samotná technologie, o které je v tomto článku řeč, nedefinuje omezení na možné obchodní modely – kdo komu za co má platit v koloběhu dat. Podle mě naopak pokud různé cloudové služby dospějí do fáze standardizované komodity, umožní to víc a líp se na tyto otázky soustředit.

kbl

potreba spolocnej aplikacnej platofmy je tu uz davno, ale myslym si, ze vyuzivat internetovy browser ako platformu nie je dobry napad. HTML ako jazyk popisujuci istym sposobom gui (alebo layout grafickych prvkov a textu) ma dost slabe vyrazove prostriedky a stale vidiet ako si vyvojari pomahaju roznymi nadstavbami (flash,activeX,­…). Takisto javascript ma dost obmedzeny exekucny model (chybaju thready, asynchronita, vyuztie paralelizmu). Aplikacie na webe maju urcite svoje vyhody ale bolo by fajn keby sa vyvoj pustil inym smerom. Napr. vylepsenim Javy (rychlost,pamat,lep­sie gui, …). Zaujimave by bolo keby sa googlovsky Dalvik virtual machine a ich .dex format dostal aj na desktop (momentalne pritomny v Androide).

srigi_nl

javascript ma dost obmedzeny exekucny model – chyba asynchronita

Toto hadam myslite iba ako vtip. Pozrite sa prosim na node.js, ktoreho prvym a najdolezitejsim mottom je „non-blocking I/O“, tj. co mozno najviac async vykonavanie kodu. Multithreading umoznuju ponovom webworkers.

srigi_nl

Co sa tyka VM Dalvik, do toho dnes nikto nepojde potom co Oracle zaluje Google za nedodrzanie licencie Javy. Situacia je nejasna.

kbl

jj, toto je problematicke, nakoniec z toho bude tazit micro$oft so svojim .net-om

Ron

Proč vymýšlet vymyšlené (a nereálné), když ten starý dobrý způsob funguje již x-let, že když chci mít data přístupná celosvětově a z jakéhokoliv zařízení, tak to je (bude) uloženo někde „ve světě“ a budu to obsluhovat kvalitní a plnohodnotnou aplikací uloženou lokálně?

Včetně možností lokálně uložených dat s replikací a následnou synchronizací někde se serverem, když bude dané zařízení online?

Stačí, když bude dostatečná úložná kapacita a rychlost připojení si „on demand“ nainstalovat lokálně danou aplikaci, když bude třeba prohlížeč obsahovat „lokálně“ všechny funkce, které bude uživatel potřebovat, příp. si je opět „on demand“ za sekundu doinstaluje?

srigi_nl

Proč vymýšlet vymyšlené, když ten starý dobrý způsob funguje již x-let.

Uz od dob jazyka C vyvojari hladaju zlaty gral „code once, run everywhere“. Riesenie vzdy vo svojej dobe predstavovala nejaka nadejna technologia: Java, Adobe AIR, Flex. Nic z toho sa neuchytilo skutocne sirokospektralne – od mobilu az po desktop. Naopak, smartphony situaciu iba skomplikovali.

A prave tetaz sa ukazuje, ze HTML5 spolu s modernymi webkit smartphonmi umoznia gral najst. Ale mozno bude vsetko uplne inak.

Sam za seba mozem povedat, ze vyvijat aplikaciu tak aby sa nejako prijatelne zobrazovala na desktopovom Firefoxe a zaroven na celej plejade smartphonov je megapeklo. napr. CSSmedia-queries predstavuju iba velmi primitivny sposob ako sa tomuto stavu priblizit.

František Kučera

Ad „Sam za seba mozem povedat, ze vyvijat aplikaciu tak aby sa nejako prijatelne zobrazovala na desktopovom Firefoxe a zaroven na celej plejade smartphonov je megapeklo.“

Ano, toto je důležité zjištění, každý si k němu musí dojít. Nakonec je potřeba si uvědomit, že počítač (s velkým rozlišením, plnohodnotnou klávesnicí, myší, velkým diskem, pamětí a dalším vybavením) a mobil (chytrý, PDA, tablet…) jsou diametrálně odlišná zařízení s naprosto jiným stylem práce. Nakonec třeba dojdeš k tomu, že je dobré tu nejvyšší (prezentační) vrstvu aplikace napsat víckrát pro jednotlivé typy zařízení (desktop, tablet, mobil) než se trápit s univerzálním řešením, které bude ale pro všechny typy koncových zařízení suboptimální.

Problém s technologií a chybějícím API se většinou dá vyřešit a často to ani není problém – např. si klidně můžu zkompilovat Pidgin (IM klient) pro Freerunner (otevřený chytrý mobil) a používat stejný software na desktopu i v mobilu – ale pak se ukáže, že rozlišení je dost malé a že trefovat se stylusem do nabídek (nemluvě o tom, že někteří ani stylus nemají a musí se trefovat prstem) není to pravé ořechové.

Napsat jednou a přeložit pro různé platformy není problém (pokud člověk není čuně a nepoužívá proprietární shitware) ale problém může být GUI, které má být použitelné na velké i malé obrazovce, ovladatelné klávesnicí a myší a zároveň nějakými tlustými prsty šťouchajícími do displeje mobilu.

X

Ale ten zlatý grál byl nalezen. Nakonec se ukazuje, že nejpřenositelnější zdroják je napsán v čistém C.

Pavel Kysilka

zdravim,

osobne mam pocit, ze programovani pro web je oproti desktopovym aplikacim od urciteho stupne slozitosti hodne narocne na zdroje. Nektere veci neudelate poradne. O spolehlivosti blizici se ke 100% po reloadu stranky radeji nemluve.

Je to sice smer presouvat aplikacni logiku na server. Ale ne cele aplikace.
Osobne si rikam, ze velmi dobry smer je Java Webstart.

Vcelku by me zajimalo, kdo ten vyvoj zaplati ? S tim, ze tak nejak predpokladam, ze by se ty webove aplikace mely kvalitativne hodne blizit tem desktopovym.

Cele mi to prijde jako polovicate reseni nahradit drazsi programatory levnymi webovymi programatory. Casem si toto reseni stejne vylame zuby a bude se to stejne snazit konvergovat k tem aplikacim, co jsou nativne na desktopu.

Navic se mi za posledni roky zda, ze vyvoj webovych aplikaci ciste pro browser zacina byt hodne drahy. Misto toho, abych resil aplikacni logiku, tak resim uplne jine veci. Ale je to online a jede to v browseru.

gf

Jakub

Jako jediný a klíčový rozdíl vidím JavaScript. Ten představuje standard, který spojuje všechna koncová zařízení a umožňuje spouštět aplikaci na „libovolném“ z nich. Podobně jako to udělalo J2ME+MIDP a bude to fungovat úplně stejně.

Pokud totiž doplníme všechny ty věci, co webovým aplikacím chybí proti nativním (desktopovým), tak vlastně nejde o webové aplikace, ale nativní aplikace, které potřebují připojení k internetu.

Tyto vylepšené webové aplikace vypadají jako směr do budoucna, protože teď vzniká pocit, že se na použití HTML+CSS+JS všichni shodli, ale ten přejde při srovnání implementací prohlížečů (na PC i mobilech).

Josef Richter

Asi vždycky záleží na aplikaci – prostě u některých bude dávat smysl, aby byly čistě desktopový, u některých aby byly webový s tlustým klientem, u dalších webový s tenkým klientem, atd.

Co je na tom krutý a zajímavý zároveň, že ty technologie všechny směřujou k nějakýmu cíli. A my si vždycky o nové těchnologii říkáme „Ty jo, to vypadá nadějně! To bude super až technologie X bude umět tohle a tohle – to bude ráj na zemi a konečně budeme mít to, o čem jsme snili“. Jenže tam nikdy nedojdeme. Protože než ta technologie dospěje, tak se změní požadavky, změní se celej svět a přijde jiná perspektivní technologie, která se bude pokoušet na to reagovat a celý kolečko se opakuje.

Takže se asi musíme smířit s tím že ideálního řešení nikdy nedosáhneme. Vždycky to bude volba technologie na základě konkrétní situace a podmínek, někdy lepší, někdy horší, ale asi nikdy ideální.

bauglir

Myslím, že spíše naopak: „opravdoví programátoři“, píšíci v tom jediném „nejlepším programovacím jazyku“ to dělají nejlépe už teď, a cokoliv jiného je kravina a hloupost. Vždyť se podívejte do komentářů u článků na rootu :)

MyOwnClone

V kontextu obsahu clanku me velmi mrzi, ze Google se vybodl na svoji technologii Gears. Treba Google Docs nebo WordPress ji podporovaly, a casto se to ukazovalo jako uzitecna featura. Google se dusoval, ze Gears nahradi HTML5, ale ekvivalence schopnosti ktere GDocs mely s Gears a ktere maji ted s HTML5, neexistuje.

bauglir

Myslím, že v současné době je jenom 2 problémy, proč nevznikají aplikace pro browsery
1/ chybý knihovna ovládacích prvků, podobně, jako jsou v Visual Studiu, Delphi, apod. Napsat rozumně vypadající aplikaci je potom peklo, strašná ztráta času s GUI, místo soustředění se na app logiku. Ano, existuje pár knihoven s pár ovládacími prvky, ale bylo by jich pořeba několik desítek pro začátek.

2/ chybí tlak na zákazníky, aby je přijali, aby si na to zvykli. Programátoři neumí vysvětlit výhody.

Jak ukládat data vytvořená JavaScriptem na disk? Třeba takhle :) http://www.webnt.cz/26-blob-url/
Už dneska, a FileWriter API se už připravuje a pomaličku implementuje.
B.

František Kučera

Ad „chybí tlak na zákazníky, aby je přijali, aby si na to zvykli. Programátoři neumí vysvětlit výhody.“

A jaké jsou ty výhody? Proč by měl někdo tlačit na zákazníky, aby něco přijali a na něco si zvykli? Nemělo by to spíš být naopak – že zákazník něco potřebuje, a tak to po vývojářích požaduje? Někteří dodavatelé aplikací resp. webová studia asi postupují stylem: „něco umíme, tak lidem vnutíme, že to potřebují a musí si to od nás koupit“ – asi jako když firma vyrábí na sklad to, co se kdysi vyrábět naučila, a pak teprve přemýšlí, jak to těm lidem nacpat a jak to prodat – místo aby řešila, co lidé potřebují a to pro ně vyráběla.

pas

Ne „tlak“, ale určitá „evangelizace“. Začíná to už třeba školou, kde se děti učí v nějakém starém Excelu udělat tabulku a poslat jí spolužákovi mailem. Místo aby se učili sdílet data v cloudu. Ve vztahu nabídky a poptávky je (v tomto oboru) ta nabídková strana přece jen „intelektuálně“ o krok napřed, jinými slovy uživatelé moc netuší, co všechno můžou potřebovat a chtít.

bauglir

+1 (Text musí být dlouhý alespoň 4 znaky)

bauglir

pochopil jste můj příspěvek jako extrémní a extrémně jste zareagoval :). Slovo „tlak“ Vás asi zmátlo :)
Kcyž bude zákazník chtít aplikaci na správu své firmičky, správu zákazníků, skladu a bude to chtít mít přístupné z firmy, z domova, na cestách, z windowsů, z maca… Sednete k desktopovým IDE a bude bouchat aplikace pro různé OS? Server pro ukládání dat? Nebo použijete prohlížeč jako runtime, HTTP jako komunikační protokol a ano, něco na serveru, ale většina serverocých jazyků pro práci s webserverem je schopna běžet na více platformách…

Na některé aplikace je vhodnější desktop, nepochybně, ale netřeba na něm trvat jenom proto, že „to je opravdové programování“, nebo že neumíme klientovi vysvětlit výhody (přenositelnost všude tam, kde lze pustit A-grade browser (já osobně to přímo limituje na Chrome), 1 kód = rychleší výroba = rychlejši upgrade funkcionality = pravděpodobně levnější).

Zažil jsem to před měsícem. Klient si na prohlížeč zvykl, přesto, že program vypadá jako aplikace (nic ani náhodou nepřipomíná webovou stránku) a teď je spokojenej, že si to může pustit všude.

Ale ještě jednou, netvrdím, že browser jako runtime je nejvhodnější pro všechno…

Mimochodem, většina sw firem takhle klientúm něco „nutí“: windows, linux, JRE, .NET… prostě nějakou běhovou platformu :). A buď klienta přesvědčí, nebo se mu podvolí, nebo jde klient jinam… děje se to už 50 let (teda až na ten výčet runtime :)) :)

P.S. když to tu takhle píšu, něco mě napadlo :) „Proč by měl někdo tlačit na zákazníky, aby něco přijali a na něco si zvykli? Nemělo by to spíš být naopak – že zákazník něco potřebuje, a tak to po vývojářích požaduje?“ Skvělej argument, příště ho použiju, až bude tady někdo vykřikovat o linuxu :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.