In de nieuwste browsers wordt JavaScript omgezet naar bytecode (geen Java bytecode, maar wel hetzelfde idee) en is dus niet puur een geïnterpreteerde taal meer. Zie bijvoorbeeld SquirrelFish, de nieuwste JavaScript interpreter in Safari: http://webkit.org/blog/189/announcing-squirrelfish/

Het afgelopen jaar heb ik echter nog geen spectaculaire tools gezien voor JavaFX. Werd er op deze JavaOne nog iets gezegd over JavaFX tools waarmee niet-ontwikkelaars ermee aan de slag kunnen (als alternatief voor Flash of Silverlight)?

Hoe met html, body en head tags wordt omgegaan is ook instelbaar, zo kun je verschillend omgaan met een volledig document of met een fragment.

Maar ik ben een fan van xslt en daarom bevooroordeeld

Hoe gaat ie om met implicit closing van elementen? denk aan iets als <b>aap<i>noot</b>mies</i>, wat geparsed zou moeten worden als <b>aap<i>noot</i></b>mies

(ai, er wordt niet ge-html escaped in de comment, bovenstaand geeft iig aan hoe het geparsed wordt)

Hoe gaat ie om met implicit closing van elementen? denk aan iets als aapnootmies, wat geparsed zou moeten worden als aapnootmies

Ik heb hier echter een voorbeeld willen laten zien van een probleem dat erg eenvoudig bleek te zijn op te lossen met NekoHTML (of met JTidy o.i.d.) en XML filters. XSLT zou het er niet eenvoudiger op maken in dit geval lijkt me.

jTidy kan niet alleen de html well-formed maken, maar ook valide (b.v. geen geneste p-elementen).

jTidy is te downloaden van http://jtidy.sourceforge.net/

Ik zou zelf jtidy (of NekoHTML) + xslt gebruiken, maar het opzetten van xslt voor dit eenvoudige voorbeeld is waarschijnlijk overkill

Volgens mij is dit inderdaad precies wat Okke probeert te zeggen; het gaat er uiteindelijk om dat je je werk binnen de gestelde tijd gedaan krijgt en dat het resultaat onderhoudbaar is…. en het liefst doe je dat met zo min mogelijk onnodige ‘ruis’!

Of een scripting taal daarin beter is…. soms wel. Van de andere kant geef je zelf al het voorbeeld van wanneer het omgekeerde ‘beter’ is: gwt (java boven javascript). En hiermee is denk ik een ander punt aan de vergelijking toegevoegd, dat libaries/frameworks van een taal een rol spelen.

Is het misschien niet zo dat de keuze van een oplossingsrichting (taal+ontwerp) voor een probleem grotendeels afhankelijk is van de libraries en bibliotheken die je nodig hebt. Simpel voorbeeld, als ik een simpele CRUD applicatie wil maken zonder spannende eisen, dan kies ik een framework wat daarin uitblinkt bijv. Rails en daarmee de taal ruby. Echter als een andere taal een gelijksoortig framework heeft dan is die taal wellicht net zo geschikt.
Verbosity gaat dan waarschijnlijk toch maar een kleine rol spelen in de te behalen velocity bij het ontwikkelen.

Oh en ik moest gelijk denken aan dit artikel + discussie:
http://ola-bini.blogspot.com/2008/04/pragmatic-static-typing.html
de mooiste flamewar in tijden

Dit vind ik een grappige uitspraak. Het lijkt alsof hij hiermee wil zeggen dat Groovy dus net zo goed is als Scala

Voordelen van static typing: Veel fouten kunnen tijdens compilatie opgespoord worden. Het voorkomt dus runtime fouten en je hoeft niet minder code te (unit)testen. Refactoring is makkelijker en de tool support is beter (kan beter zijn, het is nog even wachten op de goed werkende scala eclipse plugin..). En het lijkt erop alsof het ook veel beter performed. Maar misschien ben ik niet helemaal subjectief.

Verder ben ik sterk van mening dat JS niet te genereren valt, tenminste, niet als je fatsoenlijke, onderhoudbare code wilt opleveren die ook nog eens performt. Vergeet niet dat het een geinterpreteerde taal is, die qua snelheid ver onder gecompileerde talen zit. Optimaliseren is dus juist in een taal als JS van levensbelang als je wat meer doet dan een mouseover of een xhr.

Laat ik een concreet voorbeeldje geven over het toepassen van Gestalt principes. Deze principes komen bijvoorbeeld erg van pas bij het opdelen van pagina’s in logische groepen. In vrijwel alle enterprise software zitten een paar pagina’s waar de gebruiker data kan invoeren; de primaire invoerschermen. Deze schermen zijn vaak directe weergaves van de tabellen uit de onderliggende database. Er zijn twee kenmerken:
1. Ieder data-element wordt weergegeven als label - input (button, checkbox, veld, etc.)
2. Meerdere data-elementen kunnen samen gegroepeerd worden (bijvoorbeeld tot klantgegevens of producteigenschappen)
Door nu de gestaltprincipes toe te passen op dit type schermen kun je aangeven welke elementen bij elkaar horen. Zet de data-elementen die bij klantgegevens horen dicht bij elkaar en zet de volgende groep er verder vanaf (Proximity). Houd de labels dicht bij het corresponderende input-element (ook Proximity). Het is nogal voor de hand liggend, maar het maakt een interface echt beter bruikbaar.
Een voorbeeld Common Fate vind je in webapplicaties met frames. In een frame wordt het menu getoond en in een ander de ‘content’. De content kan vaak scrollen, maar het menu niet. Dit maakt direct duidelijk wat bij elkaar hoort (dit wordt primair gedaan met behulp van kleurverschillen tussen het menu en de content en door de borders te tonen; het is maar een voorbeeld).

Overigens gaat dat voornamelijk over punt 1 en 2. Punt 3 vind ik iets practischer.

Laat me mij even voorstellen. Ik ben 41 en ben amateur op gebied van software (ik ben namelijk in het dagelijks leven financieel directeur en heb dus beperkt met ICT te maken). Ik heb wel via HTML een eigen site gemaakt als hobby (www.detukkies.nl). Mijn volgende “zondagavonddoel” is een plattegrond op het internet (dat lukt wel) met bullets waar je op kunt klikken en dan krijg je oude ansichtkaarten. Dat laatste wil nog niet lukken. Zojuist lees ik jouw verhaal en heb ik voor het eerste een handreiking. Het moet nu gaan lukken. Thanks.

Oh ja, dat vind ik dus zo mooi, dat mensen kennis willen delen, en net zoals Bill Gates, daar de hoofdprijs voor willen hebben. Dan die google jongens. Die willen wel verdienen, maar niet aan de gewone man, maar aan het grote geld van adverteerders, en dat vind ik dan weer wel mooi.

Johan

http://alistapart.com/articles/takecontrolofyourmaps

Bij het refactoren van object geörienteerde code hoef je (als je goed ontwikkeld) vaak niet heel veel (soms zelfs niets) aan je tests aan het passen. Als je echter een beetje gaat schuiven met elementen in HTML breek je bijna altijd de tests.

Nou is het wel mogelijk (tests zijn tenslotte gewoon javascript) om tests te schrijven die en goed testen en om kunnen gaan met wijzigingen in de pagina; maar dat is erg moeilijk… vooral omdat die wijziging ook een bug zou kunnen zijn.

Dit wil niet zeggen dat ik Selenium geen mooie tool vind. Maar wel dat je al vanaf het begin al erg goed moet nadenken over hoe en wat je wilt testen.

Welnu: 16 april 2008, in Belgie.