Adobe doneert Flex-framework aan Apache

Adobe doneert het Flex-framework voor het bouwen van Flash- en Air-applicaties aan Apache. Hoewel de sdk voortaan als zelfstandig project bij de stichting door het leven zou gaan, laat Adobe weten dat het nog steeds Flex blijft ondersteunen.

Adobe gaat zich met name op de ontwikkeling van html5 richten. De technologie zou op lange termijn beter voor zakelijke doeleinden geschikt zijn en een veelvoud aan platformen ondersteuning. Flex zou daarentegen beter geschikt zijn voor desktop-applicaties, schrijft Adobe in een blogpost.

Het framework wordt bij Apache als zelfstandig project ondergebracht. Behalve Flex doneert Adobe ook andere componenten, waarvan BlazeDS de belangrijkste is. Met de software kan data tussen een Flex-applicatie en de Java-backend worden verstuurd. Daarnaast brengt Adobe de Falcon JS-compiler onder een opensourcelicentie uit. Daarmee zouden bestaande Flex-applicaties kunnen worden geport naar html.

De broncode van Flex werd in 2008 al vrijgegeven. Sinds die tijd hebben ontwikkelaars voornamelijk bugs blootgelegd. Met de donatie aan de Apache-stichting zal de community naar verluidt ook zelf nieuwe features aandragen. Dat wil echter niet zeggen dat Adobe definitief afscheid neemt van het project. Het bedrijf belooft nog jaren contributies te verrichten aan de codebase. Hoe dat precies gaat plaatsvinden, is nog onduidelijk. De aankomende weken maakt Adobe meer bekend over het precieze vervolg.

Reacties (35)

[Verwijderd]

HTML5 is not steeds niet klaar voor het gebruik van webcams en dergelijke.

Dat dit op deze manier gepusht wordt door eigenlijk Apple is jammer want het heeft geen zin om je app nu nog in Flash te bouwen en HTML5 ondersteunt dat nog niet.

We krijgen dus enige terugval in ontwikkeling de aankomende tijd.

Dit is overigens wel een mooie: http://active.tutsplus.co...%E2%80%99t-do-with-html5/

[Reactie gewijzigd door Verwijderd op 4 augustus 2024 22:52]

[Bauknecht]

Die link is zever. Kijk, HTML5 is jong, en we zijn gebonden aan legacy browsers tot XP verdwenen is. Maar elk van die dingen die gesteld worden, zullen binnen afzienbare tijd mogelijk zijn of zijn gewoon compleet irrelevant (3D transformaties op video: zucht...)

1. HTML 5 can’t interact with a webcam.
3. HTML5 cannot record audio from your microphone.
4. HTML5 cannot do any sort of web conferencing.
6. HTML5 cannot record from your webcam.
=> Komen allemaal op hetzelfde neer: een interface naar hardwareinputs. HTML5 zal dit wel degelijk voorzien op termijn: http://www.w3.org/TR/html-media-capture/

2. HTML5 video cannot be used on a 3D plane.
=> is geen fundamentele beperking, is een kwestie van tijd. ter info 2D transform lukt al perfect. Zie http://beta.theexpressiveweb.com/#!/html5-video. En dan zou ik nu graag een voorbeeld hebben van een real-life voorbeeld van 3D-getransformeerde video.

5. HTML5 cannot add dynamic objects to go over the video, like captions, titles, or navigational items.
Versta ik al helemaal niet. Graag zou ik een uitleg hebben wat de moeilijkheid is van een DIV over je video te overlayen met info. Die stelling is gewoon pertinent fout getuigd van een gebrek aan kennis omtrent HTML.

7. HTML5 cannot create desktop apps.
Gmail, Google Docs en Windows 8 anyone Stelling die weer getuigd van een gebrek aan kennis omtrent HTML5.

8. HTML5 can’t handle video with alpha channels.
Het voorbeeld dat onder dit kopje staat is al niet meer relevant want dat kan je perfect met een canvas. Los daarvan: graag een real life voorbeeld met transparante video?

9. HTML5 doesn’t yet support Peer-2-Peer.
"While P2P is in the HTML5 spec" Then we're through zeker? Next!

10. HTML5 Doesn’t do Full Screen Mode.
Ligt dat aan HTML5? Neen he. Hint: druk eens F11 in je browser

[Ventis]

True, sommige van de beperkingen zullen op termijn wel voorzien worden. Maar je kiest toch niet voor een applicatie te maken in een bepaalde technologie op basis van features die "mogelijk op termijn" zullen geïmplementeerd worden. Als je die functionaliteiten nu nodig hebt, dan moet je gekozen technologie die ook nu ondersteunen.

7. Maar hangt telkens af van hoe men kiest HTML5 te implementeren. Zou jij graag 3 verschillende versies van je applicatie maken voor bv iOS, Windows 8 en OSX? Een runtime zoals de AIR runtime biedt dezelfde implementatie op alle platformen.

8. Voorbeelden genoeg op het internet van iemand die doorheen een website/applicatie wandelt om er uitleg over te geven = video with alpha channels.

10. Flash kan bv. in fullscreen draaien zonder dat je browser in fullscreen modus draait. Ik denk dat men dat bedoelt.

[Reactie gewijzigd door Ventis op 4 augustus 2024 22:52]

[sfranken]

Puntje zeven klopt niet in je redenatie. Het is een standaard en word dus altijd op (ongeveer) dezelfde manier ingebouwd. Het is voor een appbouwer dus niet belangrijk om 3 versies te bouwen zolang je maar een browser (of browser part zoals in KDE) tot je beschikkig hebt en met een HTML5 app mag je ervan uitgaan dat dat het geval is.

[Ventis]

Een standaard wil nog niet zeggen dat de implementatie ervan overal hetzelfde is. HTML4 is ook een standaard en die geeft toch soms andere resultaten in verschillende browsers.

Om nu een heel banaal vb. te geven: moest Microsoft morgen beslissen om een HTML5 Canvas op Windows 8 standaard altijd met een rode border te renderen, dan zou je in je Windows 8 versie van je app aanpassingen moeten maken om deze te verwijderen.

Een canvas blijft een canvas, op alle platformen, maar het is het platform dat beslist hoe een canvas tag geïnterpreteerd en gerendered wordt.

In praktijk zal dit soort voorvallen natuurlijk beperkt blijven, maar het gevaar blijft bestaan.

[Bauknecht]

Een standaard wil nog niet zeggen dat de implementatie ervan overal hetzelfde is.

Implementatie interesseert dan ook niemand. Zolang de syntax en resulterende uitvoer maar keihard vastliggen, of dat nu via OpenGL, Cairo of wat dan ook is.

HTML4 is ook een standaard en die geeft toch soms andere resultaten in verschillende browsers.

Dat ligt dan aan browsers die die standaard niet volgen, quirks modi en andere troep. Dezelfde correcte HTML4 Strict pagina in FF, Chrome, IE9 en Opera zal er quasi pixelperfect identiek uitzien.

Om nu een heel banaal vb. te geven: moest Microsoft morgen beslissen om een HTML5 Canvas op Windows 8 standaard altijd met een rode border te renderen, dan zou je in je Windows 8 versie van je app aanpassingen moeten maken om deze te verwijderen. Een canvas blijft een canvas, op alle platformen, maar het is het platform dat beslist hoe een canvas tag geïnterpreteerd en gerendered wordt.

Neen neen neen, de standaard legt juist vast hoe die tag geïnterpreteerd moet worden. Hoe je die rendert is jouw zaak, maar de standaard bepaalt hoe de syntax is, en wat eruit komt.

[Reactie gewijzigd door Bauknecht op 4 augustus 2024 22:52]

[Sando]

Een runtime zoals de AIR runtime biedt dezelfde implementatie op alle platformen.

Ik weet totaal niet waar de klepel hangt, maar ik dacht dat AIR een soort Flash in een virtuele machine was, zoals Java, Mono, etc ook afhankelijk zijn van een klont software die de vertaalslag tussen de code en het platform doet.

Hoe ver zit ik er naast?

Want dit klopt vast niet, waarom zou Apple anders geen Flash player maar wel AIR 'player' ondersteunen?

[BernardV]

Dat doet het ook niet. Als je in Flash Builder een app schrijft voor mobieltjes draait het op de AIR runtime als het Android of BB is. Ga je voor iOS wordt het alsnog naar ARM instructies omgezet door een LLVM compiler die adobe heeft geregeld. Dus iOS heeft geen AIR runtime.

[Sando]

@bernardV thanks for the info. Dat klinkt wel alsof hij voor iOS veel optimaler compileert. Ik heb voor Android ook liever ARM instructies.Net ook afhankelijk zijn van dan AIR runtime instructies. Alsof je voor iOS met C++ werkt en voor Android/BB met VisualBasic, om maar even een half acceptabele vergelijking te maken.

Als ze zo goed zijn met rechtstreeks compileren, is die AIR runtime dan niet obsolete aan het worden?

[Dreamvoid]

Hangt er helemaal van af hoe goed die compiler is. Maar het grote voordeel van Air is dat het platform onafhankelijk is, "write once run anywhere". Als je voor iOS specifiek gaat compileren moet je op elke iOS versie weer testen of het allemaal nog werkt. Da's nou eenmaal het inherente nadeel van native.

[Brawler1986]

Duik maar eens in de boeken van O'Reilly over HTML5 en JavaScript. Dan klaag je wel anders. HTML5 is nog jong. 3D is na enige tijd ook beschikbaar. Het nadeel is dat niet iedereen nog de juiste browser versie heeft om HTML5 te kunnen tonen. Maar dat gaat echt wel veranderen naarmate er meer ontwikkeld wordt voor HTML5. Waar ik me nog steeds aan erger is dat IE zo traag de Canvas en CSS3 heeft geimplementeerd. De meeste mensen gebruiken IE8. Maar daar zit nog geen enkele mogelijkheid in om HTML5 te implementeren. Er zijn verschillende alternatieven met JavaScript te vinden voor canvas, maar zijn niet zo flexibel als de echte canvas van HTML5. CSS3 idemdito.

Truth be told, Microsoft loopt gewoon mateloos achter wat betreft webstandarisatie en technologie.

OT: Ik ben blij dat Adobe zich realiseert dat preformance en cross-browser belangrijker is dan het framework zelf. Zo gaat Adobe niet meer door ontwikkelen met de Mobile Flash plugin. Maar stap over naar HTML5 omdat ze daar meer potentie inzien. Daarnaast gaan ze de focus meer leggen op het implementeren van 3D engines. Ze zijn nu namelijk bezig om de Unreal Engine te implementeren in de Flash Player 11.1. Dit brengt Flash tot een nog hoger niveau. Ook zijn ze al bezig om een soort gelijke Flash programmeer omgeving te maken voor HTML5. Dit programma gaat EDGE heten. Het is nog wel in Beta.

[Reactie gewijzigd door Brawler1986 op 4 augustus 2024 22:52]

[somatik]

Bij mijn weten is dit nog niet goedgekeurd door Apache zelf. De Apache Foundation wil geen vuilbak worden voor dode projecten... #codedump

[sambalbaj]

Dat zijn ze ondertussen eigenlijk inderdaad wel een beetje aan het worden.
Ook het door Oracle bij Apache gedumpte OpenOffice.org is trekken aan een dood paard.

Maar de bedrijven die het dumpen maken nog even goede sier met hun geweldige bijdrage en goedheid.

[marrs]

Toch even toelichten hoe Apache precies werkt, want het originele artikel doet dat niet heel duidelijk en er worden hier suggesties gewekt die niet geheel juist zijn.

Voordat een project een officieel (of in Apache termen "top level") project wordt, doorloopt het een aantal fasen:

Allereerst wordt er een voorstel geschreven voor het project. Hierin motiveert een project waarom het naar Apache wil, hoe men een actieve community denkt te ontwikkelen en hoe binnen die community diversiteit gewaarborgd is. Diversiteit betekent dat de mensen die meedoen niet allemaal bij één bedrijf mogen werken. In de praktijk is het niet zo ingewikkeld om zo'n voorstel te schrijven en Apache gaat altijd uit van de goede intenties van zo'n project.

Wanneer het voorstel wordt goedgekeurd, komt je project in de Apache Incubator. Dit is een soort kraamkamer voor nieuwe projecten. Je krijgt een (minimaal) een drietal mentoren toegewezen en je moet als project gaan werken volgens de Apache principes en aantonen dat je daadwerkelijk doet wat je belooft. Dat houdt onder andere in dat je die diversiteit aantoont en dat je laat zien dat je releases kunt maken.

Het is niet ongewoon voor een project om ergens tussen de 6 maanden en 2 jaar in die incubator te verblijven. Wanneer de mentoren het een goed moment achten, en aangetoond is dat het project naar behoren functioneert, krijg je de kans om uit de incubator te gaan. Dat kan door "top level" project te worden of, als je een logische uitbreiding bent op een bestaand project, als "sub project". De derde optie is dat het je niet lukt om aan deze eisen te voldoen, waarna op een gegeven moment besloten zal worden om het project te staken (waarna het je vrij staat om er elders mee verder te gaan).

Kortom: Projecten als OpenOffice en Wave zijn formeel helemaal nog geen Apache projecten, ze zitten in de incubator en moeten eerst nog maar bewijzen dat ze daar uit kunnen komen. Ook deze Adobe projecten zouden heel goed via een voorstel in de incubator terecht kunnen komen (wat overigens nog niet gebeurd is). Wat er daarna gebeurt en of er een community gaat ontstaan, moeten we rustig afwachten. Apache heeft in elk geval een mechanisme wat zich in het verleden bewezen heeft en wat ervoor moet zorgen dat er geen dode paarden in de lijst met officiële projecten terechtkomen.

[Reactie gewijzigd door marrs op 4 augustus 2024 22:52]

[zeduude]

d'r zijn anders nog velen die open office draaien hoor...

Flex is niet slecht, t mist alleen de GUI builder (zoals flash). Flash is dood, lang leve flash.... of html5 zodra die eindelijk overal wordt geaccepteerd en gebruikt (en html5 zal hopelijk wel helpen om de laatste IE6en uit te roeien)

[Zero Grav]

Zoals Adobe Catalyst en de Design Mode in Flash Builder bedoel je? Ze zijn er weldegelijk en vormen wel een vrij solide basis om mee te beginnen. Alleen zou Catalyst veel beter zijn als de support voor PSD files wat uitgebreid zou worden.

[Xenan]

Ik denk dat sambalbaj bedoelt dat OpenOffice is gedoneerd aan Apache en niet aan LibreOffice, wat natuurlijk netter zou zijn geweest. De meeste ontwikkelaars aan OpenOffice zijn overgestapt naar LibreOffice.

[-=bas=-]

Altijd nog beter dan dat ze gewoon de stekker eruit trekken en het in een duister datacentrum achterlaten.

[Ventis]

"Het einde van Flash" is al honderden keren aangekondigd en al honderden keren fout gebleken. Men heeft de verdere ontwikkeling van Flash Player voor mobile browsers stopgezet, puur en alleen omdat niemand dit gebruikte.

Nog nooit een klant tegen gekomen die specifiek een Flash applicatie wou targetten voor de mobile browser. Dan maak je gewoon een app. En dat is nog steeds VOOR ALLE PLATFORMEN mogelijk met Flash/Flex (door gebruik van de AIR runtime). En ook de Flash Player wordt nog gewoon verder ontwikkeld voor alle platformen (buiten mobile browsers).

Ik lees op m'n Android bv Tweakers nieuwsberichten altijd op Pulse ipv in de mobile browser. Pulse is trouwens ook een Adobe AIR app.

[Verwijderd]

En dat is nog steeds VOOR ALLE PLATFORMEN mogelijk met Flash/Flex (door gebruik van de AIR runtime).

Dat vind ik toch wat kort door de bocht. Ik zou eerder zeggen "Voor alle platformen die adobe (gedeeltelijk) ondersteunt". Ik denk eerlijk gezegd niet dat je flash werkend krijgt op bvb een linux-systeem met bvb powerpc-architectuur.

[OverSoft]

Hij heeft het over mobile platformen en ik ben nog geen mobiel platform tegen gekomen die op een PowerPC architectuur is gebouwd.

[sfranken]

Bovendien is Adobe niet de enige die Flash plugins voor browsers/mobiele platformen maakt he.

Even een voorbeeldje wat losjes hieraan gerelateerd is: ik heb hier een mac staan die nog op de PowerPC arch. gebaseerd is. er draait LFS (Linux From Scratch) op met FlashPlugin in firefox/chromium. En dat gaat perfect.

[Dreamvoid]

Ik denk dat het aantal desktop/mobile clients met een PPC Linux distributie niet eens boven de 0.1% uit komt. Waarschijnlijk zijn er nog meer clients die Windows 3.1 draaien...

[OverSoft]

Voor desktop prima, ik gebruik Flex al jaren. Maar voor mobiel vind ik het wel zonde. Ik gebruik nu Flash Builder om iOS, Android en Blackberry apps te bouwen, en ik denk dat dit niet bepaald de compabiliteit en ondersteuning van nieuwere versies van die OSsen gaat helpen. Jammer

[jelmert]

Mooi gebaar van Adobe om het framework aan de community te doneren. Ze hadden het ontwikkelen ook kunnen stoppen en het laten doodbloeden. Nu kunnen de liefhebbers zelf er nog mooi aan bijdragen als ze dit willen en nog een aantal jaren gebruiken voor het ontwikkelen van applicaties.

Ben benieuwd hoe actief de community updates gaat uitbrengen voor een platform wat best veel concurrentie heeft van andere platformen.

[Dreamvoid]

Net zoveel als voor JavaFX (wat door Oracle/Sun ook aan de community is geschonken nadat er zelf geen brood meer in zagen)? Of PalmOS aka "Access Linux Platform"?

[Verwijderd]

Mooi dat de sdk open source werd in 2008, maar toch geen hond die daar intrapt. Flash is en blijft propriëtaire technologie. Flash ondersteuning zal altijd blijven afhangen van de goodwill van Adobe.

[Dreamvoid]

Niet als het open source is dus.

[kozue]

Dus volgens jou kan ik nou m'n eigen flash plugin compileren? Denk het niet hoor. Niks open source aan, als je het afhankelijk maakt van proprietary technologie om het te kunnen gebruiken.

[Xenan]

Dat Adobe een codedump doet bij Apache betekent dat Steve Jobs alsnog zijn zin gaan krijgen: dit is het begin van het einde van Flash.

Natuurlijk zal Flash nog lang bestaan en er zal nog lange tijd in ontwikkeld worden, maar je zult zien dat Adobe er steeds minder tijd en moeite in zal steken en met meer en betere HTML5 tools zal uitkomen

[Wolfos]

Dit zat er al jaren aan te komen; Adobe laat Flash in de steek.

[defiler1974]

beetje kort door de bocht. Vooral de laatste ontwikkelingen in flash player 11 zijn zeer interessant. Hierdoor gaat de flashplayer beter 3d ondersteunen en fullscreen features zijn beter ondersteund. Voor spelletjesmakers is het nog steeds een interessant platform t.o.v. HTML5 waar alles nog opnieuw uitgevonden moet worden op spellen gebied.

[Dreamvoid]

Natuurlijk is het nog steeds een technisch interessant platform, maar ik zie de toekomst toch somber in. Het nu nog overal, maar hoe lang nog? iOS heeft geen Flash, en de Metro-versie van IE (wat op veel toekomstige tablets gaat draaien) ondersteunt ook geen browser plugins meer. En hoe lang nog blijft er een goede Flash plugin voor de toekomstige Android versies bestaan als Adobe er geen werk meer in steekt?

En mensen vergeten het belangrijkste: natuurlijk is Flash voor games beter dan HTML5, maar het concurreert niet met HTML5, maar met Android/iOS/WP7 games.

[Reactie gewijzigd door Dreamvoid op 4 augustus 2024 22:52]

[Apache]

Adobe is van plan net hetzelfde te doen als google met GWT doet.

HTML5 en javascript te gebruiken als platform met daarbovenop een ontwikkelingsmodel dat WEL werkt voor grote enterprise applicaties.

Dat ze daarvoor flex onderbrengen bij een onafhankelijke organisatie lijkt mij inderdaad een wijze beslissing, hun flash platform kan gewoon blijven bestaan en flex kan stilaan een eigen leven beginnen lijden.

De falcon-js compiler speelt hierbij een grote rol.

Flex doet hééél veel wat je op een pure html5/js omgeving gewoon nog niet hebt, namelijk rich components, geavanceerdere features als databinding, validation, remoting, datamanagement, etc.

Hopelijk laat deze split de sterke kanten wat opvallen en haalt het de focus dat het naar flash gecompileerd weg naar wat het allemaal bied aan developers/users. onafhankelijk van waar het naartoe gecompileerd word.