Everything a Java Developer should know

Hier zijn 10 tips om je als Java ontwikkelaar te helpen om een overzicht te krijgen van het JavaScript ecosysteem. Dit is vooral van belang als je werk gericht is op de ‘enterprise’, dat wil zeggen; grote applicaties die de komende jaren schaalbaar en onderhoudbaar moeten blijven.

In de afgelopen jaren is veel onderzoek gedaan, en vooral veel geëxperimenteerd, rond de vraag hoe JavaScript het meest optimaal gebruikt kan worden – en of het überhaupt bruikbaar is – in grote applicaties die onderhoudbaar moeten blijven. De vraag is eigenlijk of JavaScript vooral en misschien alleen bruikbaar is in kleinere applicaties die snel opnieuw ontwikkeld kunnen worden en waar ‘onderhoudbaarheid’ minder van belang is.

Het onderzoek is bijzonder intens geworden in het licht van een reeks vrij recente ontwikkelingen. Deze draaien om drie specifieke factoren, te weten:

 

• Meerdere apparaten en ‘responsive design’

De explosie van het aantal mobiele apparaten en tablets betekent dat termen zoals ‘schermgrootte’ en ‘resolutie’ belangrijke onderwerpen geworden zijn. Je kan er niet meer van uitgaan dat gebruikers dezelfde, of zelfs vergelijkbare, ervaringen bij het werken met dezelfde applicatie zullen hebben. Je moet nadenken over de apparaten waarop applicaties eventueel gebruikt zullen gaan worden en nieuwe technologieën en hulpmiddelen vinden die op de één of andere manier de omgang met deze verschillende ervaringen versoepelen ofwel de verschillen weten te verbergen.

• De browser is nu echt overal

Waar Java ontwikkelaars er met de ‘write once, run anywhere’-mantra van uitgegaan zijn dat op een gegeven moment iedereen het wel zou snappen en dat de JVM overal beschikbaar zou zijn, blijkt nu dat – althans voor ‘frontend’ ontwikkeling – de browser veel dominanter en veel meer algemeen beschikbaar geworden is. Dit maakt veel meer verschillende soorten applicaties mogelijk. Alle ‘devices’ kennen ondertussen de browser, of ze nu nieuw en glanzend zijn, namelijk tabletten en telefoons of traditioneel, zoals PC's en laptops. Dat betekent natuurlijk niet dat Java geen rol meer te spelen heeft, vooral in business logica en ‘backend code. Maar het betekent wel dat de browser voor een groot aantal applicaties het ideale doelwit is voor het maken van user interfaces voor interactie met data, waar die data zich ook mag bevinden.

• Single page applications (SPA)

Zoals de term al aangeeft, is een SPA een web applicatie of website dat op één enkele webpagina past en gericht is op een coherente en vloeiende ervaring voor gebruikers. Het is vergelijkbaar met een desktop applicatie. Steeds vaker gaat de ontwikkeling van de ‘use cases’ hierboven beschreven naar de ‘client’, dat wil zeggen, de voorkant, en zoveel als mogelijk wordt weer lokaal gedaan, in tegenstelling tot de server-gebaseerde benaderingen die de meeste Java ontwikkelaars zijn gaan gebruiken over de afgelopen jaren.

De hierboven genoemde vrij recente ontwikkelingen, in die zin dat ze met toenemende snelheid over de afgelopen 5 jaar ontstaan zijn, zijn zeker met elkaar verbonden. Bijvoorbeeld, met een beperkte schermgrootte op kleine apparaten – die nog steeds continu populairder aan het worden zijn, zodanig dat de explosie als een continu proces beschouwd kan worden – is het zinvol om applicatieontwikkeling te richten op SPA’s, die veel minder ruimte en netwerkverbruik dan de eerdere webontwerpen vereisen.

Tot een aantal jaar geleden was men voornamelijk gericht op applicaties met meerdere pagina's. Dit leverde veel geklik op en problemen die vaak te maken hadden met navigatie van pagina naar pagina, terwijl steeds meer netwerkbandbreedte nodig was voor de steeds verder groeiende en schalende applicaties. Snellere navigatie is een vereiste als je aan moet nemen dat de gebruiker worstelt met de levensduur van een batterij in een mobiele telefoon. De beste navigatie ervaring is nul navigatie. De beste oplossing is dan om de gehele applicatie binnen één enkele pagina te ontwikkelen.

 

Hier volgen de 10 handige tips en/of inzichten die de bedoeling hebben om Java ontwikkelaars te helpen om de juiste vragen te stellen bij het evalueren van de mogelijkheden die het JavaScript landschap aanreikt.

• 1. Niet één pasklare oplossing

Hoewel het klopt dat een zeer groot aantal applicaties steeds kleiner en meer gefocust worden, moet je niet vergeten om altijd eerst na te denken over ‘business requirements’ voordat je begint met het kiezen van de daarbij passende technologieën. Neem niet aan dat je automatisch alles moet weg gooien en opnieuw moet beginnen met een SPA in de browser.

Er is niet één pasklare oplossing en er blijft een behoefte aan, bijvoorbeeld, de Java desktop omdat een mobiele app gewoon niet voor iedereen de meest geschikte vorm is om met data te werken. Grote applicaties voor industrieën, zoals luchtverkeersleiding, blijven bestaan en het zou krankzinnig zijn om een mobiele applicatie te maken voor het monitoren en beheren van het landen en opstijgen van vliegtuigen. Gebruikers van systemen die voor luchtverkeersleiding gebruikt worden, hebben behoefte aan een grote resolutie om dat te doen. In ieder geval als ze dat veilig willen doen. Kortom, ga er niet vanuit dat de nieuwe en glanzende hulpmiddelen en technologieën van toepassing zijn voor alle denkbare scenario’s. Onderzoek wat gebruikers in jouw domein eigenlijk doen en wat ze echt nodig hebben. Dwing de gebruiker niet de browser in als ze daar geen baat aan zullen hebben.

Als je trouw bent aan de principes van ‘agile development’, dan weet je wat je gebruikers zelf echt nodig hebben. Dit wellicht in tegenstelling tot wat de directie van je eigen bedrijf of dat van je gebruikers wil.

• 2. Framework vs. library

Angular is op dit moment zo populair dat het zich lijkt te bewegen in de richting van een de-facto JavaScript standaard. De meeste Java ontwikkelaars die aan het experimenteren zijn met JavaScript beginnen met Angular, want dat is waar alle ‘buzz’ is. Nog steeds, na enkele jaren van JavaScript frameworks die steeds populairder worden. Waar nog steeds een aanzienlijke hoeveelheid werk met Backbone, Knockout, Ember en dergelijke gedaan wordt, is Angular duidelijk dominant en dat lijkt niet snel te gaan veranderen. Maar let ook op React dat een duidelijk en nieuw geluid laat horen en ook veel mogelijkheden te bieden heeft.

Een deel van de reden voor de populariteit van Angular is dat het een raamwerk is en niet een library. Een alternatieve route houdt in dat je specifieke libraries bij elkaar verzamelt. Bijvoorbeeld, vind je het MVC patroon belangrijk? Kies dan Backbone. Wil je echter focussen op ‘two way databinding’ en niets anders? Kies dan Knockout. Wil je je vooral op UI componenten richten? Kies dan Ember of React. Deze library-gerichte aanpak verspreidt je inzet. Dit betekent wel dat je de stukjes van de puzzel zelf in elkaar moet zetten in plaats van dat Angular dat voor je doet.

• 3. Evalueer corporate frameworks

Een duidelijk teken van de toenemende volwassenheid van het JavaScript ecosysteem is dat de grote bedrijven een rol willen spelen. Bijvoorbeeld, neem een kijkje naar DoubleClick van Google, het Salesforce1 Platform van Salesforce, SpectINGular van ING en het MobileFirst Platform van IBM.

In elk van deze platformen wordt een reeks bestaande frameworks als uitgangspunt genomen en er worden dan business-specifieke onderdelen toegevoegd. Kijken naar grote bedrijven en zien wat ze doen met JavaScript is een slim plan. Bedrijfsoplossingen met behulp van JavaScript hebben een levensduur die langer is dan de onderliggende componenten. Zien waar de corporaties heen gaan en het afstemmen van keuzes aan hun overwegingen zou een benadering kunnen zijn voor kleinere organisaties die nieuw zijn in het JavaScript-landschap.

• 4. Modulariteit is mogelijk

Als een nieuwe taal op de JVM wordt aangekondigd, is de ingebouwde modulariteit vaak de belangrijkste eigenschap die wordt rondgebazuind (in tegenstelling tot Java zelf, natuurlijk). In staat zijn om de code te organiseren in betekenisvolle structuren is iets dat een groot deel van ontwikkelaars duidelijk interessant vindt en zelfs belangrijk.

OSGi is jarenlang de standaard voor modulariteit geweest voor Java ontwikkelaars. Het enige alternatief zijn systemen die gebruik maken van het NetBeans Platform, waarbij het NetBeans module systeem, vergelijkbaar met OSGi, gewoonlijk gebruikt wordt. In de context van JavaScript, evalueer RequireJS en Browserify, die allebei modulariteit bieden, terwijl er bij ECMAScript 6, de meest recente versie van de JavaScript spec, modulariteit ingebouwd is.

• 5. Vergelijk responsive CSS met responsive JavaScript

CSS3 gaat vooral over media query’s. Een media query is een combinatie van een media type en één of meer uitdrukkingen die controleren op specifieke voorwaarden van media functies. Zo kan bijvoorbeeld een media query gebruikt worden om de huidige omvang van het scherm te controleren. Media query’s kunnen worden gebruikt om inhoud te tonen of te verbergen op basis van de gedefinieerde voorwaarden, zoals schermgrootte.

Er kan echter iets interessants worden opgemerkt als je tools gebruikt, zoals de Chrome Connector plugin met NetBeans IDE. Met dit soort instrumenten kan je zien dat als een media query gebruikt wordt, bijvoorbeeld zoals hieronder getoond, wanneer de breedte van het scherm kleiner is dan 480, de bijbehorende inhoud, zoals een logo of ander beeld, nog steeds geladen wordt.

 

@media (min-width: 481px) {
    .logo:before {
          content:url("images/coca_cola_logo.png");
          display: block;
          text-align:center;
            }
}
@media (max-width: 480px) {
    .logo:before {
          display: none;
    }
}

Listing 1

De DOM bevat de elementen en attributen, al worden ze verborgen door de media query. Stel je voor dat je dynamisch content zou kunnen definiëren in je JavaScript, op basis van breekpunten en data attributen. Dat is wat Response.js en Foundation Interchange mogelijk maken. Beide bieden een responsieve JavaScript oplossing waarmee ze vermijden dat DOM elementen geladen worden zonder nodig te zijn.

Laten we even een kijkje nemen naar één van deze oplossingen. Foundation is een UI library, vergelijkbaar met Twitter Bootstrap en Angular UI. In de 5.0 release van Foundation werd Interchange beschikbaar gesteld. Interchange is responsive JavaScript, zodat je krachtige dingen kan doen op de client, binnen de HTML-weergave van een aanvraag. Vooraf gedefinieerde resolutie markers zijn beschikbaar. Dat wil zeggen ‘small’, ‘medium’ en ‘large’, die elk verwijzen naar een HTML-bestand, zoals hieronder getoond:

<div data-interchange="
     [fragments/small.html, (small)],
     [fragments/medium.html, (medium)],
     [fragments/large.html, (large)]">
</div>

Listing 2

Dankzij de bovenstaande code laadt Foundation Interchange het juiste fragment automatisch wanneer de schermgrootte is veranderd.

• 6. HTML is nu een application framework

Je hebt het misschien (nog) niet gemerkt, maar HTML is nu een applicatie framework. Dit biedt voor het eerst component-georiënteerde oplossingen. In de HTML5-specificatie is de beslissing genomen om ervoor te zorgen dat alle nieuwe functies gebaseerd zullen zijn op HTML, CSS en JavaScript, naar aanleiding van de nieuwe Shadow DOM specificatie, en dat de behoefte aan externe plug-ins, zoals Flash, moet worden verminderd. Bovendien, nieuw toegevoegde high-level functies, zoals error handling en de onafhankelijkheid van het apparaat, zijn twee andere indicatoren dat er iets groots veranderd is.

Bijvoorbeeld, wist je dat een ‘code completion box’, dat wil zeggen, ‘IntelliSense’ functionaliteit, in HTML kunt maken?

Hier is de HTML voor de bovenstaande met Knockout om gegevens van JavaScript laden. Hierin staat een ‘list’ attribuut in het input element, dat deze verbindt met de datalist element eronder. Zowel het ‘list’ attribuut als het ‘datalist’ element zijn nieuw in HTML5.

<input id="countryInput"
       type="text"
       data-bind="value: selectedCountry"
       list="countryList" />
 
<datalist id="countryList" data-bind="foreach: countries">
    <option data-bind="value: country"></option>
</datalist>

Listing 3

HTML is allang geen eenvoudige opmaaktaal meer, maar de basis van een full blown multimedia-ervaring met specifieke toepassingen voor animaties, games en films. HTML bevat nieuwe mediatypes, zoals ‘audio’ en ‘video’, evenals nieuwe semantische code, zoals ‘artikel’ en ‘header’ samen met nieuwe validatie attributen (bijvoorbeeld ‘vereist’ en ‘patroon’) en invoer-types (bv, ‘e-mail’, ‘url’, ‘kleur’). Deze nieuwe standaarden worden door alle browsers toegepast of staan gepland om doorgevoerd te worden. Wees je bewust van deze nieuwe mogelijkheden en bekijk HTML op een nieuwe manier: als een applicatie-framework.

• 7. JavaScript is de Assembler-taal van het web

Enkel en alleen omdat JavaScript de taal is van de browser, betekent dit niet dat het de taal is die je moet gebruiken om te coderen. Als JavaScript je niet aanspreekt, verken dan de transpilers die beschikbaar zijn, alsmede de daarmee samenhangende oplossingen. CoffeeScript, TypeScript, Vaadin en DukeScript zijn bijvoorbeeld een paar van de vele technologieën die proberen om het werken met JavaScript te vereenvoudigen.

• 8. Gebruik abstracties

Tenzij je tevreden bent met rechtstreeks coderen in JavaScript, HTML en CSS, verken abstracties die bovenop deze technologieën gebouwd zijn. Dat wil zeggen, vindt hulpmiddelen, zoals Emmet voor HTML, SASS en LESS voor CSS en CoffeeScript (en andere technologieën hierboven genoemd) voor JavaScript.

Speciaal voor Java-ontwikkelaars, wij die zijn verwend door het hebben van één enkele taal (zelfs geen XML meer, want we hebben Java-annotaties gekregen om mee te werken), helpt het om instrumenten en technologieën te hebben die het feit verbergen dat meerdere talen worden gebruikt, met de bijbehorende context switching en productiviteitsverlies als gevolg.

• 9. "Write Once, Never Touch Again"

Vaak hoeven de applicaties die geschreven zijn in het JavaScript landschap niet onderhouden te worden. Of ‘onderhoudbaarheid’ betekent iets anders dan wat we tot nu toe gedacht hadden. De business case is vaak heel dun: "schrijf een app om mijn product te verkopen" of "laat de gebruiker een kamer reserveren in een hotel". Het team van ontwikkelaars – ongeveer 2 of 3 in totaal – zet de app in elkaar, levert het en gaat vervolgens door naar de volgende app. Als zes maanden later een nieuw feature request binnenkomt, is een nieuwe app samenstellen vanaf nul praktischer. Wel wordt gebruik gemaakt van de nieuwe versie van de technologie die oorspronkelijk gebruikt werd of vervangers hiervan.

Oké, dus dit is niet de ‘enterprise’ of toch wel? Zouden we kunnen zeggen dat het de nieuwe onderneming is? Het is niet de onderneming zoals we die kennen met lange ontwikkelingscyclussen, maar het past zeer nauw samen met de ideeën van agile development. De technologieën en frameworks in het JavaScript landschap zijn ideaal voor dit soort apps, ver verwijderd als ze zijn van de grootschalige, complexe en wetenschappelijke apps waarmee Java ontwikkelaars vertrouwd zijn geworden.

Domeinkennis is een dunne laag die iedereen kent. Bijvoorbeeld, iedereen kent wel de fundamentele parameters van een hotel boekingssysteem. De time-to-market is kort en de levenscyclus van de app is overeenkomstig met die cyclus.

• 10. Vluchtigheid van het JavaScript ecosysteem is oké

Een typische ‘feature’ van het JavaScript-landschap is dat juist op het moment dat je een nieuwe technologie net een beetje onder de knie hebt, het (a) verdrongen wordt door één van haar concurrenten, het (b) onherstelbaar verschrikkelijk zal blijken te zijn, (c) het niet blijkt te werken in combinatie met één van de andere technieken die je nodig hebt, (d) het niet langer ontwikkeld wordt, of (e) een combinatie van al het bovenstaande. Als dit soort volatiliteit een groot probleem is, heb je misschien minder aan het gehele JavaScript landschap. Blijf dan bij de technologieën die je kent en de oplossingen die de tand des tijds hebben doorstaan.

 

Tot slot

Zoals blijkt uit de bovenstaande lijst is het JavaScript ecosysteem niet voor iedereen. Bovendien zou het JavaScript ecosysteem iets anders kunnen zijn dan je zelf verondersteld hebt dat het is. Het is een vreemde plek, echt een soort cowboy-land. Het is ook een interessante plek en een innovatieve plek. Innovatie en verandering zij dingen waar wij als Java ontwikkelaars net wat minder van gehad hebben. Misschien hebben we daardoor zelfs meer stabiliteit dan we zelf zouden willen hebben en is het tijd voor iets nieuws. Spring in het zadel en ontdek het nieuwe landschap! Maar wees gewaarschuwd, er kan altijd een cactus zijn of net iets meer beren en wolven dan je in eerste instantie gedacht zou hebben.