HTML 5, ja muita jorinoita

No niin, HTML 5 pompsahti pari päivää sitten standardiksi, viimein. W3C päivitti draftin moodiin recommendation, ja nyt se on sitten ihan leimaa myöten valmis.

http://www.w3.org/TR/html5/

Sinänsä tällä ei näytä olevan sen suurempia vaikutuksia – HTML5 on ollut de facto standardi jo hetken aikaa, ja toisaalta eiköhän sitä vielä jatkossakin ehosteta tarpeen vaatiessa.

Hauskaa on se, että kuten suurten selainsotien aikaan 90-luvulla, taaskin standardin tuki vaihtelee villisti ja tulkinnat myös. Oman selaimen yhteensopivuutta voi mittailla vaikkapa täältä:

http://html5test.com/

Omalla koneella vasta pyöräytetyt tulokset 555 maksimipisteestä:

Chrome: 512

Firefox: 475

Internet Explorer: 376

Chrome selain Nexus 5 puhelimessa: 497

Eli kuten aina selainten ihmeellisessä maailmassa, standardi on ”standardi”. Siltikin, näin periaatteessa ainakin, monia uusia kikkoja voi käytellä selaimissa. Niiden toimivuutta yksittäisille versioille voi mittaroida myös esim.

http://caniuse.com/

Mainokset

Netbeans 8.0.1 ja JavaScript, Angular, Require, Grunt,…

Netbeans 8 on ollut kaikista kehutuista ominaisuuksistaan huolimatta Javascript käytössä lähinnä glorifioitu tekstieditori. Tarkoittaen, että ominaisuudet vaativat toimiakseen tietyn HTML5 tyyppisen projektin, esim. Maven tai web projektit eivät kelpaa, saati sitten freeform kansiot. Sen kanssa on pärjäilty tähän asti, lähinnä Maven-tuen ja Git-tuen hyvän integraation vuoksi.

Nyt tuli kuitenkin putkesta ulos 8.0.1 päivitys, ja siinä on pieniä parannuksia tälle kentälle. Jatkossakin on vielä varaa paljon parantaa – mutta jokainen askel eteenpäin on hyvästä.

Yksi päivityksistä on parempi tuki require-moduulihallinnalle. Se löytyy nyt myös Maven projektin asetuksista:

RequireJS kirjastot

Kuten dialogista näkee, voi halutessaan määritellä polkuja myös manuaalisesti jotta moduulit löytyvät – rasti ruudussa pitäisi kuitenkin pitkälti riittää. Kun moduulit löytyvät, monet intellisense/content assist mahdollisuudet paranevat:

Content assit for require paths

Intellisense

Tosiaan kaukana ollaan vielä täydellisyydestä, parannettavaa on vielä. Intellisense on paranemaan päin mutta esim. angular templateiden ymmärtäminen aivan alkutekijöissä: nykyisellään niistä tulee lukemattomia html5 sääntömotkotuksia mm. attribuuteista ilman arvoja tai siitä mikä elementti voi olla missäkin kohtaa. Useimmat niistä ovat vääriä hälyytyksiä, mutta niiden sekaan häviävät sitten merkityksellisetkin.

Tosiaan editoripuolella suosittu vaihtoehtohan on Webstorm, itse en siitä niin innostunut koska kaupallinen ja koska Maven projektituki edelleen ainakin omalle logiikalle kehno. Muita hyviä keveämpiä open source editoreita ovat mm. Brackets, sekä Sublime. Mukavasti grunt/mavenillä rakennetussa projektissa on kivaa se että voi käyttää mitä editoria haluaa, kunhan koodin muotoiluasetukset ovat yhtenevät. Brackets tuli blogin lukijavinkkinä, ja olen siihen tykästynyt.

JSF 2.2 Faces Flow ja HTML5 friendly layout

Odotellessa tulevaa Java EE 7 sekä Java SE 8 standardia olen seuraillut yksittäisten spesifikaatioiden kehitystä. Yksi mielenkiintoinen päivitys on Java EE 7:n tuleva JavaServer Faces 2.2 versio. Se on näennäisesti taas minor update, eli ei arkkitehtuurin uusintaa kuten aikanaan 2.0 päivitys – mutta pienet päivitykset kasaantuvat aika mielenkiintoisesti.

Mitäpä on odotettavissa JSF 2.2 versiossa? Yksi kiintoisa piirre on Wicket-frameworkin tapainen mahdollisuus käyttää HTML5 pohjaa ja id attribuutteja aiemman tag-mallin sijasta. Tässä esimerkki uudesta JSF 2.2 leiskasta tähän tapaan tehtynä:

< !DOCTYPE html>
< html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:jsf="http://java.sun.com/jsf" xmlns:f="http://java.sun.com/jsf/core">
    < head jsf:id="head">
        < title>Putting it all together < /title>
        < script jsf:target="body" jsf:name="js.js"/>
        < link jsf:name="css.css" rel="stylesheet" type="text/css" />
    < /head>
    < body jsf:id="body">
        < form jsf:id="form" jsf:prependId="false">
            < label jsf:for="name">Name < /label>
            < input jsf:id="name" type="text" jsf:value="#{complex.name}">
                < f:ajax execute="@this" render="progress"/>
            < /input>
            < label jsf:for="tel">Tel < /label>
            < input jsf:id="tel" type="tel" jsf:value="#{complex.tel}">
                < f:ajax execute="@this" render="progress"/>
            < /input>

            < label jsf:for="email">Email < /label>
            < input jsf:id="email" type="email" jsf:value="#{complex.email}">
                < f:ajax execute="@this" render="progress"/>
            < /input>

            < label for="progress">Progress < /label>
            < progress jsf:id="progress" max="3">#{complex.progress} of 3 < /progress>

        < /form>
    < /body>
< /html>

Kiintoisaa? Miksei, onhan se. Toinen itseä kiinnostava tutkaan osunut piirre on JSF Faces Flow. Idea on itselle tuttu Spring Web Flow moduulin puolelta – sensijaan että navigointisäännöt naputellaan sivuihin, määritellään sivuilla liikkuminen ja eri vaihtoehdot erilliseen tiedostoon. Tässä ei ole kuitenkaan kyseessä vain navigointi, vaan page flow voi myös sisältää logiikkaa, virhekäsittelyä, jne. Faces Flow on valittu ns ’Big Ticket Feature’:ksi, eli on merkittävä osa JSF alustaa ja sen ympärille rakentuu paljonkin pientä.

Yksi osa on uusi Scope annotaatio, @FlowScoped, joka määrittää luokan elinkaareksi senhetkisen Flown (kääntäisikö tuon virtaukseksi? Aika kömpelö käännös). Tarkoittaa että scope voi olla yli yhden requestin mutta vähemmän kuin session verran. Tätä voisi vertailla hieman @FlashScoped-laajuuteen, mutta viimekädessä elinkaaren määrittää siis määritelty flow, ei se montako kutsua serverille tehdään.

@FlowScoped ottaa flow id parametrin joka määrittää mihin flow-virtaukseen se kuuluu.

Esimerkki @FlowScoped beanistä:

@Named
@FlowScoped(id = "someFlowName")
public class SomBean {
    public String someReturn() {
        return "/somePage.xhtml";
    }
}

Käytössä on oletuksia mitkä helpottavat elämää: flow oletussivu voidaan luoda luomalla kansio jonka nimi on sama kuin flow id, sekä .xhtml tiedosto jonka nimi on edelleen sama kuin flow id, esim:

/someFlowName/someFlowName.xhtml:

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:j="http://java.sun.com/jsf/flow"
>
    <f:metadata>
        <j:faces-flow-definition>
            <j:faces-flow-return id="someReturnName">
                <j:navigation-case>
                    <j:from-outcome>#{someBean.someReturn}</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>
        </j:faces-flow-definition>
    </f:metadata>

    <!-- Rest of view -->
</html>

Flow-tiedostojen välillä voi navigoida flow-id:n avulla, eli navigaatiojärjestelmä tunnistaa nyt flow id:n. Flow id voi olla sama kuin tiedostonimi, tai se voidaan määrittää j:faces-flow-definition elementin id-attribuutilla jos tiedostonimeä ei haluta käyttää. Navigointi flow-sivulta toiselle tapahtuu tähän tapaan:

 <h:commandLink value="Enter flow" action="someFlowName" />

No niin, tässähän ei ole mitään uutta. Aiemminkin JSF:ssä on voitu navigoida sivulta toiselle sivunimen perusteella. Uutta onkin se, että flow node (virtaussolmu? :p) voi olla muutakin kuin näkymä, view. Se voi olla myös Switch (EL lause joka evaluoi mikä on seuraava node), Return (virtauksen paluuarvo),  Method Call (vapaavalintaisen metodin suoritus ja navigaatio), tai Faces Flow Call (uuden flow-sarjan käynnistys).

Ja tässä vähän mehukkaampi Faces Flow määritys:

 

<f:metadata>
        <j:faces-flow-definition>

            <j:initializer>#{someBean.init}</j:initializer>
            <j:start-node>startNode</j:start-node>

            <j:switch id="startNode">
                <j:navigation-case>
                    <j:if>#{someBean.someCondition}</j:if>
                    <j:from-outcome>fooView</j:from-outcome>
                </j:navigation-case>
            </j:switch>

            <j:view id="barFlow">
                <j:vdl-document>barFlow.xhtml</j:vdl-document>
            </j:view>
            <j:view id="fooView">
                <j:vdl-document>create-customer.xhtml</j:vdl-document>
            </j:view>

            <j:faces-flow-return id="exit">
                <j:navigation-case>
                    <j:from-outcome>/exit</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>
            <j:faces-flow-return id="error">
                <j:navigation-case>
                    <j:from-outcome>/error</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>

            <j:finalizer>#{someBean.finish}</j:finalizer>

        </j:faces-flow-definition>
    </f:metadata>

 

Joten tällaista tänä vuonna. Vuosi 2013 on Javan kannalta jännä vuosi tulevien standardien johdosta. Spring Framework 4 tulee luonnollisesti sisältämään tuen myös EE 7 ja SE 8 piirteille, se on jo työn alla.

 

Sampo luopuu Javasta

Client pään Java on kokenut kovia iskuja viime aikoina, melkein voisi puhua viikon tietoturvareiästä. Jatkuvalla syötöllä on löytynyt heikkouksia ja reikiä joita jopa kaupataan kelle hyvänsä joka haluaa niitä käyttää. Oracle on pelaillut catch-up peliä mutta paikkoja tulee myöhässä, ja näemmä vasta kun haavoittuvuus päätyy lööppeihin, ja samalla kun tulee paikka löytyy uusi reikä.

Tämä ei tietysti eroa siitä mitä Flashille tapahtui aikanaan, eikä siitä mitä HTML5:lle tulee tapahtumaan jahka se yleistyy. Eikä tietysti vaikuta niinkään palvelin-Javaan joka on edelleen Javan suurin käyttöalue. Mutta on se aika ikävää työasemien osalta. Itsekin olen päivitellyt updateja tiuhemmin kuin yleensä, ja yrittänyt sulkea Javan pois selaimista joita en käytä. Sampo pankin asiakkaana on jopa ollut ikävää käytellä verkkopankkia joka vaatii Java Applet tukea toimiakseen ollenkaan. Muun hauskan lisäksi kotona 64-bittisellä win8:lla ainoa selain jolla sampo pankin Java applet toimii oli Microsoft Internet Explorer – joka perinteisesti on ollut kävelevä tietoturvareikäjuusto jota en juuri edes käynnistä vuosiin jos voin sen vältellä. Luotettu Chrome ja Firefox kieltäytyvät eri tavoin yhteistyöstä – Chrome valittaa että Javaa ei ole asennettu vaikka sen on moneen kertaan eri variaatioina asennettukin, ja Firefox vain mystisesti jää pyörimään, lataan Javaa-looppiin.

Mutta tämä ei lupaa kovin hyvää JavaFX-tekniikalle, joka muutenkin on kyseenalainen HTML5:sen kanssa kilpailuasetelmassa oleva teknologia. Se vaatii vakaan ja turvallisen Java-asennuksen toimiakseen, ja onko sellaista luvassa enää? Asia on sikäli murheellinen että JavaFX on kaunista, esteettistä, tehokasta. Mutta ellei tässä tapahdu muutoksia se on tuhoon tuomittu jo alkumetreillään. Aika näyttää, tämä on Javan vuosi, sillä tulossa on massiiviset ja mullistavat Java SE 8 sekä Java EE 7 päivitykset – paljon tulee muuttumaan Java maailmassa.

 

Lähde:

http://yle.fi/uutiset/danske_bank_luopuu_javasta_-_verkkopankkiin_uudistuksia/6470709

 

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