[SilverLight/JavaFX] Wat denken we ervan?

[JKVA]

Hoi allen,

Op alle Java fora, sites en blogs wordt over niets anders meer gesproken dan over JavaFX. Ook heel JavaOne lijkt in het teken van JavaFX te staan en dat het tegen Microsoft SilverLight op gaat boksen.

Ik heb me er nog niet tot in detail in verdiept en weet nog niet wat ik ervan moet vinden. Gaat het op dezelfde manier mis als bij Swing of wordt het echt een blijvertje?

JavaFX script zie ik wel toekomst in, tenminste als het de kracht van procedureel/OO programmeren weet te combineren met het declaratieve. Anders zie ik al gebeuren dat de gangbare gevallen eenvoudig worden, maar de iets afwijkende gevallen quasi onmogelijk worden. Ik heb nog geen "geavanceerde" voorbeelden gezien waarvan ik echt blij wordt.

https://openjfx.dev.java...._Started_With_JavaFX.html

Wat denken jullie ervan?

[BikkelZ]

Ik weet het niet, volgens mij gaat het geheel en al afhangen van hoe flitsend de development kit is. Ik vond Flash voor animaties altijd uitermate lekker werken, maar qua programmeren was (of is nog steeds, have stopped checking) is het echt de hell.

Als iemand een intuitieve interface weet te combineren met de onderliggende kracht van Java, dan is het gewoon een hele dikke hit.

-------------------------------------

Blijft het dezelfde grafische 'op alle platforms lelijk' Schwingggg vormgeving?

[ Voor 13% gewijzigd door BikkelZ op 14-05-2007 12:56 ]

[JKVA]

BikkelZ schreef op maandag 14 mei 2007 @ 12:52:
Blijft het dezelfde grafische 'op alle platforms lelijk' Schwingggg vormgeving?

Weet niet. Ik heb tot nu toe vooral naar het programmeren gekeken. De lay-out werkt met Java2D, dus in theorie kan het best mooi worden. Maar ja, het blijft Java, dus ik weet het zo net nog niet.

[BikkelZ]

JKVA schreef op maandag 14 mei 2007 @ 13:03:
[...]

Weet niet. Ik heb tot nu toe vooral naar het programmeren gekeken. De lay-out werkt met Java2D, dus in theorie kan het best mooi worden. Maar ja, het blijft Java, dus ik weet het zo net nog niet.

Ja in theorie kunnen dingen die je in COBOL bouwt ook best mooi worden, maar je moet er wel een stuk harder voor werken om dat voor elkaar te krijgen dan bij pak 'em beet .Net, HTML of Flash. Vooral bij Swing moet je echt enorm veel code rammen om iets voor elkaar te krijgen. Het automatisch aan laten maken via bvb. Eclipse geeft me lichte rillingen als ik zie hoeveel code er uit gerost wordt zonder dat ik daar meteen zicht op heb.

Natuurlijk kun je technisch gezien hele leuke dingen doen met JavaFX, maar de 'wow dat moet ik ook' factor daar ben je toch wel heel erg van afhankelijk. Flash valt pas vies tegen op het moment dat je er eigenlijk al te diep in zit.

[Serpie]

JKVA schreef op maandag 14 mei 2007 @ 13:03:

Weet niet. Ik heb tot nu toe vooral naar het programmeren gekeken. De lay-out werkt met Java2D, dus in theorie kan het best mooi worden. Maar ja, het blijft Java, dus ik weet het zo net nog niet.

Hier een filmpje van een pdf reader gemaakt met JavaFX: http://technorati.com/vid...2Fwatch%3Fv%3Dv9w5NlFm-AA

Dus zeker niet lelijk.

[Verwijderd]

Even een vraag over dat JavaFX, gaat dat iets worden dat ook voor webontwikkeling gebruikt kan worden? (ipv Javascript that is...) of is dit toch puur een taal voor "venster applicaties"

[ari3]

Verwijderd schreef op maandag 14 mei 2007 @ 15:06:
Even een vraag over dat JavaFX, gaat dat iets worden dat ook voor webontwikkeling gebruikt kan worden? (ipv Javascript that is...) of is dit toch puur een taal voor "venster applicaties"

Beiden. Het is net als een applet iets wat zowel in- als buiten de browser kan draaien. Wanneer het in de browser draait kan het net als flash en applets interactief met de DHTML/JavaScript gebruikt worden.

[ari3]

Wel jammer dat het weer een andere taal is. Mijn voorkeur was geweest om het gewoon Java te houden. Of anders gewoon Groovy wat toch scripttaal met native Java-bindings is. De meerwaarde van alweer een nieuw dialect ontgaat mij.

[JKVA]

ari3 schreef op maandag 14 mei 2007 @ 15:16:
Wel jammer dat het weer een andere taal is. Mijn voorkeur was geweest om het gewoon Java te houden. Of anders gewoon Groovy wat toch scripttaal met native Java-bindings is. De meerwaarde van alweer een nieuw dialect ontgaat mij.

Ja, mij ook, maar veel mensen hebben de indruk dat Java te moeilijk is en gaan daardoor 1000 nieuwe dialecten introduceren.

Aan de andere kant is JavaFX wel vrij anders dan de meeste dialecten, aangezien ze bij JavaFX een meer declaratieve weg inslaan, hetgeen volgens mij op zich goed is, maar ik twijfel nog of het krachtig genoeg is voor de onoverkomelijke afwijkgevallen, of dat het te beperkt is voor projecten die niet op de default projecten lijken.

[-FoX-]

Een voorbeeld applicatie ontwikkeld met JavaFX: JavaFX - Motorola Music. Ziet er best wel mooi uit!

[roy-t]

Bij de JavaFX demo tutorial uit de topic start met netbeans moet je nogsteeds zelf een form aan maken code-wise, als je dan kijkt naar Visual Studio en Silverlight waar je gewoon lekker kan drag en droppen van componenten denk ik dat Silverlight het voor venster programmas al meteen gewonnen heeft.

De code-style van JavaFX ziet er wel overzichtelijk uit maar is dus weer net iets anders dan Java,

Verder heb ik nog niet de code stijl gezien van Silverlight (was het niet C#?) maar als Silverlight dus makkelijk IDEs opbouwen combineerd met de al redelijk ingeburgerde taal C# hebben ze toch een goede voorsprong denk ik.

[djc]

Ach, iemand vergeleek de strijd tussen SOAP/WS-* en REST (SOAP/WS-* is keihard aan het verliezen) met de strijd tussen Flex/Silverlight/Apollo/JavaFX en HTML + JavaScript. Ik denk wel dat dat een goede vergelijking is. De krachten van "View Source" en openheid zijn onverslaanbaar.

[crisp]

Manuzhai schreef op dinsdag 15 mei 2007 @ 01:07:
De krachten van "View Source" en openheid zijn onverslaanbaar.

Ik denk dat je het daarmee goed samenvat, dit soort propriety formaten hebben sowieso een groot accessibility probleem en zijn daarom al niet geschikt voor publieke websites, en dan heb ik het nog niet eens over het indexatieprobleem: hoe kunnen search-engines in dit soort formaten content onderscheiden van behavior en opmaak (het zit in 1 bestand, hoezo scheiding?), daar enige semantische waarde aan toekennen, en het meest belangrijk: er direct naar linken?

[JKVA]

crisp schreef op dinsdag 15 mei 2007 @ 01:29:
[...]

Ik denk dat je het daarmee goed samenvat, dit soort propriety formaten hebben sowieso een groot accessibility probleem en zijn daarom al niet geschikt voor publieke websites, en dan heb ik het nog niet eens over het indexatieprobleem: hoe kunnen search-engines in dit soort formaten content onderscheiden van behavior en opmaak (het zit in 1 bestand, hoezo scheiding?), daar enige semantische waarde aan toekennen, en het meest belangrijk: er direct naar linken?

Tja, dat had je met Flash ook al en kijk eens hoe populair dat geworden is. (overigens onterecht naar mijn mening, doe mij maar HTML en dan zelfs met zo weinig mogelijk JavaScript) Mensen zien graag blitse dingen en veel bedrijven laten graag zien hoe flashy ze zijn.

Ligt het trouwens aan mij of worden Flash sites steeds minder populair? Ik kom tegenwoordig amper meer blitse Flash sites tegen.

[BikkelZ]

JKVA schreef op dinsdag 15 mei 2007 @ 07:21:
[...]

Tja, dat had je met Flash ook al en kijk eens hoe populair dat geworden is. (overigens onterecht naar mijn mening, doe mij maar HTML en dan zelfs met zo weinig mogelijk JavaScript) Mensen zien graag blitse dingen en veel bedrijven laten graag zien hoe flashy ze zijn.

Flash is populair geworden doordat iedere browser een plug-in had, het een zeer lage instapdrempel had, gekoppeld was aan Macromedia die met Dreamweaver toen al een zeer goed product had, en de editor voor Flash files gewoon een prima programma was.

Nogmaals, de aantrekkingskracht en initiele eenvoud van Flash gecombineerd met de kracht van Java, dat zou een killer app zijn. En Google kan wel meer doorzoeken dan HTML, als de gecompilede bestanden op de een of andere manier nog te doorzoeken zouden zijn op tekst dan is dat te implementeren. Iemand die wat te verbergen heeft encrypt het, en anders niet.

JKVA schreef op dinsdag 15 mei 2007 @ 07:21:
[...]Ligt het trouwens aan mij of worden Flash sites steeds minder populair? Ik kom tegenwoordig amper meer blitse Flash sites tegen.

Onzin, iedere film en iedere game heeft een website met Flash zo ongeveer. En wat ik goed vind, gebruiken ze Flash vaak niet meer voor de hele site, maar alleen voor die animerende kop (Vodafone.nl ?) of om een weerberichtveld met van die wolkjes te doen (Planet.nl ?), en dat is al een tijdje zo.

[DaCoTa]

BikkelZ schreef op dinsdag 15 mei 2007 @ 11:55:
Nogmaals, de aantrekkingskracht en initiele eenvoud van Flash gecombineerd met de kracht van Java, dat zou een killer app zijn. En Google kan wel meer doorzoeken dan HTML, als de gecompilede bestanden op de een of andere manier nog te doorzoeken zouden zijn op tekst dan is dat te implementeren. Iemand die wat te verbergen heeft encrypt het, en anders niet.

Volgens mij is Adobe Flex precies dat. Een (business oriented) flash front end met eenvoudig java/xml data backend.

[smokalot]

Aangezien de mobiele markt tegenwoordig erg belangrijk is, ben ik vooral benieuwd hoe makkelijk het is met vectoren te tekenen, zoals Flash bewezen heeft goed te doen, en Silverlight iig als een van de speerpunten heeft. Als je mobiel wilt zijn moet je makkelijk op verschillende resoluties/DPIs kunnen werken. En mobiele apparaten hebben nog altijd geen processorkracht in overvloed, dus hopelijk gaat dat ook goed.

Dat er geen standaard video ondersteuning in zit hoeft geen probleem te zijn, als het maar wel erg makkelijk kan, met standaard packages.

[JKVA]

smokalot schreef op dinsdag 15 mei 2007 @ 12:04:
Aangezien de mobiele markt tegenwoordig erg belangrijk is, ben ik vooral benieuwd hoe makkelijk het is met vectoren te tekenen, zoals Flash bewezen heeft goed te doen, en Silverlight iig als een van de speerpunten heeft. Als je mobiel wilt zijn moet je makkelijk op verschillende resoluties/DPIs kunnen werken. En mobiele apparaten hebben nog altijd geen processorkracht in overvloed, dus hopelijk gaat dat ook goed.
[...]

Ze zeggen dat ze voor JavaFX een soort SVG manier van rendering gebruiken, dus dat zou prima moeten werken. De Java2D API (die gebruikt wordt) klinkt op het eerste gezicht ook zeer geschikt.

[crisp]

BikkelZ schreef op dinsdag 15 mei 2007 @ 11:55:
[...]

En Google kan wel meer doorzoeken dan HTML, als de gecompilede bestanden op de een of andere manier nog te doorzoeken zouden zijn op tekst dan is dat te implementeren.

Daar zitten toch wat haken en ogen aan: hoe maak je onderscheid tussen applicatie-data en content? Hoe interpreteer je de content (semantics)? Hoe link je direct naar bepaalde content?

Als je bijvoorbeeld het XAML formaat van Silverlight bekijkt dan zie je al snel dat daar weinig tot geen rekening mee gehouden is; het blijft een brei van style en behavior data met hier en daar wat fragmenten content zonder enige vorm van semantiek. Gewoonweg waardeloos imo en dus zeker geen vervanging voor plain 'ol HTML.

[ Voor 3% gewijzigd door crisp op 15-05-2007 12:46 ]

[Confusion]

ari3 schreef op maandag 14 mei 2007 @ 15:16:
Wel jammer dat het weer een andere taal is. Mijn voorkeur was geweest om het gewoon Java te houden. Of anders gewoon Groovy wat toch scripttaal met native Java-bindings is. De meerwaarde van alweer een nieuw dialect ontgaat mij.

Waarom Groovy en geen Jython of JRuby of Beanshell?

[JKVA]

Confusion schreef op dinsdag 15 mei 2007 @ 13:33:
[...]

Waarom Groovy en geen Jython of JRuby of Beanshell?

Omdat Groovy het populairste is? Ik weet het niet, maar ik hoor over Groovy verreweg het meeste. Aan de andere kant wordt JRuby standaard.

[Confusion]

JKVA schreef op dinsdag 15 mei 2007 @ 13:48:
Omdat Groovy het populairste is? Ik weet het niet, maar ik hoor over Groovy verreweg het meeste.

Ik niet, en wat ik er over hoor is niet altijd even positief .

Aan de andere kant wordt JRuby standaard.

En aan de derde kant is Python superieur aan Ruby en Groovy, door meer structuur en meer ondersteunende libraries . Maargoed, laten we daar geen religieuze oorlog over starten: als Sun het zover krijgt dat 'iets' zo populair wordt dat ze de JVM alsnog in alle browsers kunnen krijgen, dan kan iedereen webapps in zijn favoriete scripting taal schrijven. Mijn zegen hebben ze.

[BikkelZ]

crisp schreef op dinsdag 15 mei 2007 @ 12:45:
[...]

Daar zitten toch wat haken en ogen aan: hoe maak je onderscheid tussen applicatie-data en content? Hoe interpreteer je de content (semantics)? Hoe link je direct naar bepaalde content?

Als je bijvoorbeeld het XAML formaat van Silverlight bekijkt dan zie je al snel dat daar weinig tot geen rekening mee gehouden is; het blijft een brei van style en behavior data met hier en daar wat fragmenten content zonder enige vorm van semantiek. Gewoonweg waardeloos imo en dus zeker geen vervanging voor plain 'ol HTML.

Ja ik zat ook te denken aan bvb de PDF-support van Google. Maar dat is nog redelijk netjes vergeleken met Flash en haar spinoffs.

[JKVA]

BikkelZ schreef op dinsdag 15 mei 2007 @ 16:16:
[...]
Ja ik zat ook te denken aan bvb de PDF-support van Google. Maar dat is nog redelijk netjes vergeleken met Flash en haar spinoffs.

Tja, zal het de mensen die dergelijke tools/talen/platforms gebruiken interesseren dat ze niet goed geïndexeerd worden? Ik denk niet dat dat hun primaire doel is. Dergelijke sites stellen qua content toch vaak niet zoveel voor maar dienen vooral voor "kijk ons eens cool zijn".

[ari3]

Confusion schreef op dinsdag 15 mei 2007 @ 13:33:Waarom Groovy en geen Jython of JRuby of Beanshell?

- Groovy wordt onderdeel van de Sun's J2SE distributie of zelfs van de J2SE spec
- Vanuit Groovy heb je direct beschikking over alle Java API's en frameworks i.t.t. Jython en JRuby waarbij je nieuwe API's moet leren.
- Groovy 'leent' alles wat goed is aan Ruby en Perl.
- Groovy wordt gedragen door grote spelers (Sun, IBM, Oracle, Apache, ...)
- Groovy tooling wordt onderdeel van de standaard Eclipse distributie.

Al deze punten doen mij geloven dat Groovy de scripttaal voor de JVM gaat worden.

[smokalot]

JKVA schreef op woensdag 16 mei 2007 @ 08:06:
[...]

Tja, zal het de mensen die dergelijke tools/talen/platforms gebruiken interesseren dat ze niet goed geïndexeerd worden? Ik denk niet dat dat hun primaire doel is. Dergelijke sites stellen qua content toch vaak niet zoveel voor maar dienen vooral voor "kijk ons eens cool zijn".

Ik heb bij een marketingbedrijfje gewerkt, gespecialiseerd in actiewebsites, en dan vooral spelletjes. Heel veel flash dus. Toen ik zei dat google dat niet kan indexeren was men zeker wel even geinteresseerd. Dit soort dingen *moet* eigenlijk met flash, maar als er open alternatieven zijn zouden die zeer zeker overwegen worden, ook al heeft men veel flash-kennis in huis.

[BikkelZ]

Zonder Google besta je niet.

[geerttttt]

smokalot schreef op woensdag 16 mei 2007 @ 12:19:
[...]

Ik heb bij een marketingbedrijfje gewerkt, gespecialiseerd in actiewebsites, en dan vooral spelletjes. Heel veel flash dus. Toen ik zei dat google dat niet kan indexeren was men zeker wel even geinteresseerd. Dit soort dingen *moet* eigenlijk met flash, maar als er open alternatieven zijn zouden die zeer zeker overwegen worden, ook al heeft men veel flash-kennis in huis.

Tja, dat flash niet geïndexeerd wordt is te omzeilen. natuurlijk kun je niet flash alsnog laten indexeren, maar er vallen wel hidden divjes te maken oid... waardoor de hele content in plain-text google-optimised weergeven kan worden voor google en op een normale browser verborgen kan worden. Dit kan als je het goed aanpakt nog goed uitkomen ook voor je plekje op google...

[Verwijderd]

therat10430 schreef op maandag 14 mei 2007 @ 15:39:
Bij de JavaFX demo tutorial uit de topic start met netbeans moet je nogsteeds zelf een form aan maken code-wise, als je dan kijkt naar Visual Studio en Silverlight waar je gewoon lekker kan drag en droppen van componenten denk ik dat Silverlight het voor venster programmas al meteen gewonnen heeft.

De code-style van JavaFX ziet er wel overzichtelijk uit maar is dus weer net iets anders dan Java,

Verder heb ik nog niet de code stijl gezien van Silverlight (was het niet C#?) maar als Silverlight dus makkelijk IDEs opbouwen combineerd met de al redelijk ingeburgerde taal C# hebben ze toch een goede voorsprong denk ik.

Voor Silverlight zijn er in het totaal 8! pakketten beschikbaar: XAMLPad (notepad variant), Visual Studio en Expression Toolkit (Waarbij Blend de belangrijkste Silverlight toolkit is). Blend en VS ondersteunen bij idd sleep en pleur werk.

En inderdaad Silverlight ondersteunt C# en VB.NET. Grootste nadeel atm is dat er geen Linux implementatie is. Het is echter de verwachting dat aan het eind van dit jaar het Mono team deze af heeft.

crisp schreef op dinsdag 15 mei 2007 @ 12:45:
[...]

Daar zitten toch wat haken en ogen aan: hoe maak je onderscheid tussen applicatie-data en content? Hoe interpreteer je de content (semantics)? Hoe link je direct naar bepaalde content?

Als je bijvoorbeeld het XAML formaat van Silverlight bekijkt dan zie je al snel dat daar weinig tot geen rekening mee gehouden is; het blijft een brei van style en behavior data met hier en daar wat fragmenten content zonder enige vorm van semantiek. Gewoonweg waardeloos imo en dus zeker geen vervanging voor plain 'ol HTML.

Silverlight WPF(/E) biedt wel erg goede ondersteuning styling and theming. Dit is gewoon ingebouwd. Silverlight is een subset van WPF(/E) en zal dus hoogstwaarschijnlijk in de toekomst het gewoon gaan ondersteunen. Vergeet niet dat het op dit moment nog een beta is.

geerttttt schreef op woensdag 16 mei 2007 @ 20:51:
[...]

Tja, dat flash niet geïndexeerd wordt is te omzeilen. natuurlijk kun je niet flash alsnog laten indexeren, maar er vallen wel hidden divjes te maken oid... waardoor de hele content in plain-text google-optimised weergeven kan worden voor google en op een normale browser verborgen kan worden. Dit kan als je het goed aanpakt nog goed uitkomen ook voor je plekje op google...

Zodra Google er echter achter komt dat jij hun search bot voor de gek houdt met hidden divjes verdwijnt je site in no time uit de search results.

[ Voor 32% gewijzigd door Verwijderd op 16-05-2007 21:59 ]

[JKVA]

Interessante link:
http://www.oreillynet.com..._steps_hello_onjav_1.html

[alienfruit]

Ach, je kan HTML+JavaScript net zo unaccessible maken als bijv. Flash. Ik bedoel je moet zowel voor Flash als voor AJAX centric websites moeite doen om het bruikbaar te maken.

[-FoX-]

Het probleem zit hem in het feit dat HTML+Javascript (al dan niet asynchroon) eigenlijk helemaal niet gemaakt zijn voor wat ze nu gebruikt worden. Ik vind het dan ook frappant dat iedereen zich blijft vasthouden aan het oeroude HTTP protocol.

Is het niet eens tijd om de kern van de zaak aan te pakken?

Er wordt wel veel ontwikkeling gedaan op dat gebied, zie maar naar Wikipedia - RIA, maar het probleem is dat tegenwoordig iedereen zijn graantje wil meepakken, en er commercieel voordeel uit halen. Dit in tegenstelling tot het HTTP protocol en de gewone webapplicaties, die ondertussen door iedereen aanvaard werden. Moeten we dan maar verder gaan met de tagsoup?

[JKVA]

Tja, ik denk dat de meeste ontwikkelaars het er wel over eens zijn dat AJAX niet goed is, maar er een goed alternatief moet komen in de basis van het web om het echt praktisch te maken.

Een jaar of 3-4 geleden bij mijn vorige werk waren we het daar al over eens. Gebruik het met mate en hou zoveel mogelijk vast aan de bestaande (goed werkende) technieken.

Eigenlijk denk ik er nu (ondanks de ontwikkelingen in de vorm van 6000 frameworks, patterns en andere nepoplossingen) nog vrijwel hetzelfde over als toen.

[crisp]

-FoX- schreef op zaterdag 19 mei 2007 @ 11:07:
Het probleem zit hem in het feit dat HTML+Javascript (al dan niet asynchroon) eigenlijk helemaal niet gemaakt zijn voor wat ze nu gebruikt worden. Ik vind het dan ook frappant dat iedereen zich blijft vasthouden aan het oeroude HTTP protocol.

Wat heeft het protocol voor de uitwisseling van data te maken met de gebruikte opmaaktaal?

Is het niet eens tijd om de kern van de zaak aan te pakken?

En de kern is? En hoe wou je het aanpakken? Aan loze kreten als 'HTML en Javascript zijn er niet voor bedoelt' en 'HTTP als protocol voldoet niet' hebben we niet zo veel

Er wordt wel veel ontwikkeling gedaan op dat gebied, zie maar naar Wikipedia - RIA, maar het probleem is dat tegenwoordig iedereen zijn graantje wil meepakken, en er commercieel voordeel uit halen. Dit in tegenstelling tot het HTTP protocol en de gewone webapplicaties, die ondertussen door iedereen aanvaard werden. Moeten we dan maar verder gaan met de tagsoup?

Wat versta je precies onder 'tagsoup'?

JKVA schreef op zaterdag 19 mei 2007 @ 11:19:
Tja, ik denk dat de meeste ontwikkelaars het er wel over eens zijn dat AJAX niet goed is, maar er een goed alternatief moet komen in de basis van het web om het echt praktisch te maken.

Een jaar of 3-4 geleden bij mijn vorige werk waren we het daar al over eens. Gebruik het met mate en hou zoveel mogelijk vast aan de bestaande (goed werkende) technieken.

Eigenlijk denk ik er nu (ondanks de ontwikkelingen in de vorm van 6000 frameworks, patterns en andere nepoplossingen) nog vrijwel hetzelfde over als toen.

Ajax en 'Web 2.0' staat natuurlijk nog maar in de kinderschoenen. Wat ik voornamelijk om me heen zie is dat een hele groep mensen (meestal serverside programmeurs ) het gewoon niet begrijpen, javascript maar een raar taaltje vinden, en niet in staat zijn om uit de 6000 frameworks, patterns en nepoplossingen de juiste oplossingen te pikken (omdat ze het niet begrijpen en zich er ook niet verder in verdiepen).

M.i. is het allergrootste probleem op dit moment het gebrek aan (interoperable) browsersupport. Vergeet niet dat we nog zo'n beetje in de middeleeuwen zitten wat dat betreft omdat de marktleider op browsergebied jarenlang de boel heeft laten versloffen. Juist daarom zijn veel oplossingen hacky en 'vreemd' - niet omdat dat de bedoeling is maar puur omdat het noodzakelijk is om het in bepaalde browsers te laten werken.

Niet voor niets is er nieuw leven ingeblazen in de W3C HTML WG; HTML 5 heeft als doelstelling om hiaten in de huidige HTML spec op te vangen en daarmee interoperability te verbeteren. Daardoor legt het een fundering waarop je uiteindelijk verder kan bouwen en je je kan richten op application-related zaken.

[djc]

-FoX- schreef op zaterdag 19 mei 2007 @ 11:07:
Het probleem zit hem in het feit dat HTML+Javascript (al dan niet asynchroon) eigenlijk helemaal niet gemaakt zijn voor wat ze nu gebruikt worden. Ik vind het dan ook frappant dat iedereen zich blijft vasthouden aan het oeroude HTTP protocol.

Ja, ook zo vervelend dat we voorlopig vastzitten aan het stokoude TCP-protocol, en UDP! als we ook nog wat DNS-resolutie willen doen. Een protocol veroordelen omdat het oud is is natuurlijk een kakverhaal.

Daarnaast is HTTP juist een enorm flexibel protocol, dat op dit moment volgens mij heel goed in staat is om deel uit te maken van de oplossingen die op dit moment gebouwd worden. Ik weet niet precies wat jij vindt dat er mis is met HTTP, maar als je kijkt naar wat de REST proponents allemaal te zeggen hebben over het inzetten van HTTP (en dan niet alleen GET en POST, maar liefst ook PUT en DELETE) en allle features die het heeft (E-Tags worden echt maar door een zeer beperkt gedeelte van de applicaties gebruikt, terwijl ze enorm nuttig kunnen zijn) heb ik het idee dat er nog veel meer potentie in HTTP zit die veel developers er nog niet uit hebben weten te halen.

Wat betreft JavaScript denk ik eigenlijk ook dat het een enorm ondergewaardeerde, krachtige imperatief-functionele programmeertaal is. Natuurlijk is het compatibility-verhaal (zoals crisp hierboven ook al aanstipt) op z'n zachtst gezegd een teringzooi, maar dat komt met name door de brakke implementaties, niet door de taal. Ik denk dat de combinatie HTML + JavaScript over HTTP eventueel met hier en daar wat JSON of zelfs XML maar moeilijk te verslaan is door andere oplossingen. En dat werkt allemaal al grotendeels vandaag, er bestaan tools voor, wat wil je nog meer!? Dan hebben we het nog niet eens over de verbeteringen die op komst zijn, niet alleen de verbeterde support voor CSS in Firefox 3 en (laten we hopen) IE 8, maar ook de JavaScript-uitbreidingen in JS 2 (ik verheug me bijvoorbeeld al erg op de list comprehensions, die ze uit Python geleend hebben) en dingen in HTML 5.

Ik denk persoonlijk niet dat een proprietary platform zoals Flex, Silverlight of JavaFX deze combi kan verslaan, en dat ook open platforms als XUL en OpenLaszlo er niet aan kunnen trippen. Ik weet niet waar jij de total rewrite voor nodig acht, maar ik denk dat we meer hebben aan verbetering van de compatibility across platforms en een paar incrementele updates.

[roy-t]

Zelf ben ik eigenlijk meer een voorstander van server side gegenereerde paginas, die dan ge-output worden in html(+java) zoals Visual Web Developer dat doet, je kunt dan zelfs C# gebruiken in een website, zonder de dat gebruiker ook maar Mono hoeft te draaien.

Enige nadeel (vind ik) hiervan is dat het moeilijk doorzoekbaar is.

[Verwijderd]

De hele discussie gaat nou juist over de client-kant.