Eclipse Foundation bouwt in-browser-ontwikkelomgeving

De Eclipse Foundation, bekend van de gelijknamige opensourceontwikkelsoftware, heeft een integrated development environment gebouwd die geheel in de browser draait. Het tot Orion gedoopte project zou vooral nuttig zijn voor webontwikkelaars.

Volgens de Eclipse Foundation is Orion geen port van de Eclipse-ide naar een webinterface, maar een geheel nieuw project met eigen codebase. Orion draait op een webserver als een java-applicatie, terwijl de editor als client in de webbrowser op javascript draait. Een Orion-ontwikkelaar doet dus al zijn werk in de browser.

De Orion-ide richt zich vooral op webontwikkelaars, waarbij de editor javascript grotendeels ondersteunt. In toekomstige versies moet er ook ondersteuning komen voor html, php en java. Ook kan de ide volgens de Eclipse Foundation goed worden gecombineerd met developmenttools als Firebug en JSLint. Daarnaast zou Orion overweg kunnen met de bestaande plug-in voor Eclipse.

Orion is gratis te downloaden. Ook is een wiki beschikbaar. Verder wil de Eclicpse Foundation ook partijen interesseren voor het aanbieden van Orion als hosted service.

Reacties (26)

[mr_greenguy]

Leuk project maar ik zie de voordelen niet echt tegenover de gewone eclipse vermits deze al zeer draagbaar is.

[dsdevries]

Als je ooit serieuze grote (web)apps heb gebouwt met Eclipse dan weet je wat de voordelen zijn. Wanneer je eenmaal een goede eclipse build hebt samen gesteld met al de juiste j2ee, svn, maven, etc plugins dan is het gelijk zo traag als dikke stront! Opstarten, compilen, deployen, alles duurt seconden, zo niet minuten in Eclipse. Of je moet een dijk van computer hebben, maar meestal heeft een opdrachtgever daar niet zo'n zin in. Cloudcomputing is zeker met dit soort taken een uitkomst!

[Apache]

Dan doe je iets verkeerd, java compiler in eclipse is incrementeel, je duwt ctrl-s en je file is gesaved en gecompileerd.

Je deploy's kunnen ook incrementeel, je moet alleen een app server hebben die mee wil.

Al met al vind ik het een fijne ervaring om in eclipse te devven, natuurlijk is een stevige workstation een groot voordeel (en die heb ik momenteel ook niet) maar ze hebben wel hun best gedaan om alles zo efficient mogelijk te maken.

[dsdevries]

De java compiler is idd een mooi stukje software. Dat neemt echter niet weg dat het deployen van een redelijk J2EE project met wat Spring, Hibernate, Struts, jsp, jdbc, etc naar bijvoorbeeld een tomcat webcontainer toch een behoorlijk intensieve taak is die zelfs op krachtige workstations behoorlijk wat tijd in beslag kan nemen. Zeker wanneer je dependancy management tools als maven gebruikt. En vaak is het deployen en runnen in je browser de enige manier om te testen hoe een webapp zich gedraagt. Daarnaast is 3 van zulke project tegelijkertijd in je workspace is ook nog eens een behoorlijke recource hog (700+ mb ram voor alleen Eclipse is eerder regel dan uitzondering).

Darnaast neemt ook het updaten en committen van code via svn of cvs behoorlijk wat tijd in beslag. Dit zou ook opgelost kunnen worden door rechtstreeks vanaf de cloud te werken. Committen zou dan enkel het toevoegen van een commit tag betekenen.

[YopY]

Ik zou ook niet gelijk zeggen dat er voordelen zijn (of moeten zijn), maar dat dit juist inspringt op de huidige tendens van web applicaties. Denk Chrome OS, denk netbooks, denk tablets, allerlei apparaten waarbij Eclipse net iets te zwaar is of waar die niet op geinstalleerd staat.

[Deddiekoel]

Ben benieuwd of Google deze IDE gaat aanbieden for hun AppEngine. Lijkt me een logische stap voor ze.

[-DarkShadow-]

Dat lijkt me niet. Nu dien je offline te ontwikkelen met behulp van de SDK en de ontwikkelde applicatie in een ZIP-file te uploaden naar AppEngine. Daarna kun je de nieuwste versie met één click activeren in je productieomgeving. Om een online IDE aan te bieden voor AppEngine zou Google ook source control moeten integreren met AE en een online testomgeving ter beschikking moeten stellen. Anders moet je aangepaste code direct in productie zonder getest te worden.

[Reactie gewijzigd door -DarkShadow- op 10 augustus 2024 12:16]

[Verwijderd]

Ik gebruik daar Bespin voor (van Mozilla).
Een online editor met ondersteuning voor meerdere talen, meerdere developers en met één klik geupload naar je eigen server.

Heb voorheen wel met Eclipse gewerkt (nu alleen nog voor Android, omdat het "moet"), maar echt super vind ik het niet. Met name het hele plugin/module systeem is erg vervelend en word snel traag wanneer je met meerdere talen werkt.

Geef mij maar Kladblok, werkt het snelst

[Ruudjah]

Eindelijk.

Veel devvers gebruiken al VNC om op een server te devven. Dat schiet tenminste op bij grote projecten: je kan SSD array's en 8/16 cores delen met je mededevvers. En aanspraak maken op brute processing/IO power wanneer nodig. Met Guacamole kan je al in je browser devven zonder desktop/laptop limitaties.

Veel devtaken doe je tegenwoordig al in de browser: github, issue tracking, wiki, etcetera. Het is dan ook niet meer dan logisch om ook de IDE naar de browser te verkassen. Deze gedachte heeft wat tijd gekost om bij ij door te dringen. Immers, een IDE is per definitie zwaar, omdat je je te ontwikkelen software erin runt, en daarnaast nog de ontwikkelomgeving. Internet Explorer die on the fly javascript interpreteert geeft je het idee dat je teruggaat naar en 486. Maar tegenwoordig hebben we performante browser virtual machines, waar vooral Google's v8 veel aan bij heeft gedragen. Ik voel voor veel apps/sites/pagina's geen verschil meer met native apps. Sterker nog: sommige apps voelen veel sneller aan in de browser. Een snelle javascript engine, hardware accelerated graphics en correcte asynchrone handling van de UI dragen hier vooral aan bij.

Wat een IDE in de browser nu echt superkrachtig maakt, is dat je alle andere apps op het web erin kan integreren. De meeste webapps zijn nog jong, maar geef het wat tijd en de functionaliteit van desktop apps word ingehaald. Neem svg-edit, Balsamiq, WebSequenceDiagrams, JSLint, CanvasPaint, of als je even rondgoogled kan je nog honderden vinden. Die krijgen we allemaal 'gratis' in deze webbased IDE. Stel het je voor dat je een file wil editen, er opent zich een nieuwe tab, je edit wat, je klikt "save", en een nieuwe versie zit direct in het VCS. Geen gedoe met apps installeren, configureren, of eerst een VM voor het juiste OS openen: al die schitterende apps zijn slechts 1 muisklik van je vandaan.

Als je nu FOSS maakt, dan wordt het nog leuker. Dan kan je apps gebruiken die automagisch metrieken toepassen. Niks eerst Eclipse plugin installeren en uitvissen hoe die UI werkt, gewoon 1 klik en direct in een webapp al de metrieken op de code zien. Da's lastiger als je niet FOSS hebt, dan kan je geen hosted services gebruiken (of je moet eerst licenties/EULA's doorspitten, en is je 1-klik voordeel weg).

[Verwijderd]

Wat een flauwekul: "Webapps gaan desktop applicaties inhalen". Waar haal je dat vandaan? Dat is net zoiets als roepen dat C/C++ gaat verdwijnen omdat we in de toekomst al onze besturingssystemen met Java gaan ontwikkelen. Laten we eerlijk zijn, Android komt het meeste in de buurt van een Java OS, maar de basis blijft een Linux kernel geschreven in C, waar zelfs nog gedeeltes assembly in terug te vinden zijn. Ik heb geen zin om al je voorbeelden af te gaan, maar om eventjes CanvasPaint te nemen: Dat zou dus een kloon moeten zijn van MSPaint een applicatie die al in Windows 3.11 zat. Ik zou zeggen veel plezier met de performance van CanvasPaint op een Dx486 66 MHz, met MSPaint viel destijds iig nog aardig te werken op zulke machines. Ook zag ik laatst een kloon van mario brothers in de browser, helaas moest ik alweer vaststellen dat het scrollen van de map gewoon niet soepel liep (ik dacht met weemoed weer terug naar de C64 die dat zonder problemen voor elkaar kreeg) Ik kan dan ook niks anders concluderen dat de performance van het web-framework voor bepaalde taken gewoonweg echt nog onvoldoende is. En ik beschouw het implementeren van een IDE als 1 van die taken.

Het compleet implementeren van Eclipse is namenlijk niet alleen een kwestie van text editeerbaar te maken, maar er zal tevens een parser en een indexer op de achtergrond moeten draaien. Bij grote projecten kan de indexer leiden tot een enorme grote hoeveelheid data (de normale Eclipse neemt niet voor niets zoveel geheugen) en is er waarschijnlijk zelfs schijfruimte nodig om bepaalde geindexeerde info in op te slaan. En dit moet dan allemaal natuurlijk wel het liefst in een aantal achtergrond threads lopen. Als ik naar Javascript kijk is er volgens mij geen geschikt support voor threads (ten minste de laatste keer dat ik er naar keek. Ik kan mij voorstellen dat ze het er ondertussen hebben 'ingeprutst', maar dat geeft direct al de status van de programeertaal aan: onaf, maar al in produktie). Ook kan ik mij niet voorstellen dat de performance van Javascript hoger ligt dan die van Java (even een paar benchmarks: http://shootout.alioth.de...st=all&lang=v8&lang2=java en daar wil ik graag de conclusie aan verbinden dat Java gemiddeld een factor 10 sneller is dan de V8 JavaScript engine van Google). Ik persoonlijk heb geen zin in wachten bij het programmeren op de oertrage parsers/indexers die op de achtergrond draaien. Ook zie ik het nut niet in om de parsers/indexers op de servers van de Eclipse Foundation te hebben draaien. Het is dan een kwestie van wachten tot er geld wordt gevraagd of dat er reclame verschijnt in je IDE..

BTW: je voorstelling van CVS icm werken in een team is ook een beetje komisch. Jij zou het dus prettig vinden om code automatisch in te checken in CVS bij het klikken van 'Save' zonder dat je het überhaupt gecompileerd hebt !

[Ruudjah]

"Webapps gaan desktop applicaties inhalen"

Om mezelf te quoten:

De meeste webapps zijn nog jong, maar geef het wat tijd en de functionaliteit van desktop apps word ingehaald.

Je quote me verkeerd, afgezien nog van het feit dat je mijn quote uit context trekt. Daarnaast ga je volledig in op performantie, waar ik het over functionaliteit heb. Mijn bovenstaande relaas over performantie gaat over het goed werken van webapps in de browser. Dat is redelijk nieuw, we hebben nooit snelle browsers gehad [die zich ook nog eens behoorlijk aan standaarden houden].
Sommige webapps halen qua functionaliteit al desktop apps in. Neem GitHub: alle andere git GUI implementaties zijn slechts in alpha status, en halen het bij lange na niet bij de funcitonaliteit die Github biedt.

Het compleet implementeren van Eclipse is namenlijk niet alleen een kwestie van text editeerbaar te maken, maar er zal tevens een parser en een indexer op de achtergrond moeten draaien.

Dat hangt ervan af hoe je "compleet implementeren van Eclipse" ziet. Zoals ik in mijn tweede alinea al aangaf, is het al mogelijk om full-fledged Eclipse in de browser te gebruiken, zonder enige plugin. Je werkt dan met remote desktop via het VNC protocoll.
Je hoeft niet de complete engine te porten naar javascript. Je kan immers veel logica gewoon op de server draaien. Laat dat nu net het gehele voordeel zijn, en de kern van het internet: het netwerk-effect.

Als ik naar Javascript kijk is er volgens mij geen geschikt support voor threads

Dan ben je inderdaad niet goed ingelicht: lees wat John Resig ervan zegt. Niet helemaal threads, maar zeker een goed alternatief in veel gevallen.

Jouw betoog faalt omdat je de assumptie maakt dat de gehele engine in javascript moet worden geimplementeerd. Dat hoeft niet; je kan gewoon serverside compilen en het resultaat naar de browser sturen. Dat werkt nog sneller dan je IDE draaien op je laptop/workstation: een server heeft al vrij snel *veel* meer resources tot zijn beschikking dan jouw workstation.

In je laatste alinea lees je weer niet goed: ik heb het over een versiebeheersysteem (VCS=Version Control System), niet over de implementatie CVS. Daarnaast maak je de assumptie dat code niet gecompileerd is voordat je het commit naar een VCS. Het zou prima kunnen dat de app die bepaalde functionaliteit implementeerd/biedt dat gewoon doet. Afgezien nog van dat het in veel gevallen prima is om code te submitten die niet gecompileerd is.

[Reactie gewijzigd door Ruudjah op 10 augustus 2024 12:16]

[Verwijderd]

Webapps gaan bepaalde desktop applicaties inhalen

Was misschien wat duidelijker geweest. Ik ben ervan overtuigd dat een aantal applicaties goed zijn te programmeren als Webapps. Ik gebruik al jaren web-based mail-clients. Een simpel document creeeren wil ik ook nog best geloven kwa webapp (alhoewel ik toch liever zelf de regie over mijn documenten in handen heb). Maar verwacht echt niet dat software zoals: AutoCad, PhotoShop, IDEs met de huidige generatie browsers goed te implementeren zijn. En bij vele zaken zou je jezelf ook kunnen afvragen: is het wel geimplementeerd in de browser of is de browser gewoon uitgebreid. Over 50 jaar is er vast wel iemand zo gek om een video-encoder te schrijven in Javascript, maar tot dan toe ben je afhankelijk van wat de browser-bouwers jou als programmeur aanbieden (en dat is op dit moment flash, WebM, H.264). Ook 3D ondersteuning in Browsers is natuurlijk een wassen neus; Je kunt als programmeur een model en textures naar de browser sturen en zeggen: "teken dit maar voor mij", als je meer wilt zul je moeten gaan wachten op de brouwser bouwers of je toch echt gaan verdiepen in een wat performantere taal.

Je VNC voorbeeld is natuurlijk prachtig, maar VNC is geen web-browser en als het al in de browser draait dan is het een plugin. Voor de rest is in een dergelijk geval het probleem alleen verschoven van de desktop naar de server. IPV een goede desktop neer te zetten kun je volstaan met een zeer eenvoudige machine van 200-300 en een goede server van 2000-3000 euro (ik vergeet eventjes de extra investering in het netwerk). Je kunt dan met zijn 4 nog enigszins werken. In plaats van een dergelijke opstelling had je echter ook kunnen kiezen voor 4 stevige desktops a 600-700 euro per stuk dan zit je op een zelfde bedrag. Ik persoonlijk zou eerder voor de laatste opstelling kiezen.

Zoals ik bovendien al zei: threads zouden er ondertussen alwel ingeprutst kunnen zijn. En dat klopt blijkbaar, maar ik mis toch ondersteuning in de taal zelf: Java was met zijn synchronized blocks (afgezien van de initieel buggy implemetering van Sun) een stap voorruit t.o.v C/C++. Van een redelijk nieuwe taal zoals Javascript zou toch verwacht mogen worden dat ze weer een stap voorwaarts doen, maar ipv voorruit gaan ze letterlijk een stap achteruit. Synchronized blocks bestaan gewoon niet, uit de opgestuurde link kan ik een message-queue herkennen, maar ik mis oa: semaphores, atomic values, locks.

[quote]Jouw betoog faalt omdat je de assumptie maakt dat de gehele engine in javascript moet worden geimplementeerd.[/quot]

Mijn betoog valt helemaal niet. Ik heb even naar het project gekeken en er wordt inderdaad een server geimplementeerd te worden. Het blijft een client/server applicatie, waarbij de client verheven is tot een domme presentatie laag. Als je naar de huidige Eclipse kijkt dan zul je zien dat eclipse bovenop SWT (Java) gebouwd is, dat weer bovenop GTK(C) gebouwd is, dat weer bovenop GDK gebouwd is dat weer bovenop X11 gebouwd is (iig op Linux). X11 is in prinicipe al client server, er worden mooie binaire pakketjes over het netwerk gestuurd (BTW: Ubuntu heeft plannen om X11 te vervangen door Wayland server en volgens mij mede door de verdacht van het vertragen door deze client/server benadering). Bij een Webclient is de opbouw vergelijkbaar, maar ipv binaire data wordt er XML/HTML/Javascript in UTF8/ASCII heen en weer gestuurd waarbij de client en server voortdurend bezig zijn met vertalen. De SWT laag kun je dan nog weer vervangen door een Javascript laag en je hebt de absolute totale CPU-cycle verslindende applicatie gebakken. Ik zie bovendien in een thuis situatie helemaal niet in waarom ik een client/server applicatie moet installeren als het ook in 1 applicatie kan.

Dat werkt nog sneller dan je IDE draaien op je laptop/workstation: een server heeft al vrij snel *veel* meer resources tot zijn beschikking dan jouw workstation.

Dat wil ik best geloven, maar zou je ook even naar de prijskaartjes willen kijken !

Afgezien nog van dat het in veel gevallen prima is om code te submitten die niet gecompileerd is.

Een redelijk gevaarlijke uitspraak zou ik zo zeggen.

[Ruudjah]

Webapps gaan bepaalde desktop applicaties inhalen

Wie of wat quote je nu? Mij? Jezelf?

Maar verwacht echt niet dat software zoals: AutoCad, PhotoShop, IDEs met de huidige generatie browsers goed te implementeren zijn.

Waarom niet? Een browser hoeft in principe alleen maar een UI te bieden. Het gehele object model hoeft niet per se in de browser geladen te worden, dat kan ook voor een groot gedeelte op de server blijven.

Als je niet gelooft dat "zware" software in de browser kan: Quake in je browser. Da's een voorbeeld waarbij ook het gehele object model leeft in je js virtual machine.

en als het al in de browser draait dan is het een plugin.

Als je even op de Guacamole link had geklikt, had je kunnen lezen dat Guacamole werkt met een WebSocket proxy. En vervolgens de input tekent op een canvas element. Niks plugin dus. Allemaal 100% html/javascript.

Ook 3D ondersteuning in Browsers is natuurlijk een wassen neus; Je kunt als programmeur een model en textures naar de browser sturen en zeggen: "teken dit maar voor mij", als je meer wilt zul je moeten gaan wachten op de brouwser bouwers of je toch echt gaan verdiepen in een wat performantere taal.

Ooit gehoord van WebGL? Webkit (Chrome, Safari) ondersteunt het al, Opera is bezig en Firefox heeft ook al builds die een aardig eind op weg zijn.

4e alinea

Eclipse Orion levert een headless Eclipse met daarop een 'schone' js/html implementatie voor de UI. Niks swt/x11/gtk/gdk.

Ik zie bovendien in een thuis situatie helemaal niet in waarom ik een client/server applicatie moet installeren als het ook in 1 applicatie kan.

Ik wel. Een 16-core server die 1mW idled maar mijn code razendsnel kan compilen lijkt me wel wat. En dan met een webapp in 1 click code kunnen delen met de rest van de wereld via een webinterface. Of samenwerken met vrienden/kennissen/familie.

Een redelijk gevaarlijke uitspraak zou ik zo zeggen.

Neuh. Genoeg dsl's die geen compilatie vereisen of zelfs geen compiler hebben. Succes met het compilen van je svg code. Of je html.

[Reactie gewijzigd door Ruudjah op 10 augustus 2024 12:16]

[Verwijderd]

HAHA we kunnen het niet echt eens worden met elkaar ...

Waarom niet? Een browser hoeft in principe alleen maar een UI te bieden. Het gehele object model hoeft niet per se in de browser geladen te worden, dat kan ook voor een groot gedeelte op de server blijven.

Ik herhaal het nog een keer: DEs met de huidige generatie browsers goed te implementeren zijn.. Ik zei niet dat het niet mogelijk was. Ik heb duidelijk aangegeven dat er over 50 jaar waarschijnlijk decoders geschreven zullen zijn in Javascript en over 10 jaar geloof ik best dat de huidige versie van PhotoShop, AutoCad of Eclipse te programeren valt in browsers mbv Javascript. Ik twijfel alleen of de energie die er in gestoken wordt zich loont.

Quake in de browser heb ik al gezien. Zoals ik al vermeld had; het render gedeelte wordt door OpenGL (lees WebGL) afgedekt, Javascript stuurt het alleen aan. Niks extreem complexe Javascript code. Op de eigenlijke vraag 'schrijf ik een web-based app of een desktop app' kan ik in dit geval alleen maar antwoorden: waarom is de miljarden game inudstrie nog steeds niet massaal op web-based games gesprongen ?

Eclipse Orion levert een headless Eclipse met daarop een 'schone' js/html implementatie voor de UI. Niks swt/x11/gtk/gdk.

Wel even de echte stack opsommen: op de server: web-server/Eclipse-orion. Op de thin-client: X11/GDK/GTK/FireFox(of Chrome, ...)/Javascript/Eclipse-orion-client.

Een 16-core server die 1mW idled

1 mW of 1 MW ? Ik twijfel een beetje aan een 1 mW 16 core idle processor. Verder nog wel even meerekenen de switch en de thin-desktop clients.

Genoeg dsl's die geen compilatie vereisen of zelfs geen compiler hebben.

Hier kan ik gewoon niet serieus op ingaan.

[ari3]

Hoe kan dit handig zijn als het geen 1:1 poort van Eclipse is? Zoals ik het zie ik het gewoon een soort HTML-editor in JavaScript die alleen voor statische websites werkt. En juist die editor functionaliteit is er wel voor de meeste browsers.

Op het moment dat je iets moet ontwikkelen met JSF2 en een J2EE app server lijkt me dit tamelijk nutteloos.

[chewie]

Volgens mij is het dus juist niet voor statische websites. Het doet mij eerder een beetje denken aan General Interface van TIBCO. Dit is ook een javascript gebaseerde IDE, draait ook volledig in de browser en kan ook gebruikt worden om dynamische websites te maken (er zit bv. een hele hendige mapper in om webservices aan te roepen).

Ben benieuwd hoe ver Orion gaat. Als het straks java en php gaat ondersteunen dan wordt het wel interessant.

[Herjan]

Ik gebruik nu zelf al een tijdje de Cloud9 IDE i.c.m. Node.js, en ik moet zeggen dat het erg prettig werkt om in-browser te ontwikkelen. Ik ben dus zeer benieuwd naar Orion!

[mcmd]

Het lijkt me onvergelijkbaar met elkaar, toepasbaar in verschillende situaties, waarbij iedere oplossing zijn eigen voor en nadelen heeft.

[Wolfos]

Aangezien Eclipse de officieel ondersteunde ontwikkelomgeving is voor Android apps, lijkt het me zeer waarschijnlijk dat dit voor Chrome OS bedoelt is.

[grimlock]

Ben benieuwd wat IBM gaat doen omdat ze deze omgeving ook gebruiken voor hun Lotus producten. Een full webbased LN Basic client lijkt me wel heel interessant.

[divvid]

Als dagelijkse gebruiker van Eclipse vraag ik me af of we hier op zitten te wachten. Waar we wel met z'n allen op wachten is een dikke performance boost van het hele Eclipse platform. Laat ze daar hun tijd aan besteden.

[Ruudjah]

Waar we wel met z'n allen op wachten is een dikke performance boost van het hele Eclipse platform.

Dat is precies wat je kan krijgen als je Eclipse op de server draait en je het controleert door middel van een webapp. Granted, er is misschien geen efficientie verbetering in de uitvoering van de Eclipse engine code. Maar je kan wel een server aan het werk zetten die wat meer resources tot zijn beschikking heeft dan je telefoon/taptop/ipad/whereever je mee eclipse'd.

[TheNephilim]

Heb geen goede ervaringen met het hele Eclipse gebeuren! Gewoon even simpel een FTP foldertje toevoegen is al te veel gevraagd. Waardeloos...

[Ruudjah]

FTP bij software ontwikkeling? You're doing it wrong.

[Reactie gewijzigd door Ruudjah op 10 augustus 2024 12:16]

[Florisjuh]

Niet verkeerd, maar anders. En dat Eclipse niet deze andere manier van werken ondersteund is ook niet erg want Eclipse hoeft niet een alleskunner te zijn. Overigens kan er natuurlijk wel heel veel met Eclipse en haar plugins.