[discussie] AJAX: overhyped of zegen?

[Verwijderd]

Verwijderd schreef op woensdag 24 augustus 2005 @ 12:27:
Flash niet browser afhankelijk? Dat is maar een point of view natuurlijk. Het is een extra voorwaarde voor de applicatie de je bij AJAX al niet hebt.

Flash is in elke browser het zelfde en heeft een zeer hoge marktpenetratie. Misschien wel meer dan browsers waar javascript daadwerkelijk aanstaat? . Het verschijnt nu zelfs op mobieltjes.

Mocht een klant geen flash-plugin hebben en hij wil toch de webapplicatie gebruiken, dan lijkt mij de drempel niet hoog om de plugin dan even te installeren. AJAX heeft als voorwaarde dat javascript aan moet staan.

p.s. bedoelde trouwens browserspecifiek ipv browserafhankelijk, misschien dat dit niet helemaal duidelijk was.

Verwijderd schreef op woensdag 24 augustus 2005 @ 12:27:
wat is er flexibeler aan? wat is er beheersbaarder aan? 'mooier' geef ik niks om, het gros van de flash sites vind ik persoonlijk lelijke BrEeZaH creaties.

kort samengevat: Het geeft je de mogelijkheid om Rich Internet Applications te bouwen, net zoals je een web- of windowsapplicatie zou bouwen in .NET. (Misschien dat het in de toekomst geïntegreerd is in VS.NET)

Verwijderd schreef op woensdag 24 augustus 2005 @ 12:27:
Afijn, je commentaar op ajax is precies wat ik van flex vind: "voor wat simpele dingetjes zie ik het nut van Flex".

Neem even aan dat je bedoelde 'het nut NIET van Flex' en daar ben ik het met je eens (maar dit kan veranderen als ik echt met deze technologie gewerkt heb en blijkt dat het super-eenvoudig is).

[ Voor 6% gewijzigd door Verwijderd op 24-08-2005 15:47 ]

[Verwijderd]

Neen, zoals ik het zeg: Voor simpele dingetjes zie ik het nut van Flex, bijvoorbeeld het tonen van een diagram. Voor een complete applicatie niet, het voegt immers niets toe. En zoals gezegd vereist het een extra installatie slag, wat meer voet in aarde heeft bij grote bedrijven als dat je doet voorkomen. Vergeet niet dat je domweg een specifieke applicatie moet downloaden en installeren voor dergelijke oplossingen, zodoende zou je de overweging kunnen maken om inderdaad domweg platform specifieke applicaties te schrijven.

[Verwijderd]

Afgezien van de benodigheden voor zulke applicaties, of het nu support voor Javascript is of de juiste Flash player voor Flex, is Flex gewoon nog te sluggish en te beperkt voor een echte applicatie. Zelfs met de nieuwe Flash 8 player kreeg ik er niet de performance uit die ik wilde hebben.

Het is gewoon nog veel te zwaar, en kan op geen enkele manier op het serieuze vlak concurreren met de standaard web applicaties.

Performance is een van de belangrijkste onderdelen die bepalend voor het success van een applicatie. Flex is leuk voor een eenvoudige listview, of je rss lezer, maar ik ze me er nog geen Office 2003 achtige layout mee in elkaar zetten, niemand eigenlijk.

[ Voor 7% gewijzigd door Verwijderd op 24-08-2005 16:29 ]

[Not Pingu]

Flex is vooral leuk voor guided selling naar consumenten toe, niet voor functionele applicaties. De toegevoegde waarde is dat je heel veel kunt werken met animatie (niet alleen voor irritante banners maar ook leuk voor visuele cues) en multimedia-elementen, zodat je bijv. allerlei indrukken van een vakantiereis kunt geven.

[raptorix]

Ik heb zelf al een flex implementatie gedaan en moet zeggen dat ik vrij positief over het product ben, probleem is wel dat je erg moet opletten hoe je je zaken nest, en het kan zeker op tragere pc's nogal eens mager overkomen. Toch zijn er veel manieren om de zaken sneller te krijgen maar moet zeggen dat het even tijd kost om dat door te krijgen. Ik hoop me de komende tijd nog meer met RIA's bezig te kunnen houden met name omdat ons bedrijf er veel mee bezig is, en we veel klanten hebben waar RIA's een substantieele bijdrage kunnen leveren. Ben op dit moment bezig met een kleine Flex implementatie voor een formulieren applicatie, helaas heeft de klant besloten om de productvergelijkers eruit te gooien.

Voor een klant heb ik de volgende pilot gebouwd:

http://213.193.236.53/flex/cb/main.mxml

Helaas hebben ze besloten het bij een ander bedrijf te bouwen in tradioneel flashmx

[chem]

raptorix schreef op donderdag 25 augustus 2005 @ 01:55:
Voor een klant heb ik de volgende pilot gebouwd:

http://213.193.236.53/flex/cb/main.mxml

Helaas hebben ze besloten het bij een ander bedrijf te bouwen in tradioneel flashmx

Het voelt echt vreselijk sluggish aan, alles met fancy visual cue's wat het doet voelen alsof je een Java gui-prototype aan het bekijken bent; het idee is leuk - maar na een paar seconden had ik het er al mee gehad.

Bij xmlHttp is er een soortgelijk probleem; de gebruiker heeft geen invloed dmv de useragent's gui op de requests die uitgevoerd worden (refresh, stop, url aanpassen etc.). Dit maakt het bij niet-optimale werking heel wazig of er nou iets gebeurd of niet.

[Verwijderd]

Dat kan wel, hangt van de ui af. xmlHttpRequest ondersteund gewoon abort() etc.

[Genoil]

chem schreef op donderdag 25 augustus 2005 @ 08:10:
[...]

Het voelt echt vreselijk sluggish aan, alles met fancy visual cue's wat het doet voelen alsof je een Java gui-prototype aan het bekijken bent; het idee is leuk - maar na een paar seconden had ik het er al mee gehad.

Bij xmlHttp is er een soortgelijk probleem; de gebruiker heeft geen invloed dmv de useragent's gui op de requests die uitgevoerd worden (refresh, stop, url aanpassen etc.). Dit maakt het bij niet-optimale werking heel wazig of er nou iets gebeurd of niet.

Goeie punten. Bij mij draait die demo lekker vlot, omdat mij fat client ook een fat CPU heeft. Met AJAX of flash clients ben je vaker geneigd client-side lompere dingen te doen, terwijl je juist totaal geen inzicht hebt of de client het allemaal wel aankan.

Het feit dat je met AJAX de meest vertrouwde functionaliteiten in een browser (refresh, stop, address bar en niet te vergeten 'back') praktisch om zeep helpt, is een grote bedreiging voor de user experience, die met AJAX juist zo prettig zou moeten zijn. Dat limiteert voor mij het toepassen van AJAX tot zaken waarbij je er met zekerheid vanuit kunt gaan dat de gebruiker deze nooit met een 'back' ongedaan zou willen maken.

Anderzijds heb ik wel ooit een demo van een applicatie gemaakt met AJAX (toen ik nog niet wist dat dat zo heette), die standaard in een fullscreen browser draaide op geijkte systeem specs. Het eerste wat ik er echter ingebouwd heb is een history stack, een soort van address bar die het pad aangaf, back+forward knoppen en een busy indicator

[raptorix]

chem schreef op donderdag 25 augustus 2005 @ 08:10:
[...]

Het voelt echt vreselijk sluggish aan, alles met fancy visual cue's wat het doet voelen alsof je een Java gui-prototype aan het bekijken bent; het idee is leuk - maar na een paar seconden had ik het er al mee gehad.

Bij xmlHttp is er een soortgelijk probleem; de gebruiker heeft geen invloed dmv de useragent's gui op de requests die uitgevoerd worden (refresh, stop, url aanpassen etc.). Dit maakt het bij niet-optimale werking heel wazig of er nou iets gebeurd of niet.

Klopt, de reden dat het sluggish is ligt ook met name aan het feit dat een vrij grote xml data file in geinclude is (iets van 400k ofzo) en dat maakt de performance er niet beter op. Ik moet ook zeggen dat het interface design nogal sterk bepaalt is door de klant. Ik heb een aantal private demos gezien van iemand van Macromedia en die liepen supersmooth met zaken als realtime datapush en dat was echt indrukwekkend.

[chem]

Genoil schreef op donderdag 25 augustus 2005 @ 09:08:
[...]


Goeie punten. Bij mij draait die demo lekker vlot, omdat mij fat client ook een fat CPU heeft. Met AJAX of flash clients ben je vaker geneigd client-side lompere dingen te doen, terwijl je juist totaal geen inzicht hebt of de client het allemaal wel aankan.

Een dual G5 1.8 vind ik nou niet bepaald een thin CPU. imho.

Voorlopig vind ik AJAX een hype, en zie ik het op lange termijn als een gestandardiseerde manier om cross-browser (met de juiste JS-libs) dingetjes uit te halen als real-time form validatie, inline forms submitten etc.

[raptorix]

chem schreef op donderdag 25 augustus 2005 @ 13:40:
[...]

Een dual G5 1.8 vind ik nou niet bepaald een thin CPU. imho.

Voorlopig vind ik AJAX een hype, en zie ik het op lange termijn als een gestandardiseerde manier om cross-browser (met de juiste JS-libs) dingetjes uit te halen als real-time form validatie, inline forms submitten etc.

Ajax is aardig, maar je zit alweer met browser diversiteiten/beperkingen. Ik geloof meer in flash Based Ria's zoals Flex en Laszlo. Flash heeft een dermate hoge penetratiegraad dat het zelfs voor serieuze toepassingen gebruikt kan worden, daarnaast is flash een open standaard wat ik toch wel als groot voordeel zie. Bovendien is het voordeel van producten als Flex en Laszlo dat je op een meta-achtige manier je applicatie bouwt. Theoretisch is het zelf mogelijk om in plaats van Flash, Dynamic HTML uit te spugen.

[Genoil]

//offtopic

chem schreef op donderdag 25 augustus 2005 @ 13:40:
[...]

Een dual G5 1.8 vind ik nou niet bepaald een thin CPU. imho.

Nee idd maar hier op een 3Ghz x86 loopt het als een speer, behalve het scrollen van de grote table met alle camera's (maar dat lijkt een bugje want andere scrolable area's doen het wel goed). Flash performance op OSX schijnt behoorlijk bar te zijn.

Afgezien van deze specifieke situatie mag je er vanuit gaan dat platte html (met minimale Javascript) op vrijwel alle clients acceptabel draait, terwijl AJAX beter draait op thicker clients.

[Verwijderd]

raptorix schreef op donderdag 25 augustus 2005 @ 14:01:
[...]

Ajax is aardig, maar je zit alweer met browser diversiteiten/beperkingen. Ik geloof meer in flash Based Ria's zoals Flex en Laszlo. Flash heeft een dermate hoge penetratiegraad dat het zelfs voor serieuze toepassingen gebruikt kan worden, daarnaast is flash een open standaard wat ik toch wel als groot voordeel zie. Bovendien is het voordeel van producten als Flex en Laszlo dat je op een meta-achtige manier je applicatie bouwt. Theoretisch is het zelf mogelijk om in plaats van Flash, Dynamic HTML uit te spugen.

Die browser beperkingen zien de mensen die eraan bouwen niet zo, ik hoor alleen van de mensen die er niet mee bezig zijn dat er beperkingen zijn. Als je vervolgens aan ze vraagt, joh, noem ze dan eens dan krijg je "euh" "euh" .. ik vind dat persoonlijk een beetje schaapjes gedrag.

De beschikbaarheid van Javascript is hoog. Nog steeds krijg je verhalen als "maar Javascript is uitgeschakeld". En vervolgens vraag je hoe ze dan hun dagelijkse websites bezoeken, en dan krijg je "euh" "euh".

Ik heb niets tegen Flex, maar ik kom teveel opmerkingen tegen waar ik zo iets van heb, wie probeer je nu te overtuigen? Argumenten als kun je zo op mobile devices draaien, terwijl de persoon die dat zegt vol overtuiging is dat diezelfde applicatie 1 op 1 in dat kleine schermpje draait met een prima snelheid, of ... gaan gooien met support voor video, terwijl het maken van opnames met een blauwe wand niet bepaald goedkoop zijn laat staan nuttig in applicaties, etc.

Als Flex de spierballen heeft om het op te nemen tegen de snelheid van pure DHTML apps heb je een leuk onderdeel, maar zoals het nu is is het een niche product met weinig potentie behalve de initiele wow factor. Dan kan elke persoon aankomen met management dashboards, en simpele data entry, maar voor het echte interface werk is het gewoon nog niet klaar.

Voor javascript zijn er ook genoeg opmerkingen te maken, maar het meerendeel is overkomelijk en om heen te werken. Om de performance van Flex is niet heen te werken. Komt nog bij dat de support van Macromedia gewoon rondweg associaal slecht is. De forums lijken wel op deathvalley, geen enkele vraag wordt beantwoord, en voor elke vorm van basic support zelfs als er bugs zijn, worden schandalige support bedragen gevraagd onder het excuus dat er niet genoeg resources zijn.

Idem overigens voor de andere Macromedia producten, de service en kwaliteit is tegenwoordig ver te zoeken.

[ Voor 22% gewijzigd door Verwijderd op 25-08-2005 15:48 ]

[raptorix]

Verwijderd schreef op donderdag 25 augustus 2005 @ 15:41:
[...]


Die browser beperkingen zien de mensen die eraan bouwen niet zo, ik hoor alleen van de mensen die er niet mee bezig zijn dat er beperkingen zijn. Als je vervolgens aan ze vraagt, joh, noem ze dan eens dan krijg je "euh" "euh" .. ik vind dat persoonlijk een beetje schaapjes gedrag.

Het is vaak wel mogelijk, maar het kost stukken meer moeite en zowiezo veel meer code.
Plus dat je per browser vaak weer afhankelijkheden hebt. Daarnaast loop je tegen allerlei problemen aan zoals history management, als je dit moet gaan afvangen in DHTML wordt je meestal niet vrolijk

.....

Ik heb niets tegen Flex, maar ik kom teveel opmerkingen tegen waar ik zo iets van heb, wie probeer je nu te overtuigen? Argumenten als kun je zo op mobile devices draaien, terwijl de persoon die dat zegt vol overtuiging is dat diezelfde applicatie 1 op 1 in dat kleine schermpje draait met een prima snelheid, of ... gaan gooien met support voor video, terwijl het maken van opnames met een blauwe wand niet bepaald goedkoop zijn laat staan nuttig in applicaties, etc.

Als Flex de spierballen heeft om het op te nemen tegen de snelheid van pure DHTML apps heb je een leuk onderdeel, maar zoals het nu is is het een niche product met weinig potentie behalve de initiele wow factor. Dan kan elke persoon aankomen met management dashboards, en simpele data entry, maar voor het echte interface werk is het gewoon nog niet klaar.

LOL weinig potentie, ik denk dat je dan niet serieus naar dit product hebt gekeken, vergelijk een product als backbase eens met flex en je weet waar ik het over heb, en de snelheid van flex is vele malen hoger, zeker als je weet dat xml parsing kan laten doen door de flex server. Nog maar niet te spreken dat je met dynamic HTML je libraries moet gaan meesturen naar de client, terwijl dit in flash al gecompileerd is.

Voor javascript zijn er ook genoeg opmerkingen te maken, maar het meerendeel is overkomelijk en om heen te werken. Om de performance van Flex is niet heen te werken. Komt nog bij dat de support van Macromedia gewoon rondweg associaal slecht is. De forums lijken wel op deathvalley, geen enkele vraag wordt beantwoord, en voor elke vorm van basic support zelfs als er bugs zijn, worden schandalige support bedragen gevraagd onder het excuus dat er niet genoeg resources zijn.

Idem overigens voor de andere Macromedia producten, de service en kwaliteit is tegenwoordig ver te zoeken.

De support is perfect, de yahoo flex coders list wordt continue door 2 a 3 mensen van de Flex megelezen en je hebt meestal binnen een halfuur goed antwoord, plus dat iedereen die zich met flex bezig houdt actief op deze list is.

[Verwijderd]

Raptorix ik heb met zowel Flex als met de oude situatie ontwikkeld, ik weet dus wel zeker waar ik over praat. Voor Flex hoef je gewoon veel minder moeite te doen om een simpele applicatie te ontwikkelen, dat is ook geen probleem maar dat komt wel met een prijs en de beperkte mogelijkheden. Jij wil toch niet beweren dat je een site als Salesforce op dezelfde snelheid, met dezelfde servers, en met dezelfde traffic kunt laten draaien op een pure Flex oplossing. Ik weet niet hoe jouw ervaringen zijn, maar die van mij waren dat de Flex applicatie het bij een beetje drukte zwaar liet afweten, de requests niet netjes ging afronden, bleef hangen met een loading icon, en de al zware quad cpu server echt een heel moeilijke tijd bezorgde.

Wat Flex dan wel mooi heeft geflikt zijn de histories, dat ben ik met je eens, echter Dynamic libraries worden gecached, idem voor css, dat kan ik niet van Flex zeggen. Bij Flex is er geen enkele manier om de data clientside te cachen buiten de actieve sessie om, serverside legt Flex een cache aan in /web-inf/flex/cache.dep om nogmaals compilation te voorkomen maar dat is ook de enige mogelijkheid die Flex door middel van de cache tags heeft. Zodra de sessie weg is, ben je je cache ook kwijt. De rest van de data wordt telkens opnieuw opgehaald, dat wil je echt niet met veel traffic hebben. Komt nog bij dat alles via de Flex server gaat, een webserver heeft gewoon een veel hogere capaciteit met betrekking tot het serveren van data die niet behandeld hoeft te worden.

Een community, jazeker ik ben ook actief in de FlexCoders list maar je kunt support van een product bij een klant niet verkopen onder de term "community hulp" als er flink wat geld voor betaald moet worden. Dat vind ik echt onacceptabel gezien de licentietarieven. (Al voelen de oude kopers zich helemaal genaaid met hun prijzen nadat de licenties zijn omgegooid .. ).

Flex zal er echt nog wel komen, maar ik heb zelf het gevoel dat ze nog een lange weg hebben te gaan. Het is het gewoon nog net niet. Ik heb nog geen enkele applicatie in Flex gezien die lekker performde, en dat kan ik wel van de "Ajax" kant van het verhaal zeggen waarbij we ook praten over hele grote applicaties die zonder hickup response gaven.

[ Voor 3% gewijzigd door Verwijderd op 25-08-2005 20:47 ]

[raptorix]

Ben ik met je eens Gordijnstok, de performance kan zeker nog wel beter. Overigens kan je gerust de helft van de prijs afpingelen op een flex licentie

Heb je trouwens wel eens met Laszlo gewerkt, niet zo uitgebreid qua componenten als Flex maar wel gratis en opensource, werk er al tijdje mee en zeker als je product beetje kent en de beperkingen ervan is het een goed alternatief.

Begrijp me niet verkeerd, ik been zeer positief over Ajax, kijk naar Gmail en Google personalised, dat zijn mooie voorbeelden.
Je zou eens naar openrico moeten kijken, een zeer aardige library van Ajax widgets.

[Verwijderd]

raptorix schreef op donderdag 25 augustus 2005 @ 17:00:
LOL weinig potentie, ik denk dat je dan niet serieus naar dit product hebt gekeken, vergelijk een product als backbase eens met flex en je weet waar ik het over heb, en de snelheid van flex is vele malen hoger, zeker als je weet dat xml parsing kan laten doen door de flex server. Nog maar niet te spreken dat je met dynamic HTML je libraries moet gaan meesturen naar de client, terwijl dit in flash al gecompileerd is.

Wat maakt flex anders dan een ordinaire java applet?

[alienfruit]

Je kan het grafisch "leuker" maken, en je hebt de Java runtime niet nodig. Iets wat mensen volgens minder geïnstalleerd hebben dan de Flash player.

[Verwijderd]

alienfruit schreef op vrijdag 26 augustus 2005 @ 09:47:
Je kan het grafisch "leuker" maken, en je hebt de Java runtime niet nodig. Iets wat mensen volgens minder geïnstalleerd hebben dan de Flash player.

Redelijk natte vinger werk wat je nu zegt. Of ik nou een flash player of jre moet installeren, dat boeit niet. Heb je harde cijfers over de penetratie graad? Dat je flash grafisch leuker zou kunnen maken is natuurlijk bullshit, je kunt in beide hetzelfde.

Dus nogmaals wat maakt flash anders dan een applet?

[alienfruit]

Ja, redelijke natte vinger werk, maar als je er vanuit gaat dat Flash standaard met IE6 meekomt en Java runtime niet onder Windows XP. Maar goed in iedergeval is zowel een Java applet als een flash movie cross-platform, en voor beidde moet een plugin worden geïnstalleerd. Verder kan je van een flash movie een canvas dump maken en van Java wel. Maar verder is er een verschil in de achterliggende programmeertaal ECMAScript tegenover Java, en nog wat van zulke dingen.

Source: http://www.macromedia.com.../version_penetration.html

[ Voor 13% gewijzigd door alienfruit op 26-08-2005 10:09 ]

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 10:00:
[...]

Redelijk natte vinger werk wat je nu zegt. Of ik nou een flash player of jre moet installeren, dat boeit niet. Heb je harde cijfers over de penetratie graad? Dat je flash grafisch leuker zou kunnen maken is natuurlijk bullshit, je kunt in beide hetzelfde.

Dus nogmaals wat maakt flash anders dan een applet?

Flash heeft een penetratiegraad van 98.5 procent, is onderzocht door macromedia, daarnaast heb ik hier voor een klant ook zelf onderzoek naar ingestelt.

Bovendien is Java qua initialisatie stukken trager en is het veel meer werk om zaken voor elkaar te krijgen.

[Verwijderd]

alienfruit schreef op vrijdag 26 augustus 2005 @ 10:08:
Ja, redelijke natte vinger werk, maar als je er vanuit gaat dat Flash standaard met IE6 meekomt en Java runtime niet onder Windows XP. Maar goed in iedergeval is zowel een Java applet als een flash movie cross-platform, en voor beidde moet een plugin worden geïnstalleerd. Verder kan je van een flash movie een canvas dump maken en van Java wel. Maar verder is er een verschil in de achterliggende programmeertaal ECMAScript tegenover Java, en nog wat van zulke dingen.

Source: http://www.macromedia.com.../version_penetration.html

Kijk het gaat me niet zozeer om wie meer markt aandeel heeft oid. Maar meer om hetzelfde type product. De technieken waren er al, maar klaarblijkelijk is het geen interessante oplossing.

Tsja en die lik van stats, nietzeggend natuurlijk.

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 09:39:
[...]

Wat maakt flex anders dan een ordinaire java applet?

Als je niet weet waar je over praat, zeg dan niets, Flex is serverside, Apllets client side.

[raptorix]

alienfruit schreef op vrijdag 26 augustus 2005 @ 09:47:
Je kan het grafisch "leuker" maken, en je hebt de Java runtime niet nodig. Iets wat mensen volgens minder geïnstalleerd hebben dan de Flash player.

Flex is een enterprise product, en richt zeg echt niet op het grafische werk. De kracht ligt juist in serverside ondersteuning naar webservices. Ga het eens proberen en je zult verstelt zijn hoe snel je een applicatie in elkaar zet.

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 10:21:
Als je niet weet waar je over praat, zeg dan niets, Flex is serverside, Apllets client side.

Het idee van flex is toch dat je de uitkomst van je stevige server werk toont in een client side flash applicatie? Oftewel de vergelijking flex en applet is gerechtvaardigd.

Als jij nu eens uitlegt wat het significante voordeel is van Flex boven Ajax dan hebben we allemaal wat meer aan je opmerkingen. Tot nu toe geef je enkel aan dat jij het prettiger en mooier en sneller vind. Helaas ontbreekt tot op moment van schrijven de duidelijke onderbouwde argumentatie. We moeten het doen met je waarde oordeel.

[ Voor 3% gewijzigd door Verwijderd op 26-08-2005 11:27 ]

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 11:26:
[...]

Het idee van flex is toch dat je de uitkomst van je stevige server werk toont in een client side flash applicatie? Oftewel de vergelijking flex en applet is gerechtvaardigd.

Als jij nu eens uitlegt wat het significante voordeel is van Flex boven Ajax dan hebben we allemaal wat meer aan je opmerkingen. Tot nu toe geef je enkel aan dat jij het prettiger en mooier en sneller vind. Helaas ontbreekt tot op moment van schrijven de duidelijke onderbouwde argumentatie. We moeten het doen met je waarde oordeel.

Nee Flex genereert Flash, terwijl een applet een statisch object is. Bovendien werkt de gegeneerde Flash weer samen met de Flex server, bijvoorbeeld om sessies bij te houden en serverside requests te proxieen. Kortom het is wel iets meer als het even naar buiten kwakken van een Flashje. Het voordeel van Flex boven Ajax is dat Ajax slechts een verzamelnaam is voor webtechnieken die met elkaar samen werken, daar waar Flex een compleet framework is. Daarnaast biedt Flex een goede IDE waarbij je zowel in coding als visuele modus kan werken.

Je opmerkingen komen nogal kinderlijk over, je hebt totaal geen idee wat het product inhoud, maar je velt er wel een oordeel over.

Nog een voordeel ten opzichte van Ajax is dat het beter bescherming biedt voor toekomstige issues. Als Microsoft morgen besluit de implementatie van HTTP requests af te handelen dan werkt jou mooie Ajax app niet meer. Terwijl je bij Flex daar geen last van hebt, omdat je geen client side code schrijft maar deze gegenereerd wordt door de server.

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 11:54:
Nog een voordeel ten opzichte van Ajax is dat het beter bescherming biedt voor toekomstige issues. Als Microsoft morgen besluit de implementatie van HTTP requests af te handelen dan werkt jou mooie Ajax app niet meer.

Maak jij je ook zorgen of de hemel op je hoofd valt?

Ik vind overigens wel dat je deels gelijk hebt in de Flex vs. AJAX discussie. Flex is echt een product gebouwd voor ontwikkelaars. Een taal+IDE+framework die ontwikkelaars in staat stelt (relatief) snel complete Rich Internet Applications te bouwen. AJAX is niets meer dan een techniek die ontwikkelaars mogelijk maakt client-server requests uit te voeren en af te handelen zonder een webpagina te verversen. Verdomd handig, maar op zichzelf niet bepaald indrukwekkend.

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 11:54:
Je opmerkingen komen nogal kinderlijk over, je hebt totaal geen idee wat het product inhoud, maar je velt er wel een oordeel over.

Pardon, ik vraag gewoon vriendelijk naar het voordeel en zit dus niet te wachten op dit soort nergens opslaande opmerkingen. Je kunt niet verwachten dat iedereen de complete ins en outs van flex kent. Jij presenteert het notabene zelf als (beter) alternatief op AJAX zonder duidelijk beargumenteerd over de voordelen te spreken.

Dit "Het voordeel van Flex boven Ajax is dat Ajax slechts een verzamelnaam is voor webtechnieken die met elkaar samen werken, daar waar Flex een compleet framework is" bijvoorbeeld is geen gegrond argument. Waarom zou een framework uberhaupt een voordeel zijn? Gebruikt flex niet meerdere technieken (http, html, flash, xml, etc) en daarmee ook niks anders dan een verzamelnaam?

En deze opmerking "Terwijl je bij Flex daar geen last van hebt, omdat je geen client side code schrijft maar deze gegenereerd wordt door de server.", nogmaals, wat is het voordeel boven een applet, want dat is nog steeds hetzelfde (een applet die dus bepaalde data interpreteert)?

[Verwijderd]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 12:20:
Dit "Het voordeel van Flex boven Ajax is dat Ajax slechts een verzamelnaam is voor webtechnieken die met elkaar samen werken, daar waar Flex een compleet framework is" bijvoorbeeld is geen gegrond argument. Waarom zou een framework uberhaupt een voordeel zijn?

Omdat frameworks over het algemeen zijn ontworpen om bepaalde veel voorkomende taken veel gemakkelijker te maken. Losse technieken bieden meer flexibiliteit maar vereisen over het algemeen meer inzet van de developer.

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 12:20:
[...]
En deze opmerking "Terwijl je bij Flex daar geen last van hebt, omdat je geen client side code schrijft maar deze gegenereerd wordt door de server.", nogmaals, wat is het voordeel boven een applet, want dat is nog steeds hetzelfde (een applet die dus bepaalde data interpreteert)?

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 13:26:

Je kunt uitleggen wat er mis aan is of je reageert domweg niet. Aan dit soort nutteloze opmerkingen heeft niemand wat. Dus leg nou eens uit wat ons allen naar Flex moet bewegen en Ajax links moet laten liggen

[raptorix]

Als je niet het verschil in kan zien tussen statische objecten en serverside gegenereerde objecten verwijs ik je graag door naar een forum hoger. Voorts stop ik deze discussie met jou omdat je kennelijk in een discussie wilt mengen zonder dat je ook maar enigzins kennis van zaken hebt.

[mulder]

raptorix schreef op vrijdag 26 augustus 2005 @ 13:35:
Als je niet het verschil in kan zien tussen statische objecten en serverside gegenereerde objecten verwijs ik je graag door naar een forum hoger. Voorts stop ik deze discussie met jou omdat je kennelijk in een discussie wilt mengen zonder dat je ook maar enigzins kennis van zaken hebt.

Zeg alomwetende doe eens niet zo stoer, het zijn dan nog altijd serverside genereerde statische objecten. Applets zouden ook serverside genereerd kunnen worden.

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 13:35:
Als je niet het verschil in kan zien tussen statische objecten en serverside gegenereerde objecten verwijs ik je graag door naar een forum hoger. Voorts stop ik deze discussie met jou omdat je kennelijk in een discussie wilt mengen zonder dat je ook maar enigzins kennis van zaken hebt.

Het spijt mij dat ik jou elite niveau nog niet heb bereikt.

Of ik nu een compleet gegenereerde flash over een lijntje stuur of dat ik wat geserialiseerde data over een lijntje pomp naar een applet maakt voor het resultaat niet uit. Het resultaat is dus een applicatie draaiende binnen een context van een webbrowser. Maar goed dat hoef ik jou natuurlijk niet uit te leggen want jij stond al een aantal traptreetjes hoger

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 13:41:
[...]

Het spijt mij dat ik jou elite niveau nog niet heb bereikt.

Of ik nu een compleet gegenereerde flash over een lijntje stuur of dat ik wat geserialiseerde data over een lijntje pomp naar een applet maakt voor het resultaat niet uit. Het resultaat is dus een applicatie draaiende binnen een context van een webbrowser. Maar goed dat hoef ik jou natuurlijk niet uit te leggen want jij stond al een aantal traptreetjes hoger

Lekker niveau hier, maar jij vraagt me naar de voordelen van Flex boven Ajax technologieen, als je met dit soort non argumenten komt ben ik hier zeker weg. Ik wil me zelf geen betweter noemen, maar kan wel zeggen dat ik serieus naar alle type Ria Producten heb gekeken, ik neem de tijd om uit te leggen wat de voor en nadelen zijn. Terwijl jij alleen maar op negativisme uitbent. Typisch voor een hoop programmeurs, bang voor nieuwe technologieen, en te weinig innovatief. Kijk eens met een open vizier naar de mogelijkheden die er zijn, en geef dan je oordeel. De manier waarop jij dingen afbrand is wel heel makkelijk. In dezelfde analogie kan ik net zo goed zeggen dat JSP/PHP/ASP geen voordeel hebben boven HTML, immers de code die het oplevert is niets anders dan statische HTML

[raptorix]

Don Facundo schreef op vrijdag 26 augustus 2005 @ 13:41:
[...]


Zeg alomwetende doe eens niet zo stoer, het zijn dan nog altijd serverside genereerde statische objecten. Applets zouden ook serverside genereerd kunnen worden.

Het gaat niet om stoer of alomwetend, het gaat erom dat ik een aantal voordelen noemt, die verworpen worden op basis van non argumenten. Vervolgens gaat mijnheer beledigend lopen doen. Op die manier heb ik geen zin om een fatsoenlijke discussie te voeren.

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 13:49:
Lekker niveau hier, maar jij vraagt me naar de voordelen van Flex boven Ajax technologieen, als je met dit soort non argumenten komt ben ik hier zeker weg.

Ik vraag inderdaad naar de voordelen, en ik hoop nog steeds op antwoord. Dat lijkt me vele malen constructiever dan het niveau van deze discussie aan de kaak te stellen. Verder wil ik best geloven dat ik non-argumenten lever en dat jij ook precies weet waarom, doch kan ik je heldere uitleg " " niet geheel bevatten.

raptorix schreef op vrijdag 26 augustus 2005 @ 13:49:
Ik wil me zelf geen betweter noemen, maar kan wel zeggen dat ik serieus naar alle type Ria Producten heb gekeken, ik neem de tijd om uit te leggen wat de voor en nadelen zijn.

Daar ben ik blij om, dus dan bij deze nogmaals het verzoek om deze is hier neer te zetten

raptorix schreef op vrijdag 26 augustus 2005 @ 13:49: Terwijl jij alleen maar op negativisme uitbent. Typisch voor een hoop programmeurs, bang voor nieuwe technologieen, en te weinig innovatief. Kijk eens met een open vizier naar de mogelijkheden die er zijn, en geef dan je oordeel.

Ik brand niks af, ik zie het grote voordeel niet. Maar gelukkig geef je in je post aan dat je dat kunt uitleggen en daar ben ik dan weer blij om. Tevens vind ik het geweldig dat je naast een top-programmeur ook een psycholoog bent

raptorix schreef op vrijdag 26 augustus 2005 @ 13:50: Vervolgens gaat mijnheer beledigend lopen doen. Op die manier heb ik geen zin om een fatsoenlijke discussie te voeren.

Sorry dat ik je beledigd hebt. Zou je alleen voor mij even kunnen aangeven hoe ik je hebt beledigd zodat ik de toekomst deze fout niet nogmaals maak.

[ Voor 12% gewijzigd door Verwijderd op 26-08-2005 14:00 ]

[raptorix]

Ok laten we even kappen met dit vijandelijke gedoe, ik zit nu op me werk en heb niet zoveel tijd, ik zal dit weekend een goed overzicht geven wat de voordelen van flash based ria's zijn ten opzichte van Ajax.

[NMe]

raptorix schreef op vrijdag 26 augustus 2005 @ 13:59:
Ok laten we even kappen met dit vijandelijke gedoe.

I second that. Een discussie voeren is prima, maar met modder gooien op het persoonlijke vlak is nergens voor nodig. Hou het dus ontopic en op een plezierige toon.

[alienfruit]

Flex is een enterprise product, en richt zeg echt niet op het grafische werk. De kracht ligt juist in serverside ondersteuning naar webservices. Ga het eens proberen en je zult verstelt zijn hoe snel je een applicatie in elkaar zet.

Ik weet prima wat Flex is, alleen ik las Flex als Flash. Oftewel ik haalde wat namen door elkaar. Execuses dat het zorgde voor een flinke discussie.

[ Voor 14% gewijzigd door alienfruit op 26-08-2005 15:20 ]

[raptorix]

alienfruit schreef op vrijdag 26 augustus 2005 @ 15:07:
[...]


Ik weet prima wat Flex is, alleen ik las Flex als Flash. Oftewel ik haalde wat namen door elkaar. Execuses dat het zorgde voor een flinke discussie.

Oki, overigens vind ik dit een mooi voorbeeld hoe flex kan worden toegepast:

http://flexapps.macromedia.com/flex15/restaurant/finder.mxml

[Verwijderd]

raptorix schreef op vrijdag 26 augustus 2005 @ 15:31:
http://flexapps.macromedia.com/flex15/restaurant/finder.mxml

Ik wil het restaurant bookmarken wat ik heb gevonden...

[Verwijderd]

De reden waarom ik Flex noemde (zonder er ooit mee gewerkt te hebben ), was puur om het hele pakket\framework. Je hebt een ontwikkelomgeving, controls, geïntegreerd, abstract, etc. Dingen die een programmeur\manager snel en 'makkelijk' producten\projecten laat ontwikkelen.

Dit vind ik in AJAX (nog) niet terug, alhoewel je natuurlijk je eigen controls en frame kan opbouwen, maar dit kost tijd. Maar nu kijkend naar Backbase lijkt dit qua tools en middelen ook veel op Flex (heb de site snel bekijken, dus kan het fout hebben) en dat ziet er ook veel belovend uit. (Ook mooie demo's trouwens).

Voor de opmerking dat Flex traag is (zoals Gordijnstok heeft ondervonden), hopelijk wordt dit bij komende versies verholpen en dat het over een jaar of twee echt goed bruikbaar is.

[Verwijderd]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 15:35:
Ik wil het restaurant bookmarken wat ik heb gevonden...

Dit nadeel heeft AJAX niet?

[Bluestorm]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 15:46:
[...]

Dit nadeel heeft AJAX niet?

Hoeft niet persee volgens mij. Je zou de URL achter het # teken kunnen manipuleren iedere keer als er wat nieuws wordt geladen. De pagina refresht dan niet, maar je kunt achteraf wel de precieze toestand achterhalen uit de URL. (in m'n superkleine testpagina werkte het in iedergeval)

[Verwijderd]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 15:46:
Dit nadeel heeft AJAX niet?

Dit probleem heeft AJAX net zo hard op het moment dat je AJAX voor al je communicatie gaat gebruiken. Daarom gaf ik in een van mijn eerste posts in deze thread aan dat ik AJAX gehyped vind en dat ik het enkel interressant vind in gevallen van bijvoorbeeld van elkaar afhankelijke dropdowns.

En Flex is handig voor bijvoorbeeld duidelijke diagrammen waar een plaatje niet volstaat. Voor totaal oplossingen vind ik beide niet geschikt.

[raptorix]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 15:35:
[...]

Ik wil het restaurant bookmarken wat ik heb gevonden...

Je zou in de flash zelf een knop kunnen maken met bookmark this location. Vervolgens een javascript functie in de pagina aanroepen die de juiste info opslaan. Als iemand via de bookmark komt kan je de paramater vanuit de pagina doorzenden aan de flash.

[Verwijderd]

Het hele punt met RIA's en hun bookmarks is dat alles op het web nog steeds als een pagina wordt beschouwd. Waar heb je bijvoorbeeld de back/forward/ en stop button nog voor nodig. Eigenlijk moet er een mogelijkheid komen om die buttons uit te schakelen in de browser doordat je bijvoorbeeld een bestand definieert op de server net zoals een favicon.ico zodat de browser ziet dat het hier gaat om een web applicatie en niet om een collectie van pagina's.

Dit zijn duidelijke nadelen aan zowel Ajax, Flex, Java Webstart (al draait dit niet in de browser) en Applets. Het hangt samen met het soort applicatie of je echt veel waarde moet hangen aan die bookmarks discussie. Er zijn maar weinig applicaties die geschikt zijn als bookmark, dat is nu ook al en dat verandert niet zonder dat de browser kan reageren op de context van van het canvas van de browser.

Ik zie voor Ajax eigenlijk ook maar bar weinig mogelijkheden op de frontend. Er zijn vaak situaties waarin je zelfs wilt dat de pagina lekker gewoon wordt herladen zoals bijvoorbeeld banners. Ik zie de voordelen ook voornamelijk in gebruik van administratieve interfaces in de browser waar je veel met databewerking bezig bent.

Echter, en dat wil ik wel vermelden is de groei bij applicaties met javascript groter is dan bij menig andere omgeving. Er wordt met bizar veel enthousiasme door velen mensen gewerkt aan onder andere frameworks als dojo en django en de kwaliteit laat op bepaalde plekken nog te wensen over maar de drive is enorm en de kwaliteit gaat met stapjes omhoog. Waar het vooral nog aan ontbeert is goede ontwikkelaars met kennis van het hele pakket wat je nodig hebt.

[ Voor 17% gewijzigd door Verwijderd op 26-08-2005 20:56 ]

[Verwijderd]

Verwijderd schreef op woensdag 24 augustus 2005 @ 16:28:
maar ik ze me er nog geen Office 2003 achtige layout mee in elkaar zetten, niemand eigenlijk.

Eenvoudige dummie interface: http://83.98.152.28/sampl....mxml?versionChecked=true

Gunp01nt schreef op woensdag 24 augustus 2005 @ 16:53:
Flex is vooral leuk voor guided selling naar consumenten toe, niet voor functionele applicaties. De toegevoegde waarde is dat je heel veel kunt werken met animatie (niet alleen voor irritante banners maar ook leuk voor visuele cues) en multimedia-elementen, zodat je bijv. allerlei indrukken van een vakantiereis kunt geven.

Interessant dat meerdere mensen in dit topic soortgelijke dingen roepen, dat Flex niet voor echte applicaties is. En dat terwijl het merendeel van onze klanten het juist voor dit soort zaken toepast, met name op het intranet. Ik denk dat deze verwarring met name komt door het gebrek aan publieke voorbeelden hiervan? (toegegeven, Macromedia heeft voornamelijk guided selling apps te laten zien omdat ze publiek zijn. Veel bedrijven prefereren niet hun intranet applicaties ten toon te stellen).

Overigens staan er grote performance verbeteringen op schema voor Flex 2.0. Hetgeen niet wil zeggen dat huidige Flex applicaties niet performant kunnen zijn, je moet echter wel beter opletten met wat je doet (maar volgens mij is dat bij veel technieken het geval).

raptorix schreef op donderdag 25 augustus 2005 @ 13:37:
[...]
Ik heb een aantal private demos gezien van iemand van Macromedia en die liepen supersmooth met zaken als realtime datapush en dat was echt indrukwekkend.

Verwijderd schreef op donderdag 25 augustus 2005 @ 15:41:
[...]
Voor javascript zijn er ook genoeg opmerkingen te maken, maar het meerendeel is overkomelijk en om heen te werken. Om de performance van Flex is niet heen te werken..

Ik heb niet de indruk dat je hier uit ervaring spreekt? Mijn ervaring wijst in ieder geval anders uit (en ja, er is nog een hoop te verbeteren ook). Net als bij javascript zijn er bij Flex vele wegen om een probleem heen.

Verwijderd schreef op donderdag 25 augustus 2005 @ 15:41:
[...]Komt nog bij dat de support van Macromedia gewoon rondweg associaal slecht is. De forums lijken wel op deathvalley, geen enkele vraag wordt beantwoord, en voor elke vorm van basic support zelfs als er bugs zijn, worden schandalige support bedragen gevraagd onder het excuus dat er niet genoeg resources zijn.

Dat wat jij de support forums noemt, dat zijn niet de support forums; die zijn namelijk alleen bereikbaar voor klanten. Blocking issues/bugs worden gratis gefixed voor klanten en er worden zelfs klant specifieke releases van Flex gemaakt.

Excuus dat "er niet genoeg resources zijn" ben ik nog niet tegen gekomen, hoe kom je daar aan?

Ook je opmerking over data-caching roept vraagtekens bij mij op; Flex geeft je de keus, je kan zelfs offline je applicatie gebruiken inclusief de data. Hoezo geen cache mogelijkheden?

De discussie van JavaScript vs Flash vs Java kunnen we eindeloos voeren; er zal nooit een eenduidig antwoord komen denk ik. Voor de ene applicatie is JavaScript de beste keus, een ander Flash, weer een ander Java.

[alienfruit]

Eenvoudige dummie interface: http://83.98.152.28/sampl....mxml?versionChecked=true

Ziet er leuk uit? Maar hoe kan je nou je eigen stijl maken dus niet de Halo-theme?

[chem]

Verwijderd schreef op zaterdag 27 augustus 2005 @ 15:35:
[...]


Eenvoudige dummie interface: http://83.98.152.28/sampl....mxml?versionChecked=true

Ik moet het nog een keer zeggen... wat een gruwelijk traag gedoe is dat Flex (nog?). 10 volle seconden om een GUI te laden is imho echt veel te veel.

Het doet me al te veel aan client-side Java denken; het blijft onwennig traag en sluggish allemaal.

Ook mis ik, en eigenlijk vooral, de GUI van m'n OS. Weer allemaal nieuwe widgets, nieuw gedrag en waarschijnlijk zal de developer nog (te) veel logica zelf moeten bouwen. De toolbar zit niet waar ik hem verwacht - etc., etc. etc.

Laat me even voorop stellen: dit is bij AJAX net zo goed; al voelt het daar sneller aan (opstarttijd is korter), heb ik m'n eigen OS' widgets (al zijn sommige widgets niet via HTML bereikbaar) en voelt het allemaal veel snappier aan.

Daarom vind ik dat AJAX en dergelijke tools alleen nuttig zijn als *aanvulling* op hedendaagse mogelijkheden, een echte statefull desktop applicatie blijft zoveel fijner. Enige wat ik nog fijn vond werken (als gebruiker) is XUL, aangezien het te themen valt *door de gebruiker*. Helaas is de penentratie daarvan vrijwel nihil, en heeft het dermate veel beperkingen dat het vooral prototypische waarde heeft.

[Verwijderd]

Verwijderd schreef op zaterdag 27 augustus 2005 @ 15:35:
Eenvoudige dummie interface: http://83.98.152.28/sampl....mxml?versionChecked=true

Het ziet er zonder meer leuk uit, dat wil ik je nageven, maar dan praten we nog over een basis canvas met een kleine hoeveelheid informatie. Wat gebeurt er straks als we toolbars met icons krijgen, en de listview wordt volgestampt met data.

Interessant dat meerdere mensen in dit topic soortgelijke dingen roepen, dat Flex niet voor echte applicaties is.

Nee, dat het nog niet op het niveau beland is dat je voor echte volle interfaces nodig hebt. Er is niemand hier die het niet zou willen toepassen als het qua performance een flinke stap voorruit zou doen. Ik denk dat de hoeveelheid Flex niet willen toepassen vanwege Flash wel meevalt.

Overigens staan er grote performance verbeteringen op schema voor Flex 2.0. Hetgeen niet wil zeggen dat huidige Flex applicaties niet performant kunnen zijn, je moet echter wel beter opletten met wat je doet (maar volgens mij is dat bij veel technieken het geval).

Ik hoop het echt, het zou zonde zijn als het zo lang bleef aanmodderen. Het is een mooi product, en we hebben in ieder geval weer keuze in ontwikkelen, maar een Flash 8 player weliswaar beta stadium kon de performance van oa zaken die ik bij flex oa dashboard applicaties van Akzo heb gezien ook niet verbeteren. Het zou jammer zijn als het Central achterna ging, het verdient beter.

Ik heb niet de indruk dat je hier uit ervaring spreekt? Mijn ervaring wijst in ieder geval anders uit (en ja, er is nog een hoop te verbeteren ook). Net als bij javascript zijn er bij Flex vele wegen om een probleem heen.

We gebruikten een flinke server met een nog relatief licht testplan. Het enige wat Flex hoeft te doen is compileren en de sessies en server cache regelen, maar toch had die het er heel erg moeilijk mee. Ik zal de laatste zijn die de problemen bij Javascript zal ontkennen, ik heb ook altijd gezegd dat ze er wel degelijk zijn, en dat het aan de requirements afhangt of ze acceptabel zijn. Ik vind dat er op veel vlakken nog veel werk ligt, oa in functionaliteit voor sneller ontwikkelen. Dat is waar Flex momenteel de absolute aanvoerder is. Er is op "Ajax" vlak maar weinig wat zorgt voor sneller ontwikkelen en je vrijheid behouden.

Dat wat jij de support forums noemt, dat zijn niet de support forums; die zijn namelijk alleen bereikbaar voor klanten. Blocking issues/bugs worden gratis gefixed voor klanten en er worden zelfs klant specifieke releases van Flex gemaakt.

Hoe wordt dit aangepakt bij een volgende release, of een patch. Worden dan al die custom builds weer door de testmolen gegooid, waarna alle stages van tests weer worden uitgevoerd. Idem bij een nieuwe mayor release, worden er dan weer nieuwe versies ontwikkeld, immers niet alle mayor bugs gaan een productieproces in bij Macromedia. Wat is de reden dan voor die specifieke releases, is het nog niet klaar voor het echte werk? Het komt mij over als additioneel flexibel zijn omdat het produkt out of the box niet voldoet.

Excuus dat "er niet genoeg resources zijn" ben ik nog niet tegen gekomen, hoe kom je daar aan?

Van iemand die meer connecties heeft met MM ontwikkelaars, en die mij dit wist te vertellen nadat ik oa zag dat er op zowel de Breeze als Flex forums geen enkele serieuze vraag wordt beantwoord door Macromedia.

Ook je opmerking over data-caching roept vraagtekens bij mij op; Flex geeft je de keus, je kan zelfs offline je applicatie gebruiken inclusief de data. Hoezo geen cache mogelijkheden?

Hoe gaat een SWF om met 304 (Not Modified) headers? Kortom, elke sessie zal je weer je assets moeten inladen. Het hangt af van je applicatie in hoeverre dit problemen kan gaan opleveren.

De discussie van JavaScript vs Flash vs Java kunnen we eindeloos voeren; er zal nooit een eenduidig antwoord komen denk ik. Voor de ene applicatie is JavaScript de beste keus, een ander Flash, weer een ander Java.

Het maakt mij echt helemaal niets uit, wat voor mij telt is het eindresultaat. Als daarvoor Flex nodig is, geen enkel probleem. Het moet alleen nog uitkristaliseren, en geoptimaliseerd worden.

[ Voor 16% gewijzigd door Verwijderd op 27-08-2005 19:37 ]

[raptorix]

chem schreef op zaterdag 27 augustus 2005 @ 17:00:
[...]

Ik moet het nog een keer zeggen... wat een gruwelijk traag gedoe is dat Flex (nog?). 10 volle seconden om een GUI te laden is imho echt veel te veel.

Het doet me al te veel aan client-side Java denken; het blijft onwennig traag en sluggish allemaal.

Ook mis ik, en eigenlijk vooral, de GUI van m'n OS. Weer allemaal nieuwe widgets, nieuw gedrag en waarschijnlijk zal de developer nog (te) veel logica zelf moeten bouwen. De toolbar zit niet waar ik hem verwacht - etc., etc. etc.

Laat me even voorop stellen: dit is bij AJAX net zo goed; al voelt het daar sneller aan (opstarttijd is korter), heb ik m'n eigen OS' widgets (al zijn sommige widgets niet via HTML bereikbaar) en voelt het allemaal veel snappier aan.

Daarom vind ik dat AJAX en dergelijke tools alleen nuttig zijn als *aanvulling* op hedendaagse mogelijkheden, een echte statefull desktop applicatie blijft zoveel fijner. Enige wat ik nog fijn vond werken (als gebruiker) is XUL, aangezien het te themen valt *door de gebruiker*. Helaas is de penentratie daarvan vrijwel nihil, en heeft het dermate veel beperkingen dat het vooral prototypische waarde heeft.

Dat is initieele load, bij goed gebruik van rich interface applications is de totale laadtijd korter omdat men niet continue zaken hoeft in te laden waarvan dat eigenlijk helemaal niet nodig zou zijn.

Bovendien heeft niemand ooit beweerd dat RIA's complete websites zouden moeten vervangen, voor bepaalde zaken kan het nuttig zijn, voor andere zaken overkill. IMO zijn Ria's met name handig waarbij je veel userinteraction hebt. Iedereen kan begrijpen dat het weinig nut heeft om RIA's in te zetten voor een site waar men alleen zaken leest.

[PrisonerOfPain]

Bluestorm schreef op vrijdag 26 augustus 2005 @ 15:50:
Hoeft niet persee volgens mij. Je zou de URL achter het # teken kunnen manipuleren iedere keer als er wat nieuws wordt geladen. De pagina refresht dan niet, maar je kunt achteraf wel de precieze toestand achterhalen uit de URL. (in m'n superkleine testpagina werkte het in iedergeval)

Klopt anchors zijn daar prima voor te gebruiken. Alleen het bookmarken onder opera 8 (beta, of het in de final opgelost is weet ik niet) werkt niet. Die 'vergeet' namelijk die anchors tijdens het bookmarken, wat best vervelend is.

[Verwijderd]

chem schreef op zaterdag 27 augustus 2005 @ 17:00:
[...]
10 volle seconden om een GUI te laden is imho echt veel te veel.

Hmmm, veel langzamer dan mijn lokale Outlook is het niet (toegegeven, daar gebeurt meer dan in bovenstaand dummie voorbeeld dat alles behalve geoptimaliseerd is voor opstart performance - daar kan best nog wat in verbeterd worden). Wat ik bedoel: een applicatie opstarten moet niet vergeleken worden met het laden van 1 enkele webpagina.

Verwijderd schreef op zaterdag 27 augustus 2005 @ 18:19:
Hoe gaat een SWF om met 304 (Not Modified) headers? Kortom, elke sessie zal je weer je assets moeten inladen. Het hangt af van je applicatie in hoeverre dit problemen kan gaan opleveren.

Alle SWFs, WebServices en XML/HTTPRequests worden door de Flash Player via de browser uitgevoerd. Oftel; als je browser de headers goed implementeerd dan zou Flash daar ook automatisch mee om moeten gaan. Tenzij ik nu echt iets over het hoofd zie.

Verwijderd schreef op zaterdag 27 augustus 2005 @ 18:19:
Van iemand die meer connecties heeft met MM ontwikkelaars, en die mij dit wist te vertellen nadat ik oa zag dat er op zowel de Breeze als Flex forums geen enkele serieuze vraag wordt beantwoord door Macromedia.

Hmmm, aangezien ik bij Macromedia werk heb ik geloof ik toch wel alle connecties die ik nodig heb. Sterker nog, ik probeer er zelf continue voor te zorgen dat onze Flex klanten de support krijgen die ze nodig hebben en ik heb hierover nog geen klachten gehad. Wat betreft de forums kan ik me wel iets voorstellen maar nogmaals; dat is niet waar klanten heen gaan voor support. Die hebben namelijk allemaal een engineer toegewezen gekregen waar ze rechtstreeks terecht kunnen bij problemen en alle klanten die ik ken die hiervan gebruik hebben gemaakt zijn zeer tevreden (en indien je iemand kent die dat niet is, let me know dan moet dat zo snel mogelijk opgelost worden. Nogmaals, ik ken ze niet).

[Verwijderd]

Verwijderd schreef op zondag 28 augustus 2005 @ 00:43:
Hmmm, veel langzamer dan mijn lokale Outlook is het niet (toegegeven, daar gebeurt meer dan in bovenstaand dummie voorbeeld dat alles behalve geoptimaliseerd is voor opstart performance - daar kan best nog wat in verbeterd worden). Wat ik bedoel: een applicatie opstarten moet niet vergeleken worden met het laden van 1 enkele webpagina.

Ik zie die starttijd ook niet zo als een probleem eerlijk gezegd. Als je maar zorgt dat de client merkt dat er iets gebeurt, en daar zorgt de loading bar voor.

Alle SWFs, WebServices en XML/HTTPRequests worden door de Flash Player via de browser uitgevoerd. Oftel; als je browser de headers goed implementeerd dan zou Flash daar ook automatisch mee om moeten gaan. Tenzij ik nu echt iets over het hoofd zie.

Als dit het geval is valt mij hele discussiepunt over clientside cache weg, tenzij ik nog iets over het hoofd zie zoals loadMovie voor elke container Maar dat lijken me ook niet de zaken die echte vertragingen opleveren. In ieder geval op een Ajax vergelijkbare wijze.

Wat betreft de forums kan ik me wel iets voorstellen maar nogmaals; dat is niet waar klanten heen gaan voor support.

Ik ben bekend met je klantgerichtheid in positieve zin. Ik doelde ook meer op het inzetten van resources voor de public forums voor mensen die echt in de problemen komen te zitten.

[alienfruit]

Ja, over de ondersteuning aan Macromedia's is nagenoeg geen kwaad woord over te spreken
Blijf het nog steeds jammer vinden dat ik Studio MX opnieuw moest kopen toen ik van Windows naar MacOSX wilde verhuizen

[ Voor 3% gewijzigd door alienfruit op 28-08-2005 21:06 ]

[Verwijderd]

Ik denk dat er op bepaalde punten wel verbeteringen nodig zijn, met betrekking tot de afhandeling van bug requests, de activatie issues in Studio MX (die Waldo dus perfect had aangepakt maar het is jammer dat hij er uberhaupt werk voor moest verrichten), mayor bugs die al jaren aanwezig zijn maar gewoon niet worden aangepakt waardoor functionaliteit onbruikbaar wordt (cfschedule bug in CF MX heb ik het hier over), en de beperkte aandacht voor DWMX fixes (heb hiervoor ook al 3x een lange lijst aan bugs voor ingediend via het formulier). Maargoed, dat valt buiten de scope van deze thread Ik weet ook niet in hoeverre dit actueel is binnen MM.

[ Voor 8% gewijzigd door Verwijderd op 28-08-2005 22:00 ]

[Verwijderd]

Ik heb niet netjes alle reacties op dit topic doorgelezen, maar ik wil even mijn 2 cents spuiwen:

Ik vind Ajax inderdaad overhyped. Zoals de meesten waarschijnlijk wel weten is er niets nieuws onder de zon; ajax-techniek bestaat al een jaar of 5+, maar heeft pas onlangs een naam gekregen. En zelfs daarvoor was het mogelijk om soortgelijke "effecten" te creeeren, door bijvoorbeeld een verborgen frame te gebruiken als alternatief voor het xdingesrequest object.

Maar goed, het beestje heet nu ajax en natuurlijk zijn er zeer nuttige toepassingen mee te bouwen. Google heeft daar enkele mooie voorbeelden van en deze zijn ook inderdaad erg nuttig. Maar als ik nu bijvoorbeeld kijk naar Microsoft's Live (het is dan nog wel in beta fase), dan vind ik dat 3x niks. Hartstikke leuk hoor, dat je een portal achtige site zo on the fly kan aanpassen. Maar kijk hoe traag het werkt... Al die kleine nieuwsreaders roepen vermoedelijk live een webservice aan en laden vervolgens de headlines in. En dat is te zien, de pagina's werken tergend traag.

Een gewone "statische" pagina vind ik dan een stuk lekkerder werken; eventueel met een options pagina (zoals ze hier bij tweakers hebben) voor lay-out instellingen e.d. Schone html pagina's werken gewoon een stukje lekkerder en sneller. En ja, javascript kan een zegen zijn, maar "live" communicatie vind ik gewoon vervelend.

Verder vind ik inderdaad het zoekmachine argument een hele sterke. Als je een site echt volledig bouwt op ajax, dan kan een zoekmachine daar niet veel mee, voor zover ik weet. Stel dat je een menu hebt wat gebruik maakt van ajax; dan kan een spider deze links al niet eens volgen. Natuurlijk; als je content uit een database inlaad, dan kan je een mooie "verborgen" doorway-achtige pagina maken, maar dat vind ik geen mooie oplossing.

Dus goed. Ajax is nuttig, maar geen revolutie. In vele gevallen zou ik er juist geen gebruik van maken. Alleen voor specifieke doelen vind ik het een handige oplossing.

Overigens ben ik .NET ontwikkelaar. Wij hebben de Telerik tools aangeschaft. Daarin zitten een aantal callback (ajax) componenten. Deze werken heerlijk om te implementeren; ik heb geen regel javascript hoeven schrijven en het werkt als een trein. Ik moest onlangs een soort formulier maken met daarop een aantal listboxen die afhankelijk van elkaar waren. Daarbij waren deze tools een zegen; geen roundtrips naar de server nodig...

[RedRose]

Well,

16 - 19 mei is er de XTech conferentie in Amsterdam waar Ajax uitvoerig behandelt gaat worden, evenals Javascript 2, XSLT 2.0 etc.. Als je ziet hoeveel bedrijfjes daar komen, kan je stellen dat Ajax weldegelijk een bodem heeft om op te groeien, maar dat het allemaal nog erg in de kinderschoenen staat. Ik denk deels vanwege de toepasbaarheid en deels vanwege de wat oudere hedendaags algemeen geaccepteerde technieken.

Maar goed, ik weet meer na XTech.

[OxiMoron]

Ajax is leuk en handig..

Maar als je je aan de standaard wilt houden mag je geen gebruik maken van innerHTML.
Dus kun je alleen dingen aanpassen met de DOM.

Als je bijvoorbeeld een hele grafische (veel plaatjes) website hebt en hierbinnen foto's wilt laten zien is ajax handig om door de foto's te bladeren zonder alle andere plaatjes te herladen. Probleem is echter als je ook nog commentaar bij die foto's hebt.
Dan moet je dus in je javascript html gaan aanmaken, dit is niet echt netjes..

Maar ja.. de meeste ajax sites gebruiken wel innerHTML.. maar toch.. het is niet echt netjes in z'n geheel

[djc]

OxiMoron schreef op vrijdag 21 april 2006 @ 11:14:
Maar ja.. de meeste ajax sites gebruiken wel innerHTML.. maar toch.. het is niet echt netjes in z'n geheel

Qua performance doet innerHTML het alleen wel een stukje beter.

[flowerp]

RedRose schreef op vrijdag 21 april 2006 @ 10:51:
Well,

16 - 19 mei is er de XTech conferentie in Amsterdam waar Ajax uitvoerig behandelt gaat worden, [...]
Maar goed, ik weet meer na XTech.

Het klinkt opzich wel interesant, maar wel ranzig duur zeg! Voor de toegangs prijs kun je bijna een maand een developper laten werken.

[Annie]

flowerp schreef op zondag 23 april 2006 @ 09:35:
[...]

Het klinkt opzich wel interesant, maar wel ranzig duur zeg! Voor de toegangs prijs kun je bijna een maand een developper laten werken.

Pardon? Een developer kost heel wat meer dan dat hoor

Ik vind de prijs wel meevallen (zeker aangezien het een meerdaags evenement is).

[flowerp]

Annie schreef op zondag 23 april 2006 @ 11:24:
[...]

Pardon? Een developer kost heel wat meer dan dat hoor

Dan weet ik niet wat jullie je developpers betalen, maar bij ons kun je voor een krappe 1500,- ex BTW toch echt wel een developper met HBO opleiding een maand laten werken.

Het is langzaam aan het bijtrekken, maar zeker de afgestudeerden van 2003 mochten gezien de schaarste van toen blij zijn als ze voor het minimum loon aan de slag konden (onder het motto van alles beter dan thuis op de bank zitten en waardevolle jaren aan ervaring kwijt raken).

Maar goed, die discussie is eigenlijk beetje offtopic hier

[Fuzzillogic]

Dat innerHTML sneller is, is een "probleem" van de browsers. Het is hoe dan ook niet netjes. Maar dat je niet constant met DOM-nodes wil klooien is ook heel begrijpelijk.
M.i. is de oplossing dan ook om innerHTML te splitsen in 2 stappen. 1) deserializer die van een tekst een DOM-node teruggeeft. Of een exceptie. 2) zet de verkregen DOM-node op de juiste plaats in het document. Als ik mij niet vergis is dat met IE, Mozilla en Opera9 sowieso al mogelijk. Dus geen reden meer om innerHTML te gebruiken.

We zijn nu 7 maanden verder sinds de opening van deze thread. Opmerkelijk vind ik dat er nog steeds geen ajax-apps zijn die echt uitstijgen boven de normale desktop-varianten. Ik heb coole dingen gezien ja, waarvan ik een jaar geleden niet had gedacht dat het mogelijk was met een browser. Maar qua snelheid, ease of use, gebruiksvriendelijkheid kan het gewoon niet tippen aan een desktop-app. Om nog maar te zwijgen over het programmeer-gemak.

Uitzonderingen daargelaten probeert Ajax nog steeds krampachtig dingen voor elkaar te krijgen die met andere methoden (Statische pagina's, Java, normale native desktop-apps) veel makkelijker en beter voor elkaar te krijgen zijn. Waarom wordt er dan nog steeds zo groots op ingezet?

[Verwijderd]

flowerp schreef op zondag 23 april 2006 @ 12:39:
Dan weet ik niet wat jullie je developpers betalen, maar bij ons kun je voor een krappe 1500,- ex BTW toch echt wel een developper met HBO opleiding een maand laten werken.

offtopic:
Wat jammer dat deze discussie hier offtopic is, want ik overweeg nu om klussen 1:1 aan 'jullie' door te schuiven en zelf in een hangmat op een Thais strand te gaan liggen.

edit@flowerp hieronder: Ik overdrijf natuurlijk graag Maar in elk geval is loon van een werknemer totaal iets anders dan loonkosten voor een werkgever. (sociale verzekeringen, werkplek etc.). Het is niet uitzonderlijk dat een werkgever aan een klant 100,- per uur rekent, terwijl de werknemer die het werk uitvoert daar netto 10,- aan overhoud (Mag 'ie nog blij zijn).

Van werken in dienstverband is nog nooit iemand echt rijk geworden.

[ Voor 37% gewijzigd door Verwijderd op 24-04-2006 14:16 . Reden: verduidelijkt + offtopic gemaakt ]

[flowerp]

Verwijderd schreef op zondag 23 april 2006 @ 16:20:
[...]
Wat jammer dat deze discussie hier offtopic is, want ik overweeg nu om klussen 1:1 aan 'jullie' door te schuiven en zelf in een hangmat op een Thais strand te gaan liggen.

offtopic:
Is het zo erg? Mischien moeten we er maar een apart topic voor openen Maar helaas, wij komen al om van het werk dus nog meer erbij gaat echt niet lukken. Daarbij, we doen geen externe opdrachten maar bouwen onze eigen (Java EE) software die we verkopen. Maar zo bijzonder kan het loon ook niet zijn, want gedurende de afgelopen +- 3.5 jaar hebben we meerdere solicitaties gehad van zowel informatica HBO als informatica WO afgestudeerden en die kwamen gewoon allemaal werken voor het loon dat geboden werd. De meeste waren al lang blij dat ze uberhaupt aan de slag konden!

Vergeet niet dat 2002/2003 bijna onmogelijk was voor pas afgestudeerden om aan een baan te komen zodat deze mensen eigenlijk voor elk loon wel wilde werken. De komende jaren zal het wellicht wat moeilijker worden om aan personeel te komen die geen absurde loon-eisen stelt, omdat de economie en de ICT sector in het bijzonder weer een beetje aan het bijtrekken is.

[Verwijderd]

Wat mij voornamelijk opvalt bij ajax is dat de commerciele wereld niet echt lijkt te weten wat het inhoud. Zo lijkt het alsof versleepbare dingen opeens 'ajax' en 'web 2.0' is, terwijl dit alleen maar javascript hoeft te zijn. Dan de web aplicaties die wel gebruik maken van ajax, maar het er niet zo dik opleggen worden dan bestempeld als niet helemaal ' web 2.0 ' etc.

Al met al is ajax heel cool, maar net zoiets als dhtml. Er wordt gedaan alsof het super makkelijk is, en dat elke developer er zo maar mee kan werken terwjil in de praktijk ajax best moeilijk toepasbaar is. Ik denk dan ook dat er veel ajax site's / web aplicaties onderweg zijn, maar dat er veel nooit het daglicht zullen zien.

[Gomez12]

Nexxennium schreef op zondag 23 april 2006 @ 14:05:
We zijn nu 7 maanden verder sinds de opening van deze thread. Opmerkelijk vind ik dat er nog steeds geen ajax-apps zijn die echt uitstijgen boven de normale desktop-varianten. Ik heb coole dingen gezien ja, waarvan ik een jaar geleden niet had gedacht dat het mogelijk was met een browser. Maar qua snelheid, ease of use, gebruiksvriendelijkheid kan het gewoon niet tippen aan een desktop-app. Om nog maar te zwijgen over het programmeer-gemak.

Uitzonderingen daargelaten probeert Ajax nog steeds krampachtig dingen voor elkaar te krijgen die met andere methoden (Statische pagina's, Java, normale native desktop-apps) veel makkelijker en beter voor elkaar te krijgen zijn. Waarom wordt er dan nog steeds zo groots op ingezet?

Ik vermoed omdat ajax een hele mooie tussen-oplossing is. Het is geen page-reload zoals html, het is geen jre benodigd zoals java. ( flash laat ik even buiten beschouwing, want dit is mooie techniek die ik nu standaard laat blocken vanwege flashadvertenties met geluid etc, dus verpest )

Het is gewoon een techniek die nu gebruikt kan worden bij bijna iedereen. Java is misschien mooier, maar niet iedereen heeft het geinstalleerd staan.

En ajax is perfect te gebruiken voor enkele dingen binnen een site ( zie tweakers.net zoekfunctie / google beta search functie( naam weet ik ff niet meer )).
Als je een site 100% ajax afhankelijk maakt, dan kan je inderdaad net zo goed kiezen voor java / .Net / flash.
Maar op dit moment zie ik het voornamelijk gebruikt worden voor makkelijke extraatjes, het is niet 100% nodig ( het is via page reload te doen, maar onhandiger ) zodat iedereen die het wil het kan gebruiken.

Btw, het gaat hier over webpages, niet over webapps. Want voor webapps denk ik inderdaad dat 95% beter in java / .Net geschreven kan worden puur vanwege het feit dat je dan meer mogelijkheden hebt en je hebt de mogelijkheid om bij je klant een requirement voor je app neer te leggen. Dit heb je niet met een webpage.

[flowerp]

Gomez12 schreef op zondag 23 april 2006 @ 21:27:
[...]
Btw, het gaat hier over webpages, niet over webapps. Want voor webapps denk ik inderdaad dat 95% beter in java / .Net geschreven kan worden puur vanwege het feit dat je dan meer mogelijkheden hebt

Ik snap je opmerking niet helemaal. Je kunt voor webapps beter Java of .Net gebruiken in plaats van Ajax? Het enige wat een -beetje- zou kunnen concureren met AJAX zijn Java applets, maar omdat je ook .NET noemt neem ik aan dat je bedoeld dat Java en .NET server side gebruikt worden. In dat geval zijn AJAX en Java/.NET helemaal geen concurrenten maar juist complementair.

Je hebt zowel in Java als .NET web componenten die onderliggend AJAX gebruiken. Het gebruik van AJAX is dan voor de eind gebruiker (de serverside programmeur dus) compleet verborgen. Je plaatst een tag (in geval van JSP of ASP pagina), voorziet deze van een data-binding en klaar ben je. Het component regelt zelf het omzetten van de data die je data-binding leverd naar XML en rendert zelf de benodigde javascript naar de response die asynchroon de requesten gaat doen.

Nogmaals, als programmeur hoef je je dan helemaal niet met AJAX bezig te houden. Je zult alleen merken dat je methoden in je (serverside) class worden aangeroepen, maar of dat nou geinitieerd wordt door een full-page refresh of door een AJAX request doet er technisch niet toe. Je methoden geven ook gewone data terug (bv aan ArrayList met Integers erin).

[Gomez12]

flowerp schreef op zondag 23 april 2006 @ 22:01:
[...]


Ik snap je opmerking niet helemaal. Je kunt voor webapps beter Java of .Net gebruiken in plaats van Ajax? Het enige wat een -beetje- zou kunnen concureren met AJAX zijn Java applets, maar omdat je ook .NET noemt neem ik aan dat je bedoeld dat Java en .NET server side gebruikt worden. In dat geval zijn AJAX en Java/.NET helemaal geen concurrenten maar juist complementair.

Je hebt zowel in Java als .NET web componenten die onderliggend AJAX gebruiken. Het gebruik van AJAX is dan voor de eind gebruiker (de serverside programmeur dus) compleet verborgen. Je plaatst een tag (in geval van JSP of ASP pagina), voorziet deze van een data-binding en klaar ben je. Het component regelt zelf het omzetten van de data die je data-binding leverd naar XML en rendert zelf de benodigde javascript naar de response die asynchroon de requesten gaat doen.

Nogmaals, als programmeur hoef je je dan helemaal niet met AJAX bezig te houden. Je zult alleen merken dat je methoden in je (serverside) class worden aangeroepen, maar of dat nou geinitieerd wordt door een full-page refresh of door een AJAX request doet er technisch niet toe. Je methoden geven ook gewone data terug (bv aan ArrayList met Integers erin).

Nee hoor, niet alleen server-side ook client-side.Wat ik bedoel is dat een webapp helemaal niet altijd via een browser hoeft te lopen.
In veel gevallen zie ik dat er toch makkelijk een client-side app kan draaien die de complete gui verzorgt en alleen voor de data afhankelijk is van het web. Dan heb ik nog steeds een web-app, en de data-transfer hoeft helemaal niet via ajax te lopen ( of je moet ajax zo breed zien dat je alles wat maar met xml te maken heeft onder ajax schaart, zoals ik het idee heb wat je met je voorbeeld illustreert ) Ajax is voor mij een bepaalde werkwijze en niet alles wat maar met een xmlhttp request te maken heeft.

Hint. XML HTTP Request, zegt volgens mij alleen maar iets over een manier om mbv XML over http een request te doen.

[flowerp]

Gomez12 schreef op zondag 23 april 2006 @ 22:52:
[...]
Nee hoor, niet alleen server-side ook client-side.Wat ik bedoel is dat een webapp helemaal niet altijd via een browser hoeft te lopen.

Ok, op die manier. Tjsa, dan zou ik het persoonlijk geen web-app noemen maar meer een remote-app. Het probleem tot op heden met deze aanpak was dat je geen makkelijk deployment model hebt. Met een web-applicatie (voor alle duidelijkheid via een browser dus), kun je naar een eenduidige URL surfen en je applicatie 'start' dan (begint een sessie voor jou). Traditionele desktop applicaties die de GUI client-side draaien (met native widgets) en voor business logic contact opnemen met de server hebben veel problemen van de traditionele applicaties zoals installatie en onderhoud.

In dit licht gezien zou het oude X-Window protocol wel interesant zijn (alleen je GUI widgets draaien client-side, alle andere dingen draaien server side) maar dat is helaas niet echt geoptimaliseerd voor een WAN en veel connecties. En daarbij heb je ook niet echt een makkelijke 'start' functie.

Een andere interesante technologie die voor de door jou genoemde werkwijze gebruikt kan worden is java webstart. Dit zorgt voor een eenvoudige deploy methode en zorgt dat je client-side code gesynched is met de nieuwste versies op de server. Wel programmeer je hiermee toch meer een client-side app die (af en toe) contact op neemt met de server. Dit is toch nog net even wat anders dan een 'gewone' server side app waarbij je niet expliciet 2 communicerende systemen schrijft (de client-tier en de server-tier in dit geval), maar waarbij je kort door de bocht de GUI naar de client stuurt.

In veel gevallen zie ik dat er toch makkelijk een client-side app kan draaien die de complete gui verzorgt en alleen voor de data afhankelijk is van het web.

Dit zie ik ook zeker als een mogelijkheid. Nu wordt er veel tijd gestopt in het proppen van applicatie functionaliteit in een protocol (http) en een markup taal (html) die hier eigenlijk nooit voor ontworpen waren.

( of je moet ajax zo breed zien dat je alles wat maar met xml te maken heeft onder ajax schaart, zoals ik het idee heb wat je met je voorbeeld illustreert )

Dan heb je me verkeerd begrepen. De voorbeelden (Java web components, dwz JSF en .NET controls) renderden in mijn voorbeeld AJAX. M.a.w. Asynchronous Javascript And XML. Dezelfde web components kunnen met een andere renderkit ook een totaal andere techniek gebruiken. Het zelfde webcomponent in JSF zou ook XUL kunnen renderen en theoretisch zelfs Swing widgets (hoewel dat laatste een theoretische aangelegenheid blijft).

Het punt was dat vanuit het viewpoint van de serverside programmeur die components gebruikt, de onderliggende techniek niet direct zichtbaar is. Binnen de HTML renderkit zou een widget net zo goed een hidden self-refressing iframe kunnen renderen en via dat mechanisme XML ontvangen of eventueel direct tekst of HTML. Dat kun je dan met een mooi naampje HSIX gaan noemen of whatever. Ook hier zal de serverside programmeur alleen zien dat haar methodes worden aangeroepen die ze heeft gebonden aan het serverside component.

Hint. XML HTTP Request, zegt volgens mij alleen maar iets over een manier om mbv XML over http een request te doen.

Maar met HET XMLHttpRequest object wordt het specificieke object bedoeld wat aangeboden wordt door een browser en waarmee je zowel sync en async via javascript requesten kunt doen. Een heel simpel ding. In essentie is het niet meer en niets minder.

Een generieke XML request over HTTP heet ook wel een webservice

[Verwijderd]

flowerp schreef op zondag 23 april 2006 @ 23:47:Een andere interesante technologie die voor de door jou genoemde werkwijze gebruikt kan worden is java webstart. Dit zorgt voor een eenvoudige deploy methode en zorgt dat je client-side code gesynched is met de nieuwste versies op de server.

In .NET 2.0 zit nu ook iets vergelijkbaars: ClickOnce

[ Voor 82% gewijzigd door Verwijderd op 24-04-2006 08:03 ]

[pgussow]

Wij (Cordys) werken sinds 2000 via de AJAX methode. 1 van de belangrijkste redenen (toen) was dat je de power van de lokale PC's (Die tegenwoordig toch behoorlijk wat rekenkracht en geheugen hebben) optimaal te kunnen benutten. Je kan dus meer clients bedienen met dezelfde server hardware.

Maar de AJAX methode is niet zalig-makend. Ook deze manier van werken heeft een aantal nadelen/valkuilen (sommige al eerder genoemd) waar je je terdege van bewust moet zijn:

• Browser afhankelijkheid. IE houdt zich misschien niet geheel aan de standaarden, maar je kan er wel gigantisch veel mee
• Je moet je heel erg bewust zijn van de hoeveelheid roundtrips die je gaat doen. Combineren van requests, local caching, etc om je applicatie goed performant te houden.
• Dicipline van je ontwikkelaars. JavaScript is behoorlijk krachtig, maar het is ook heel erg makkelijk om er een gigantische puinhoop van te maken die niet meer onderhoudbaar is. Dus de kwaliteit van je ontwikkelaars is heel erg belangrijk.
• Combinaties van asynchroon/synchroon. Per pagina moet je goede keuzen maken: welke data heb ik minimaal nodig en welke data kan ik onder water bij lezen.
• Mensen zijn geneigt om data validatie alleen in JavaScript te doen en het op de server niet meer te controleren. Vertrouw nooit de data die vanaf de browser komt, ook niet in een AJAX omgeving.