[discussie] AJAX: overhyped of zegen?

zaterdag 20 augustus 2005 00:45

Cool

Topicstarter

Ja ik zag het al. Er werd ook al diverse keren gerefereerd naar Backbase. Nou ik krijg in mijn moderne, capabele browser (Opera 8.02) dit te zien: "our web browser is not compatible with the primary Backbase site." Dat is natuurlijk ook een (afgrijselijke) manier om van de multi-browser-support-hell af te komen.

Maar wat ik in dat topic zo 1-2-3 ook niet zag is waarom Ajax zo de hemel in geprezen wordt. Wat maakt het beter dan bestaande technieken, die er notabene voor gemaakt?

Acties:

zaterdag 20 augustus 2005 00:52

the alien you never expected

Java gebruiken heeft de requirement dat je Java runtime moet installeren, iets wat ik alleen heb omdat ik JBuilder heb draaien. Maar normaal gesproken installeer ik het niet, dan ish et gewoon dan maar na de concurrent. Als een website persé Java wil gebruiken. Overigens heb je daar toch Administrator-rechten nodig

Verder heb je gelijk met accesebility probleem bij het gebruik van Java, maar daar zijn ze bij IBM druk mee bezig. Onder Windows heb je hetzelfde probleem hoor, zolang de framework niet de WAA Microsoft Active Accessibility 2.0 implementeert. Kun je ook niet fatsoenlijk werken met Win32/.NEt programma's in Windows XP bij. Verder heb je ook het probleem dat de meeste slechtzienden of blinden die gebruik maken van programma's zoals JAWS of WindowEyes, vaak verouderde versie gebruiken. Waardoor de gebruiker toch de ondersteuning voor de nieuwe MSFT api moet missen, waarom? Omdat de licentie voor bijv. JAWS begint voor 895euro, niet een goedkoop hulpmiddel. Een braille leesregel ook niet, dat gaat richting de duizenden euro's.

[ Voor 9% gewijzigd door alienfruit op 20-08-2005 00:53 ]

Acties:

zaterdag 20 augustus 2005 00:53

Devver

Pixelated

Accessibility hoeft geen probleem te zijn, mits je je site/applicatie/whatever maar op de juiste manier opbouwt: zorg voor een goede basis die zonder javascript gewoon functioneert. Bouw daar vervolgens een laag overheen mbv javascript (al dan niet ism XmlHttpRequest voor onderhuids client-server communicatie - er zijn soortgelijke methoden die al jaren gebruikt worden) - het key(stop?)woord hier is 'unobtrusive'.

Intentionally left blank

Acties:

zaterdag 20 augustus 2005 01:02

Cool

Topicstarter

Mensen installeren de meest vreemde fratsen. De JRE kan er ook wel bij. Nee, ik zie dat niet als een doorslaggevend nadeel. Bovendien, zo ongeveer alleen Windows heeft toch standaard géén recente JRE geinstalleerd?

Crisp, ben ik het mee eens. Maar lukt het jou om dat bij de klant te slijten? Je implementeert de UI dan min of meer 2 keer.

[ Voor 24% gewijzigd door Fuzzillogic op 20-08-2005 00:55 ]

Acties:

zaterdag 20 augustus 2005 01:08

the alien you never expected

Maar goed je moet toegeven dat Accessibility en JavaScript niet echt lekker samen gaan, ik bedoel meeste screenreaders hebben niet echt door dat je via DOM de pagina aan het wijzigen bent. Als je dan van die Ajax trucjes wilt uithalen... lijkt het toch meer bedoeld voor een groep mensen die toch nog niet (grote) problemen hebben met hun cognitieve functies (geheugen, visuele perceptie).

Natuurlijk iemand die kleurenblind (hoewel het voor achromatopsie patiënten wel wat probleematischer is) kan het nog prima gebruiken, maar iemand die blind is heeft grotere problemen. Waarom? Omdat hij al helemaal niet kan zien dat er wat wijzigt, in de demo van JAWS kreeg ik nergens een melding dat de pagina is veranderd. Maar wordt Ajax gebruikt om het gebruik van de website/applicatie te vergemakkelijken (bijv. automagische straat lookup na invoer van postcode en huisnummer e.d.). Iets wat je prima kan doen via de unobtrusive manier.

Verder zou ik niet eens JRE op het lijstje zetten van mogelijke oplossingen, omdat je dan weer een extra programma moet installeren. Windows XP/IE komt standaard niet met een JVM. Zo ook Firefox niet. Ik zal het vast mis hebben maar er is geen browser die native ondersteuning heeft voor Java (applets).

[ Voor 19% gewijzigd door alienfruit op 20-08-2005 01:08 ]

Acties:

zaterdag 20 augustus 2005 01:12

Cool

Topicstarter

Als je JRE geen oplossing vindt voor web-based applicaties, wat dan wel?

Acties:

zaterdag 20 augustus 2005 01:29

the alien you never expected

Ik vind zelf JavaScript via de unobstrusive de beste oplossing, het is laagdrempeliger dan Java.Ik zie Java niet echt als taal voor thin-clients, Als je dan toch Java wilt gebruiken zal ik het vervolgens niet in een html pagina gieten, maar goed bij Java heb je ook weer anderen problemen. Accessibility, gui componenten die anders zijn dan host besturingssysteem etc.

Maar goed, ik zie niet precies waarom je dingen twee keer moet implementeren? Alles wat je client-side invult moet je toch ook server-side valideren, bijv. een form validatie. Dat doe je toch ook niet alleen client-side? De gebruiker zonder JavaScript aan heeft dan geen form validatie.

[ Voor 29% gewijzigd door alienfruit op 20-08-2005 01:19 ]

Acties:

zaterdag 20 augustus 2005 02:06

Cool

Topicstarter

Ja gewoon XHTML met wat unobstrusive JavaScript ter ondersteuning lijkt mij idd ook het meest geschikt voor normale websites. Maar daar wilde ik het eigenlijk helemaal niet over hebben.

Kijk waar ze Ajax tegenwoordig voor gebruiken. GMail zit ermee vol. Google Maps. Backbase. Al met al zijn het toch niet bepaald thin clients meer. Waar het mij om gaat is dat Rasmussen e.a. zo vol van Ajax zijn dat ze het ook voor veel grotere applicaties willen inzetten, terwijl ik dat juist zeer onhandig en ongewenst vind. Unobstrusive JavaScript kun je bij dergelijke toepassingen al op je buik schrijven, al was het maar omdat dat veel te duur is.

Waar Rasmussen naartoe wil gaan, zo lijkt het, leunt dermate op Ajax dat het vrijwel onmogelijk is om het zonder Ajax te maken.

[ Voor 21% gewijzigd door Fuzzillogic op 20-08-2005 01:33 ]

Acties:

SinergyX

____(>^^(>0o)>____

Ik vind alle reacties toch best bijzonder, met name de topic dat NMe aanhaalt.
Iedereen vind dit duidelijk geval van "gooi het bij elkaar" product, waar iedere onderliggende product allang zulke creaties kon maken.

Ik denk voor de "matige" website bouwer lijkt dit toch een bijzondere mooi product te zijn. Ik heb 0.0 verstand van javascript, laat staan PHP, maar als ik de source zo bekijk van die voorbeelden is dit toch enorm simple te schrijven. Iedereen wil schijnbaar een superieur opgemaakt en schone website, dat is je volle recht. Ik ga voor het "simpelere" werk, als het op het scherm goed verschijnt vind ik het helemaal best, met name omdat deze sites totaal niet bedrijfsgericht zijn. Niet te zien in opera/mozilla? Dan duidelijk geval van jammer..zoek dan maar een andere website.

^{Nog 1 keertje.. het is SinergyX, niet SynergyX}
_{Im as excited to be here as a 42 gnome warlock who rolled on a green pair of cloth boots but was given a epic staff of uber awsome noob pwning by accident.}

zaterdag 20 augustus 2005 02:10

Acties:

zaterdag 20 augustus 2005 09:40

the alien you never expected

Ja gewoon XHTML met wat unobstrusive JavaScript ter ondersteuning lijkt mij idd ook het meest geschikt voor normale websites. Maar daar wilde ik het eigenlijk helemaal niet over hebben.

Ooh

Kijk waar ze Ajax tegenwoordig voor gebruiken. GMail zit ermee vol. Google Maps. Backbase. Al met al zijn het toch niet bepaald thin clients meer. Waar het mij om gaat is dat Rasmussen e.a. zo vol van Ajax zijn dat ze het ook voor veel grotere applicaties willen inzetten, terwijl ik dat juist zeer onhandig en ongewenst vind. Unobstrusive JavaScript kun je bij dergelijke toepassingen al op je buik schrijven, al was het maar omdat dat veel te duur is.

De projecten van Rasmussen is natuurlijk een positieve inbreng geweest voor de bevordering van de user experience. Hoewel er hier ook weer gevaren liggen overigens. Als je kijkt na een GMail zonder JavaScript dit werkt nog best aardig, vind ik. Een Google Maps achtige applicatie is gewoon onbruikbaar zonder JavaScript. Google Maps werkt bijvoorbeeld anders in IE6 dan in Firefox op implementatie niveau. Maar goed Ajax kan wel de user experience bevorderen maar alleen voor een bepaalde groep gebruikers binnen de doelgroep. Verder zie ik Ajax meer als een extra, om de webapplicatie op te fleuren

GMail werkt toch wat fijner als JavaScript aanstaat

Maar Google Maps en Gmail hebben gezorgd voor de excessive use of Ajax.Verder zie ik niet zoveel in het verplaatsen van desktop applicatie naar een webapplicatie, het heeft meer beperkingen.

Waar Rasmussen naartoe wil gaan, zo lijkt het, leunt dermate op Ajax dat het vrijwel onmogelijk is om het zonder Ajax te maken.

Ja, ik vind hetzelf ook wat overdone -- het werkt leuk. Maar daar houd het wel een beetje voor mij op

Acties:

Alarmnummer

-= Tja =-

AJAX is niet anders dan indicatie dat het huidige webgebeuren met html ed te beperkt is. Zo gauw ze dat fixen is AJAX niet meer nodig. AJAX = dus noodzakelijk kwaad als je zulke interactieve applicaties wilt en alleen html/javascript wilt gebruiken.

zaterdag 20 augustus 2005 10:56

Acties:

djc

AJAX is mijns inziens gewoon een manier om iets van de interactiviteit en responstijd van web-applicaties te verbeteren, om ze op die manier qua gebruiksvriendelijkheid dichter in de buurt van fat clients te krijgen, en daar is het heel geschikt voor.

JavaScript chaotisch? JavaScript is gewoon een dynamische taal, unlike C#/Java/C++/C/whatever, net als PHP, Ruby, Python.

Rustacean

zaterdag 20 augustus 2005 11:22

Acties:

zaterdag 20 augustus 2005 11:26

Software Architect

Werkt hier

Nexxennium schreef op zaterdag 20 augustus 2005 @ 00:33:
De prachtige mogelijkheden die men nu toedicht aan Ajax zijn precies die dingen waar o.a. Mozilla's XUL, Java, .NET zich op richten.

Mja, maar voor JavaScript hoef je alleen maar een (moderne) browser te hebben, welke maakt weinig uit.

Heel Ajax draait op XMLHttpRequest. Een leuk ActiveX-geintje van Microsoft. (het zit dus niet eens ingebouwd in de browser). Het is niet gestandaardiseerd. DOM Level 3 heeft/krijgt wel een gestandaardiseerde vervanger daarvoor, maar tot dusver wordt dat alleen ondersteund door Opera!

Ik ben nu bezig met een applicatie die heel zwaar op javascript leunt om een behoorlijk complex form op te bouwen, zonder de pagina steeds te refreshen. De applicatie is wel dusdanig dat ie toch niet op mobiele apparaten of door blinden bruikbaar is, domweg door het doel van de applicatie, maar ik heb maar weinig problemen op het gebied van JS gehad met IE6 en Firefox.
Het gros van die JS maakt overigens geen gebruik van AJAX, dat heb ik pas kortgeleden erbij gebouwd om wat details beter uit te werken. Opera ondersteun ik voor het gemak idd niet, maar de applicatie doet het dan weer wel "ongetest" in Safari. Bij mijn applicatie kan ik overigens wel wat eisen stellen aan de gebruiker en zijn browser.

JavaScript. Hoewel Ajax een thin-client gebeuren zal zijn blijft, IMHO, JavaScript te chaotisch voor grotere programmeertalen. Java is veel beter geschikt daarvoor, en nu al veel flexibeler en veel krachtiger.

Ach, wat is groot. Mijn app. is iets van 2400 regels javascript en 3300 regels php (inclusief whitespace en comments), is dat groot? Als het groter was geweest had ik het wellicht allemaal OO in JS gemaakt, maar daar had ik nu niet zo'n zin in.

Zonder internetverbinding werkt het niet. Een Java-applicatie kan ook prachtig werken zonder een verbinding. En Java-applicaties kun je met WebStart ook direct starten, zonder dingen te installeren. En met WebStart wordt het ook automatisch up-to-date gehouden.

Dat is haast nog wel je slapste argument

Het gaat juist om dynamische webapplicaties, dan is een internetverbinding vrijwel per definitie nodig.

Sites die 'gewoon' een full-page-refresh doen zijn van nature al beter geschikt voor mobiele apparaten.

Je zult idd rekening met je doelgroep moeten houden.

Wellicht wel. Indien gebruikt in beperkte mate kan het de responsiviteit en interactiviteit van websites verbeteren. Maar of die extra developmenttijd opweegt tegen het nadeel?..

't Hangt echt enorm van je applicatie af.
Bij google maps hoef je je niet zo druk om blinden te maken en de alternatieven (java en .net) zouden ook hogere eisen aan de client stellen. En gmail heb ik nooit gebruikt, maar een webmailclient die wat minder vaak refresht? Graag

Zie ik iets fantastisch over het hoofd? Of heeft Rasmussen e.a. nog nooit van Java gehoord ofzo? Wat mis ik?

HTML is in veel gevallen gewoon veel makkelijker dan Java. Ga maar eens kijken hoeveel werk de GUI van een webmailclient is in een Java-app(let) of een HTML-app. (maar ik moet er wel bij vermelden dat ik al tijden geen java-gui meer opgezet heb).
Bovendien heeft vrijwel iedere PC de beschikking over IE6 of een van de recentere KHTML/Gecko-based omgevingen. Maar niet iedere heeft Java, .NET of Flash en je kan niet van iedereen verwachten dat ze dat installeren (computers in de bieb, op je werk, op je school, in een internetcafe, noem maar op).

[ Voor 6% gewijzigd door ACM op 20-08-2005 11:25 ]

Acties:

zaterdag 20 augustus 2005 11:34

Cool

Topicstarter

Zo gauw ze dat fixen is AJAX niet meer nodig.

Wanneer gaat dat gebeuren? Ik zie nog niets dat in die richting wijst. Het blijven allemaal losse onderdelen.
Waarom zou dat gebeuren? Hebben we voor echte applicaties niet gewoon Java and the likes?

Wat ik me echt afvraag is waar die bijkans heiligverklaring van AJAX door sommigen toch vandaan komt? Ik zie het als dubbel werk waarbij het wiel vaak opnieuw uitgvonden moet worden. En dan ook nog een houten wiel, want de flexibiliteit op er een luchtband omheen te leggen en spaken te gebruiken ontbreekt vooralsnog.

Acties:

ripexx

bibs

Nou zo nieuwe is AJAX niet. Het gebruik van XMLHtrpRequest is bekender bij het grotere publiek geworden nadat het een naampje heeft gekregen en sites als Google met maps en gmail het zijn gaan gebruiken.

Het principe van AJAX is dat er een requets wordt gedaan zonder dat de pagina wordt ververst. Voorheen werden hiervoor hidden frames gebruik welke dan op de achtergrond wel opnieuw werden geladen. Mijn werkgever gebruik al veel langer remote scripting (IE) en voor een web applicatie is dat prima.

Daarnaast moet je een duidelijk onderscheid maken tussen websites en webapplicaties. Aan een webapplicatie kan je veel meer voorwaarden vastleggen. Dus bijvoorbeeld het gebruik van ActiveX in IE. Een van onze eisen is bijvoorbeeld IE. Voor een applicatie kan je die eisen stellen. Daarnaast is IE de standaard voor de grotere bedrijven. Dus dat is goed verenigbaar. Een website heeft als doel beschikbaar te zijn en informatie beschikbaar te stellen. Dan is het gewoon niet mogelijk om eisen zoals ActiveX, IE only etc hard af te dwingen.

Wat er wel gebeurt is dat steeds meer bedrijven webbased enterprise pakket gaan aanbieden (Siebel CRM, MS CRM), geviolg hiervan is ondermeer dat deze grote firma's tegen de beperkingen van standaard HTML, CSS en JS aanlopen.

Een simpel voorbeeld is het gebruik van een control. De default <select> is gewoon een onding. Stel ik wel uit een lijst van enkele duizende bedrijven één bedrijf selecteren. Dan is het gewoon niet handig om alle ste laden. Dus je wil de gebruik kunnen laten zoeken enz. Google heeft iets soort gelijks al laten zien met de typeahead functionaliteit. Default is het dus niet mogelijk en ben je dus gedwongen om andere oplossingen te gaan zoeken.

Wel wordt het steeds duidelijk dat het (technisch)beheer van webbased applicatie velemalen eenvoudiger is. Immers staat de code op een webserver welke eenvoudig te beheren is. De uitrol is velemalen makelijk net als het upgraden naar een nieuwe versie. Steeds meer grote bedrijven zien dit in en in de gemiddelde RFC is webbased gewoon een must have.

Dus AJAX is mode maar de trend is wel gezet

buit is binnen sukkel

zaterdag 20 augustus 2005 11:36

Acties:

zaterdag 20 augustus 2005 11:41

Cool

Topicstarter

HTML is in veel gevallen gewoon veel makkelijker dan Java. Ga maar eens kijken hoeveel werk de GUI van een webmailclient is in een Java-app(let) of een HTML-app. (maar ik moet er wel bij vermelden dat ik al tijden geen java-gui meer opgezet heb).

Ahh het was laat gisteren. Je hebt hier helemaal gelijk: met HTML gooi je idd in no-time een GUI in elkaar. Maar het blijft een XUL, en een hele beperkte eigenlijk ook. Voor Gecko is er ook een XUL (Voorbeelden van wat je ermee kunt: Mozilla Suite. Duh) en voor Java zijn er ook tig van.

Nou ken ik die Java XUL's niet, maar met NetBeans is het toch ook niet een al te grote moeite om een GUI in elkaar te flansen, gewoon met Swing.

Bovendien heeft vrijwel iedere PC de beschikking over IE6 of een van de recentere KHTML/Gecko-based omgevingen. Maar niet iedere heeft Java, .NET of Flash en je kan niet van iedereen verwachten dat ze dat installeren (computers in de bieb, op je werk, op je school, in een internetcafe, noem maar op).

Dat argument komt vaak terug, maar als het om een applicatie gaat die een persoon wilt gebruiken dan installeert Jan Modaal thuis echt wel een plug-in daarvoor. En als het genoeg momentum heeft, dan installeert de bieb het ook.

Acties:

zaterdag 20 augustus 2005 11:49

Software Architect

Werkt hier

Gmail's extra functionaliteit werkt dus zonder de noodzaak dat allemaal te installeren

Acties:

ripexx

bibs

Nexxennium schreef op zaterdag 20 augustus 2005 @ 11:36:
[...]
Dat argument komt vaak terug, maar als het om een applicatie gaat die een persoon wilt gebruiken dan installeert Jan Modaal thuis echt wel een plug-in daarvoor. En als het genoeg momentum heeft, dan installeert de bieb het ook.

Je denk fout is dat jij kijkt naar Jan Modaal maar de grote software jongens kijken naar de grote bedrijven en multinationals. En daar zijn beheerskosten en TCO heel belangrijk. Dat google zich met namen richt op B2C wil niet zeggen dat dat in alle gevallen zo is.

buit is binnen sukkel

zaterdag 20 augustus 2005 11:49

Acties:

zaterdag 20 augustus 2005 12:17

Devver

Pixelated

De kracht van Ajax is eigenlijk de simpelheid voor de programmeur; een dynamische select bouw je met een handjevol regels javascript. In feite is het gewoon een hele simpele techniek; een techniek die in de mode is gekomen dankzij o.a. Google en het feit dat browsers naast Mozilla en IE er ook ondersteuning voor zijn gaan bieden in meer of mindere mate.
Een webprogrammeur hoeft geen java oid te leren om toch snel iets leuks in elkaar te flansen.
Zelf voel ik me best thuis in het werken met HTML, CSS en javascript; ik heb niet de behoefte aan IDE's en complete toolboxen waar de echte techniek verborgen gaat onder een dikke laag abstracties.

Ajax is nu beschikbaar en het verleden heeft geleerd dat veranderingen vwb ondersteuning van nieuwere technieken in de browserwereld gewoon heel erg langzaam gaan (met name bij een niet nader te noemen, maar veel gebruikte browser), dus we zitten voorlopig nog wel vast aan de nu beschikbare technieken.

Intentionally left blank

Acties:

Alarmnummer

-= Tja =-

Nexxennium schreef op zaterdag 20 augustus 2005 @ 11:26:
[...]
Wanneer gaat dat gebeuren? Ik zie nog niets dat in die richting wijst. Het blijven allemaal losse onderdelen.
Waarom zou dat gebeuren? Hebben we voor echte applicaties niet gewoon Java and the likes?

De reden dat ik deze opmerking maak is dat ik duidelijk wil maken dat AJAX niets anders is dan een noodoplossing voor een gebrekkig en verouderd systeem. En daaruit kan je mijn mening opmaken over AJAX: het is zeker niet heilig of een zegen.

[ Voor 4% gewijzigd door Alarmnummer op 20-08-2005 12:25 ]

zaterdag 20 augustus 2005 13:13

Acties:

RedRose

Icebear

Alarmnummer schreef op zaterdag 20 augustus 2005 @ 12:17:
[...]

De reden dat ik deze opmerking maak is dat ik duidelijk wil maken dat AJAX niets anders is dan een noodoplossing voor een gebrekkig en verouderd systeem. En daaruit kan je mijn mening opmaken over AJAX: het is zeker niet heilig of een zegen.

Dat ben ik zeker met je eens. Alleen wil het niet zeggen dat Ajax niet 'mooi' te implementeren is met het scala aan technieken. JavaScript hoeft niet vies te zijn en eerlijk gezegd is het dat ook niet.

Ik zit al een tijdje te denken aan een opvolger voor http en de daarop / daardoor gegroeide (web)technieken vanuit een hoop verschillende invalshoeken, maar toch voornamelijk vanuit functioneel oogpunt. Ooit wil ik er nog eens een echt functioneel ontwerp voor maken. Niet dat ik pretendeer het allemaal te kunnen, maar het is een leuke geestelijk oefening.

Sundown Circus

zaterdag 20 augustus 2005 13:14

Acties:

Bluestorm

Alarmnummer schreef op zaterdag 20 augustus 2005 @ 12:17:
[...]

De reden dat ik deze opmerking maak is dat ik duidelijk wil maken dat AJAX niets anders is dan een noodoplossing voor een gebrekkig en verouderd systeem. En daaruit kan je mijn mening opmaken over AJAX: het is zeker niet heilig of een zegen.

Ben ik het wel mee eens. HTML etc. is veel te veel gericht op het opmaken van hypertext content. (op zich niet zo gek natuurlijk... want daar is het voor) maar de gemiddelde website en zeker webapplicatie is veel meer dan een beetje hypertext en vraagt dan ook eigenlijk gewoon om een andere benadering.

Grootste zegen van AJAX is natuurlijk dat het nu opeens een naampje heeft. Het feit dat deze discussie in P&W staat, terwijl het eigenlijk om een hoopje client-side techniek gaat die al tijden lang mogelijk is geeft al aan dat er in iedergeval eindelijk wat aandacht is voor de client-side mogelijkheden op de plaats waar dat hoort

Tenminste... dat [ denk / zie / weet ] ik... | Javascript obfuscator | foto's en video's uploaden

zaterdag 20 augustus 2005 13:15

Acties:

zaterdag 20 augustus 2005 13:28

Dumbass ex machina

Nexxennium schreef op zaterdag 20 augustus 2005 @ 11:26:
[...]
Wanneer gaat dat gebeuren? Ik zie nog niets dat in die richting wijst. Het blijven allemaal losse onderdelen.
Waarom zou dat gebeuren? Hebben we voor echte applicaties niet gewoon Java and the likes?

Kijk naar XForms. Kijk naar XAML.

Nexxennium schreef op zaterdag 20 augustus 2005 @ 00:33:
Heel Ajax draait op XMLHttpRequest. Een leuk ActiveX-geintje van Microsoft. (het zit dus niet eens ingebouwd in de browser). Het is niet gestandaardiseerd. DOM Level 3 heeft/krijgt wel een gestandaardiseerde vervanger daarvoor, maar tot dusver wordt dat alleen ondersteund door Opera!

Firefox ondersteunt het, Safari ondersteunt het, Opera ondersteunt het. Het is een Microsoft techniek die zo bruikbaar is gebleken dat iedereen hem overneemt. Dat dit geen innovatie is die gedreven is door het W3C maakt het niet ineens een slecht iets: het laat hooguit zien dat het W3C alweer hopeloos achter de feiten aanloopt.

Multi-browser-support-hell.

You can't make an omelet without breaking some eggs. Het gaat bij AJAX meer over het kunnen toepassen van de techniek, over het maken van betere webapplicaties. Dat de techniek daarbij nog wat te wensen overlaat is irrelevant. Je bent imho een slecht webdeveloper als je iets afkeurt omdat het niet makkelijk is. Als iedereen dat deed, zaten we nu nog in 1994.

GUI's worden daardoor chaotisch. Elke applicatie ziet compleet anders uit, werkt compleet anders, de accessability-fucties van het OS/platform zelf zijn afwezig.

De GUI wordt zo chaotisch als je wilt. Fout gebruik van een techniek is altijd een risico, maar dat is niet iets wat je de techniek zelf kunt aanrekenen. Vind jij de GUI van Google maps chaotisch en onoverzichtelijk? Integendeel! Het ontleent zijn bestaansrecht juist aan die interactiviteit. Luchtfoto's van je huis waren al jarenlang te vinden op internet. Google is de eerste die ze aan elkaar plakt en makkelijk te bekijken maakt.

Content blijft verborgen voor zoekmachines. Je ziet sites die voor de navigatie compleet leunen op Javascript. Onbereikbaar voor zoekmachines dus. Nou is dat voor een applicatie meestal geen probleem, maar toch.

Je zegt het al: voor een applicatie geen probleem. Dat er een nieuwe techniek wordt gelanceerd, betekent niet dat we al onze pagina's nu moeten converteren. Net zoals alle technieken moet je hem toepassen waar nodig, en weglaten waar ie niet nodig is.

Zonder internetverbinding werkt het niet. Een Java-applicatie kan ook prachtig werken zonder een verbinding. En Java-applicaties kun je met WebStart ook direct starten, zonder dingen te installeren. En met WebStart wordt het ook automatisch up-to-date gehouden.

Wacht even hoor, je vertelt me nu dus dat een website niet werkt zonder internetverbinding? Zeg dat het niet waar is! Die systeemeisen worden ook steeds hoger tegenwoordig!

Zie ik iets fantastisch over het hoofd? Of heeft Rasmussen e.a. nog nooit van Java gehoord ofzo? Wat mis ik?

Dat de functionaliteit van XmlHttp al eerder bestond is irrelevant. Java is al jarenlang aan het kwakkelen (dan heb ik het over de verspreiding en mate van gebruik), en dat is niet voor niks. XmlHttp is echter voor de gebruiker een relatief hassle-free technologie. Dat maakt het grote verschil, en dat maakt XmlHttp/javascript zoveel bruikbaarder dan Java. Je hoeft geen plugins te installeren, en je hoeft ook je oude vertrouwde browser niet te verlaten.

[edit]
Dat het overhyped wordt, ben ik wel met TS eens. Het nadeel van een hype in de IT wereld, is dat mensen er niet over nadenken. Elke manager roept nu: "Wij moeten ook AJAX gebruiken in onze websites/webapps! En het liefst overal! Want ik lees hier net dat AJAX goed is dus als we zoveel mogelijk AJAX in onze apps stoppen, dan worden onze apps ook goed!".

Maar laat je door de hype niet afleiden van de inhoud. Ik zou zeggen, probeer zelf eens wat met AJAX te doen, en dan wel in een testcase waar het echt nut heeft. Ik betwijfel persoonlijk of het hele nut van AJAX valt of staat met navigate/het updaten van pagina-content. Dat is een van de dingen die me persoonlijk te futiel lijkt: het internet is tegenwoordig zo snel dat een nieuwe pagina toch vaak binnen no-time geladen is. En is dat niet zo, dan is vaak de webserver te traag/te overbelast. Wil je dat met een XmlHttpRequest sneller maken, dan zul je niet veel tijd winnen, lijkt me, omdat je nog steeds afhankelijk bent van de reactietijd van de server.

[ Voor 14% gewijzigd door Not Pingu op 20-08-2005 13:24 ]

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

RedRose

Icebear

Gunp01nt schreef op zaterdag 20 augustus 2005 @ 13:15:

Kijk naar XForms. Kijk naar XAML.

Al één van de problemen. XForms/XAML/XUL/XSL/XAny/JavaScript/HTML4/XHTML/ActiveX/Java-plugins/ etc. Hoe meer verschillende technieken, hoe lastiger het voor een browserbouwer allemaal te ondersteunen is en voor developers te implementeren is.

Firefox ondersteunt het, Safari ondersteunt het, Opera ondersteunt het. Het is een Microsoft techniek die zo bruikbaar is gebleken dat iedereen hem overneemt. Dat dit geen innovatie is die gedreven is door het W3C maakt het niet ineens een slecht iets: het laat hooguit zien dat het W3C alweer hopeloos achter de feiten aanloopt.

Ik weet niet of het w3c daar iets aan kan doen. Ze hebben denk ik niet genoeg mandaat om voorop te lopen.

You can't make an omelet without breaking some eggs. Het gaat bij AJAX meer over het kunnen toepassen van de techniek, over het maken van betere webapplicaties. Dat de techniek daarbij nog wat te wensen overlaat is irrelevant. Je bent imho een slecht webdeveloper als je iets afkeurt omdat het niet makkelijk is. Als iedereen dat deed, zaten we nu nog in 1994.

Het maakt niet uit of het lastig te leren is, het moet wel vrij eenduidig te programmeren / implementeren zijn. Proberen om platformonafhankelijk te bouwen kost gewoon veel meer tijd dan dat eigenlijk nodig is om een webapp te bouwen.

De GUI wordt zo chaotisch als je wilt. Fout gebruik van een techniek is altijd een risico, maar dat is niet iets wat je de techniek zelf kunt aanrekenen. Vind jij de GUI van Google maps chaotisch en onoverzichtelijk? Integendeel! Het ontleent zijn bestaansrecht juist aan die interactiviteit. Luchtfoto's van je huis waren al jarenlang te vinden op internet. Google is de eerste die ze aan elkaar plakt en makkelijk te bekijken maakt.

Dat klopt ja.

Je zegt het al: voor een applicatie geen probleem. Dat er een nieuwe techniek wordt gelanceerd, betekent niet dat we al onze pagina's nu moeten converteren. Net zoals alle technieken moet je hem toepassen waar nodig, en weglaten waar ie niet nodig is.

Als je bedoelt dat er omwegen zijn om toch je pagina's geindexeerd te krijgen, dan ben ik het met je eens. Maar ik denk wel dat een zoekmachine zich moet aanpassen aan nieuw te gebruiken technieken en niet andersom.

Wacht even hoor, je vertelt me nu dus dat een website niet werkt zonder internetverbinding? Zeg dat het niet waar is! Die systeemeisen worden ook steeds hoger tegenwoordig!

Sundown Circus

zaterdag 20 augustus 2005 13:31

Acties:

zaterdag 20 augustus 2005 13:50

Dumbass ex machina

RedRose schreef op zaterdag 20 augustus 2005 @ 13:28:

Als je bedoelt dat er omwegen zijn om toch je pagina's geindexeerd te krijgen, dan ben ik het met je eens. Maar ik denk wel dat een zoekmachine zich moet aanpassen aan nieuw te gebruiken technieken en niet andersom.

Wat ik bedoelde is dat je een nieuwe techniek niet als een kip zonder kop moet toepassen. HTML is nog steeds een heel goede manier om informatie te structureren.
Maar de Google-waarde van een webapplicatie (denk in de trend van Outlook Web Access of Google Maps) is nul komma nul, dus daarbij valt dat nadeel al meteen weg.

Wat betreft de adoptie van nieuwe technieken door zoekmachines: in de praktijk is het vaak juist andersom. Google heeft zo'n enorm leidende positie verkregen, dat webstandaarden ineens belangrijk (want praktisch voordelig) werden. Daarom is iedereen naar Google toe gaan coden. Juist omdat je informatie goed kan structureren met een markuptaal, is Google daarop geënt.

Google kan niet elke gebruikte techniek ondersteunen (ze zijn nog steeds bezig met ondersteuning voor Flash), maar elke nieuwe techniek zal daarentegen sneller geaccepteerd worden als ie al 'compatible' is met Google.

[ Voor 34% gewijzigd door Not Pingu op 20-08-2005 13:36 ]

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

RedRose

Icebear

De markup-taal an sich, daar is ook niks mis mee natuurlijk. Het probleem ontstaat juist wanneer iemand meer functionaliteit wil aanbieden in de browser dan dat eigenlijk mogelijk is met alleen een markup-taal. Op het moment dat er een goede (of betere) techniek voor is dan dat er misschien nu beschikbaar is _en_ deze gaat enorm veel toegepast worden, _dan_ zal Google zich ook aan moeten passen. Dat is gewoon marktwerking. Dat is tegelijk dan weer één van de redenen waardoor het w3c altijd achter de feiten aanloopt. Daarom blijf ik erbij dat Google c.s. achter de leidende technieken aan moet lopen en niet andersom. In zekere zin doen ze dat ook, ze spitsen zich toe op de dan (nu) geldende standaard, waardoor iedereen ook zo gaat werken. Daar is ook niks mis mee.

/edit:

Je kan je afvragen welk nut het heeft om flashobjecten te gaan indexeren. Waar worden flash-objecten voornamelijk toegepast?

[ Voor 9% gewijzigd door RedRose op 20-08-2005 13:51 ]

Sundown Circus

zaterdag 20 augustus 2005 13:58

Acties:

zaterdag 20 augustus 2005 15:00

Dumbass ex machina

RedRose schreef op zaterdag 20 augustus 2005 @ 13:50:
Je kan je afvragen welk nut het heeft om flashobjecten te gaan indexeren. Waar worden flash-objecten voornamelijk toegepast?

Ik wou dat ik een stuiver kreeg voor elke site die ik bezocht die totaal onnodig, volledig in Flash was gemaakt.

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

zaterdag 20 augustus 2005 15:03

Devver

Pixelated

Alarmnummer schreef op zaterdag 20 augustus 2005 @ 12:17:
[...]

De reden dat ik deze opmerking maak is dat ik duidelijk wil maken dat AJAX niets anders is dan een noodoplossing voor een gebrekkig en verouderd systeem. En daaruit kan je mijn mening opmaken over AJAX: het is zeker niet heilig of een zegen.

En waarom is dat systeem gebrekkig en verouderd? Nieuwe technologieën stranden op het gebrek aan implementatie bij de marktleider; dezelfde marktleider die een aantal jaren geleden uit het w3c is gestapt, en in de tussentijd ook vernieuwing van zijn eigen browser heeft laten versloffen. Daar stokt het dus al.
Nu een andere grote speler op het web gebruik maakt van bepaalde technieken krijgt eea eindelijk weer eens een impuls, en uiteindelijk is het gebruik van Ajax al een stuk netter dan de oude truuks met hidden (i)frames.

Een noodoplossing zou ik het niet willen noemen; Ajax zelf blinkt uit in eenvoud. Het is de hassle met je GUI die het wat complexer maakt als je niet echt bekent met de mogelijkheden van DOM om je presentatielaag te manipuleren. Dat is iets wat je toch vaak tegenkomt bij webprogrammeurs die voornamelijk werken met abstracties en geen feeling meer hebben met de elementaire ondergrond.

Ik sluit me overigens wel aan bij de rest; Ajax is geen wondermiddel wat je als een sausje overal overheen kan en moet gooien.

Intentionally left blank

Acties:

zaterdag 20 augustus 2005 15:06

Dumbass ex machina

crisp schreef op zaterdag 20 augustus 2005 @ 15:00:
[...]

En waarom is dat systeem gebrekkig en verouderd? Nieuwe technologieën stranden op het gebrek aan implementatie bij de marktleider; dezelfde marktleider die een aantal jaren geleden uit het w3c is gestapt, en in de tussentijd ook vernieuwing van zijn eigen browser heeft laten versloffen.

Maar ondertussen wel 2 van de meest gekopieerde en meestgebruikte 'bouwstenen' van het internet heeft geintroduceerd.

(XmlHttp en rich text editing dus)

Het is natuurlijk maar net waarop je je concentreert. Heeft gebrekkige ondersteuning van CSS en JS in IE er ons al deze jaren van weerhouden om goeie webapps in IE te maken?

Maar hoe dan ook is allang duidelijk dat er een splitsing is komen te ontstaan tussen webpagina's en webinterfaces. En voor webinterfaces voldoen HTML+javascript+css bij lange na niet.

[ Voor 26% gewijzigd door Not Pingu op 20-08-2005 15:05 ]

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

zaterdag 20 augustus 2005 19:23

Devver

Pixelated

Gunp01nt schreef op zaterdag 20 augustus 2005 @ 15:03:
[...]

Maar ondertussen wel 2 van de meest gekopieerde en meestgebruikte 'bouwstenen' van het internet heeft geintroduceerd.

(XmlHttp en rich text editing dus)

Ja, maar op hun eigen manier zonder uitgebreide (open) technische documentatie. Het is dus niet gek dat andere browservendors terughoudend zijn met het overnemen van deze pseudo-standaards...

Intentionally left blank

Acties:

zaterdag 20 augustus 2005 20:29

Cool

Topicstarter

crisp schreef op zaterdag 20 augustus 2005 @ 15:00:
[...]

Een noodoplossing zou ik het niet willen noemen; Ajax zelf blinkt uit in eenvoud.

Nou ik vind juist van niet. Ik zie het bijna als een stap terug zelfs. De afwezigheid van IDE's, duidelijke en eenduidige, complete documentatie ontbreekt, JavaScript is gewoon beperkt en niet uit te breiden.. Je bent ontzettend vaak bezig met zaken die in andere platforms peanuts zijn.

En voor grote applicaties snak ik eigenlijk naar strong typing. Zelfs voor PHP definieer ik variabelen nu voordat ik ze ga gebruiken; de IDE die ik gebruik geeft een waarschuwing als ik dat niet doe. Dat soort dingen, beginners vinden het vaak 'lastig', voorkomen wel heel veel ellendige kutbugs.

Acties:

bgever

Je moet nu natuurlijk niet twee dingen door elkaar gaan halen. Ajax is technologisch eenvoudig toe te passen. Dat het niet eenvoudig te implementeren is, is natuurlijk een andere zaak, maar dit maakt het zeker niet minder belangrijk.

Toch heb ik een beetje een paradoxaal gevoel; XML, HTML, CSS en JS zijn redelijk eenvoudige talen, maar door de verscheidenheid in implementaties maakt dit alles allerminst eenvoudig. Ik ben lang moderator geweest op een (ander) webdesign forum en als ervaren webontwikkelaar weet je dan wel de gebreken van de browsers. Maar een beginner die zich aan de voorschriften houdt (webstandaarden) merkt al snel dat het leven als webontwikkelaar lang niet zo rooskleurig is.

Vandaar dat ik zeker wel de mensen kan begrijpen die geneigd zijn naar Java en .Net. Deze platformen zijn degelijk en je kunt er goed op vertrouwen als ontwikkelaar. Dit vertrouwen hoef je zeker niet te hebben met het "browser platform".

Ik vind dat er de laatste tijd veels te veel wordt gebrobeerd om alles maar in de browser werkend te krijgen. Natuurlijk leuk dat je een wijde doelgroep hebt met een applicatie die in een browser draait, maar heb je dat eigenlijk nog wel als deze browser niet alle technieken ondersteund? Er wordt veels te veel van de browser verwacht en dat gaat zo eenvoudig nog niet. Laat ze maar lekker klooien met Ajax en ander soort oplapmiddelen om zo het gewenste gedrag te creëren bij iets waar het helemaal niet voor bedoeld is. Ach misschien heeft dit nog allemaal wel tot gevolg dat de implementerende partijen nu eens eindelijk goed naar hun implementaties gaan kijken...

zaterdag 20 augustus 2005 23:39

Acties:

zondag 21 augustus 2005 00:28

Devver

Pixelated

Nexxennium schreef op zaterdag 20 augustus 2005 @ 19:23:
[...]

Nou ik vind juist van niet. Ik zie het bijna als een stap terug zelfs. De afwezigheid van IDE's, duidelijke en eenduidige, complete documentatie ontbreekt, JavaScript is gewoon beperkt en niet uit te breiden.. Je bent ontzettend vaak bezig met zaken die in andere platforms peanuts zijn.

Jij hebt ook gewoon nog de oogkleppen op van de meeste serverside programmeur-boys die verwent zijn met IDE's en abstractie-lagen en daardoor de feeling met de onderliggende techniek verloren hebben... jammer eigenlijk...

En voor grote applicaties snak ik eigenlijk naar strong typing. Zelfs voor PHP definieer ik variabelen nu voordat ik ze ga gebruiken; de IDE die ik gebruik geeft een waarschuwing als ik dat niet doe. Dat soort dingen, beginners vinden het vaak 'lastig', voorkomen wel heel veel ellendige kutbugs.

best-practices zijn er in alle talen; strong of loose-type heeft daar niets mee te maken - voor beiden valt wel iets te zeggen. Ik ben het met je eens dat talen als Javascript of PHP 'simpel' overkomen en daardoor nogal geplaagt worden door 'bad examples' - dat doet echter niets af aan de taal zelf, hooguit aan het imago. Javascript is een volledige programmeertaal en geenszins beperkt; meestal is de programmeur de beperkende factor...

Intentionally left blank

Acties:

zondag 21 augustus 2005 00:53

Cool

Topicstarter

crisp schreef op zaterdag 20 augustus 2005 @ 23:39:
[...]

Jij hebt ook gewoon nog de oogkleppen op van de meeste serverside programmeur-boys die verwent zijn met IDE's en abstractie-lagen en daardoor de feeling met de onderliggende techniek verloren hebben... jammer eigenlijk...

* Fuzzillogic trekt een wenkbrauw op.
Werkelijk, je opmerkingen verbazen me echt.

IDE's zijn niet voor de lol ontwikkeld of om zaken minder transparant te maken. Voor PHP heb ik het hele spectrum gehad, van veredelde notepad tot TruStudio. Nou mag je raden waar ik toch veel sneller mee werk, en betere code mee produceer.

Maar wat je met "feeling voor onderliggende techniek" bedoelt is mij volstrekt onduidelijk. Doel je soms op ASP-achtige fratsen waar de server zelf de HTML 'verzint'? Of ben je bang dat iemand die met JSP werkt geen JavaScript meer kan produceren?

best-practices zijn er in alle talen; strong of loose-type heeft daar niets mee te maken - voor beiden valt wel iets te zeggen. Ik ben het met je eens dat talen als Javascript of PHP 'simpel' overkomen en daardoor nogal geplaagt worden door 'bad examples' - dat doet echter niets af aan de taal zelf, hooguit aan het imago. Javascript is een volledige programmeertaal en geenszins beperkt; meestal is de programmeur de beperkende factor...

Ik heb ervaring met C, PHP, JavaScript en Java. Als programmeur wil ik duidelijk hebben wat in mijn variabelen kan zitten. Nou ieder het zijne, maar ik wil strong-typing.

En NATUURLIJK is JavaScript beperkt. Niet zozeer qua taal, hoewel dat ook wel zo zijn rare kanten heeft, maar qua mogelijkheden. De "runtime omgeving" van JavaScript is natuurlijk ernstig beperkt. Kun jij een plaatje even resizen in JavaScript en uploaden naar de server?
JavaScript kan hooguit dienen om allerhande extensies waarmee dat wel zou kunnen (ActiveX, plug-ins) aan te sturen. Maarja, ik hoef je niet te vertellen dat dat zéér browser-afhankelijk is.

Acties:

zondag 21 augustus 2005 01:36

amateur megalomaan

crisp schreef op zaterdag 20 augustus 2005 @ 23:39:
Jij hebt ook gewoon nog de oogkleppen op van de meeste serverside programmeur-boys die verwent zijn met IDE's en abstractie-lagen en daardoor de feeling met de onderliggende techniek verloren hebben... jammer eigenlijk...

Dit heeft imho niets met "verwend zijn" of "abstractielagen" te maken, Crisp. Een goede IDE en een goed (gedocumenteerd) framework maken het leven van een developer een stuk makkelijker. Ik vind dat Nexxennium daar wel een punt heeft.
Dat server-side developers zich minder bezig houden met puur client-side development staat daar los van. Waarom zou je niet dezelfde eisen mogen stellen aan het developen van client-side code?

crisp schreef op zaterdag 20 augustus 2005 @ 23:39:
Javascript is een volledige programmeertaal en geenszins beperkt; meestal is de programmeur de beperkende factor...

Je laatste zin is wel een ontzettende dooddoener. En de discussie over strong-typed of weak-typed talen, tja, laten we die maar niet gaan voeren hier; dat wordt een beetje offtopic.

Today's subliminal thought is:

Acties:

zondag 21 augustus 2005 01:42

amateur megalomaan

crisp schreef op zondag 21 augustus 2005 @ 01:08:
Wat ik in mijn vorige reply al aangaf is dat IDE's, hoewel handig, ook beperkend kunnen zijn. Immers zijn vaak niet alle facetten van de onderliggende techniek bereikbaar via de IDE (dat dat een tekortkoming in de IDE is is een feit maar vaak ook de realiteit).

Dit is alleen een tekortkoming als je de kwaliteit van de client-code als uitgangspunt neemt. Doe je dat niet, dan is het geen tekortkoming, maar een zegening. Je hoeft je immers niet cq. minder bezig te houden met de details. Misschien is het voor de standards-compliant client-side zealots (jawel, ik kan ook generaliseren

) een doorn in het oog dat niet alles perfect is, maar vanuit commercieel oogpunt is het wel verdedigbaar.

crisp schreef op zondag 21 augustus 2005 @ 00:54:
Er zijn in mijn beleveling maar weinig mensen op deze aardkloot die echt goed weten om te gaan met HTML, DOM en Javascript...

Kom op zeg. Dus je zegt dat het gros van de (web)developers 'out there' prutsers zijn? Alsof je een F1 coureur zou moeten zijn, om jezelf een goede bestuurder te mogen noemen. Wie heeft er nu de oogkleppen op?

Today's subliminal thought is:

Acties:

zondag 21 augustus 2005 02:07

Devver

Pixelated

Annie schreef op zondag 21 augustus 2005 @ 01:36:
[...]

Dit is alleen een tekortkoming als je de kwaliteit van de client-code als uitgangspunt neemt. Doe je dat niet, dan is het geen tekortkoming, maar een zegening. Je hoeft je immers niet cq. minder bezig te houden met de details. Misschien is het voor de standards-compliant client-side zealots (jawel, ik kan ook generaliseren ) een doorn in het oog dat niet alles perfect is, maar vanuit commercieel oogpunt is het wel verdedigbaar.

je geeft zelf al toe met minder tevreden te zijn; de vraag is of je klanten dat ook zijn...

Kom op zeg. Dus je zegt dat het gros van de (web)developers 'out there' prutsers zijn? Alsof je een F1 coureur zou moeten zijn, om jezelf een goede bestuurder te mogen noemen. Wie heeft er nu de oogkleppen op?

nee, ik zeg enkel dat het gros van de webdevelopers die uiteindelijk ook clientside technieken toepassen dat op een prutserige manier doen

Intentionally left blank

Acties:

zondag 21 augustus 2005 11:45

amateur megalomaan

crisp schreef op zondag 21 augustus 2005 @ 01:42:
[...]
je geeft zelf al toe met minder tevreden te zijn; de vraag is of je klanten dat ook zijn...

Klopt, soms moet je water bij de wijn doen. Als je dat niet kan, dan wordt je niet zo gelukkig in het bedrijfsleven. En ja, mijn klanten zijn heel tevreden over het werk wat ik en mijn collega's afleveren

offtopic:
Laten we het maar weer over AJAX hebben. We dwalen af naar een discussie over het wel of niet goed toepassen van de standaarden cq. technieken en de vraag of dat een doodzonde is.

Mea culpa. Ik zwengelde deze discussie ook zelf aan.

Today's subliminal thought is:

Acties:

brokenp

Persoonlijk denk ik dat AJAX een grote toekomst in het verschiet heeft.
Mijn persoonlijke ervaringen betreffen het ontwikkelen van een Thunderbirdextensie met bepaalde AJAX- serververbindingen en een website welke vrij intensief AJAX gebruikt.

Voor beide zaken was AJAX wat mij betreft ideaal, de gebruiker had volledige controle over de data(drag en drop interfaces e.d.) terwijl elke wijziging direct aan de server werd doorgegeven. Zonder AJAX had ik hiervoor een applet oid moeten maken.

De meeste AJAX projecten die ik gezien hebben waren over het algemeen vaak houwtje touwtje oplossingen welke deden wat ze moesten doen, maar daar hield het dan ook wel mee op.
Echter door mijn ervaringen met de thunderbird extensie heb ik gezien dat je ook in javascript elegant kan coden.

Ik zie bijvoorbeeld wel een toekomst voor applicaties geschreven op het mozilla framework (XUL,XBL etc) welke ook een HTML front end hebben zodat je met 1 codebase zowel een applicatie als een website onderhoud.

In de toekomst zullen er wel een aantal zaken aandacht verdienen:
- Standaard componenten
- IDE's
- elegante code, goede paterns en best practices
- Cross platform js zonder browser uitzonderingen..

Ik denk dat het nadeel van 3 talen moeten kennen (js, html, css) zal blijven, maar bij iets grotere projecten zal 1 iemand zich met het skinnen (css) bemoeien, en de echte programmeurs meer met de html/js.

zondag 21 augustus 2005 11:53

Acties:

RM-rf

1 2 3 4 5 7 6 8 9

Annie schreef op zondag 21 augustus 2005 @ 00:53:

Dat server-side developers zich minder bezig houden met puur client-side development staat daar los van. Waarom zou je niet dezelfde eisen mogen stellen aan het developen van client-side code?

Ik denk dat het deels een combinatie is van verschilende aspecten.... zodra je gebruikers vrijheid geeft wat betreft gebruik van verschillende platformen, zelfs redelijk verschillende toepassingen van een ecma-standaard (Jscript vc Javascript) ....

Ik denk dat dit idee voor voor serverside ontwikkelaars verschrikkelijk is dat hun applicatie op een veelvoud aan platformen moet draaien, van verschillende fabrikanten, die onderling concurreren ....
Java is daarin een verbetering al merk je daar hoeveel problemen het oplevert als er enkel twee verschillen virtual machines aanwezig zijn

de enige mogelijkheid om een clientside (webbased, dus niet direkt intra- of extranet apps) omgeving dezelfde eisen als een serverside heeft, zou het enkel mogelijk zijn als deze clientside omgeving door een 100% monopolist verzorgd zou worden ... zou dat wenselijk zijn?

Intelligente mensen zoeken in tijden van crisis naar oplossingen, Idioten zoeken dan schuldigen

zondag 21 augustus 2005 12:45

Acties:

zondag 21 augustus 2005 12:56

Cool

Topicstarter

brokenp schreef op zondag 21 augustus 2005 @ 11:45:
Persoonlijk denk ik dat AJAX een grote toekomst in het verschiet heeft.
Mijn persoonlijke ervaringen betreffen het ontwikkelen van een Thunderbirdextensie met bepaalde AJAX- serververbindingen en een website welke vrij intensief AJAX gebruikt.

Voor beide zaken was AJAX wat mij betreft ideaal, de gebruiker had volledige controle over de data(drag en drop interfaces e.d.) terwijl elke wijziging direct aan de server werd doorgegeven. Zonder AJAX had ik hiervoor een applet oid moeten maken.

Errr... Met XUL haal je idd één van de grote nadelen van het hedendaagse Ajax onderuit: de zeer beperkte HTML UI. Ik vind dat je in dit geval dan ook niet meer echt van ''Ajax" kunt spreken: XUL is vooralsnog enkel beschikbaar in Gecko.

Stel het zou gestandaardiseerd en geimplementeerd worden in de browsers, dan zou het een andere verhaal zijn en daadwerkelijk al een stuk bruikbaarder.

Acties:

Harm

Nexxennium schreef op zondag 21 augustus 2005 @ 12:45:
[...]

Errr... Met XUL haal je idd één van de grote nadelen van het hedendaagse Ajax onderuit: de zeer beperkte HTML UI. Ik vind dat je in dit geval dan ook niet meer echt van ''Ajax" kunt spreken: XUL is vooralsnog enkel beschikbaar in Gecko.

Native is het alleen in Gecko beschikbaar, maar via wat scripts kun je XUL ook in IE en Opera laden: http://wednus.com/wednus0.3.4/doc/samples/DXULi.php.

zondag 21 augustus 2005 14:36

Acties:

zondag 21 augustus 2005 15:04

crisp schreef op zaterdag 20 augustus 2005 @ 23:39:
[...]

Jij hebt ook gewoon nog de oogkleppen op van de meeste serverside programmeur-boys

En girls, dankjewel

die verwent zijn met IDE's en abstractie-lagen en daardoor de feeling met de onderliggende techniek verloren hebben... jammer eigenlijk...

Feeling met onderliggende techniek? Tsja, beetje vreemde woorden van iemand die op een "VM" werkt die zo'n beetje het hoogste abstractie niveau heeft van alle omgevingen. Laten we eerlijk wezen, het scripten van een browser is nou niet bepaald een low-level techniek. Nu is de Java of .NET VM alweer wat meer high level dan de bare hardware (en zelfs 'bare' hardware is tegenwoordig vaak slechts aan abstractie van de 'echte' hardware), maar als programmeur ben je vaak ook serverside nog een stuk meer bezig met de "onderliggende technieken".

Ik houd me oa bezig met memory allocations, types, resource management (open DB connections, open files, etc), memory sharing tussen gebruikers (bv String[][]'s in Java ipv resultsets), threading, synchronisation en af en toe JNI om server side native dingen te doen (zoals laatst een graphviz rendering maken waar alleen een native C lib voor was).

De beauty van wat sterkere omgevingen zoals .Net & Java is dat je op alle niveaus kunt werken. Maak je een library of web component, dan werk je op een wat lager resp machine / web niveau. Werk je aan business logic dan ben je waarschijnlijk wat meer high-level bezig, etc.

Waar je wel gelijk in hebt is dat je als serverside-programmeur die in de UI werkt uiteindelijk "web code" genereerd. Feitelijk is elke serverside-ui programmeur dus met code generatie bezig. Het komt inderdaad dikwijls voor dat deze mensen de taal die ze zelf genereren in hun componenten niet goed kennen. Dit is het zelfde als iemand die een C++ naar x86 compiler schrijft, een expert in C++ is, maar amper x86 assembly kent.

Als je het zo bekijkt, kun je inderdaad de "web-talen" meer low-level noemen, ook al zijn ze ansich eigenlijk higher-level.

Volgens deze visie is het dan ook niet echt wenselijk om in de low-level talen zelf te gaan programmeren. Je wilt dan veel liever dat enkele personen libraries van componenten schrijven die je dan makkelijk kan hergebruiken. In Java kan dit bijvoorbeeld met JSF. Je (iemand) schrijft eenmalig een web-component die bijvoorbeeld AJAX gebruikt (bestaan al verschillende van in de praktijk!) en andere gebruiken deze. Dit is weer vergelijkbaar met C++, delen van de libraries moeten in assembly geschreven worden, waarbij C++ programmeurs deze dan hergebruiken. Vanuit het oogpunt van onderhoudbaarheid en productivity wil je niet dat een hele applicatie in assembly gemaakt gaat worden.

Kenmerkend van de volwassenere platformen zijn dingen als goede debugging support, profiling en unit tests. Ik heb eigenlijk nog nooit een echt goede debugger voor javascript gezien (ze zijn er wel hoor, maar de kwaliteit is toch dubieus), profiling tools en unit testen heb ik nog helemaal nooit gezien voor javascript. Bestaan deze wel?

Als ik een bottleneck heb in mijn Java of C# (.Net) app dan laat ik er even een profiler overheen gaan, en na een tijdje draaien van de applicatie zie ik zo waar de meeste CPU tijd en geheugen allocaties in gaan zitten. Ik zie welk type object het meest gealloceerd wordt en wat de life time is van zo'n object. Hierop kan ik mijn verdere optimalisaties sturen. Kan dat met javascript ook?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

zondag 21 augustus 2005 16:22

Devver

Pixelated

flowerp schreef op zondag 21 augustus 2005 @ 14:36:
[...]

Kenmerkend van de volwassenere platformen zijn dingen als goede debugging support, profiling en unit tests. Ik heb eigenlijk nog nooit een echt goede debugger voor javascript gezien (ze zijn er wel hoor, maar de kwaliteit is toch dubieus), profiling tools en unit testen heb ik nog helemaal nooit gezien voor javascript. Bestaan deze wel?

Als ik een bottleneck heb in mijn Java of C# (.Net) app dan laat ik er even een profiler overheen gaan, en na een tijdje draaien van de applicatie zie ik zo waar de meeste CPU tijd en geheugen allocaties in gaan zitten. Ik zie welk type object het meest gealloceerd wordt en wat de life time is van zo'n object. Hierop kan ik mijn verdere optimalisaties sturen. Kan dat met javascript ook?

Er zijn wel wat tools beschikbaar; bijvoorbeeld de venkman debugger en ik heb ook wel wat profiling tools gezien (hoewel die meestal vrij beperkt waren).
Wat dat betreft kan je inderdaad wel stellen dat er (nog) niet zo gek veel beschikbaar is, en dus is een goede kennis van de taal zelf en de implementaties ervan op dit moment wel belangrijk.
Ik ben zelf een old-school programmeur en van code-generators heb ik (misschien daarom wel) nooit zo gehouden; ik heb teveel het gevoel dat ik beperkt wordt door de generator.

Een simpel voorbeeld: ik ben jaren RPG-programmeur geweest op AS/400 platformen. Bij een vorige werkgever moest ik gebruik maken van ASSET wat zeg maar een IDE is die uiteindelijk RPG genereerd. Wel eens geprobeerd fatsoenlijke subfiles te programmeren in ASSET (subfiles zijn zeg maar paged listings)? Gewoon absoluut onmogelijk door de beperkingen van ASSET zelf.
Datzelfde zie ik (afgaande op topics daarover bij gebrek aan eigen ervaring) ook met bijvoorbeeld ASP.NET: sommige dingen zijn gewoon heel erg lastig te realiseren terwijl het op HTML/JS-niveau eigenlijk heel simpel zou zijn als je volledige controle over de gegenereerde code zou hebben - een goede tool zou die mogelijkheid dan in mijn ogen ook altijd moeten bieden.

Nou ja, waar het op neer komt is denk ik dat hoewel code-generators in 90% van de gevallen prima voldoen die extra 10% vaak een heel stuk lastiger is - ook versterkt door het feit dat de gegenereerde code vaak sub-optimaal is.

Wat AJAX betreft heb ik al gekeken naar diverse libraries, maar in bijna alle libraries zie ik zaken die beter/efficienter hadden gekunt. Vanuit mijn kennis van javascript ben ik wat dat betreft ook bijhoorlijk kritisch; een aantal AJAX-libraries die ik heb bekeken introduceerden memory-leaks of vervuilden de global namespace.
Dat is eigenlijk een beetje een algemeen probleem: heel veel javascript libraries zijn gewoon matig van kwaliteit; derhalve schrijf ik toch meestal zelf mijn scripts, dat scheelt vaak ook weer een hoop extra code van functionaliteit die je toch niet nodig hebt.

Intentionally left blank

Acties:

zondag 21 augustus 2005 16:31

Software Architect

Werkt hier

crisp schreef op zondag 21 augustus 2005 @ 15:04:
Ik ben zelf een old-school programmeur en van code-generators heb ik (misschien daarom wel) nooit zo gehouden; ik heb teveel het gevoel dat ik beperkt wordt door de generator.

Een simpel voorbeeld:
[knip]
Nou ja, waar het op neer komt is denk ik dat hoewel code-generators in 90% van de gevallen prima voldoen die extra 10% vaak een heel stuk lastiger is - ook versterkt door het feit dat de gegenereerde code vaak sub-optimaal is.

Je wilt toch niet beweren dat IDE een synoniem is bij jou voor "iets met code generators"?

Ik ga er van uit dat het dat niet is voor je, maar je brengt al een aantal postings over IDE's wel zo. Een IDE kan inderdaad code generation aanbieden/uitvoeren voor je, maar degenen die ik actief gebruikt heb gebruikte ik vooral om allerlei suf herhaalwerk te voorkomen. En dan heb ik het naast project management en syntax-kleuring over zeer uitgebreide vormen van code-completion inclusief parameter-type-analyses van de zichtbare variabelen om zo de mogelijkheden te beperken, gecontroleerde code-generation (getter/setters aanmaken bijv), error-highlighting (je weet wel, wat Word met spelfoutjes kan), refactoring-support (bijv functies/variabelen/e.a. hernoemen zonder dat je zelf op zoek moet naar waar je dat nog meer moet veranderen enzo), en nog meer van dat soort zaken.
Daar is een IDE als Jetbrain's IntelliJ IDEA echt erg goed in en zulk soort IDE's helpen je alleen maar met je werk, zonder je te beperken in wat je probeert te bereiken.

Je hebt natuurlijk wel gelijk zodra je een IDE te pakken hebt die je gewoon bepaalde dingen niet laat doen of als je een omgeving hebt geadopteerd waar je alleen met een (specifieke) IDE mee kan werken, omdat het anders te complex wordt door allerlei abstracties en tig niveau's van referenties en code-duplicaties.

Voor Java is er dus minstens één IDE die je helpt bij het doen van de vervelende dingen en je lekker aan de slag laat met wat je wilt doen. Voor .NET heeft de ontwikkelaar van diezelfde IDE overigens ook een IDE in het programma, of die net zo goed voor .NET is als IDEA voor Java is weet ik niet.

Voor Javascript, maar zelfs PHP, heb ik dergelijke complete IDE's nog niet gezien. Voor de laatste heb je Zend's IDE en Komodo, maar of er meer dan dat zijn die je als programmeur een beetje fatsoenlijk ondersteuning bieden weet ik niet. Voor Javascript heb ik al helemaal nog nooit van een IDE in deze zin gehoord, zijn die er?

Als het dus over IDE's gaat, dan is dat niet noodzakelijkerwijs een code-generator met een mooie klik-en-geniet interface, maar een applicatie die je helpt met het uitwerken van code in Javascript. Bijvoorbeeld om overzichten van klassen dynamisch bij te houden en je zo code-completion van functies van klassen aan te bieden of het helpen met inzicht in de functie-parameters zodat je dat niet meer hoeft op te zoeken in de code als je de volgorde vergeten bent.

Acties:

zondag 21 augustus 2005 16:52

the alien you never expected

Ja hoor er zijn wel IDEs voor JavaScript en/of PHP. PHPEdit bijv. Voor JavaScript heb ik zelf een homemade oplossing, met vergelijkbare functionaliteit als CodeRush.

Acties:

zondag 21 augustus 2005 17:00

Cool

Topicstarter

PHPEdit

Afbeeldingslocatie: http://images.fok.nl/s/schater.gif

Naja granted, sinds dat ik het geditcht heb zijn er wel nog wat broodnodige features bijgekomen. Toch blijf ik voorlopig even bij TruStudio, dat zich meer kan meten met Zend Studio. Oh en het is OSS/gratis.

Een van mijn grootste bezwaren, waar ik hier nog niet echt iemand anders over gehoord heb, is de verschillen tussen de features van de browsers. Een maandje of wat geleden heb ik eens een 'multi-target link' in elkaar gebeund. Het idee kwam van een /.-artikel, alleen de implementatie daarvan werkte met server-side browser-sniffing. En werkte dus alleen in IE6 en Gecko.

Mijn oplossing gebruikt gewoon wat standaard CSS en wat JavaScript-gefriemel met de DOM. Heel basic allemaal. _{Nee ik ben geen JS-master, het zal her en der vast beter kunnen, maar het gaat even om het idee.}

Toch werkt het niet in IE6, en niet alleen vanwege de CSS2-selectors. Persoonlijk ben ik er inmiddels al aardig moe van de browser-verschillen. De GCD is nog steeds best klein en/of je moet telkens weer work-arounds gaan verzinnen. Maar dit is gewoon een direct gevolg van de afwezigheid van een "AJAX-standaard".

Natuurlijk heb je ook wel verschillen tussen bijv. de verschillende PHP-versies en bij Java zul je vast ook upwards en downwards incompatibliteiten hebben, maar die verbleken gewoon bij XHTML/CSS/JavaScript. Basically: je maakt iets, je controleert of het werkt, en je kunt er eigenlijk al vanuit gaan dat het op een willekeurige andere machine met een JavaVM/PHP ook werkt.

Browsercompatibiliteit kost veel tijd, dus geld. En voor mij is het frustrerend.

Acties:

zondag 21 augustus 2005 17:13

Software Architect

Werkt hier

Op javascript-niveau vind ik de verschillen juist wel meevallen tussen firefox en IE6. Het scheelt natuurlijk dat ik naast crisp zit tijdens het werk daaraan, maar behalve hoe je aan het event-object bij de event-handling en hoe je aan dat xmlhttprequest-object komt is er weinig code in mijn app die specifiek voor IE6 of Firefox geschreven is.

Met CSS2 blijf je idd klooien, tenzij je af en toe negeert dat IE6 foutjes maakt (het werkt toch?

) en je niet alles van CSS wilt gebruiken.

Overigens ben ik bij het testen of React werkte in vrij late RC-build van PHP5 ook maar gestopt met verder proberen, er waren gewoon te veel dingen in de OO-omgeving gewijzigd om het zonder veel inspanning volledig werkend te krijgen... so much for backwards compatibility in PHP

Het "broertje" van PHP, MySQL kan er trouwens ook wat van... een dump vanuit 4.0 is niet gegarandeerd geldig in 4.1 en hoger. Nouja, je blijft gewoon altijd wel tegen forward- en backward-issues aanzitten. Hoe beter gestructureerd en ontworpen de taal/omgeving, hoe minder het zou moeten zijn.

Acties:

Verwijderd

Het hele probleem met dit Ajax gebeuren is dat het leeuwendeel van de mensen die erover willen praten het verkeerde verhaal propageren.

a) Ze weten ten eerste in de basis al niet wat het is
b) Ze weten niet wat de technische nadelen en voordelen zijn
c) Ze weten niet hoe de oude situatie is
d) Ze gebruiken vervolgens ook nog eens dit pattern op de verkeerde manier

Het is echt kuddegedrag de laatste tijd, en het is erg jammer dat zelfs bekende weblogs de verkeerde informatie spuiten, of in een totaal verkeerd pakket verpakken. Op het moment dat er discussie ontstaan over het wegvallen van desktop applicaties omdat er opeens Ajax is

dan heb ik hier wel een leuk voorbeeld van te pakken, want dan snapt men de hele principes van Ajax niet. Dan hebben we het nog niet eens over scripts die puur een list in staat stellen om van volgorde te veranderen, dat is opeens ook Ajax

Ajax is helemaal niet bedoeld om een vervanger te zijn van desktop applicaties (hta anyone?), het is puur bedoeld als een functionaliteit die een gebruik in staat stelt om te communiceren met de server zonder een postback. Het is initieel ontwikkeld voor gebruik in Microsofts webmail interface voor Microsoft Exchange Server.

De combinatie van acceptatie, beschikbare kracht bij clients, professionalisering van web applicaties en de showcases ervoor van Google zorgden ervoor dat men doorkreeg dat Javascript toch niet zo beperkt was als men altijd had gedacht. Men kreeg eindelijk door dat Javascript niet meer de taal was om sneeuwvlokjes op je website te krijgen.

Wat je nu ziet zijn allemaal losse flodders die iets met xmlHttpRequest doen. De een heeft een half werkend grid, de ander een dropdown box die ondemand gegevens ophaalt, maar verder wordt mijnziens de hele plank misgeslagen en stopt het verhaal te snel. Dan ben ik nog niet eens begonnen over het feit dat een groot aandeel van de voorbeeld gewoon complete HTML code injecten.

Het gaat hier ook over een visie over hoe een webapplicatie kan gaan werken. Het is de aanzet om ontwikkelaars te laten zien dat er ook een andere manier is dan elke klik laten resulteren in het volledig laten herladen van pagina's. De kracht bij clients is er, de techniek is er, de resultaten zijn er naar, en het enige wat het nu nog tegenhoud is een immens gebrek aan kennis.

Er zijn zoveel toepassingsgebieden te bedenken, en er zitten voor ondernemingen enorme voordelen aan. Er zijn ook een aantal hele goede leveranciers van software die hun hele product gewoon als web based product aanbieden en dit levert niet alleen flinke kostenbesparingen op voor een onderneming, er zitten ook gigantische voordelen aan die de nadelen kunnen laten verbleken.

Er is nog veel misconceptie over Javascript. Ondanks de loose typed omgeving waarin je werkt heb je de mogelijkheid om gestructureerd te scripten, de taal is krachtig en veelzijdig en de snelheid is voor waar het voor gebruikt wordt prima.

De nadelen zijn vooral in het ontbreken van goede tooling. Er is geen enkele goede IDE voor Javascript verkrijgbaar. Dwz, een IDE die intellisense ondersteund, een boomstructuur van je methods kan tonen, etc.

[ Voor 8% gewijzigd door Verwijderd op 21-08-2005 17:17 ]

zondag 21 augustus 2005 17:52

Acties:

Alarmnummer

-= Tja =-

Verwijderd schreef op zondag 21 augustus 2005 @ 17:13:

De nadelen zijn vooral in het ontbreken van goede tooling. Er is geen enkele goede IDE voor Javascript verkrijgbaar. Dwz, een IDE die intellisense ondersteund, een boomstructuur van je methods kan tonen, etc.

[offtopic]
Probeer Intellij Idea eens. De nieuwste versie (5) heeft support voor javascript. Code completion, syntax checking etc. Ik heb er zelf nog niets mee gedaan trouwens, maar als het half zo goed is als de rest van hun werk, dan moet het wel goed zijn

Trouwens ook uitstekend voor html/xml/css etc.

[ Voor 6% gewijzigd door Alarmnummer op 21-08-2005 17:56 ]

zondag 21 augustus 2005 18:06

Acties:

Verwijderd

Bedankt voor de tip! Ik werk zelf erg veel met Javascript en wat er tot nu toe het dichts bij zat was Eclipse met de Javascript plugin, maar die werkt niet meer in 3.1 van Eclipse

Ik ben als uitstapje op dit topic wel benieuwd naar wat men vind van het model van applicaties als SalesForce, CRM Ondemand van Siebel, Alex. Het is echt bizar om te zien hoeveel gebruikers ze elk hebben, en moet je voorstellen wat dit aan kostenbesparingen voor een onderneming kan opleveren. De grootste risk factor bij deze applicaties blijft het idee dat je gevoelige data buiten je bedrijf opslaat, maar dat is voornamelijk een kwestie van een onderbuikgevoel.

Van dit soort initiatieven kan ik dan wel weer enthousiast worden. Zeker als je bedenkt wat de service graad kan zijn, de mogelijkheden voor het leveren van de hoogst mogelijke kwaliteit vanuit een gecentraliseerd punt, de snelheid waarmee nieuwe features kunnen worden geintroduceerd en de mate waarin je heel makkelijk wel of niet functionaliteit kunt verkopen en eigenlijk on the fly beschikbaar kan stellen. De operationele kosten daar nog niet in meegenomen, zijn dit echt beauties van bedrijfsmodellen imo

zondag 21 augustus 2005 18:54

Acties:

zondag 21 augustus 2005 20:21

Dumbass ex machina

Verwijderd schreef op zondag 21 augustus 2005 @ 17:13:
Ajax is helemaal niet bedoeld om een vervanger te zijn van desktop applicaties (hta anyone?), het is puur bedoeld als een functionaliteit die een gebruik in staat stelt om te communiceren met de server zonder een postback. Het is initieel ontwikkeld voor gebruik in Microsofts webmail interface voor Microsoft Exchange Server.

Wat was nou hetgene dat het meeste opviel aan Outlook Web Access? Juist! Dat het net zoveel kan en net zo interactief is als de desktop-variant van Outlook. Daar komt het inzicht vandaan dat bepaalde applicaties die nu op de desktop draaien, ook naar het web geporteerd kunnen worden, met allerlei voordelen vandien omtrent uitrol, updaten en toegangsbeheer. Zie ook: Rich Internet Applications

AJAX is de eerste stap in de richting van de Rich Client wereld, waarbij er geen verschil meer is tussen desktopapplicaties en internetapplicaties. In concepten als XAML en XUL wordt daarop voortgeborduurd. Overigens herhaal ik nu wat ik al vaker gezegd heb, maar dit hele topic is zowat een herkauwoefening geweest imho.

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

zondag 21 augustus 2005 20:39

Cool

Topicstarter

Mja het is wel duidelijk dat jullie het over een heel ander soort applicatie hebben dan waar ik op doel, en Rasmussen for that matter.

CRM, Agenda, e-mail is idd prima te doen met de huidige middelen. Met SVG komt er ook nog allemaal grafische grappen en grollen bij.

Maar stel dat je met Ajax of zijn kleinkinderen ook meer grafische apps kunt maken, zoals Google Eearth waar Rasmussen het over had, dan zal je browser over een veel grotere "runtime library" moeten beschikken dan wat nu het geval is. Het programmeren zal dan ook net zo complex zijn als hedendaags Java/.NET/PHP. Voor het zover zal zijn zijn we de nodige jaren verder. En wat heb je dan? Techniek die je vandaag de dag ook al hebt met Java/.NET...

Ik zie het nu van Ajax-achtige dingen bij apps als e-mailclients en CRM e.d. ook wel. Maar het goede fundament om er veel meer mee te doen ontbreekt gewoon IMHO. Dat is wat ik bedoel.

Acties:

Verwijderd

Dan ga je veel te ver. Voor licht grafische applicaties is Flash de beste keuze, voor de zwaardere applicaties kom je altijd nog uit bij C/C++ geschreven code. Er zijn grafische applicaties in Java, en C# maar die komen bij lange na niet aan de gewenste performance.

Als ik een Fiat Panda koop moet ik ook niet pretenderen om een Caravan van 8 meter te gaan trekken. Dan moet ik een auto kopen met de capaciteit om die caravan te trekken. Zo zie ik het ook bij dit soort ideeen. Je moet niet om het willen een bestaande techniek in een dergelijke vorm gaan drukken om vooral maar aan te geven dat fundamenten voor jouw (Rasmussen in dit geval) ideeen niet bestaan. Je zou zeggen in dit geval dat de Fiat Panda dus gewoon geen geschikte auto is, .... dat is die wel, alleen niet voor die taak

Als je zulke ideeen gaat uiten krijg ik ook meer het idee dat je kritiek gaat geven om het kritiek willen geven. Geen probleem als je echt een punt hebt wat slaat op daadwerkelijk toepasbare zaken, elke persoon die ermee aan de gang gaat kan je zo zeer zwakke punten opnoemen. Het is verre van perfect, maar als het groeit, en meer wordt geaccepteerd of liever de ideeen erachter, dan krijgen we een mooie toekomst qua web applicaties.

[ Voor 24% gewijzigd door Verwijderd op 21-08-2005 20:46 ]

zondag 21 augustus 2005 20:43

Acties:

zondag 21 augustus 2005 22:29

Dumbass ex machina

Nexxennium schreef op zondag 21 augustus 2005 @ 20:21:CRM, Agenda, e-mail is idd prima te doen met de huidige middelen.

...

Daar gaat het niet om. Natuurlijk kun je met simpelweg HTML en CSS gebruikers hun mailbox laten browsen, en natuurlijk kun je allerlei data weergeven. Het gaat om de interactiemogelijkheden die technieken zoals AJAX bieden. Het gaat erom dat webapplicaties dezelfde rijkheid kunnen hebben als desktopapplicaties. Als ik het heb over een e-mailclient in de browser, dan heb ik het niet over Hotmail.

Je zou bijv. ook Word of Excel in je browser kunnen proppen, dankzij Javascript (en in mindere mate AJAX) en dat dan meteen aan een grote documentopslag hangen. Nooit meer Word-documentjes per e-mail versturen, gewoon je collega een link geven naar het document in de centrale opslag.

Er zit een heel scala aan programma's tussen simpele e-mail clients en ingewikkelde 3d-ontwerpomgevingen e.d., of andere grafisch zware applicaties.
Dat programma's als Photoshop of 3D studio max niet in aanmerking komen voor een browserport moge duidelijk zijn, maar daarbij is het connectiviteitsvoordeel ook minder: je hoeft in Photoshop niet continu een link naar de buitenwereld / centrale opslag open te hebben. En waarom zou Google Earth niet in je browser kunnen? Javascript zal het idd niet aankunnen, maar gegeven de nodige ontwikkelingen op dit gebied, zullen er heel wat deuren opengaan.

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

zondag 21 augustus 2005 22:56

Devver

Pixelated

ACM: ik doelde inderdaad op componenten in IDE's die below the surface aan code-generation doen; uiteraard biedt een goede IDE ook veel functionaliteit die wel handig is zonder dat het je belemmert (integendeel zelfs dus). Ik ben zelf misschien wel wat vastgeroest wat dat betreft, de overstap naar notepad++ met syntax-highlighting was al een grote stap voor me

Intentionally left blank

Acties:

zondag 21 augustus 2005 22:59

Cool

Topicstarter

Gunp01nt schreef op zondag 21 augustus 2005 @ 20:43:
[...]
En waarom zou Google Earth niet in je browser kunnen? Javascript zal het idd niet aankunnen, maar gegeven de nodige ontwikkelingen op dit gebied, zullen er heel wat deuren opengaan.

Waarom zou je het überhaupt willen? Dat is toch al een vraag die ik de OP min of meer heb neergelegd en waar ik nog steeds naar mijn mening geen goed argument op heb gekregen.

Stel dat je uiteindelijk de techniek in je browser krijgt, dan zit je qua programmeer-complexiteit echt op hetzelfde niveau als nu. Wat is dan nog het voordeel?

"Dan hoef je niets te installeren" kennen we al. Flash is ook zo alom aanwezig dat het ook een enorme installatie-graad heeft. Zolang je niet voor elk wissewasje een nieuwe plug-in moet installeren is er niets aan de hand. Besides, nieuwe browsers zullen ook geinstalleerd moeten worden.

Acties:

Verwijderd

Zowiezo echte volwaardige applicaties die helemaal zijn gebouwd op de visie achter Ajax, zijn heel moeilijk haalbaar omdat de kosten relatief hoog zijn en de voordelen in kosten maar lastig zijn aan te tonen (lees suggestief als de pest). Je zult het voorlopig alleen zien in de regionen waar men er flink wat geld tegen aan kan smijten (Google Microsoft -> Fortune 500) of op het hobby vlak voor de mensen met veel tijd over.

Dan hebben we het nog niet eens over de mate van expertise die er aanwezig moet zijn op een diversiteit aan vlakken, en die expertise is redelijk zeldzaam als ik het even lomp mag zeggen. We hebben het naast zaken als gevorderde kennis in markup, styling, javascript over additionele zaken als ui patterns, ui architecture, en handson ervaring met verschillende browsers en alles wat niet werkt zoals men het verwacht te werken. Google kan er bakken met geld tegenaan gooien voor de beste mensen, evenals Microsoft maar voor de kleinere ondernemer is het niet zo haalbaar. De mensen zijn gewoon te schaars, een Ajax toolkit voor een .NET of welke toolkit dan ook verandert daar niets aan.

zondag 21 augustus 2005 23:11

Acties:

zondag 21 augustus 2005 23:22

Verwijderd schreef op zondag 21 augustus 2005 @ 18:06:
Bedankt voor de tip! Ik werk zelf erg veel met Javascript en wat er tot nu toe het dichts bij zat was Eclipse met de Javascript plugin, maar die werkt niet meer in 3.1 van Eclipse

De javascript plug-in van Genuitech die je als onderdeel van de MyEclipse feature (verzameling plug-ins) krijgt werkt ook wel redelijk met code completion, maar haalt het niet bij de kwaliteit van de Java editor, en waarschijnlijk ook niet bij Intellij Idea.

Vanuit de Eclipse organisatie is men wel druk bezig met een project die in editors en deployers voor alle basis web talen voorziet. Dit (toplevel) project heet web tools. Momenteel zit men nog in de pre-release fase (versie 0.7 is net uit), maar de final 1.0 wordt al over een paar maanden verwacht. Je zou deze eens kunnen proberen. (niet samen met MyEclipse gebruiken, die bouwt namelijk ook op WTP maar gebruikt een andere versie).

Hoe dan ook, geen enkele van dergelijk javascript editors ondersteund integrated debugging. Om dat te laten werken zouden browsers universeel een debugging API moeten ondersteunen. De Java VM gaat hier redelijk ver in. Vanuit een IDE maak je een connection met je VM via zo'n universele interface. Dit kunnen VMs van verschillende vendors zijn en deze kunnen zelfs remote draaien.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

TheGhostInc

Om aan te haken op het punt van Nexxennium:

Wat wil de gebruiker, wat verwacht de gebruiker en hoe sluit je programmeertaal en omgeving daarbij aan. Om even een paar leuke voorbeeldjes te geven:

WINDOWS - De standaard, context menu's, kruisje is sluiten, dat soort gesnor.
JAVA - Met de standaard GUI is het herkenbaar, gebruikers weten dat het niet Windows Like is, verwachten een andere response, en krijgen die ook. Zijn vaak tevreden met de eenvoudige interface, weinig toeters en bellen, usability hoog.
HTML - Back, context menu's van de browser, bookmarks, reloaden als er nieuwe data komt enz.

En dan krijg je dadelijk met AJAX:
Je zit in je browser, je Back knop doet niks, krijg je weer van die achterlijk meldingen over POST enz. Gebruikers zitten te wachten op een refresh om nieuwe gegevens te krijgen, maar die data is er soms wel, soms niet als de serverload te hoog is.

Je krijgt er dus een omgeving bij, die lijkt op wat je in je browser kunt, maar gedeeltelijk niet werkt, zoals bookmarks/back. Afhankelijk van de ervaring van de programmeur krijg je er functionaliteit bij, waarbij het steeds verder naar een windows app neigt, maar het uiteindelijk niet wordt.

Een beetje content laden op de achtergrond is handig, wat scripting op je pagina is praktisch, maar wanneer stop je.

De enige reden dat Outlook webaccess goed werkt is omdat mensen met Outlook werken, draai het eens om, iemand die niet met Outlook kan werken, en komt voor de webaccess terecht, die verwacht een website en krijgt iets anders, maar als hij alleen static HTML kent, hoe handig is zo'n site dan nog? Of ben je dan langer aan het uitleggen hoe het werkt dan met een standaard webmail site?

Techniek is mooi, maar zeker niet alles. De gebruiker zal de nieuwe fouten van AJAX niet toejuichen, sites hebben nu al moeite om hun javascript ed. goed te laten werken.

Disclaimer: geen AJAX programmeur, just trying to put things in perspective.

Edit Novell:
Pak Novell Groupwise, en dan de webaccess (ken de nieuwste versies niet btw), zitten lekker veel verschillen tussen. Zelfde kleuren, zelfde layout, maar wel hun eigen look & feel. HEERLIJK, want je browser blijft je browser, en je app blijft je app. Geen rare crossover dingen.

[ Voor 8% gewijzigd door TheGhostInc op 21-08-2005 23:26 . Reden: Novell ]

zondag 21 augustus 2005 23:35

Acties:

zondag 21 augustus 2005 23:35

Gunp01nt schreef op zondag 21 augustus 2005 @ 18:54:
AJAX is de eerste stap in de richting van de Rich Client wereld, waarbij er geen verschil meer is tussen desktopapplicaties en internetapplicaties.

Ik wil niet vervelend doen, maar was X Windows dat niet al vele, vele jaren voordat ook maar het web bestond? Ok, over small-band werkte het niet echt, maar ik kan nu via ADSL bij het bedrijf waar ik werk inloggen en remote een X applicatie draaien alsof ik het lokaal heb draaien. Dit kan ik bereiken zonder extra moeite whatshowever. Gewoon de standaard XLib, Motif, GTK, Qt dingen gebruiken en je hebt *gratiz* een remote interface.

Eigenlijk is dit een schitterend programmeer model. Mischien zouden er wat meer bandwidth besparende features aan het protocol toegevoegd kunnen worden en een makkelijkere manier bedacht kunnen worden om een applicatie te starten (bv door gewoon zoals op het web naar een URL te serven).

Technisch zou het geen probleem moeten zijn. Een X Server (in web terminology eigenlijk X Client; X draait voor je gevoel de server en client rollen om) heb je voor elk platform, zelfs voor Windows.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

maandag 22 augustus 2005 00:20

Dumbass ex machina

Nexxennium schreef op zondag 21 augustus 2005 @ 22:56:
[...]

Waarom zou je het überhaupt willen? Dat is toch al een vraag die ik de OP min of meer heb neergelegd en waar ik nog steeds naar mijn mening geen goed argument op heb gekregen.

Je wuift nu gauw het no-install argument weg, maar weet je wat dat voor systeembeheerders betekent? En verder het feit dat elke gebruiker automatisch de nieuwste versie van de software gebruikt, je de toegang tot de software bij de bron kan beteugelen (geen CD-Roms meer die van hand tot hand gaan). Denk niet alleen aan de consument thuis, maar denk aan interne bedrijfstoepassingen (want hoeveel consumenten gebruiken Outlook? Daar is Outlook Web Access dus ook niet voor bedoeld).

Maar zoals al eerder vermeld, is AJAX een opstapje. Een inkijk in de toekomst, een kans om van mindset te veranderen. Want als over een paar jaar technieken als XAML of XForms wijdverspreid zijn (of er is 1 duidelijke 'winnaar') dan gaan internetapplicaties je browser uit. Omdat het via het internet/intranet verspreid wordt heb je wel dezelfde voordelen als een webapplicatie, maar je bent niet meer gelimiteerd door de browser.

Uiteraard kan een browser dan nog wel gebruikt worden om die applicaties te verkrijgen.

Certified smart block developer op de agile darkchain stack. PM voor info.

Acties:

maandag 22 augustus 2005 09:23

Cool

Topicstarter

Gunp01nt schreef op zondag 21 augustus 2005 @ 23:35:
[...]

Je wuift nu gauw het no-install argument weg, maar weet je wat dat voor systeembeheerders betekent? En verder het feit dat elke gebruiker automatisch de nieuwste versie van de software gebruikt, je de toegang tot de software bij de bron kan beteugelen (geen CD-Roms meer die van hand tot hand gaan). Denk niet alleen aan de consument thuis, maar denk aan interne bedrijfstoepassingen (want hoeveel consumenten gebruiken Outlook? Daar is Outlook Web Access dus ook niet voor bedoeld).

Err. Het gaat hier met name om applicaties die verbinding maken met een server. *Daar* leg je de access control. Dat Jan en alleman dan toegang heeft tot de applicatie (UI) is dan niet eens zo erg.

En verder: Sun's WebStart zorgt er ook voor dat je applicatie up-to-date is. Ik geloof niet dat het deployen van Java in een bedrijfsomgeving nou echt zo schrikbarend anders is dan een ander stuk software.

Maar zoals al eerder vermeld, is AJAX een opstapje. Een inkijk in de toekomst, een kans om van mindset te veranderen. Want als over een paar jaar technieken als XAML of XForms wijdverspreid zijn (of er is 1 duidelijke 'winnaar') dan gaan internetapplicaties je browser uit. Omdat het via het internet/intranet verspreid wordt heb je wel dezelfde voordelen als een webapplicatie, maar je bent niet meer gelimiteerd door de browser.

Uiteraard kan een browser dan nog wel gebruikt worden om die applicaties te verkrijgen.

Ik zeg nou juist de hele tijd dat die mogelijkheden er allang zijn. Waarom zou je dan nu nog moeite doen met een onhandig en klein opstapje?

Acties:

Verwijderd

Maar welke mogelijkheden dan? Een .NET applicatie moet je nog steeds installeren, evenals een Java webstart applicatie. Alleen die stap al, de installatie maakt de acceptatie van web applicaties mogelijk

Als je bij een stadhuis komt, en iemand heeft software nodig dan moet het eerst over 10 etages, door 5 business units, en langs evenzoveel personen totdat er een ticket komt waarbij je in de wachtrij staat zodat er iemand naar je bureau toekomt om de software te installeren, want dat moet gebeuren door een I&A afdeling. Germien van afdeling X weet bij god niet wat ze moet doen, laat staan dat ze al durft om op te knop "next" te klikken want het zou zo maar niet meer kunnen werken.

Normaliter is I&A alleen verantwoordelijk voor infrastructuur, maar ook hier komt het steeds vaker voor dat afdelingen niet zelf zorg kunnen dragen voor de installatie van applicaties en wordt dit dus uitbesteed aan I&A. Als je bekijkt wat een operationele kosten dit met zich meebrengt, en dat deze kosten groeien in vergelijking met de hierarchie en grootte van een onderneming dan is het aspect van "access everywhere" een enorm groot punt voor de keuze van web applicaties.

Ook de gehele infrastructuur voor de opslag van gegevens, voor de bewaking (backup) van die gegevens, en de schaalbaarheid van dergelijke applicaties zijn bepalend voor het succes ervan. Je kunt zomaar ineens op een geheel andere locatie toegang krijgen tot je software, die normaliter op de Citrix omgeving van het stadhuis stond. Je hoeft niets te installeren, puur een internet verbinding en die zijn al helemaal niet schaars meer, laat staan dat de benodigde snelheid niet aanwezig is.

maandag 22 augustus 2005 11:38

Acties:

BoomSmurf

Am-Ende!

(response op originele vraag/titel, niet op discussie)

IMHO is AJAX zowel overhyped als een zegen. Waarom een zegen? De voordelen zijn veelgenoemd, betere responsiveness, rijkere gui, geen constante reloads, etc. Bij alles waarbij je in feite data aan het browsen bent is het handig. Het is echter ook zwaar overhyped. Er wordt teveel met javascript gefrutseld, vaak zonder duidelijke reden. Er wordt altijd XML gebruikt in de communicatie, wat vaak gewoon puur overkill is. Daarbuiten bestond de techniek an sich allang en brengt AJAX eigenlijk niets nieuws onder de zon behalve de combo een naam te geven. Verder wordt het te pas en te onpas gebruikt, zijn de meeste voorbeelden ronduit knullig en werkt het vaak ook maar half. Ik vind het nog steeds mooi, maar ik merk vaak dat als ik ergens zoiets voor nodig heb, dat ik toch liever met m'n eigen 'tailored' oplossing werk dan dat ik AJAX ga gebruiken.

maandag 22 augustus 2005 11:38

Acties:

maandag 22 augustus 2005 11:40

*kuch* X Window *kuch*

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

Verwijderd

BoomSmurf schreef op maandag 22 augustus 2005 @ 11:38:
(response op originele vraag/titel, niet op discussie)

En wat is die tailored oplossing dan wel

maandag 22 augustus 2005 12:47

Acties:

maandag 22 augustus 2005 12:53

amateur megalomaan

Verwijderd schreef op maandag 22 augustus 2005 @ 11:40:
[...]

En wat is die tailored oplossing dan wel

offtopic:
Laat me raden: comma-separated (oid) data overpompen. Of tekst in een hidden (i)frame.

tailored is toch vaak gewoon "houtje-touwtje" (maar dan met een wat hippere naam), of niet?

[ Voor 4% gewijzigd door Annie op 22-08-2005 12:48 ]

Today's subliminal thought is:

Acties:

maandag 22 augustus 2005 13:03

Devver

Pixelated

Annie schreef op maandag 22 augustus 2005 @ 12:47:
[...]

offtopic:
Laat me raden: comma-separated (oid) data overpompen. Of tekst in een hidden (i)frame.

tailored is toch vaak gewoon "houtje-touwtje" (maar dan met een wat hippere naam), of niet?

mwa, als het bijvoorbeeld enkel om een stukje tekst gaat waarom zou je dan geen text/plain terugsturen?
Ik gebruik nog wel eens een vorm van serializen voor bijvoorbeeld arrays. XML heeft dan meestal toch een grotere overhead.

Intentionally left blank

Acties:

Verwijderd

Dat is ook niet een issue, wel wordt het wanneer je de kracht van asynchrone communicatie gaat vergelijken met synchrone rpc requests of met synchrone iframe requests (tenzij je dynamisch iframes aan gaat maken ..

).

maandag 22 augustus 2005 15:31

Acties:

Verwijderd

Ik ben hem niet in deze discussie tegen gekomen maar Google suggest is een heel mooi voorbeeld waar je AJAX voor kunt gebruiken. Je creeert een hele andere user experience. Voor bepaalde apps kan dit heel verhelderend zijn. Je kunt eindelijk zaken oplossen waar je bv eerder Flash (of Flexx) zou inzetten.

Natuurlijk kan het allemaal allang en is het niet zo spannend, maar door de hype ga je wel anders kijken naar je apps. En wat mij betreft: Als het werkt op IE 5.5+ en Firefox (en dan ook waarschijnlijk Safari) vind ik het best. Als iemand in een auto op 2-takt wil rijden moet ie niet verwachten dat ie overal kan tanken denk ik maar.

maandag 22 augustus 2005 17:16

Acties:

BoomSmurf

Am-Ende!

crisp schreef op maandag 22 augustus 2005 @ 12:53:
mwa, als het bijvoorbeeld enkel om een stukje tekst gaat waarom zou je dan geen text/plain terugsturen?
Ik gebruik nog wel eens een vorm van serializen voor bijvoorbeeld arrays. XML heeft dan meestal toch een grotere overhead.

Dat bedoel ik idd.

maandag 22 augustus 2005 17:19

Acties:

Verwijderd

Ja ik vind het wat overhyped. Ik vind het interessant op het moment dat je dropdowns in moet vullen op een formulier en er is afhankelijkheid tussen de dropdowns.

Van het vullen van iFrames/divs/ of wat voor delen van de pagina ben ik geen fan aangezien ik liever een duidelijke (leesbare) URL per pagina aan de gebruiker toon.

maandag 22 augustus 2005 17:27

Acties:

maandag 22 augustus 2005 18:35

Devver

Pixelated

BoomSmurf schreef op maandag 22 augustus 2005 @ 17:16:
[...]

Dat bedoel ik idd.

Ik meen dat google suggest ook geen XML gebruikt

Intentionally left blank

Acties:

maandag 22 augustus 2005 19:20

Cool

Topicstarter

Daar wordt nog even een leuk punt aangesneden: vziw is er geen standaard, eenvoudige manier om een XML (DOM) document met daarin de data die je naar de server wilt sturen ook werkelijk met XMLHttpRequest daar te krijgen. Is dat niet iets dan met DOM level 3 load/save wel kan?

Ik heb me iig sterk verbaasd hoe ranzig het was om data uit een simpel formuliertje daadwerkelijk naar de server te versturen.

Acties:

Verwijderd

Ik kan me voorstellen dat werken volgens een json model prettig werken is, maar er was ooit een standaard, soap, die ondertussen ook al niet meer uitwisselbaar is tussen verschillende systemen omdat iedereen zijn eigen draai er aan geeft.

Daarnaast zijn er verschillende formats voor uitwisseling van serialized complexe datatypes, waaronder dus soap en wddx.

Standaarden genoeg, nu nog de juiste implementaties ervan.

maandag 22 augustus 2005 22:23

Acties:

JeromeB

woei

Verwijderd schreef op maandag 22 augustus 2005 @ 19:20:
Ik kan me voorstellen dat werken volgens een json model prettig werken is, maar er was ooit een standaard, soap, die ondertussen ook al niet meer uitwisselbaar is tussen verschillende systemen omdat iedereen zijn eigen draai er aan geeft.

Daarnaast zijn er verschillende formats voor uitwisseling van serialized complexe datatypes, waaronder dus soap en wddx.

Standaarden genoeg, nu nog de juiste implementaties ervan.

Nu je het toch over JSON hebt en 'juiste implementaties'. Jan-Klaas Kollhof heeft een zeer interessante JSON-module geschreven in JavaScript: JSON-RPC.

PC load letter? What the fuck does that mean?

dinsdag 23 augustus 2005 00:20

Acties:

dinsdag 23 augustus 2005 08:39

flowerp schreef op zondag 21 augustus 2005 @ 23:35:
Ik wil niet vervelend doen, maar was X Windows dat niet al vele, vele jaren voordat ook maar het web bestond? Ok, over small-band werkte het niet echt, maar ik kan nu via ADSL bij het bedrijf waar ik werk inloggen en remote een X applicatie draaien alsof ik het lokaal heb draaien. Dit kan ik bereiken zonder extra moeite whatshowever. Gewoon de standaard XLib, Motif, GTK, Qt dingen gebruiken en je hebt *gratiz* een remote interface.

Eigenlijk is dit een schitterend programmeer model. Mischien zouden er wat meer bandwidth besparende features aan het protocol toegevoegd kunnen worden en een makkelijkere manier bedacht kunnen worden om een applicatie te starten (bv door gewoon zoals op het web naar een URL te serven).

Technisch zou het geen probleem moeten zijn. Een X Server (in web terminology eigenlijk X Client; X draait voor je gevoel de server en client rollen om) heb je voor elk platform, zelfs voor Windows.

Ik zat hier zelf ook al de hele tijd bij het lezen van deze thread aan te denken. Ik heb zelf nooit geloofd in serieuze applicaties via web technieken, en dat doe ik nog steeds niet. Tuurlijk, een webmail interface kan op zijn tijd best handig zijn, maar het haalt het niet bij een "echte" client. Ik denk ook best dat je een hoop nuttige dingen binnen dat soort interfaces kan doen met AJAX technieken. Je bereikt echter nooit een consitstente look & feel tussen je applicaties op die manier, en dat is volgens mij wel belangrijk.

Er zijn de laatste jaren aanzienlijke stappen gemaakt voor wat betreft het X protocol. X is nu ook over smalband prima bruikbaar, en over breedband razend snel. Kijk maar eens naar de NX client en server. Dat is echt heel indrukwekkend, en is volgens mij een veel bruikbaarder weg als je je applicaties centraal wil houden. Zelfs de eenvoudige startmethode waar je het over hebt is al gerealiseerd.

[ Voor 9% gewijzigd door ATS op 23-08-2005 00:24 ]

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

Verwijderd

ATS schreef op dinsdag 23 augustus 2005 @ 00:20:
Ik zat hier zelf ook al de hele tijd bij het lezen van deze thread aan te denken. Ik heb zelf nooit geloofd in serieuze applicaties via web technieken, en dat doe ik nog steeds niet. Tuurlijk, een webmail interface kan op zijn tijd best handig zijn, maar het haalt het niet bij een "echte" client. Ik denk ook best dat je een hoop nuttige dingen binnen dat soort interfaces kan doen met AJAX technieken. Je bereikt echter nooit een consitstente look & feel tussen je applicaties op die manier, en dat is volgens mij wel belangrijk.

Het is ook zeker niet overal op toepasbaar. Onlangs heeft een grote verzekeringsmaatschappij een product wat dagelijks werd gebruikt en op het web was gebaseerd vervangen door een echt client applicatie, puur omdat het toch net iets anders aanvoelde en het aantal verwerkingen per uur omhoog ging. Ik denk echter niet dat je daar veel verschil in zult merken. Er zijn client applicaties die slecht zijn opgezet, en ook niet instant de gebruiker voorzien van dialogs en hetzelfde geld voor web applicaties. Echter, er zijn ook net zoals echte clients, evenzoveel echte goede web applicaties.

Het is juist vooral hier dat je ziet dat er behoefte is aan oplossingen die het doel hebben om de snelheid en het gedrag van een interface op te krikken naar een dermate hoog niveau dat je er gewoon ontzettend snel mee kan werken.

Die consistente look is 100% haalbaar, maar dat hangt van de persoon af die de looks definieert. Dit is behalve het gemis aan standaard gedefinieerde controls als een spinbox, slider, etc. toch echt niet een probleem van de techniek daar ook deze componenten gewoon op het web te vinden zijn, in consistente look & feel.

dinsdag 23 augustus 2005 09:52

Acties:

dinsdag 23 augustus 2005 09:54

Ik doelde op een consistente look met de rest van je systeem. Als ik via X een applicatie op mijn desktop set, dan ziet die applicatie er net zo uit als elke andere applicatie op mijn desktop. Natuurlijk kan je ook slechte clients schrijven, daar zijn legio voorbeelden van, maar ik denk dat makkelijker is om een goede client te schrijven dan het is om een goede AJAX applicatie te schrijven.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

chem

Reist de wereld rond

Ik kan het niet laten; aangezien hier toch wat mensen met AJAX ervaring lijken te zitten die mogelijk niet in W&G komen: chem in "IE kent geen responseXML.getElementById"

[/schaamteloze-crosspost]

Klaar voor een nieuwe uitdaging.

dinsdag 23 augustus 2005 09:58

Acties:

Verwijderd

chem schreef op dinsdag 23 augustus 2005 @ 09:54:
Ik kan het niet laten; aangezien hier toch wat mensen met AJAX ervaring lijken te zitten die mogelijk niet in W&G komen: chem in "IE kent geen responseXML.getElementById"

[/schaamteloze-crosspost]

Is niet crossbrowser mogelijk, heb het nog even nagevraagd

De support is er gewoon nog niet.

dinsdag 23 augustus 2005 09:59

Acties:

Verwijderd

Feit blijft dat het up to date houden van een webapplicatie makkelijker is dan een client applicatie. Ik zie AJAX als een mooi opstapje voor statefull communicatie. Doch vind ik de opzet niet transparant genoeg aangezien het naar mijn mening op teveel technieken leunt (java/javascript/xml). Het is een beetje roeien met de riemen die je hebt.

dinsdag 23 augustus 2005 10:07

Acties:

Verwijderd

ATS schreef op dinsdag 23 augustus 2005 @ 09:52:
Ik doelde op een consistente look met de rest van je systeem. Als ik via X een applicatie op mijn desktop set, dan ziet die applicatie er net zo uit als elke andere applicatie op mijn desktop.

Ik denk niet dat dit een echte issue is. Er zijn genoeg applicaties die op zichzelf ook al niet consistent zijn. Kijk naar een Microsoft Encarta, Microsoft Money, Macromedia Studio MX, die hebben totaal geen enkele consistentie met standaard client applicaties. Dan hebben we het nog niet eens over de interface van Outlook 2003 die op geen enkele manier overeenkomt met de standaard windows applicaties. Zowiezo in de hele Office suite gebruikt men totaal andere controls voor de contextmenu's en de navigatie. Als dat niet inconsistent is dan weet ik het ook niet meer

Natuurlijk kan je ook slechte clients schrijven, daar zijn legio voorbeelden van, maar ik denk dat makkelijker is om een goede client te schrijven dan het is om een goede AJAX applicatie te schrijven.

Dat denk ik dus ook. Daarom, de kosten zullen qua ontwikkeling toch nog steeds aan de hoge kant zijn mits je al een framework hebt die je veel tijd bespaart (zoals ze dit bij MSN Kahuna/FireAnt aan het doen zijn). Er zijn ook maar weinig goede componenten in public te vinden, het meeste spul is van bar slechte kwaliteit. Er is geen enkel goed grid/listview te vinden laat staan dat de componenten die er rondzweven in 99% van de gevallen niet beschikken over een interface die als listener fungeert voor wijzigingen van data en daarop een actie kan uitvoeren.

Daarom zullen ook hier de kosten hoog zijn, want er zal gewoon ontwikkeld moeten worden. Er is namelijk niets/bar weinig op dat gebied te koop.

dinsdag 23 augustus 2005 10:09

Acties:

dinsdag 23 augustus 2005 10:14

Verwijderd schreef op dinsdag 23 augustus 2005 @ 09:59:
Feit blijft dat het up to date houden van een webapplicatie makkelijker is dan een client applicatie.

Dat hoeft dus niet, als je je "client" applicaties ook centraal houdt. Je vergeet dat deze ook niet gedeployed worden, maar dat ze op een centrale server draaien. Met behulp van (N)X kan je je programma's op een workstation gebruiken alsof hij locaal draait, terwijl hij in feite op een server elders werkt. Waarom zou dat lastiger up to date te houden zijn dan een webapplicatie?

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

chem

Reist de wereld rond

Verwijderd schreef op dinsdag 23 augustus 2005 @ 09:58:
[...]

Is niet crossbrowser mogelijk, heb het nog even nagevraagd De support is er gewoon nog niet.

Maar, wat is dan de oplossing? Alle data als XML binnenhalen en in beide browsers een XSLT eroverheen?

Klaar voor een nieuwe uitdaging.

dinsdag 23 augustus 2005 10:18

Acties:

Verwijderd

chem schreef op dinsdag 23 augustus 2005 @ 10:14:
[...]

Maar, wat is dan de oplossing? Alle data als XML binnenhalen en in beide browsers een XSLT eroverheen?

Ja

dinsdag 23 augustus 2005 10:21

Acties:

dinsdag 23 augustus 2005 10:28

the alien you never expected

Google maakt daar toch ook gebruik van? XSLT in de browsers? Ik zag op code.google.com nog een JavaScript versie van een xslt-engine van hun hand: http://sourceforge.net/projects/goog-ajaxslt/

Acties:

dinsdag 23 augustus 2005 10:41

Verwijderd schreef op dinsdag 23 augustus 2005 @ 10:07:
[...]

Ik denk niet dat dit een echte issue is. Er zijn genoeg applicaties die op zichzelf ook al niet consistent zijn. Kijk naar een Microsoft Encarta, Microsoft Money, Macromedia Studio MX, die hebben totaal geen enkele consistentie met standaard client applicaties. Dan hebben we het nog niet eens over de interface van Outlook 2003 die op geen enkele manier overeenkomt met de standaard windows applicaties. Zowiezo in de hele Office suite gebruikt men totaal andere controls voor de contextmenu's en de navigatie. Als dat niet inconsistent is dan weet ik het ook niet meer

Wat mij betreft zou dat wel een issue moeten zijn. Het feit dat Microsoft zich niet aan eigen standaarden houdt en geen consitente look & feel heeft tussen haar applicaties verdient IMHO zeker geen navolging. In usability kringen is met het er over eens: consistency is king.
Nu weet ik wel dat een "echt" programma dus geensinds een garantie is voor een consistente interface, maar het is in ieder geval mogelijk zo'n interface te maken. Ik zie niet in hoe je met behulp van AJAX een interface kan bouwen die consistent is met de rest van mijn systeem, zeker niet als de gebruiker andere instellingen heeft dan de default.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

dinsdag 23 augustus 2005 10:41

the alien you never expected

Maar ja, de werking tussen de webapplicatie en desktop applicatie hoeft qua gebruikersinterface ook niet consistent te zijn. Als de groep webapplicaties onderling maar consistent zijn. Webapplicaties krijg je toch nooit consistent met de desktop applicatie, kijk naar Outlook voor Windows en voor MacOSX. Het lijkt mij dan beter dan de webapplicatie gewoon op elk platform hetzelde werkt of, gewoon werkt volgens interactiestylen van de gastheer/besturingssysteem.

Acties:

Verwijderd

Ze mogen het best eens zijn in die kringen, feit blijft dat het toch met open armen wordt ontvangen door gebruikers. Men kan ook te ver doorschieten met consistency, om het consistency zijn ondanks, dat de applicatie vanwege die geforceerde consistency de usability krijgt van een onhandelbaar gedrocht.

Uiteindelijk zeggen we nadat alle gebruiker de applicatie links lieten liggen, "Ja maar het was wel consistent". Consistency is een richtlijn en niet meer dan dat.

Komt bij dat binnen de scope van een applicatie er wel degelijk consistency is, overal werken de toolbars hetzelfde, gebruikt men dezelfde dialogs met tabs, zit over een ok en cancel button en zijn de kleuren overal doorgevoerd. Maar dat is binnen de applicatie, en dat is wat telt voor een gebruiker

dinsdag 23 augustus 2005 10:45

Acties:

dinsdag 23 augustus 2005 11:05

the alien you never expected

Ach, als je tijdens een gebruikersonderzoeken tot de conclusie bent gekomen dat de meeste gebruikers er goed mee kunnen werken.... dan lijkt mij het prima. Met consistent bedoelen ze ook vaker dat een icon dezelfde betekenis hebben in de applicaties.

Acties:

Verwijderd

Gunp01nt schreef op zaterdag 20 augustus 2005 @ 13:15:
Elke manager roept nu: "Wij moeten ook AJAX gebruiken in onze websites/webapps! En het liefst overal! Want ik lees hier net dat AJAX goed is dus als we zoveel mogelijk AJAX in onze apps stoppen, dan worden onze apps ook goed!".

Dergelijke managers ben ik gelukkig nog niet tegengekomen. Mijn ervaring is dat het voornamelijk de programmeurs zijn die graag met een nieuwe techniek aan de slag gaan.

dinsdag 23 augustus 2005 21:53

Acties: