Sun komt met Ajax- en Silverlight-concurrent

Halverwege april kondigde Microsoft aan dat het met Silverlight de concurrentie wilde aangaan met Macromedia's Flash en nu krijgen beide bedrijven er nog een extra concurrent bij. Ook Sun wil de markt van 'interactieve rich media webcontent' betreden.

Met JavaFX wil het bedrijf een nieuwe variant van Java introduceren die geschikt is voor zowel desktopsurfen als voor mobiele toepassingen. JavaFX Script, de taal achter JavaFX, wordt naar verwachting op de JavaOne-conferentie geïntroduceerd die vandaag in San Francisco van start is gegaan. Deze nieuwe programmeertaal moet het makkelijker maken om 'rijke' internetapplicaties te ontwikkelen voor computers en handhelds die voorzien zijn van Java. De focus ligt daarbij niet zozeer op het bouwen van webpagina's, maar meer op de gebruikservaring en met name op rijkelijk geanimeerde dingen, volgens Rich Green van Suns softwaredivisie. Het bedrijf geeft toe dat de mogelijkheden met JavaFX vergelijkbaar zijn met die van Silverlight, al ligt de focus bij Microsofts platform op streaming video. Hoewel JavaFX op onderdelen met Flash en Silverlight gaat concurreren, wordt het vooral een alternatief voor Ajax, verwacht onderzoeksbureau Forrester. James Gosling, die als de vader van Java wordt beschouwd, bevestigt dat het platform alles kan waar nu Ajax voor wordt gebruikt.

Reacties (79)

[Left]

Dit is een strijd die Flash en JavaFX niet kunnen winnen. Hoe goed ze hun platforms ook maken, Microsoft zal ervoor zorgen dat Silverlight deel uitmaakt van Windows. Dus dat het al in het geheugen geladen is als je Windows hebt opgestart. Daardoor zullen Silverlight apps altijd veel sneller opstarten en dat is natuurlijk een groot voordeel als je aan het surfen bent.

[ThjK]

Aah, het oude vertrouwde (illegale) monopolie misbruik dus.... (ik geef toe, daarvoor moeten ze natuurlijk ook de api's verbergen, maar gezien de problemen die de eu heeft om api-documentatie los te peuteren zal dat wel snor zitten)

[Fireshade]

Gelukkig hebben we de EU-waakhonden nog

[Dreamvoid]

Als je je browser laadt, laadt die ook Flash, etc in - ik zie niet hoe MS daar een voordeel in heeft. Bovendien zetten al die Adobe produkten zichzelf ook al in de startup van Windows.

[Janoz]

Het gaat niet om het inladen, maar om het installeren. Windows wordt standaard niet geleverd met een flash plugin. Deze moet je na je instalatie altijd nog even downloaden.

Ik denk echter dat het niet zo'n vaart zal lopen. Flash is wel zo enorm ingeburgerd dat het niet snel zal verdwijnen (maar goed, dat dachten we van Netscape en Word Perfect ook)

@hieronder: Macromedia bestaat eigenlijk al niet meer. Gekocht door Adobe. Adobe is dus degene die zijn ogen open moet houden

[Dreamvoid]

Tsja, maar die hebben het dan ook zelf keihard opgebokt: Netscape met het onnoemelijk brakke 4.0 en Wordperfect dat dacht dat het met dat rare "Windows" niet zo'n vaart zou lopen en jaren te laat kwam met een fatsoenlijke Windows-versie. Als ze bij Macromedia gewoon de ogen open houden en blijven innoveren gaan ze echt niet weg.

[Verwijderd]

Dat Silverlight eventueel sneller zou kunnen starten zal van Silverlight geen winnaar maken.
+ 98% van de pc's heeft de Flash-player geïnstalleerd. Dat is inclusief pc's met MacOs, Linux, Unix of wat ook.
Als ontwikkelaar is het dus niet gek om voor bijvoorbeeld Flex te kiezen ipv Silverlight. Veel krachtiger is Silverlight namelijk niet.

Eerder zie ik Silverlight net zoals de Zune een mislukking worden.

[sjunnie]

98% van de pc's heeft de Flash-player geïnstalleerd. Dat is inclusief pc's met MacOs, Linux, Unix of wat ook.

Ik vraag me af of je inderdaad tot 98% zult komen, maar goed.
Microsoft zal de silverlight client gewoon als update erdoor drukken zodat de gemiddelde gebruiker er helemaal niets van merkt, laat staan er wat voor moet doen om deze geinstalleerd te krijgen, iets wat men bij flash wel zelf moet doen.

Hierdoor heeft straks wel 98% van alle windows machines deze client, wellicht in absolute aantallen zelfs meer dan machines met flash.
Als ontwikkelaar hoef je je dan ook niet echt druk te maken of je doelgroep de client wel heeft.
Diegenen wat de client na het uitrollen van deze 'update' nog niet hebben zijn zich daar zelf vast wel van bewust.

[arendjr]

Toegegeven, het zijn cijfers van Adobe zelf, en niet wereldwijd, wat suggereert dat ze in andere markten minder sterk vertegenwoordigd zijn, maar nog is 98,7% bepaald niet lullig:
http://www.adobe.com/products/player_census/flashplayer/

Daartegenover, zoals jij suggereert dat 98% van alle Windows machines in absolute aantallen meer zou zijn dan 98% van alle systemen is natuurlijk de grootste onzin die je kunt bedenken. Windows heeft een marktaandeel van ergens tussen de 90-95% en kan dus nooit zo'n hoog aandeel halen als Flash, tenzij ze Silverlight ook op andere platformen gaan uitbrengen (ik geloof wel dat Mac OS X ondersteuning aangekondigd is).

[arjankoole]

Dit is een strijd die Flash en JavaFX niet kunnen winnen.

Kweenie hoor. Het merendeel van de designers werkt met flash, en ik heb nog geen enkel gerucht gehoord dat men silverlight zou kunnen gaan overwegen. ( ik werk bij een heel groot mediaburau ).

Ik zie ook geen echte features aan silverlight die mensen zou kunnen doen bewegen over te stappen. De meeste designers werken toch op een Mac, en volgens mij komen de tools op silverlight mee te maken niet uit voor dat besturingssysteem.... Wat ik persoonlijk erg dom vind van microsoft.

Maar goed, time wil tell.

[tjerkw]

Hoewel je een punt maakt zou je zo niet moeten denken.

Firefox is het toch ook ( bijna ) gelukt tegen MSIE?

[Rowdy.nl]

Goede ontwikkeling, hoe meer concurentie...

Hoop alleen voor Sun dat ze eens een 'kleine' installer maken, ik zoek het persoonlijk niet om een complete 80 mb tellende omgeving binnen te halen en te installeren zodat ik in mijn browsertje fijn Java applets kan draaien...

[Rinzwind]

JRE is maar zo'n 7 MB...

[Rowdy.nl]

JRE offline download is idd 'maar' 14 MB. Echter, als je de installer download en opstart moet je voor de grap maar eens 'Custom' kiezen bij installatie type.

JRE: 65 MB, extra talen 18 MB, extra fonts 6MB. Da's in totaal toch weer 89MB. Staat in schril contrast tegen Flash...

[peke]

Sowieso moet je geen echte programmeertaal vergelijken met een scriptingtaal.
Java is zoveel meer dan Flash.

[MetroidPrime]

Die installer komt er misschien ook aan. Sun doet momenteel onderzoek naar een lightweight Java VM genaamd Java Browser Edition. Deze versie van Java zal alleen de standaard classes meegeleverd krijgen die het absolute minimum zijn om een Java Applet te draaien zodat de installer maar een paar megabyte inneemt. Het is verder de bedoeling dat als er Java onderdelen benaderd worden die wel in de standaard VM zitten, maar niet in JBE, deze automatisch worden gedownload.

Gezien het feit dat Sun in ieder geval onderzoek doet naar een lightweight versie van Java, vind ik JavaFX niet zo'n hele schokkende stap. Ik denk dat het potentieel veel terrein zou kunnen winnen, JavaFX zal open source zijn terwijl Silverlight en Flash allebei proprietary zijn.

[Apache]

.NET is onderliggend vaak gewoon wat calls naar bestaande dll's & components, java staat echt los op zichzelf en bevat zeer zeer veel.

Zoals al gezegd er zitten ook allerlei talen bij als je wenst, dan moet je het al gaan vergelijken met de totale grote van .NET beschikbaar voor alle talen ook, en als je er al 4 hebt kom je al hoger uit ...

[Rowdy.nl]

Klopt, maar om webapplets te kunnen runnen heb je toch die logge/grote install nodig. Je zou het idd eerder moeten vergelijken met 't .NET Framework. Maar die is ook slechts 22 MB, en geen 89?

However, Sun zou gewoon een kleine install moeten hebben, zonder al die developer spullen erbij. 't liefste dan nog een enkele installer voor Java en JavaFX samen...

[Verwijderd]

En dan is Silverlight 1.1 nog eens iets van 4 MB, waarmee je dan de DLR krijgt, dus dan kun je in Python, Ruby, VBx, C# en noem het maar op je applicaties maken.

[Professor_Botje]

De kleinste installer om java aplets te kunnen runnen is btw maar 8Mb nu vraag ik mij af wat er mis is

[Verwijderd]

Mooi?

Hierdoor krijg je alleen maar meer 'fragmentatie'

Als je webontwikkelaar bent, moet je nu al rekening houden met 40% IE6, 30% IE7, 20% FF, en 10% overig.
85% Flash, 15% zonder javascript, 60% breedband,
20% op 800x600, 40% op 1024x768 en 40% overig etc.

Concurrentie is goed, maar op het gebied van software en hardware is compatibiliteit iets wat ten koste gaat door marktaandeel veroveren.

[smokalot]

volgens mij snap je het web niet helemaal. Het is voor ons als webontwikkelaars helemaal niet de bedoeling om te gaan onderzoeken wat voor software iedereen wel niet installeert. Er bestaan standaarden, daar heb jij als ontwikkelaar mee te maken, en de consument kan dan kiezen welk stuk software hij het prettigst vindt, waarbij hij criteria als gebruiksgemak, veiligheid, snelheid, prijs en standaard-compatibiliteit gebruikt om zijn keuze te maken.

Ik zie ook wel dat dit op dit moment niet de werkelijkheid is, maar de fragmentatie van de browsermarkt brengt het wel een stuk dichterbij!

om de een of andere reden loopt deze rich content markt een paar jaar achter, net zoals instant messaging achterloopt op email (vroeger kon je ook niet mailen naar iemand bij een andere provider, en toen kwam smtp). Maar zoals je bij instant messaging kan zien komt het uiteindelijk echt wel goed, met jabber/google talk, yahoo en msn die samenwerken, enz.

[arjankoole]

(vroeger kon je ook niet mailen naar iemand bij een andere provider, en toen kwam smtp)

heeeele kleine correctie: toen kwam UUCP, SMTP kwam weer een tijdje daarna. (en was ook gelijk mateloos populair omdat het stukken beter werkte).

waarbij hij criteria als gebruiksgemak, veiligheid, snelheid, prijs en standaard-compatibiliteit gebruikt om zijn keuze te maken.

nee, de consument kiest voor datgene wat ie al heeft, al kent, of hem al met grof geweld door z'n strot is geduwd. (okay, niet helemaal eerlijk van me, het is nog helemaal niet zeker dat Microsoft dat gaat doen met Silverlight).

Consumenten en kiezen gaat bijzonder moeilijk op software gebied, daar hanteren om de een of andere absurde reden absoluut niet dezelfde criteria die ze wel zouden handhaven als ze bijvoorbeeld gaan shoppen voor een nieuwe vaatwasser, tv of auto.

[Rowdy.nl]

Je hebt een punt, echter niet als ontwikkelaar heb je er de meeste last van. Een ontwikkelaar zal de applicatie maken in de taal waarvan hij/zij verwacht dat het grootste gedeelte van zijn/haar doelgroep die gebruikt... Je gaat echt niet drie keer dezelfde applicatie maken...

De consument/gebruiker zal meerdere (3) plugins moeten installeren, dus voor hem/haar zal het vervelender zijn...

Maar concurentie is imho wel goed, voor ontwikkelaar en gebruiker; door deze concurentie zullen de producenten zich willen onderscheiden; betere performance, meer feature's, noem maar op... Als ik dan 3 (liefst kleine) plugins moet installeren, so be it...

[Fishbeast]

ja idd. het wordt tijd dat ze het eens voor elkaar krijgen dat het in windows geintegreerd wordt.

[haling]

Of een (simpelere) 'browser plugin' - net als flash, etc...

Maar nu het open source is en een universele taal voor veel platformen zie ik dat nog wel goed komen in de toekomst...

[Rowdy.nl]

Het wás in Windows geïntegreerd. Maar ik meen door licenties oid wordt de JVM niet meer standaard met Windows meegeleverd. Wel jammer, dat was veel kleinere install, alleen de JVM, en dus niet de complete development omgeving ed...

[E-E-R]

Microsoft breidde hun JVM uit met wat MS only extensies, dat was tegen Sun's licenties -> lawsuit -> Microsoft komt met C#

[flowerp]

Hoop alleen voor Sun dat ze eens een 'kleine' installer maken, ik zoek het persoonlijk niet om een complete 80 mb tellende omgeving binnen te halen en te installeren zodat ik in mijn browsertje fijn Java applets kan draaien..

Hier wordt aan gewerkt, wellicht al voor Java 7. De voorlopige naam is 'Java kernel'. De gehele runtime is dan slechts 2.5MB, misschien zelfs wel 2MB. Dat is alles wat je feitelijk moet installen.

Al het andere benodigde wordt dan afhankelijk van de Applet on-demand gedownload en natuurlijk bewaard (zodat je maar 1 keer hoeft te downloaden). Dit is vergelijkbaar met Flash waarbij vele flash websites ook eerst een tijdje moeten laden.

[reddog33hummer]

I dacht dat project flair van sun de concurent tegen ajax zou zijn. JavaFX zal dan eigenlijk alleen tegen silverline bedoelt zijn.

Toch vraag ik me af hoe flex (adobe) tegen deze twee gaat verzetten.

[Olaf]

Dat is ook zo, het verschil is dat Flair is gebaseerd op JavaScript

[Verwijderd]

Meer en meer wordt de browser dus eigenlijk een plug-in container. Is op zich niet verkeerd met betrekking tot consisitentie. De weergave wordt dan meer bepaald door de makers van de plug-in dan de renderengine van de browser.

Kan interessant worden.

[Fishbeast]

@aToMac:
ja idd, want dan heb je niet meer dat gezeur dat content op 20 verschillende browsers er op 20 verschillende manieren uit ziet. zou wel een hele verbetering zijn. alhoewel ik denk dat er altijd wel mensen blijven die met eht oude vertrouwde html en css blijven werken. en dan blijf je nog wel met dat probleem zitten

[zenica]

Ik mag hopen dat mensen verder blijfen werken met html en css, sommige sites moeten niet onnodige rotzooi bevaten. Ik moet er niet aan denken dat tweakers vol gestopt wordt met nuttelooze flash/silver/java rotzooi dan kan ik lekker uur gaan wachten met laden en daarnaast me doodergeren aan "blije" thema. Begrijp me niet verkeerd de drie technologien zijn leuk om interactive sites te maken en er voor te zorgen dat ze hip uitzien etc..... maar ik wil graag de browser gebruiken om te interneten en niet als een "software web portal" met allerlei verschillende rendering enigns.

[Punksmurf]

Dat veel overbodige dingen in Flash worden gemaakt wil nog niet zeggen dat iets wat is gemaakt in Flash overbodig is.

Ook met Flash kan je prachtig, lightweight spul maken; helaas ontbreekt het de meesten de kennis om dat te doen .

[Tsunami]

Ik zie het zo nog niet gebeuren dat die content dan ook doorzoekbaar wordt door zoekmachines, dus als je een populaire site wil met veel resultaten in zoekmachines zul je toch echt bij HTML moeten blijven.

[Verwijderd]

Google indexeert al de textvlakken van SWF/ flash files die online in html pagina's ge'embed zijn.

[Verwijderd]

Jaja, omdat Internet Explorer al jaren render-bugs heeft (die ze nu langzamerhand gaan oplossen), moeten we heel HTML en CSS maar achter ons laten?

Als je 10.000 plugins hebt, dan wordt het pas inconsistent. En wie zegt dat al die plugins op alle browsers werken? Of op elk besturingssysteem? Bovendien moet je dan voor elke site weer een andere plugin downloaden... lekker handig.

[Verwijderd]

10.000? Voor elke site een? Je kan ook overdrijven. We kijken nu naar 3 plug-ins, waarvan 1 met Windows Update komt, 1 heel makkelijk te installeren is (Flash) en dan nog JavaFX (die hopelijk makkelijker is te installeren dan de JRE).

[smokalot]

Ik hoop dat ze er een beetje mooie, snelle, en makkelijk bruikbare grafische toolkit bij gemaakt hebben, want het gebrek daaraan heeft java zn imago van "traag" opgeleverd.

Vectorgebaseerd is toch ook een must tegenwoordig, zeker als je met flash en silverlight wilt concurreren.

[J.J.J. Bokma]

"want het gebrek daaraan heeft java zn imago van "traag" opgeleverd."

Misschien wat minder roken, maar wat voor grafische toolkit mis je dan? Java komt juist met een prachtige 2D toolkit.

En traag? Traag bij Java is 9 van de 10 keer gebrek aan kennis bij de programmeur.

[Verwijderd]

Batik is een prachtige toolkit.
Werkt met SVG

[Possstema]

Jammer dat je juist de programma's van die 9 programmeurs op je computer hebt draaien. Ik wist eerst niets van Java, maar had wel ontdekt welke programma's traag waren, en dat bleek bijna altijd een java programma...

Ik geef trouwens zelf de voorkeur aan silverlight, vanwege VS en omdat je kunt werken in C# met WPF, wat ( dacht ik ) vrij gemakkelijk om te toveren is in een applicatie, en andersom.

[apokalypse]

Heel raar, maar java lijkt altijd langzaam (bij mij).
Terwijl uit de testen .Net als langzamer uit komt.
Misschien is java te langzaam met Gui's ofzo.
De standaard layout van java programma;s zijn echt lelijk. Misschien als je 1 of andere geadvanceerd toolkit hebt niet.

java studio, eclipse.
Beide langzaam en lelijk.

Vergelijk eens met visual studio (ok volgens mij niet met .Net geschreven)....paint.net enz...

[J.J.J. Bokma]

"De standaard layout van java programma;s zijn echt lelijk."

Opnieuw: dat ligt aan de programmeur. Ik gebruik b.v. JDiskTree nu en dan, en het is dat de J mij er aan herinnert dat het in Java gescheven is, want verder merk ik er niets van.

@johnbetonschaar - "Welke 2D toolkit bedoel je": De Java 2D API.

En nogmaals, als je UI traag is, dan doe je iets goed verkeerd. Ik heb er nog nooit last van gehad in eigen werk. OK, in den beginne wel, toen het inderdaad zo was dat Java traag als stroop was (jaren '90). Mensen die het over Java is traag hebben spreken dan vaak over of die tijd, of hebben slecht geschreven rommel bekeken (of gemaakt).

Het is net als roepen dat C/C++ software bol staat van de buffer overflows en dat dat door de taal komt. Of dat PHP software onveilig is, en dat dat door de taal komt. Of dat Perl ononderhoudbaar is, en dat dat door de taal komt.

Welnee, het is de programmeur, maar daar wil men vaak niet aan omdat het dan op "ons" bordje ligt.

[tjerkw]

Het is net als roepen dat C/C++ software bol staat van de buffer overflows en dat dat door de taal komt. Of dat PHP software onveilig is, en dat dat door de taal komt. Of dat Perl ononderhoudbaar is, en dat dat door de taal komt.


Elke taal heeft zijn voor en nadelen:
Met C/C++ kun je wel programmas schrijven die geen buffer overflows, danling pointers en memmory leaks heeft.. maar het punt is dat het wel mogelijk is.

Een taal als java is higher-level en regelt zelf zijn memory allocation ( foutloos, ok niet supersnel ). Dus heeft deze taal daar zijn voordeel.

Perl daarentegen heeft veel rare syntaxtische sugar, waardoor die taal over het algemeen moelijker te lezen is.
Nu zeg ik niet dat je er geen geweldige programmas mee kunt maken: ik zeg alleen dat je als nadeel hebt dat onderhoudbaarheid minder wordt: zeker ( vooral ) in grotere teams.


Welnee, het is de programmeur, maar daar wil men vaak niet aan omdat het dan op "ons" bordje ligt.


Het ligt dus echt niet alleen aan de programmeur. Goede talen helpen wel degelijk.
Maar ok een programmeur is een belangrijke factor.

Trouwens goed om je weer te zien John, ken je me nog van de nieuwsgroepen, altijd leuk die discussies.

Groeten Tjerk Wolterink

[johnbetonschaar]

Misschien wat minder roken, maar wat voor grafische toolkit mis je dan? Java komt juist met een prachtige 2D toolkit.

Welke 2D toolkit bedoel je, AWT, Swing of SWT? Ik heb behoorlijk veel Java ervaring, maar als het op UI coding aankomt is het vreselijk vergeleken bij alternatieven. In termen van moeite, performance en mogelijkheden.

En traag? Traag bij Java is 9 van de 10 keer gebrek aan kennis bij de programmeur.

Niet als het op de UI aankomt. Die 3 toolkits die ik opnoemde zijn alledrie enorm heavyweight met listeners, callbacks, lagen over lagen van abstractie enzovoort. Technisch leuk allemaal maar funest voor de responsiveness van Java UI's

[flowerp]

Niet als het op de UI aankomt. Die 3 toolkits die ik opnoemde zijn alledrie enorm heavyweight met listeners, callbacks, lagen over lagen van abstractie enzovoort. Technisch leuk allemaal maar funest voor de responsiveness van Java UI's

Listeners (message/event handlers, observers) en "lagen over lagen" komen bij alle UI toolkits voor. Win32/MFC, Motif, GTK, AWT, Swing, SWT... het werkt allemaal op een zeer gelijke manier.

Eigenlijk zijn AWT en Swing juist kaler dan iets als Win32/MFC wat behalve een UI toolkit ook nog een compleet application framework is (MVC, MDI).

Eclipse en Azureus (beide SWT apps) vind ik er kwa looks absoluut niet slecht uit zien. Ik heb 'native' apps (wat dat tegenwoordig nog mag betekenen) gezien die er slechter uit zien.

Wel is het zo dat Eclipse met name op wat oudere systemen trager is dan Visual Studio. Op een moderne machine staat Visual Studio (2003) zo ongeveer instant op m'n scherm bij het opstarten, terwijl Eclipse duidelijk een tijdje aan het opstarten is.

Voor puur (serverside) rekenwerk en transaction handling is Java zeker niet langzamer en dikwijls juist sneller dan de directe concurenten.

[johnbetonschaar]

Listeners (message/event handlers, observers) en "lagen over lagen" komen bij alle UI toolkits voor. Win32/MFC, Motif, GTK, AWT, Swing, SWT... het werkt allemaal op een zeer gelijke manier.

[..]

Voor puur (serverside) rekenwerk en transaction handling is Java zeker niet langzamer en dikwijls juist sneller dan de directe concurenten.

Dat begrijp ik, maar ten eerste zijn MFC/GTK/Qt/etc native geimplementeerd, en ten tweede deel ik je mening
dat SWT etc. 'kaler' zijn dan eerstgenoemden niet.

Ik heb veel Swing/SWT code geschreven en gedebugged, en als ik bij het debuggen van een event handler aan de stack trace zie hoe ver door de VM dat event heeft moeten komen... Van abstracte listener dit, door proxy dat, via afgeleide interface zus etc. etc. En dat allemaal in bytecode, en (volgens mij) niet preemptable. Vergelijk ik dat ff met bijvoorbeeld een GTK programma dan is dat niet alleen veel makkelijker en korter in het gebruik maar ook veel efficienter.

Je kan me een hoop wijsmaken over Java performance, maar face it: Java UI's zijn gewoon retesloom. Zelfs op een vrijwel nieuwe machine merk je zo duidelijk verschil met elke native toolkit en op elk OS...

[tjerkw]

Welke 2D toolkit bedoel je, AWT, Swing of SWT? Ik heb behoorlijk veel Java ervaring, maar als het op UI coding aankomt is het vreselijk vergeleken bij alternatieven. In termen van moeite, performance en mogelijkheden.


Jij hebt het over GUI toolkits. De 2D toolkit van java is Java2D. Een zeer goede grafische toolkit:
http://java.sun.com/products/java-media/2D/


Overigens Swing is helemaal niet traag. Het is een van de beste Toolkits die er nu aanwezig zijn. Zeer goede architecftuur en herbruikbaarheid. Ok het is moeilijker, maar met tools als Matisse: gaat het opbouwen van GUI's een stuk makkelijker:
http://www.netbeans.org/kb/articles/matisse.html

Java programma's lijken traag omdat telkens de JVM moet worden opgestard. En daar komt aardig wat bij kijken. .NET programmas starten sneller op omdat Microsoft weer misbruik maakt van zijn machtspositie: De VirtualMachine ( of Runtime) is altijd al geladen en daarom laden programmas sneller.


Niet als het op de UI aankomt. Die 3 toolkits die ik opnoemde zijn alledrie enorm heavyweight met listeners, callbacks, lagen over lagen van abstractie enzovoort. Technisch leuk allemaal maar funest voor de responsiveness van Java UI's


Swing is juist LightWeight: maar hierdoor heb je wel een tragere executie. ( Google maar eens op swing en lees er maar wat over ).

Maar juist met hudige pc's en de verbeterde JVM is Swing jusit een geschite kandidaat voor grotere programma's. Kijk maar naar NetBeans: www.netbeans.org. Een supergroote IDE vollledig in Swing geschreven.

[johnbetonschaar]

@tjerk en @j.j.j.bokma
De Java 2D API is m.i. geen UI toolkit maar precies wat de naam zegt: een 2D API. Dat je er ook UI's mee kan maken geloof ik best, maar voor de huis-tuin-en-keuken applicatie gebruik je voor Java toepassingen gewoon AWT/Swing/SWT.

Al die argumenten dat Java niet traag is en dat het maar zo lijkt vanwege de opstarttijd van de VM daar hoef je bij mij niet mee aan te komen. Ik weet dat zelf ook wel. Maar je kan me er echt niet van overtuigen dat Java UI's niet traag zijn vergeleken bij native GUI toolkits, want dat is gewoon pertinent niet waar.

Voorbeelden te over: Azureus, Eclipse, NetBeans, Intel VTune, elke Java Applet, enzovoort. Prachtige programma's hoor, UI ziet er fatsoenlijk uit, maar de responsiveness is gewoon enorm slecht, en al helemaal als hetzelfde proces het druk heeft. Zet maar eens 4 bittorrents aan in Azureus en ga dan eens de context-menus of de top-menus openen, of van tab switchen. Zelfs op een high-end machines zitten er zoveel vertragingen in de beeldopbouw dat het storend is.

[tjerkw]

Netbeans Eclipse etc zijn niet zelf traag, ze starten alleen traag op.

Ik denk dat het bij jou traag lijkt doordat je witte vlakken op het beeld krijgt: dat is een bekend probleem van Java en volgens mij al opgelosd in Java 5, of Java 6.

Die zou ik maar eens downloaden als ik jou was.

PS, natuurlijk blijven die programmas trager dan de C++ programmas. Maar wel veel betrouwbaarder ( kijk maar eens naar de complexiteit van NetBeans ).

[johnbetonschaar]

@tjerkw
Netbeans Eclipse etc zijn niet zelf traag, ze starten alleen traag op.

Ik denk dat het bij jou traag lijkt doordat je witte vlakken op het beeld krijgt: dat is een bekend probleem van Java en volgens mij al opgelosd in Java 5, of Java 6.

Netbeans en Eclipse zijn niet extreem traag, maar zeker ook niet snel vergeleken bij bijvoorbeeld Visual Studio, XCode of een andere ontwikkelomgeving. Maar het is redelijk bruikbaar.

Over die UI-sluggishness: het gaat niet om witte vlakken of dat soort dingen, hoewel je die ook vaak ziet op het moment dat de applicatie zelf het zwaar heeft en je ook nog UI acties plaatst (heeft voor zover ik weet te maken met de threading van de Java UI kits die niet preemptive is). Bijvoorbeeld Intel VTune is zo goed als onbruikbaar vanwege de crappy trage UI. Zelfs op mijn machine op werk (=dual Opteron-64 met 16GB RAM) is het 1) start sampling, 2) koffie halen, 3) wachten totdat de sampling klaar is en de resultaten worden verzameld, 4) koffie halen, 5) klaar. Probeer niet in de tussentijd op een knopje te klikken want dan zit je 10 minuten naar een wit vlak te staren en zie je niet eens meer waar ie mee bezig is.

Wat ik verder heel duidelijk merk is dat bij elke UI actie je een vertraging hebt bij Java, dat het een kwart seconde ofzo duurt voordat er iets op het scherm gebeurt. Dus geen keihard 'performance' probleem maar een latency probleem. Voor een UI is dit funest want daar ga je je als gebruiker enorm aan irriteren. En dat is dan ook wat ik merk bij UI-intensieve Java applicaties.

[flowerp]

Dat begrijp ik, maar ten eerste zijn MFC/GTK/Qt/etc native geimplementeerd

Tsja, hoe native zijn GTK en Qt op bijvoorbeeld het Windows of OS X platform? Winform uit .NET is ook niet native. "native" heeft de laatste tijd wat aan betekenis verloren. Echt native is directe hardware access op een console of arcade board, en zelfs dat komt steeds minder voor.

en ten tweede deel ik je mening
dat SWT etc. 'kaler' zijn dan eerstgenoemden niet.

Dat komt omdat jij niet snapt wat er bedoeld werd met kaalheid. Het aantal method (functie) calls wat gedaan wordt om ergens te komen is een totaal onzinnige maat om te gebruiken. Wat doen die method calls? Zijn het hele dunne wrapper ergens om heen of gebeurd er heel veel?

Ik kan een (console) programma zo schrijven dat ik alles doe met een stack van hoogstens 2 methods diep. Elke method is dan wel 1000 regels. Ik kan het ook refactoren tot +- 10 regels per method. In mij stack kom ik dan dikwijls stacks van 10 diep tegen. Draait die gerefactorde versie trager? In z'n geheel niet. We leven niet meer in 1990 waar de overheid van een call nog significant was. Tegenwoordig is het bijna onmerkbaar.

Daarbij komt nog dat jij in DEBUG mode kijkt. In gewone (optimized) mode worden veel method/functie calls weggeoptimaliseerd of inlined. Stacks van tientallen calls diep worden zo dramatisch gereduceerd.

Wat ik wel met kaalheid bedoelde is dat Swing geen application framework is. Als je niet snapt wat dat is, dan moet je er maar eens op googlen. MFC is dat wel. Java gaat er eentje krijgen in een toekomstige versie.Een AF doet in het algemeen meer dan een widget toolkit.

[tjerkw]

Het eerste wat je noemt is een fout in het programma: ze voeren langdure operatie uit in de event-thread. Dat is heel dom van de programmeurs want zo kan de event-thread gebruikers-interacties niet meer registeren.
Een echte beginnersfout al zeg ik het zelf.

De vertragen die je merkt bij java programmas merk ik zelf helemaal niet.. maargoed.. kan ook aan het programma liggen.


Ik snap overigens je punt wel.. Java en de Desktop dat gaat nog niet zo goed.. die DotNet programmas die kun je super snel runnen met een mooie .exe erbij.

[Verwijderd]

Mooi !

En dan nu mogen alle partijen eens goed naar elkaar kijken, en dan naar hun eigen producten, en dan gaan ze maar fijn heel veel zaken verbeteren, verduidelijken, gebruiksvriendelijker maken en vooral goedkoper maken voor de consument (de ontwikkelaars). Dan hebben wij er met zijn allen lekker voordeel van. MacroMedia (en nu Adobe) zijn al te lang alleen op de wereld geweest.

[Fishbeast]

wel een mooie ontwikkeling. ik snapte nooit eigenlijk wat van flash, maar met java ben ik zeer goed bekend. ik hoop dan ook dat de api e.d. veel op bestaande java lijkt! en dat er ook zo'n mooie toolkit bijkomt als met google's ajax

[mashell]

Java, Javascript, Java FX script? Volgens mij doet iemand erg z'n best om het verwarrend te maken.

[Rembert]

Om te voorkomen dat er wazig in de ruimte wordt gezweefd, een linkje naar de openjfx pagina. Daar staan demo's en tutorials. De JavaFX Canvas Tutorial (helemaal onderaan) is een fantastisch voorbeeld hoe een tutorial ook kan werken: dit is wat er bedoeld wordt met hands-on. Of ik overtuigd ben van openjfx? Nee, nog niet...

[Thundy]

Sorry maar ben ik de enige die de link tussen animatie en AJAX niet ziet?

tegenwordig denken ze geloof ik dat alles wat mooi is AJAX is ofzo.

Als dit ergens mee gaat concurreren dan is het:
flash/silverlight/flex/SVG/javascript.

en zoals DOT al zei, dat ze weer allemaal een eigen richting op gaan is heel jammer...

nog 5 jaar en je mag blij zijn als je hippe website in 10% van de browsers draait.

[Verwijderd]

Ajax heeft idd geen drol te maken met dit artikel.
Ik denk dat de OP flash en silverlight bedoelde ipv ajax en silverlight.

Ajax is een manier van clientside een java app starten die vervolgens gaat ouwehoeren met de server om content over te trekken.

-R-

http://en.wikipedia.org/wiki/AJAX

[bartware]

Ajax heeft idd geen drol te maken met dit artikel.

Nounou, dat is wel kort door de bocht.

Ajax is a development technique for creating interactive web applications.

En dat is precies wat Silverlight, Flash/Flex en dus JavaFX ook zijn.
Resultaat zijn webpagina's die zonder page refresh data ophalen en versturen en nieuwe informatie presenteren.

-B- (overbodige letter tussen streepjes )