Google komt met Ajax-toolkit

Google heeft de Google Web Toolkit (GWT) vrijgegeven, een framework dat het mogelijk maakt om Ajax-applicaties in pure Java-code te schrijven. Met GWT kunnen Ajax-applicaties in Java geschreven worden met Java-ontwikkeltools zoals Eclipse, IntelliJ, JProfiler en JUnit. GWT bestaat uit een aantal libraries die in een Java-applicatie opgenomen kunnen worden en integreert met Eclipse. De GWT-compiler vertaalt de Java-applicatie naar JavaScript en HTML, die door de browsers kunnen worden verwerkt. UI-elementen kunnen worden toegevoegd aan applicaties door gebruik te maken van de 'widgets' die in het framework zijn opgenomen. Onder meer hiërarchische bomen, tabbalken, menubalken en dialoogvensters zijn standaard opgenomen in de verzameling widgets.

Niet de volledige Java-klassebibliotheek is beschikbaar als JavaScript-implementatie. De meeste java.lang-packages zijn wel beschikbaar, evenals een deel van het java.util-package, maar de rest wordt niet standaard ondersteund. De reden is deels dat packages zoals java.io geen betekenis hebben in webapplicaties aangezien zij alleen netwerk- en lokale bestandssystemen raadplegen. Voor de communicatie tussen de webapplicatie en de webserver biedt GWT een automatisch RPC-mechanisme zodat de programmeur de klassen niet hoeft te (de-)serialiseren. GWT-applicaties laten de 'terug-knop' intact volgens Google en zouden over het algemeen zonder aanpassingen uitvoerbaar moeten zijn met IE, Firefox, Mozilla, Safari en Opera. Google heeft enkele voorbeeldapplicaties, zoals Kitchen Sink, beschikbaar gemaakt die widgets en het gebruik van de terug-knop demonstreert.

Google Web Toolkit applicatie die een knop toont met klikfunctionaliteit.

Reacties (48)

[Verwijderd]

Ajax is een tijdelijke technologie die tot leven geroepen is om de tijd te overbruggen tussen 'wat was' en wat 'komen gaat'. Er zijn genoeg artikelen te vinden die AJAX toelichten, maar wat mij opvalt is dat google caches relatief minder nu gaan hebben.

Met AJAX en de toekomstige techniek is het de bedoeling dat de client (de websurfer bijv.) de grafische user interface regelt. Dat niet langer HTML server calls nodig zijn om het scherm bij te werken. De noodzakelijke bandbreedte wordt hierdoor behoorlijk gereduceerd tot slechts de contentdata van een website.

De google cache slaat juist pagina's op met inhoud. Die inhoud zal dus meer en meer verloren gaan, terwijl de opmaak meer zal toenemen. Denk hierbij aan meer interactieve componenten i.p.v. hyperlinking.

De voorbeeld applicaties zijn krachtige voorbeelden an sich, al zijn ze niet W3-compliant. Misschien dat ik er toch eens een keer naar ga kijken tot de nieuwe technologie gemeengoed is.

[mOrPhie]

Ajax is een tijdelijke technologie die tot leven geroepen is om de tijd te overbruggen tussen 'wat was' en wat 'komen gaat'

Wat komen gaat is een discussie an sich. MS wil streaming applicaties, de consument wil websites. AJAX is daar een gulden middeweg in en zou het nog wel 'ns aardig wat jaren uit kunnen houden hoor.

Met AJAX en de toekomstige techniek is het de bedoeling dat de client (de websurfer bijv.) de grafische user interface regelt. Dat niet langer HTML server calls nodig zijn om het scherm bij te werken.

HTML Server Calls? AJAX is javascript en HTTP. De communicatie kan in XML geschieden, maar ook met andere talen. Maar het heeft geenzins met HTML van doen, afgezien van dat het een website is.

De noodzakelijke bandbreedte wordt hierdoor behoorlijk gereduceerd tot slechts de contentdata van een website.

Ik denk dat je hier een denkfout maakt. Als ik iets maak dan wil ik hetgeen de bezoeker te zien krijgt totaal onder controle hebben. Met een website heb je dat, binnen de grenzen van de techniek. Wanneer je alleen nog content gaat streamen, dan heb je die controle niet meer en zou dat een degradatie van de mogelijkheden zijn. Ofwel, iets wat niemand wilt gebruiken.

Dat een degelijke client/server architectuur op basis van SOA van de business naar de particulier moet komen, is iets wat de business heel graag wil (verhuren van services bijvoorbeeld), maar wil de consument het ook.

[bgever]

Volgensmij mis je compleet superzaads punt.

Het gaat er niet om hoe prachtig AJAX is, maar wat het doet met de software van nu. AJAX sites passen niet in het model van de huidige manier van indexeren door zoekrobots.

De webapplicaties bieden dynamisch content aan die niet door een zoekmachine te bereiken is omdat er menselijke feedback nodig is.
Voldoen niet altijd aan de standaard, hoewel het er leuker uit ziet. Een webapplicatie is geen document, waardoor je HTML dus niet gebruikt waarvoor het bedoeld was, terwijl andere toepassingen het wel nog steeds zo proberen te interpreteren...

Met andere woorden; door zo'n API te publiceren maakt Google het zichzelf alleen maar moeilijker. Tenzij ze zo slim zijn om in hun API een manier zien te verzinnen om alsnog de gegevens te kunnen indexeren en er naar te kunnen linken...

[dj.verhulst]

Zit ik daar als gerechtaarde rotterdammer
Ajax-applicaties in pure Java-code te schrijven..

Daar verzin je toch niet

Teering !!!

[Verwijderd]

Ik vind dat "wij" Rotterdammers maar eens in de tegenaanval moeten gaan en stel de volgende nieuwe technieken voor:

- Framework for Enhanced Interactive Javascript Environment for Normalized Object Oriented Rapid Development
- Sophisticated Programming Architecture for Rich Technology Applications
- Enhanced XML Communication Elements Layer for Solid Internet and Office Representation

[Cowboy op zee]

ff lekker off-topic: sinds 1973 wordt de naam met een "y" ipv een "ij" geschreven zie Wikipedia
Verder hulde voor de prachtige afkortingen.

[havana]

Als Amsterdammer en dev-leek dacht ik dat Google een Ajax-skin had ontwikkeld. Lijkt me wel wat, Huntelaar op mijn Google pagina

[Verwijderd]

Ik vind de iframe oplossing persoonlijk ook niet zo geweldig, maar ik vermoed dat de enige echte reden compatibiliteit met browsers zonder XmlHttpRequest is.

Niet alleen is de performance en latency van een xmlHttpRequest object een stuk beter, je zit ook direct vast aan een doctype die framesets ondersteund. Je kunt hem dus niet zomaar toepassen in een reeds bestaand project zonder dat je iets gaat vernielen. History functionaliteit kun je ook zonder iframes goed oplossen.

Voor de rest, wederom een misser. Ze hadden de componenten van Erik Arvidsson kunnen gebruiken. Hij werkt bij Google, en zijn componenten zien er velen malen beter uit dan wat Google hier nu heeft neergezet.

Telkens als ze wat uitbrengen heb ik het gevoel van "Jongens, is dit alles wat jullie neer kunnen zetten met zoveel kapitaal en kennis?"

En verder zijn er veel betere toolkits te vinden voor dit werk die ook nog is superieur zijn vergelijke met Google, Backbase bijvoorbeeld.

[-RenE-]

....En verder zijn er veel betere toolkits te vinden voor dit werk die ook nog is superieur zijn vergelijke met Google, Backbase bijvoorbeeld.

En wat zie ik dan staan op de Backbase site als ik aankom surfen met mijn browser:

Your web browser is not compatible with the primary Backbase site. Find out which browsers are supported at the Compatible browsers page.

Google heeft voor compatibiliteit gekozen met zoveel mogelijk browsers. Het kan best zijn dat er betere toolkits zijn, maar ze werken niet overal. Voor een bedrijf als Google is het van belang dat ze iedereen kunnen bedienen. Eén procent missen is een groot verlies aan reclame inkomsten voor hen.

[Verwijderd]

Je kunt het overdrijven. De kosten voor de browsersupport (ontwikkeling, service & support, onderhoud, testprocedures, documentatie enzovoorts) van die paar exotische browsers zijn hoger dan de opbrengsten.

Het zal meer een prestige kwestie zijn voor Google. Hun keus uiteraard, maar ik zou als dergelijke partij met een sterke focus op web applicaties voor nu en zeker in de toekomst ook werken aan een stukje innovatie ook om als een van de "initiators" de drijvende kracht te zijn voor de toekomst van deze functionaliteiten.

Sommige innovaties moet je niet laten belemmeren door missende ondersteuning of verstokte eindgebruikers.

[-RenE-]

...Je kunt het overdrijven. De kosten voor de browsersupport (ontwikkeling, service & support, onderhoud, testprocedures, documentatie enzovoorts) van die paar exotische browsers zijn hoger dan de opbrengsten.

Safari is de standaard browser van Apple. Wordt door miljoenen mensen gebruikt. Niet echt exotisch dus.

[Verwijderd]

Vanaf versie 1.2 ondersteund Safari (en Konqueror) het gebruik van het native xmlHttpRequest object.

http://developer.apple.co...ebcontent/xmlhttpreq.html

Het is dus puur een kwestie van je software bijhouden.

[mcdronkz]

Ik vind het interessant om te zien dat Google zich nu ook serieus gaat richten tot de developer. Het is duidelijk dat ze zich nu bezig houden met het aanspreken van een zo groot mogelijk publiek.

[XiDiX]

Waar richt google zich niet op? De tools worden met de dag uit de grond gestampt

[.Johnny]

Als ze dat nou ook deden voor Google Ad-Sense. Laatste keer dat ik ze vroeg of ze van plan waren AJAX te ondersteunen (dus de referer zegt niks meer over de inhoud van de pagina, je moet dan dus zelf een url kunnen construeren die google wat over de inhoud zegt), was het antwoord dat hier nog niks voor in de pijplijn zit. Da's dan weer jammer...

[crisp]

GWT maakt clientside gebruik van hidden iframes en niet van het XMLHttpRequest object; je kan dus niet echt spreken van Ajax.

[Verwijderd]

Ik vrees dat je hier een forse denkfout maakt. AJAX (Asynchronous Javascript And XML) staat voor 3 dingen: Asynchroon, JavaScript en XML. Het is prima mogelijk dit te doen zonder gebruik te maken van het, niet in alle browsers beschikbare, XMLHttpRequest object.

Een van de redenen waarom veel publieke WEB 2.0 / AJAX sites gebruik maken van iframe requests is omdat dit altijd en overal werkt. Ook achter beveiligde proxy's bijvoorbeeld. XMLHttpRequest en varianten daar op is eigenlijk meer iets voor besloten netwerken waar je meer aanname's kunt doen over de gebruikte browsers en de infrastructuur.

Een van de redenen waarom veel ontwikkelaars vaak voorkeur hebben voor XMLHttpRequest is omdat het hiermee mogelijk is synchrone requests te doen. Met iframes wordt je in feite bijna gedwongen asynchroon te werken. Asynchroon levert vaak betere applicaties op (latency wordt veel minder belangrijk, vaak wordt met message queue's gewerkt) maar is wel veel lastiger te begrijpen en te ontwikkelen. Echt asynchroon is natuurlijk wel de "AJAX way".

[Verwijderd]

mooi verhaal, maar GWT gebruikt dus ook geen XML maar JSON

[Verwijderd]

Ik reageerde op iframe versus XMLHttpRequest, dat heeft verder weinig met JSON te maken denk ik.

JSON (voor de niet kenners: JavaScript Object Notation) wordt overigens met name gebruikt om gegevens uit te wisselen tussen de server en de webbrowser. Denk hierbij ook aan Unicode / UTF8 gerelateerde ellende. JSON kan prima worden gebruikt om XML objecten uit te wisselen. En je zult XML objecten als je ze in een programmeertaal wilt benaderen (JavaScript of de talen die op de server draaien) per definitie een keer om moeten zetten naar het native formaat van de betreffende programmeertaal. JSON is, gegeven dat JavaScript helaas de enige universele binnen de browser beschikbare keuze is, dan nog niet zo onlogisch gekozen van Google. Dat het minimale belasting voor de browser oplevert zal ook hebben meegewogen.

JSON wordt door sommigen beschouwd als iets wat weer boven op AJAX draait, zie bijvoorbeeld: http://ajaxpatterns.org/JSON_Message of http://jehiah.com/projects/cfjson/ajax-json-examples.php

[crisp]

Nee, dat is zeker geen denkfout. Hoewel de term 'Ajax' an sich natuurlijk slecht gekozen is (asynchroon is geen must en XML ook niet - de meeste Ajax-applicaties gebruiken niet eens XML voor de data-overdracht), maar het gebruik van het XMLHttpRequest is wel een overeenkomst tussen de verschillende Ajax-toolkits.
Wat Google hier doet is oude wijn; zo deden we 6 jaar geleden al RPC-like calls om onderhuids data op te halen in clientside applicaties - toen noemden we dat DHTML

Dat de Google JS-goeroes niet helemaal up-to-date zijn blijkt ook uit het gebruik van het deprecated document.location en de gare manier waarop ze meerdere handlers toekennen aan hetzelfde event

Verder is XMLHttpRequest ondertussen gewoon beschikbaar in alle moderne browsers, en voor webapplicaties kan je gewoon eisen stellen aan de client.
Nog een nadeeltje van het gebruik van iframes is het feit dat iframe geen geldig element is in Strict conforming documents.

[timstegeman]

Het maakt toch niet uit hoe je aan je data komt.
Met een iframe kun je ook prima xml data opvragen.

[Verwijderd]

Nee, het is nep. Het is dan namelijk niet AJAX. Iedereen kan XML laden in een iframe door een HttpRequest te doen, maar AJAX implementeren is nog even wat anders hoor...

[Reason]

Of je nou het object XMLHTTPrequest gebruikt of een iframe. Beiden zijn objecten en beiden handelen http requests af.
Het enig echte verschil is eigenlijk dat een XMLHTTPrequest geen grafisch object is, dat het meer status informatie biedt en dat het geen last heeft van de back button, maar ook een iframe biedt voordelen. Dus het is maar wat je zelf wil.
Het blijft in iedergeval in beide gevallen wel degelijk AJAX.
AJAX is niets meer dan een naampje voor een bepaalde methode. Dus hoe je het bouwt is geen issue.
Niemand verplicht je om het XMLHTTPrequest object te gebruiken.
Er zijn zelfs mensen die de communicatie via JSON laten verlopen (Geen XML dus) en die noemen het ook AJAX.
Het is wat mij betreft dan ook niks meer dan een term om stateless applicaties via het web te voorkomen.

[mOrPhie]

Is het niet zo dat hetgeen in de iframe wordt geladen wel AJAX-code kan bevatten voor search-boxes of ander dynamisch geladen lijsten? De iframe lijkt mij op het eerste gezicht alleen een manier om de server te schoppen om danwel cached, danwel gecompileerd de html en javascript terug te geven.

[levi_h]

Maar het mooie van het gebruiken van een toolkit is dat als Google voor GWT 2 besluit AJAX te gebruiken, dat je dan zelf geen code hoeft te veranderen, maar toch met de tijd meegaat.

[markg85]

hebben zoekmachines niet een groot probleem als er eenmaal veel sites op ajax draaien.. ik bedoel.. ze kunnen dan niet meer linken naar bijvoorbeeld: "www.testjes.nl/index/php?page=nogoogle" zulke pagina`s bestaan volgens mij niet meer als je echt een ajax site maakt.. en gewoon data ophalen van publieke html/php pagina`s is er ook niet meer bij aangezien alles uit een database wordt opgehaald..

of zie ik het hier nu helemaal fout?

[Verwijderd]

Hangt helemaal van de site af.

Sommige AJAX sites, om indruk te maken, laden hun boxjes en windowtjes in met AJAX nadat de pagina is opgevraagd in plaats van in 1 keer die pagina neer te rammen, en later alleen updates met AJAX te doen. Het resultaat: een langzamer ladende pagina (maar je "ziet" het wel!) en een lege pagina voor search bots.

Mijn eigen AJAX site is natuurlijk veeeeel slimmer
What you see: http://dutchpipe.org/
Wat Google ziet: http://64.233.183.104/sea...chpipe&hl=en&ct=clnk&cd=1

[.Johnny]

Misschien een beetje off-topic, maar voor mensen die nu geinteresseerd raken en hier mee bezig gaan wel interessant om uit te leggen wat voor "truuk" je dan dus moet uitvoeren;

volgens mij is in dergelijke gevallen het altijd safe een non-ajax equivalent achter de hand te houden. Dat kun je bijvoorbeeld doen door links als:
<a href="nonajax.php?parameters" onclick="return ajaxCheckAndExecute(parameters);">
in zo'n geval wordt nonajax.php gespiderd, dus je site wordt normaal geindexeerd en de return in de onClick kun je met false als return value de actie op "href" laten bypassen voor ajax gebruikers.
Initieel bouw je dan de site aan de server kant op en niet aan de client kant met ajax, want dat is sowieso trager. Alleen de wijzigingen doe je dan met AJAX.

Voordelen: dit werkt ook altijd voor non-javascript/non-ajax en google indexeert je site.

[Bosmonster]

Wat ik me afvraag, wat kan de Google indexeer spider hier in hemelsnaam dan nog mee...

De code is niet meer dan javascript calls..

[Brupje]

denk dat de google spider meer met hun techniek kan dan de concurrent

[killercow]

aangezien dat ding tegenwoordig gewoon op gecko gebaseerd is (mozilla engine) zal hij de javascript dus wel kunnen parsen.

[Verwijderd]

En is deze omgeving meer bedoeld voor web-based applicaties en niet voor webpagina's die in een zoekmachine terecht hoeven komen.

[Verwijderd]

Ik merk dat de functionaliteit van de back-button toch niet helemaal behouden blijft.
Als je bv bij images kijkt, en een paar keer op next hebt geklikt, kun je met de backbutton niet terug naar de vorige afbeelding, in plaats daarvan ga je terug naar het vorige geselecteerde menu-item.

[.Johnny]

Dat is inderdaad jammer want daar is zeker wel een javascript oplossing voor:

Really Simple History
History proposal van Randomize

edit: ik zie nu dat google zelf deze techniek wel gebruikt, maar dat voor de plaatjes browser simpelweg niet geimplementeerd heeft.

[Rekcor]

Ook niet onbelangrijk:

Permitted Uses

The Google Web Toolkit is made available to you for your limited personal or commercial use in compliance with all applicable laws, rules and regulations. The following limitations apply to your commercial use of Google Web Toolkit Development Tools:

- You may make commercial use, to the extent permitted by applicable law, of Java and JavaScript code, HTML, and other code or content that you create using Google Web Toolkit Development Tools (collectively "Google Web Toolkit Output").
- You may not redistribute the Google Web Toolkit Development Tools, including but not limited to selling Google Web Toolkit Development Tools for payment.

[Verwijderd]

Het "mooie" aan dit verhaal is wat mij betreft het kunnen gebruiken van een Java ontwikkelomgeving,als Eclipse, om Ajax applicaties te kunnen maken.

Je hoeft dan als Java ontwikkelaar niet alweer een nieuw trucje te leren. De hulpmiddelen binnen een ontwikkelomgeving kunnen veel tijd besparen. Uiteindelijk gaat het om tijdwinst, dat wordt door Google ook als belangrijkste genoemd.

Het is natuurlijk ook een antwoord op Microsoft's Atlas Ajax framework, volgens mij een vergelijkbaar concept...in die zin gewoon weer gewoon:
"good old competition"