Microsoft stopt mogelijk met ontwikkeling Silverlight

Microsoft gaat volgens geruchten stoppen met zijn Flash-alternatief Silverlight. Bovendien zou de laatste grote release, versie 5 alleen maar werken met Internet Explorer en op Windows-systemen, en niet met andere browsers of op Mac OS X.

Het is onduidelijk waarom Microsoft zou willen stoppen met de ontwikkeling van Silverlight. De technologie zou wel in gebruik blijven als ontwikkeplatform voor rich-media applicaties en voor apps op Windows Phone 7, meldt Mary Jo Foley, een redactrice van ZDNet die fulltime schrijft over Microsoft en die in het verleden vaak als eerste ontwikkelingen bij Microsoft heeft gemeld.

De release zou volgens ZDNet alleen beschikbaar komen voor Windows-systemen. Daarnaast zouden naar verluidt behalve Internet Explorer andere browsers niet worden ondersteund. Microsoft liet vorig jaar al weten dat Silverlight alleen nog gepromoot zal gaan worden als ontwikkelruntime voor Windows Phone 7 en sommige toepassingen op het gebied van media en 'line of business-applicaties'.

De rtm-release van Silverlight 5 zal naar verwachting voor eind november verschijnen. Een van de belangrijkste vernieuwingen is de ondersteuning voor hardwarematige versnelling bij het afspelen van h.264-video's met behulp van de gpu. Ook worden 3d-graphics via de grafische processor afgehandeld, terwijl met de Trickplay-feature video's versneld kunnen worden zonder dat de audio-pitch wordt verstoord.

De softwarefabrikant gaf daarnaast al eerder aan dat het meer aandacht zou schenken aan html5 en andere aanverwante technologieën. Volgens Microsoft wordt html5 in hoog tempo door de software-industrie omarmd en is dit ook noodzakelijk om de diverse mobiele platformen goed te kunnen bedienen.

Adobe, de fabrikant van Silverlight-concurrent Flash, maakte woensdag bekend dat het gaat stoppen met het ondersteunen van Flash op mobieltjes. In plaats daarvan wil het bedrijf het voor ontwikkelaars van Flash-applicaties makkelijker maken om applicaties met de Adobe Air-runtime te maken. Hiermee moet het mogelijk worden om vanuit een enkele codebase apps voor verschillende platforms te schrijven.

Reacties (121)

[NicoJuicy]

Jammer....
Silverlight kon WebApplicaties perfect aanvullen, vooral dan in bedrijfsomgevingen...

Keyboard shortcuts, tabellen waardoor vlug genavigeerd kan worden en met vlugge input (tab tab tekst enter tab tab tekst enter control+n (nieuw) tab tab tekst tab tekst) , UI, animaties, ... bekijk maar eens http://pjd.mscui.net/default.htm dat ondertussen al 2-3 jaar oud is

Silverlight kan / kon echt veel

[Reactie gewijzigd door NicoJuicy op 23 juli 2024 03:35]

[Splinter Cell]

64 bits zou een mooie afsluiter zijn. Nu Flash ook eindelijk officieel 64 bits is.

[Whizzer191]

De release candidate is inmiddels beschikbaar in 64-bit en lijkt prima te werken. Wel een aparte installer, dus let op dat je de goede binnentrekt (of gewoon beiden).

[Splinter Cell]

Bedankt. Maar Uitzenddinggemist & RTLGemist doen moeilijk.

[Reactie gewijzigd door Splinter Cell op 23 juli 2024 03:35]

[Ertepeller]

Bedankt. Maar Uitzenddinggemist & RTLGemist doen moeilijk.

RTL zal nooit werken vanwege de DRM...
UitzendingGemist kun je ook met Flash bekijken, problem solved.

[mutley69]

Eigenlijk is dit pas schandalig - je gaat een systeem op pensioen sturen - moet je er dan niet voor zorgen dat het nog op zoveel mogelijk platformen kan blijven draaien - zodat je tenminste kan compatibel blijven met het verleden?

Het is jammer dat ik het moet zeggen - maar gesloten systemen, daar heeft men u altijd mee bij uw "edele onderdelen".

Zelfs met html5 zal u daar moeten voor oppassen. Hanteer misschien de volgende regel: als het niet werkt op een BSD + een linux - mot ik 't niet (zelfs al werk je zelf op apple, windows of wat dan ook).

Het spaart u achteraf bakken ellende - zelfs al blijft u op dat platform. Flash en SIlverlight bewijzen het!

[Dreamvoid]

1 detail alleen: Silverlight was niet gesloten. Het is door Microsoft uitgevonden, maar de specs zijn gewoon nog openbaar. Tot in de verre toekomst kan iedereen altijd nog een Silverlight client bouwen en de huidige applicaties draaien - ook al is Microsoft allang ermee gestopt. Dat is het voordeel van een open standaard.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[BeosBeing]

Ofwel, naar analogie van "De koning is dood, lang leve de (nieuwe) koning." nu
Silverlight is dood, lang leve Moonlight.
Nu nog een port van Moonlight voor Windows (al duurt het nog wel even voordat Moonlight zover is dat ze aan versie 5 van de Silverlight-specificatie zitten).

[Rhapsody]

Op de desktop heeft het met de ondersteunng van HTML5 ook weinig meer te zoeken. Zeker omdat je ook WPF kunt gebruiken voor het ontwikkelen van Windows Applicaties.

Wat betreft Windows Phone ben ik benieuwd wat de strategie dan zal zijn? Silverlight samenvoegen met WPF? Of daar op de lange termijn ook enkel HTML5 met JS api's ondersteunen?

[Reactie gewijzigd door Rhapsody op 23 juli 2024 03:35]

[koendenb]

Volgens mij snap jij er niet zo veel van.

er staat duidelijk in dat ze stoppen met Silverlight, hoezo zouden ze dit dan in de toekomst samenvoegen met WPF?

Het mooie van HTML5 is dat het op de telefoons en desktops hetzelfde kan uitvoeren.

[Rhapsody]

Er speelt al langer iets bij Microsoft m.b.t. Silverlight en WPF. Deze technologieen lijken voor een groot deel op elkaar.

Als de ontwikkeling van Silverlight op de desktop wordt gestaakt, dan kun je vraagtekens zetten bij de strategie van Microsoft op het gebied van Windows Phone, het andere vlak waar Silverlight wordt gebruikt. Gaan ze daar dan wel mee verder? Wordt het samengevoegd met (of vervangen door) WPF?

Volgens mij snap ik er meer van dan dat jij denkt :-)

[jecede]

precies hetzelfde vroeg ik me ook al af. Op zich lijkt het me niet onlogisch als ze Silverlight alleen op WP blijven ondersteunen. Al heb ik ook gehoord dat ze met windows 8 (of 9?) naar een meer hybride os willen waarbij dezelfde windows kernel gebruikt gaat worden op andere platformen zoals mobiele telefoons. Misschien dat ze dan gewoon WPF willen gaan gebruiken voor WP? En dan net zoals in feite Silverlight nu een subset van WPF is slechts gedeeltes van WPF ondersteunen wanneer er een WP project wordt aangemaakt?

[Dreamvoid]

Silverlight is in feite WPF-in-de-browser (ok, er zijn wat verschillen, maar grotendeels komt het overeen). Dat is zo goed als voorbij: exit Silverlight, alleen nog maar HTML in de browser. Maar buiten de browser, in de nieuwe Windows WinRT API, is het gewoon allemaal .NET, WPF en XAML als altijd.

Dus XAML (met alle mooie features) buiten de browser, HTML (met al zijn beperkingen) in de browser. Geen mix meer tussen de 2. En wat crossplatform development voor RIA's betreft: Microsoft steekt er geen moeite meer in. Wil je wat moois maken, schrijf maar een native app.

In feite net als op OS X/iOS, waar je alle fancy Cocoa goodies krijgt als je netjes native apps schrijft, terwijl Safari alleen maar HTML doet.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[BeosBeing]

Op de desktop heeft het met de ondersteunng van HTML5 ook weinig meer te zoeken. Zeker omdat je ook WPF kunt gebruiken voor het ontwikkelen van Windows Applicaties.

In tegenstelling tot Silverlight is WPF ook in principe Windows-only.

Silverlight is officiëel cross-platform, ook al ondersteunde Microsoft alleen haar eigen besturings-systemen en OS-X waardoor andere platforms afhankelijk zijn van de opensource variant, Moonlight, welke uiteraard niet anders kan als achterlopen.

Voor WPF is er in ieder geval geen alternatief op andere besturingssystemen. Hierdoor heeft WPF niets te zoeken in webapplicaties, hetgeen toch is waar je Silverlight (en Flash) nu het meeste tegenkomt.

Vooruitgang is goed, en daarom is WPF voor native Windows applicaties in principe niet verkeerd, al bemoeilijkt het wel het draaien van Windows applicaties in Wine (op Linux, FreeBSD, OpenSolaris/Illumos en OS-X) en ik heb begrepen dat het ook niet draait met Apple's Parallels Desktop). Misschien is dat ook precies wat Microsoft met deze stap beoogd.

[fredmatrack]

Goede zaak, op voorwaarde dat HTML5 gepusht gaat worden ten voordele van Silverlight (en flash). Belangrijk is dan wel dat HTML5 echt een standaard wordt die op alle browsers prima werkt. Dus ook voor video één standaard.

[Niemand_Anders]

Ik snap nog steeds niet waarom mensen zo graag maar een video standaard willen. Allereerst zouden later alsnog patent issues kunnen optreden (denk aan gif) en daarnaast zou je later nooit naar een beter formaat kunnen overgaan.

Het enigste wat ik hoor is dat H.264 een aantal patent issues heeft, maar dat heeft browsers nooit weerhouden om jpeg bestanden te ondersteunen..

De huidige HTML5 specificatie heeft daarvoor juist de source elementen:
[code]
<video poster="movie.jpg" controls>
<source src='movie.webm' type='video/webm; codecs="vp8.0, vorbis"'/>
<source src='movie.ogv' type='video/ogg; codecs="theora, vorbis"'/>
<source src='movie.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>
[/code]

Waarom werken [code] tags niet op de frontend?

[Reactie gewijzigd door Niemand_Anders op 23 juli 2024 03:35]

[Blokker_1999]

Omdat je bij een standaard je geen zorgen moet maken over het al dan niet afspeelbaar zijn van een video. Als er 1 codec als standaard word genomen dan kunnen browsermakers zelf voor de ondersteuning zorgen en ben je net van al dat gedoe met plugins en codecs van af.

Ook als content leverancier is het een heel pak eenvoudiger als je maar 1 formaat moet ondersteunen ipv 4 of 5 verschillende. Maar 1 keer coderen ipv 5 keer ...

[Terracotta]

En als er betere codecs ontstaan dan zit je technologie muurvast. De client operating systems kunnen tegenwoordig meer dan genoeg codecs aan, moet de browser maar zorgen dat hij het video element door het OS of een multimedia framework laat afspelen (zoals het in alle zinnige implementaties ook gedaan wordt).

[kmf]

Dat er ooit HTML3 is vastgelegd, betekent niet dat HTML4 nooit is gekomen.
Dat divx vroeger de de facto standaard is, betekent niet dat er nu geen andere codecs meer zijn.
Dat vroeger een parallel poort op elke computer zit, betekent niet dat usb niet kan doordringen.

De meest populaire codecs worden vast wel ondersteund. Maar dan moet dan ook aangetoond worden dat die codecs ook daadwerkelijk het ondersteunen waard zijn. (Jpeg2000 ben ik de afgelopen 10 jaar maar 1x tegengekomen)

[Mellow Jack]

Uuuuuhm H.264 word al niet native ondersteund door Android en iOS terwijl beide toch een groot deel van de gebruikers vertegenwoordigen

[Dreamvoid]

H.264 word al niet native ondersteund door Android en iOS

Uh, wel toch? Of is dit een spelfoutje?

[arjankoole]

[...]

Uh, wel toch? Of is dit een spelfoutje?

moet haast wel, want beiden ondersteunen H.264 inderdaad. Maar dat is OS support, dat wil niet onmiddellijk zeggen dat de browser dat doet.

[kmf]

Voor de gebruiker:

1 standaard betekent dat de kans groot is dat deze standaard hardware accelerated wordt/is en je deze dus op alle apparaten kan laten afspelen.

En voor de leverancier/beheerder:
1 formaat aanleveren betekent dat je minder diskruimte kwijt bent.

[BeosBeing]

Het enigste wat ik hoor is dat H.264 een aantal patent issues heeft, maar dat heeft browsers nooit weerhouden om jpeg bestanden te ondersteunen..

Het hangt er nogal vanaf wat voor licentievoorwaarden de patenthouder(s) hanteren.
De bekende patenten op h.264 liggen bij een firma die ook de licenties voor MPEG (2 en 4) en dusdanige voorwaarden hanteert dat deze prima zijn te hanteren voor bv DVD-apparatuur-fabrikanten maar
- onmogelijk voor bouwers van (gratis) downloadbare software omdat er nooit bekend is voor hoeveel keer de software gebruikt gaat worden (één download kan op meerdere PC's geïnstalleerd worden of juist op geeneen (ik zelf download ook best veel waarvan ik achteraf afzie van het installeren, bv omdat voorwaarden me niet aanstaan of omdat ik daarna iets anders vind dat beter is. In het geval van de codec's, je gaat ook niet K-lite én CCCP installeren, als iets niet werkt met de ene, probeer je de andere)
- voor video-opnameapparatuur enorm belemmerend is omdat men eist dat er per video-opname betaald wordt. Daarom staat bij de meeste appatuur dat deze bedoeld is voor thuisgebruik, zelfs bij professionele apparatuur. Als je daarmee iets filmt waarmee je geld verdiend overtreed je de licentievoorwaarden. De apparatuur waar deze licentievoorwaarde is afgekocht kost dan gelijk duizenden euro's.

[Mellow Jack]

Het probleem op dit moment is nog de codec volgens mij... De video tag zal bij allemaal wel werken maar dan moeten ze wel een video oproepen waar de codec voor aanwezig is

Edit @Bartjeh, idd dat bedoelde ik, had mijn post niet doorgelezen voordat ik hem poste. Pas hem ook niet aan omdat ik het niet relaxt vind wanneer dingen verdwijnen uit posts

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 03:35]

[Bartjeh]

Bij HTML5 kan je meerdere bestandsformaten erin voegen, dan wordt de ondersteunde codec gekozen. Voorwaarde is wel dat je dus meerdere formaten aanlevert.

_{Na nog 3x je post te lezen bedoelde je dat ook eigenlijk al denk}

[Reactie gewijzigd door Bartjeh op 23 juli 2024 03:35]

[skatebiker]

Precies en dat is het nadeel.
Moet je van een filmpje van 100MB een .h264, webm en een .ogv aanbieden. Zullen hosting providers blij mee zijn

Waarom niet een formaat die door alle browsers ondersteund wordt ?
Zolang dat niet het geval is is HTML5 hoe mooi ik het ook vind, geen alternatief voor online video's.

[hackerhater]

Tegenwoordig alleen .h264 en webM
en zodra MS en Apple eens niet zo moeilijk meer doen alleen nog webM

[HerrPino]

en zodra MS en Apple eens niet zo moeilijk meer doen alleen nog webM

Volgens mij draai je de zaken hier om. .h264 was al gekozen toen pushte Google zijn webM formaat (waarschijnlijk vanwege het 'not invented by us' syndroom waar Google wel vaker last van heeft).

[killercow]

Nack,

h264 was alleen door apple gekozen.
Microsoft had nog geen uitspraak gedaan,

google had h264 naast andere formats, en firefox kan geen h264 implementeren, en opera wilde dit niet ivm de patenten die er op rusten.

Kortom, apple was de enige die dwars ligt, vooral ook omdat ze in de mpegla zitten, disney nogal close bevriend was via pixar / de heer jobs.

[Dreamvoid]

Alle hardwarefabrikanten hebben ook allang voor H.264 gekozen, geen enkel platform heeft WebM decoding support.

[mark_vb]

h264 was alleen door apple gekozen.
Microsoft had nog geen uitspraak gedaan,

google had h264 naast andere formats, en firefox kan geen h264 implementeren, en opera wilde dit niet ivm de patenten die er op rusten.

Kortom, apple was de enige die dwars ligt, vooral ook omdat ze in de mpegla zitten, disney nogal close bevriend was via pixar / de heer jobs.

Microsoft heef anders ook behoorlijk wat tijd en moeite geinvesteerd in het standaardiseren van h264 als videocodec binnen Windows en WP7. Bovendien is h264 een in veel grotere mate bewezen codec als men kijkt naar alle real world applicaties (zowel software als hardware)

Daarnaast is VP8 (wat webM eigenlijk is) een afgeleide van h264 en heeft het dus in potentie hetzelfde probleem als het andere (tevens aangekochte, dus sowieso niet "invented by us" zoals HerrPino hierboven oppert) paradepaardje van Google: Android. Dat probleem is de zwakke positie in het huidige patentenklimaat.

zoals beschreven door Jason Garrett-Glaser: "With regard to patents, VP8 copies too much from H.264 for comfort, no matter whose word is behind the claim of being patent-free. This doesn’t mean that it’s sure to be covered by patents, but until Google can give us evidence as to why it isn’t, I would be cautious."

[sjongenelen]

daar is al veel over gezegd. even uit mijn hoofd zijn de 4 grote browserpartijen verdeeld.. zou je eventjes op moeten zoeken...

probleem zit 'm in de licenties (nu of in de toekomst) verbonden aan video codecs en bestandsformaten waar niet elke partij op zit te wachten

[Mellow Jack]

Het probleem zit m gewoon in het feit dat MS aan de MPEG kant staat en Apple in zijn eigen hoekje waardoor ze het risico niet waard vinden om bijv WebM te gaan gebruiken

[arjankoole]

Het probleem zit m gewoon in het feit dat MS aan de MPEG kant staat en Apple in zijn eigen hoekje waardoor ze het risico niet waard vinden om bijv WebM te gaan gebruiken

Apple zit in hetzelfde hoekje als MS hoor. H264 en MPEG zijn onlosmakelijk aan elkaar verbonden.

Het enige echte nadeel van H264 is dat er nogal wat patenten op zitten, maar was er onlangs al niet een versoepeling van de licenties afgekondigd op dat vlak?

(want iedereen snapt ook wel dat 't nooit aan zal slaan in browserland als het niet vrijelijk te integreren is)

[MacWolf]

Een groot "probleem" met h.264 is dat de licentie om de 5 jaar (ofzo) kan veranderen. Dus terwijl het momenteel gratis is voor gebruikers om h.264 video te bekijken, hoeft dat na afloop van deze termijn niet meer zo te zijn. Ik kan ergens wel begrijpen dat Opera en Firefox niet zo gelukkig zijn met deze onzekerheid.

MPEG LA's decision to extend the no-cost terms for free Internet video distribution will effectively defer this issue until 2016, the new expiration date. It's still unclear what the licensing terms will be after the new expiration date—MPEG LA could choose to apply hefty fees at that time. For now, however, the absence of licensing costs for Internet streaming will likely contribute to expanding the acceptance of h264 in the world of Web video.

Bron: Ars Technica

[Reactie gewijzigd door MacWolf op 23 juli 2024 03:35]

[Dreamvoid]

Het is Apple, Microsoft, min of meer alle film en televisieproducenten en alle GPU/SoC hardwarefabrikanten (de groep die met MPEG een openbare "industry standard" probeert te definieren) versus Google, Opera, Mozilla en de "free software" community (de groep die geen MPEG licensies wil, ook al zijn die nu gratis).

Voor HDTV, BluRay, telefoons, camera's, webcams, Video-on-Demand (films huren) en piraterij is MPEG inmiddels wereldwijd de standaard geworden, maar voor web streams (denk YouTube) probeert de laatste groep toch nog een overwinning te behalen. Het is inmiddels een principe kwestie geworden.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[CivLord]

Nu alleen nog een HTML 5 standaard i.p.v. een wolk mogelijkheden die verschillende browserbouwers onder die noemer implementeren.
Wat ik van HTML 5 heb gezien zijn een hoop voorstellen waarvan er een aantal bij gebrek aan beter alvast worden gebruikt, maar de definitieve standaard is nog lang niet in zicht.

[brabbelaar]

Wat ik me qua video vooral afvraag bij de <video> tag, ondersteund hij ook streaming of alleen progressive downloads? Het voordeel van flash en silverlight was natuurlijk dat dit wel kon (kan). Ik ben voor meer standaardisatie op dit gebied, maar dit is een tekortkoming. Of kan het wel?

[actionhenk]

Ik denk dat dit echt het begin van het einde is van mediaplugins als Flash en Silverlight. Nu HTML5 steeds beter ondersteund wordt lijkt het mij in 90% van alle toepassingen simpel weg onnodig om iets als Flash te gebruiken. Enkel de DRM features zouden nog een goede reden kunnen vormen om Flash of Sliverlight in te zetten. Hoewel de performance van games op dit moment in Flash wat beter is dan in Javascript, lijkt het alsof moderne browsers hier amper voor onder doen. Een voordeel is dat je HTML5 applicatie in een keer op vrijwel alle platformen werkt.

[Eagle Creek]

Dat begin was een tijdje geleden al gestart denk ik.

Toch vind ik het wel opvallend, daar Silverlight nog niet zo lang meedraait. Het leek, zeker in het begin, een goede concurrent te worden van Flash. De marktpenetratie verliep vrij snel, en in Nederland helemaal mede gepusht door sites als rtlgemist.nl en uitzendinggemist.nl.

Maar goed, als de noodzaak voor dit soort applicaties verdwijnt, dan sterft het vanzelf een stille dood. Ik zie er nog een aardig voordeel in: wat kleinere attack surface op je systeem, minder plug-ins te installeren en bij te werken.

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 03:35]

[Dreamvoid]

wat kleinere attack surface op je systeem

Ik weet niet of het vervangen van het (tot nu toe vrij secure) Silverlight door de aan alle kante lekke JavaScript engines van de browsers nou zo'n security voordeel is. Op die manier kan je ook roepen dat als iedereen maar stopt met Linux gebruiken, je attack surface ook kleiner wordt (immers, dan hou je alleen nog maar de lekken in Windows/OS X over).

(edit: je kan dat inderdaad wel zeggen, maar ik weet niet of de Linux community daar zo blij van wordt )

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[Eagle Creek]

Dat kun je inderdaad ook roepen. Als jij binnen een bedrijf 3 verschillende OS-en draait, dan verklein je het attack surface door dat terug te brengen naar 1.

Dat het niet in alle gevallen de meest ideale oplossing is, is een ander verhaal.

Nu dien je te updaten je browser, je silverlight, je java, je pdf reader, je flash, je etc.. Stel nu dat we stellen dat je pdf reader, flash en silverlight allemaal 'in' de browser komen te zitten, dan hoef je alleen nog maar je browser te updaten.

Uiteraard staat of valt de veiligheid van het systeem met de veiligheid van de browser, maar het totale oppervlak is kleiner.

[i-chat]

ja en een spof is goed want? als ik jouw redenatie moet volgen is een zo groot mogelijke attack surface juist beter. want de kans dat alle apps lek gaan is aanzienlijk kleinder dan wanneer alleen je browser lek gaat...

[Eagle Creek]

is een zo groot mogelijke attack surface juist beter.

Eeh.. nee hoor. Die (onjuiste) conclusie trek jij. Ik heb het uitsluitend over attack surface.

En een SPOF heb je toch met 1 browser en 3 plug-ins. Immers: een losse flash-plugin is zonder browser ook nutteloos.

Wat het OS-gedeelte heb je mogelijk gelijk, maar ik gaf al aan dat dat specifieke voorbeeld wellicht geen ideale oplossing is.

Nou geen dingen lezen die ik niet getypt hebt he .

[Dreamvoid]

Tis aan een kant jammer (Silverlight is puur technisch waarschijnlijk het best crossplatform framework wat er is), maar de markt beweegt duidelijk de andere kant op: native applicaties zijn de toekomst. En voor websites (bewegende ads, video) is HTML5 goed genoeg. Dit is het definitieve einde van crossplatform development.

Het goede nieuws is: met al die native platforms sites die nu ondersteund moeten worden is er veel meer werk voor developers.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[Carharttguy]

Ik denk dat ik iets mis. Silverlight, beste crossplatform framework?
U hebt nog nooit met Silverlight op Linux gewerkt? Ahneen juist, dat gaat helemaal niet.

Ontopic. Goede beslissing. Ik denk dat het tegenvallend gebruik er ook wel mee zal te maken hebben.

[Terracotta]

moonlight laat silverligth applicaties wel draaien, zij het niet zo super, maar ja, flash is al geen haar beter.

[i-chat]

welke silverlight apps, want die van rtlxl en van UG in ieder geval niet! dit terwijl de vroegere flash versies het wel prima deden.

[Carharttguy]

Flash wordt wel door Adobe zelf ontwikkeld. Moonlight is ontwikkeld door de community. Toch wel een verschil me dunkt.

Op 32bit Linux zie je trouwens weinig problemen met Flash.

[Ertepeller]

64bit werkt ook uitstekend hoor, al een hele tijd. Zelfs de eerste alpha werkte eigenlijk al beter dan de 32bit versie.

[Anoniem: 166774]

Het feit je moonlight nodig hebt is dus exact het punt dat siverlight niet crossplatform is.

[Dreamvoid]

Ik denk dat ik iets mis. Silverlight, beste crossplatform framework?

Daarom zeg ik ook "puur technisch". Het feit dat de open source community geen goede client heeft willen/kunnen bouwen is 1 (kleine) reden geweest dat het niet is doorgebroken. De grotere redenen zijn dat Apple het niet in iOS toe liet, en dat de andere browserbouwers het niet wilden integreren zodat SL altijd een los framework bleef itt bv JavaScript dat wel werd ingebouwd in browsers. Hun goed recht natuurlijk - als de rest van de industrie geen MS technologie wil supporten dan mag dat.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[zx9r_mario]

Magister en Reeleezee zijn net overgestapt over Silverlight, nu kunnen ze alles weer herschrijven. Leuk om te hoe Microsoft minded bedrijven door hun eigen vendor-lockin gepakt worden.

[ro8in]

Het is ook gewoon dom om software die je langdurig wil gaan inzetten te schrijven voor een plugin waarvan het voortbestaan vanaf de eerste release al niet zeker is geweest... Just my 2 cents.

[Anoniem: 113282]

Dat is niet helemaal waar. Ik ben het er mee eens dat een plugin voor algemeen website gebruik achterhaald is en gedoemd is om te mislukken. Hier is HTML 5 zeker de aangewezen techniek voor.

Echter voor een bepaald doel is Silverlight een uitermate geschikte techniek: Dat doel is (afgeschermde) rich business applicaties (zoals Reeleezee en Magister) via het web. HTML 5 is super als techniek, maar er zijn genoeg (grotere) bedrijven die nu nog op IE 6 / IE 7 / IE 8 draaien en hier zeker op korte termijn geen afstand van zullen doen. Silverlight werkt gewoon prima onder IE 6. Het hele binding verhaal wat 1 op 1 overkomt met WPF is gewoon fijn (en snel) met ontwikkelen, je kunt één applicatie maken en wanneer je MVVM goed toepast kun je door het schrijven van alléén 3 verschillende views deze applicatie via Silverlight, WPF en Windows Phone geschikt maken.

[ro8in]

Het gaat ook niet om het een beter is voor iets dan het ander. Het gaat erom dat als jij een applicatie maakt voor een plugin waarvan je weet dat de toekomst er van niet zeker is dat je dan een bewust risico neemt en niet raar moet opkijken als je opeens weer je applicatie opnieuw kan gaan schrijven omdat de plugin vendor er mee ophoudt.

Dit is een mooi voorbeeld van waarom Steve Jobs het ook niet zo had met Flash. Als jij een produkt bouwt dat weer afhangt van het product van een ander bedrijf, ben jij dus ook meteen overgeleverd aan hun keuzes. Met open standaarden als HTML5 heb je deze problemen niet.

[Dreamvoid]

Silverlight is ook een open standaard, elke browserbouwer kon gewoon een client schrijven en die integreren in zijn browser, net zoals ze dat met JavaScript hebben gedaan. Het probleem van Silverlight is dat de browserbouwers dat niet wilden, en SL altijd een plugin bleef. Je standaard kan nog zo open zijn, als niemand 'm wil supporten is het alsnog over en uit.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:35]

[ro8in]

Volgens mij is Silverlight niet volledig opensource hoor. In dat geval kan je dan altijd nog je eigen plugin ontwikellen..

[_Piwi_]

Dus dan hebben Mac en Linux gebruikers pech als te rtlXL o.i.d. willen kijken?
Nu is de software niet geweldig maar het werkt... Hopen dat er snel een vervanging voor komt dan

[eew]

Er was geen behoefte aan, en vervanging is er dus zat. Als het zo slecht ondersteunt gaat worden zal RTL er toch ook wel mee stoppen. Probleem is voor RTL dat ze mobiele apparaten willen weren. Met HTML 5 is dat lastig.

[HawVer]

Als je als bedrijf innovatief wilt zijn en je zet in op nieuwe dienster en producten (zoals Silverlight) kun je dat nu weer gedag zwaaien. De grotere bedrijven laten zich leiden door de waan van de dag. Apple heeft recentelijk een showcase van HTML 5 online gezet en een paar weken later hebben Google en Microsoft een vergelijkbare showcase opgezet.

Ik ben absoluut voorstander van een standaard zoals HTML 5.0 die toch steeds meer en meer de toekomst lijkt te worden. Alleen moet je als ontwikkelaar je pijlen gaan richten op dit relatief nieuwe product in plaats van Silverlight? Het is nogal een gok en wie zegt dat we niet binnen een jaar weer wat nieuws hebben? Is het safe om als ontwikkelaar nu te kiezen voor HTML 5.0? Is het een platform met toekomst. Ik ben benieuwd. De omarming van Apple, Google en Microsoft (de grootte spelers op de markt) zijn veelbelovend.

[Vexxon]

Apple heeft recentelijk een showcase van HTML 5 online gezet en een paar weken later hebben Google en Microsoft een vergelijkbare showcase opgezet.

Als Apple dat onlangs gedaan heeft dan waren ze zeker niet de eerste.
Zowel Google als Microsoft hebben al minimaal een jaar een dergelijke showcase.

OnTopic: Voor een webontwikkelaar os het op dit moment nog vrij lastig om een site volledig in HTML5 te bouwen.
Aangezien er nog een hoop oudere browsers zijn welke geen HTML 5 ondersteunen.
Wil je persé HTML 5 gebruiken zul je dus twee versies moeten maken.
En dat is weer niet lekker voor de onderhoudbaarheid, daarbij kost het extra tijd.