Java vs HTML 5 vs Flash

Olen pannut huvittuneisuudella merkille miten maailmalla kirjoitetaan artikkeleita Javan tuhosta. Alustalla on tietoturvahaavoittuvuuksia, se suositellaan siis poistettavan. Näin ollen Javan aika on ohi ja se vuotaa rahaa Oraclelta. Tässä lauseessahan on niin paljon väärin ettei tiedä mistä aloittaa. Javan pääkäyttöhän ei ole työasemissa vaan servereissä, jonne mm. IBM, Oracle ja RedHat ovat tehneet ja tulevat tekemään rahallisia panostuksia, ja joissa Java-pohjaiset web serverit ovat tyypillisimpiä alustoja web-sovelluksille, etenkin yrityspuolella. Ja jossa noilla mainituilla haavottuvuuksilla ei ole (juuri) mitään merkitystä. Java siis elää tai kuolee sen mukaan miten hyvin se suoriutuu palvelinohjelmoinnissa vastaan muita teknologioita, ja miten hyvin sitä puolta tuetaan ja kehitetään. Jos tänä päivänä java se tapettaisiin kokonaan, merkitys Javan kannalta ei olisi suuren suuri. Javan merkitys on servereissä, ei työasemissa. Tosin työasemissakin sekä mobiililaitteissa on Javaa asenneltuna miljardeja yksi

Väite: Pitäisikö sitten Java työasemista poistaa? Sehän on täynnä tietoturva-aukkoja ja joka kuukausi eletään pelossa löytyykö uusi. Lisäksi, kuka enää tekee rich client ohjelmointia, kun kaiken voi tehdä HTML5:lla? Adobekin luopuu flashistä. Java on ihan tarpeeton tekele?

Vai onko? Katsotaanpa tarkemmin näitä argumentteja:

Voiko kaiken todella tehdä HTML5:lla? Kenties voi. Perinteisesti rikasta käyttöliittymää lähdettiin tekemään Javalla tai Flashillä siksi että perinteinen HTML pohjainen web-sovellus on staattinen ja jäykkä, se reagoi vain napinpainallukseen ja pystyy ainoastaan näyttämään web sivuja ja ottamaan syötettä, ei esim. minkäänlaista pääsyä työaseman/mobiililaitteen rautaan kuten älykortinlukijoihin, (web) kameraan, paikkatietopalveluihin, yhteystietoihin, kalenteriin, värinärajapintaan, kiihtyvyysanturiin, kallistusanturiin, verkkokorttiin, äänikorttiin, piirtämiseen, videon soittoon, matalan tason tehokkaisiin grafiikkarajapintoihin, jne. JavaScript laajensi palettia antamalla mm. rikkautta tapahtumankäsittelyyn. AJAX lisäsi vielä lisää rikkautta kun dataa voi hakea dynaamisesti verkon yli ja sillä päivittää sivua ilman että täytyy edes navigoida. Ja HTML 5 lisää vielä lisää kuten Canvas piirtoalusta, ääni ja videorajapintoja, paikallinen tietovarasto. Sillä voi soitella videota ja ääntä, ja tehdä kaunista käyttöliittymää.

Mitä sitten uupuu? No pari asiaa. HTML 5 ei pärjää suorituskyvyssä lähempänä käyttöjärjestelmää ajetulle koodille, eli kun halutaan ottaa koneesta kaikki irti, se jää jälkeen. HTML5 pääsee vain niihin resursseihin käsiksi jotka on siihen avattu, eli aina kun joku uusi vimpain keksitään työasemiin tai mobiililaitteisiin, HTML5 sovellukset ovat jälkijunassa sen soveltamisessa. Samoin tietysti Java, mutta vähemmän kuin HTML. Esim. JavaFX teknologian suorituskyky on täysin eri planeetalta ja visuaalista ilmaisukykyä riittää eri sarjassa.

Pahimmat niitit tulevat kuitenkin tässä: HTML5 ei ole vielä edes valmis, se on tällä hetkellä vaporwarea kunnes toisin todistetaan. Sen spesifikaatiokaan ei ole valmis, se _ehkä_ tulee 2014. Selainvalmistajat _ehkä_ toteuttavat sen. Siihen mennessä _ehkä_ maailma ei ole muuttunut yhtään. Muistan myös 90-luvun suuret selainsodat, kun Dynamic HTML ja JavaScript olivat uusi ja kuuma juttu, ja valmistajat kilpailivat siitä kuka tekee hienoimmat toteutukset ja tulkitsee standardeja nerokkaimmin ja mahdollisimman epästandardein tavoin. 2014 web sivustot tulevat räjähtämään käsiin ellei ihmiskunta ja eritoten selainvalmistajat ja kehittäjät ole jotenkin viisastuneet siitä. Todennäköisesti joudutaan taas tekemään eri versiot sivustoista eri selainversioille, tätä on jo nyt näkyvissä vaikka speksi ei ole edes valmis.

Entäpä sitten tietoturvaongelmat? Javassahan on niitä, haavoittuvuuksia, jotka pitää paikata tai niitä hyödynnetään. Samoin on Windowsissa. Linuxissa. JavaScriptissä. Ja niin myös Ajaxissa ja eritoten HTML 5:ssa. Jos haluaa alustan jossa ei ole tietoturvaongelmia niin se onnistuu kunhan alustassa ei voi tehdä mitään. Mitä enemmän alustalla voi tehdä sitä rajummin siellä on potentiaalia tietoturva-aukoille, ja aukotonta järjestelmää ei olekaan. Miten nopeasti tulevat HTML5 aukot paikataan ja kenen toimesta?

No, siinä pohdittavaa. HTML5 on mielestäni mielettömän kaunis ja lupaava teknologia, mutta se ei ole mullistava eikä sovelluskehityksen pelastaja eikä missään nimessä ongelmaton. Siinä tulee olemaan tietoturvaongelmia ja vakavia sellaisia kun sen käyttö lisääntyy, samalla kun sen ominaisuudet muuttuvat paremmiksi. Suuren vallan mukana tulee suuri vastuu.

Monet artikkelit ja mielipiteet julistavat sokeasti HTML5:den uutta tulemista ja kaikkien rikkaiden käyttöliittymäteknologioiden kuten Flash, Applet, JavaFX kuolemaa, ja tämä on ehkä yksipuolinen näkemys. En halua myöskään väittää että JavaFX jyräisi HTML5:sen, tuskinpa vain. Hyvä jos sille tilaa riittää markkinoilla. Mutta HTML5 ei ole Suuri Pelastaja joka mullistaa kaiken. Se on yksi teknologia muiden joukossa, ja omaa samoja ongelmia kuin muutkin. Suorituskyky, pääsy uusiin rautaratkaisuihin ja rajapintoihin client päässä, todellinen siirrettävyys eri alustoilla kuten eri selaimet, käyttöjärjestelmät, ja eri valmistajien mobiililaitteet, sekä tietoturva, ovat kaikki haasteita, jotka tulee ratkaista. Yhtäkaikki ei ole huono juttu että 2015 vuonna työkalupakissa on useita hyviä uusia mahdollisuuksia.

Lähdelinkkejä ja lisäluettavaa:

Facebook liian aikaisessa HTML5:sen kanssa:
http://css.dzone.com/articles/facebook%E2%80%99s-html5-mistake

HTML5 suorituskykyä voidaan kiihdyttää:
http://www.html5rocks.com/en/mobile/nativedebate/

Green is good 😉
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)

Java vs HTML5 Canvas:
http://www.zynaps.com/site/experiments/mandelbrot.html

Mainokset

JSF 2 ja AJAX

Pitkästä aikaa pääsin taas pitämään JSF 2 koulutuksia. Kovasti olen tästä tekniikasta itse pitänyt, siinä on huomattavia parannuksia versioon 1 nähden mutta siltikään ei joudu aikaisempia oppejaan täysin hukkaan heittämään.

Yksi koukuttava uutuus on JSF AJAX moduuli. JSF 1 heikkoutena oli aiemmin että kun se oli täysin serveripuolen ratkaisu, ja vielä korkealla nostetulla abstraktiotasolla, niin AJAX ei oikein istunut kuvaan. Sitä voi scriptata komponenttien sisään mutta Googlen suosima yhden sivun ajax malli ilman navigointia ei oikein onnistu elleivät kontrollit keskustele keskenään niin client kuin server puolellakin.

JSF 2 to the rescue! Nyt löytyy parannettu elinkaarimalli, JavaScript kirjasto AJAX:ia varten, ja myös helppo tag jolla käskyttää JSF kontrolleja JavaScriptin kautta. Näin ollen sivu jolta ei navigoida ollenkaan pois on nyt mahdollinen.

Perusidea on että vaiheet execute (sisältäen muodosta oliomalli sivusta, päivitä sitä lähetetyillä parametreilla, validoi, konvertoi, kopioi tiedot model:eihin, ja suorita koodi) ja render (käy puumalli läpi ja käske kontrolleja generoimaan lopputulokseen tarvittava HTML) on nyt erotettu toisistaan, ja lisäksi tukevat osittaista suoritusta ja renderöintiä. Näin voidaan pähkinänkuoressa sanoa: Suorita kontrolliin a liittyvät vaiheet, ja piirrä kontrolli b. Eli reagoi johonkin eventtiin, ja päivitä joku osa sivua.

Tässä siis klassinen hello world versio tästä:

<h:form>
   <h:inputText id="name" value="#{helloBean.name}"/>
     <h:commandButton value="Greet me">
	 <f:ajax execute="name" render="output" />
     </h:commandButton>
   <h2><h:outputText id="output" value="#{helloBean.greeting}" /></h2>
</h:form>

Eli tuossa käytännössä todetaan: kun painat nappia, suorita kontrolli jonka id on ’name’, ja päivitä kontrolli jonka id on ’output’. Jos haluaa reagoida muihin javascript eventteihin, ylläolevassa voidaan lisätä parametri ’event’. Ja suorittaessa kontrollia ’name’ mekanismi käy siis pistämässä kaikki muuttujat paikalleen, ja ajaa tarvittaessa myös action bindingit. Todellinen voima ei piile napin painalluksen käsittelyssä, vaan muissa javascript eventeissä, mutta sekin voi olla hyödyllinen – esim. taulurakenne jossa on sorttaukseen ja sivutukseen napit jotka eivät navigoi pois sivulta, vaan päivittävät managed bean tilaa ja renderöivät vain taulun uusiksi.

Tässä esimakua aiheesta, jos päädyn leikittelemään asialla lisää kirjoittelen pikkasen hello worldiä kiintoisampia kikkailuja. Näitä on toki jo maailmalla ruodittu, esim. html 5 canvas elementistä saa paketoitua aika kivan komponentin JSF 2 komposiittimallilla.

 

AJAX Tietoturvahuolet

Pikkasen olen jo pitkän aikaa uumoillut miten tulevina vuosina tullaan kiroilemaan kaikkia AJAX:in ylikäyttöön liittyviä tietoturvahuolia ja virheitä ja sotkuisia JavaScript mylläköitä. Edes Google ei ole ollut haavoittumaton näiden suhteen. Vietin suurimman osan 2000-luvun alkua saarnaten miten JavaScriptin käyttö on saatanasta koska se johtaa selainriippuvuuksiin ja on lähes mahdotonta testata eri selainyhdistelmillä, ja mitä enemmän JavaScriptiä sitä enemmän myös siirrämme tilatietoa ja vastuuta selainpäähän – päähän johon ei voi luottaa. Mikä sitten on muuttunut niin että AJAX on yllättäen turvallisempaa? Ei oikeastaan mikään..

AJAX oireilee samaa ongelmaa. Käyttäjä kirjautuu sisään – missä käyttäjän autentikointistatus ja id luuraavat? Onko syötteiden validointi sellaista että luotetaan JavaScriptin olevan aina päällä ja toimivan moitteettomasti? Mitä enemmän teet client päässä sitä enemmän kysymyksiä herää. Selain on vihamielistä maaperää. Keskiverrot tietokonekyvyt osaavalle on triviaalia muuttaa kaikki selaimeen lähetetty toimimaan täysin eri tavalla, oli sitten kyse cookieista tai javascript logiikasta. Voimme tietysti siirtää riskialtista tilaa enemmän palvelinpäähän, ja mahdollisesti logiikkaa myös, mutta sitä taas monet frameworkit ja koodit eivät tee.. Eli tulevina vuosina odotettavissa enemmän ja enemmän hauskoja pikku sivuefektejä rikkaita käyttöliittymiä hyödyntäville sovelluksille – no ainakin osille niistä. Aika ajoin törmää ratkaisuihin joissa nämä on tehty fiksummin, ja toki kehnosti tehdynkin sovelluksen voi auditoida ja panssaroida jälkikäteen.

Sitä odotellessa, tässä muidenkin mietteitä, enemmän tuon JavaScriptin puolelta kuin niinkään AJAX:ista: http://www.dzone.com/links/r/javascript_must_die.html

Ja tässä harvinaisen selkeä selitys Scrum:sta: http://www.dzone.com/links/r/presentation_scrum_at_bbv_software_services_ag.html