Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 65, views: 14.661 •
Submitter: Rubinski

Microsoft heeft kortstondig een Quickstart Kit for Mac Developers verkocht. De 25 dollar kostende kit bevatte een Windows 8 Pro-licentie en de virtualisatiesoftware Parallels 8 for Mac op een usb-stick. Microsoft wil zo ontwikkelaars stimuleren hun sites te optimaliseren voor Internet Explorer.

De kit werd door Microsoft verkocht op crowdfundingsite Swish.com voor 25 dollar, exclusief verzendkosten, en werd ook buiten de Verenigde Staten geleverd. Het geld ging in de vorm van een donatie naar Watsi.org, de Kahn Academy of Code.org. TechCrunch meldt dat de Quickstart Kit is ondertussen al uitverkocht; het is niet bekend hoeveel bestellingen Microsoft heeft geaccepteerd.

De kit is bedoeld voor webontwikkelaars die op een Mac werken en moet ervoor zorgen dat het makkelijk wordt om websites te testen en te optimaliseren voor Internet Explorer. Normaal gesproken werkt Internet Explorer niet op een Mac, maar met behulp van Parallels is het mogelijk om Windows-applicaties binnen OS X uit te voeren. Microsoft wil met de kit vooral modern.IE, de versie van Internet Explorer 10 die in de 'Modern UI' van Windows 8 draait, toegankelijker maken voor ontwikkelaars. De aanbieding van de Quickstart Kit verscheen ook op modern.IE; de website waarop Microsoft Internet Explorer 10 promoot en waarop websites op compatibiliteit getest kunnen worden.

Hoewel de Quickstart Kit volgens Microsoft bedoeld is voor het testen van IE10 op Mac-computers, geeft de afbeelding die bij het product staat aan dat de kit voor iOS Developers bedoeld is. Wellicht probeert Microsoft op deze manier iOS-ontwikkelaars aan te sporen om bij het ontwikkelen van een iOS-app ook een versie voor de Windows Store te ontwerpen.  De Windows- en Parallels-licentie zouden het voor iOS-ontwikkelaars makkelijker kunnen maken om die stap te zetten. Apps voor iOS kunnen normaliter alleen op een Mac ontwikkeld worden, terwijl Windows-apps alleen op Windows 8 gebouwd kunnen worden.

Microsoft is al langer bezig om Windows 8 interessanter te maken voor ontwikkelaars. Vorige maand nog startte de softwaregigant een campagne waarbij ontwikkelaars 100 dollar per ontwikkelde Windows-, of Windows Phone-app ontvingen.

Windows QuickStart

Reacties (65)

IE begint meer en meer aan standaarden te voldoen.
Webkit daarin tegen...
Je bent duidelijk niet op de hoogte van de recente ontwikkelingen.
Op heden als vandaag heeft elke web browser een mankement en IE is zeker niet het slechtste in dit geval.
Ja alleen hebben webdevelopers daar de komende 10 jaar nog geen hol aan, omdat de meeste gebruikers nog lager dan IE9 draaien
Dan moet je correct leren CSS'en want zo'n groot probleem is het niet. Enige die af en toe moeilijk doet is IE7.
Wat betreft CSS ben ik het met je eens. IE6 was @*&!^#, IE7 kan nog lastig doen, maar met IE8 valt prima te werken.

Javascript is meer een issue. Er is inmiddels een hoop mogelijk met allerlei polyfills, maar de performance deuk die je daarmee oploopt maakt dat het naar mijn mening niet echt feasible is om meer dan een paar nieuwe features te combineren in 1 project.


En gelukkig moet die 10 jaar in een context worden geplaatst. Tegenwoordig wordt IE over het algemeen beter ge-update.

Helaas kunnen bedrijven updates uitstellen (/uitschakelen?). Afgelopen maand werkten we aan een site waar IE6 nog redelijk prominent in de statistieken voorkwam.

Maar als dergelijke bedrijven niet de doelgroep zijn, dan is het onzin om hen meer prioriteit te geven dan de bezoekers die wel tot de doelgroep behoren. In dat geval kun je al veel sneller overschakelen naar moderne IE versies.
Makkelijk gezegd maar ook iets wat onder Firefox draait, draait ook niet perse goed/vloeiend onder Chrome. Ook daar zitten verschillen. Een standaard ondersteunen is iets anders als hem correct te implementeren. Alle browsers bevatten verschillende (mis)interpretaties van de standaard.
Dat komt op dit moment nog vooral omdat de HTML5 standaard nog afgemaakt moet worden. Gelukkig is er nu wel een overeenkomst bereikt op de meeste toevoegingen, maar browsermakers zijn gewoon veel te vroeg begonnen daarmee en door dat gedoe met die browserprefixes en andere interpretaties zitten we nu met het probleem dat ook al wordt alles ondersteund, dan kan er nog verschil zijn.

Vooralsnog heb ik geen enkel probleem om overigens een site in alle browsers compatible te krijgen. Het zijn vaak minimale verschillen.
quote: Martinspire
de HTML5 standaard nog afgemaakt moet worden
In July 2012, WHATWG and W3C have decided on a degree of separation. W3C will continue the HTML5 specification work, focusing on a single definitive standard, which is considered as a "snapshot" by WHATWG. The WHATWG organization will continue its work with HTML5 as a "Living Standard". The concept of a living standard is that it is never complete and is always being updated and improved.

[Reactie gewijzigd door David Mulder op 3 april 2013 10:14]

Inderdaad een snapshot. Het is in de laatste fase, maar nog niet 100% af
Ik denk dat je de quote van David Mulder nog iets beter moet lezen ;)
The concept of a living standard is that it is never complete and is always being updated and improved.
HTML5 zal nooit af zijn. Er komt dus ook nooit zoiets als 'HTML5 Final' om te implementeren, er is dus ook niet zoiets als een 'laatste fase'. ;)

Geeft mij persoonlijk overigens niet erg veel vertrouwen in HTML5 als 'standaard' zijnde. Naar mijn mening verandert het teveel voor een 'standaard', je weet vandaag niet of volgend jaar dezelfde featureset nog ondersteund wordt en of je design er nog hetzelfde uit ziet / werkt.
Men gaat over het algemeen heel voorzichtig te werk wanneer het backwards compatibility betreft. Alleen zelden zal men gedrag veranderen wanneer deze al wijdgesprijd gebruikt wordt. Dan zal het lang vantevoren worden aangekondigd.
Klopt gedeeltelijk, met dingen die gewoon als experimental worden bestempeld word het wel gedaan, maar in principe worden experimentele dingen niet al te wijd gebruikt. Neem bijvoorbeeld websockets, in het begin zijn die flink chaotisch ontwikkeld en alhoewel er dan wel verschillende versie nummers waren gebeurde het vaak genoeg dat demo's stuk gingen. En hetzelfde was ook het geval met WebRTC. Hoe dan ook, die dingen werden ook vooral alleen nog maar in demo's enzo gebruikt, maar daarbij merkte je wel echt duidelijk dat het een ontwikkelproces was.
Die browser prefixes zijn juist een goed iets. Zo kunnen ontwikkelaars iedere browser apart finetunen, zodat je geen last hebt van verschillende interpretaties. Als alle browsers dan op één lijn zitten kan je uiteindelijk één standaard gebruiken.

We zitten nu al redelijk goed html5 en css3, we waren echt nog niet zo ver geweest als iedereen gaat wachten tot alles af is. Daarnaast geeft David Mulder terecht aan dat html5 een 'levende' standaard is.
Leuk die prefixes, maar het zorgt voor een hoop overbodige regels CSS. Ik wil niet 5 regels nodig hebben voor het regelen van een simpele border-radius. Die dingen moeten gewoon overeen komen (al is border-radius mogelijk een slecht voorbeeld want die doet het ook zonder prefix, maar je snapt wat ik bedoel).

Finetunen zou namelijk niet nodig moeten zijn voor websites. De interpretatie moet gelijk zijn, daar zou je niet over moeten twisten.

Een levende standaard is leuk en aardig, maar hiermee houdt je toch altijd nog wel wat bugs in de sites en applicaties. Er hoeft dan maar wat te gebeuren en het resultaat is ineens volledig anders. Ik vind het niet erg dat ze nieuwe dingen toevoegen, maar ze moeten dat doen nadat de grote browserfabrikanten het erover eens zijn hoe deze moet gaan werken. Nu is Chrome bijvoorbeeld heel hyperactief geweest met het toevoegen van nieuwe dingen, waardoor deze ineens anders zijn dan wat de standaard is of wat de bedoeling van de standaard was. Hierdoor is een applicatie die je voor Android maakt, ineens niet meer hetzelfde op iOS of andere systemen (en browsers).

In zekere zin zijn sites erg fragiel voor veranderingen en daardoor heb ik liever dat het in 1x goed gebeurd dan dat het 5x veranderd en ik daardoor bezig blijf. Vernieuwing is prima, maar op dit moment wordt er sterk overdreven met wat er allemaal voor het web nodig is.
Het is jammer dat er hier op tweakers.net minder en minder publiek komt met veel en jarenlange ervaring. De dingen die je hier soms leest, tenen krullend.... Dat je +2 wordt gemod is daar een toonbeeld van.
Leuk die prefixes, maar het zorgt voor een hoop overbodige regels CSS. Ik wil niet 5 regels nodig hebben voor het regelen van een simpele border-radius. Die dingen moeten gewoon overeen komen
Ik schrijf anders minder code dan vroeger. Zaken zoals SASS, LESS, Emmet/Zen Coding, ... zijn daar een grote oorzaak van.

We komen uit een tijdperk waar men geen prefixes gebruikte en dat was een regelrechte ramp. En sorry dat ik nog eens oude koeien uit de gracht moet halen, maar MS was daar 99% de oorzaak van. Zelf tot op vandaag ondervinden sommigen daar nog last van.

Prefixes zorgen er voor dat de standaarden niet vervuild worden en je als webdeveloper de vrijheid hebt om zaken te implementeren. Maar dat is de verantwoordelijkheid van de ontwikkelaars.

Het is inderdaad zo dat tussen diverse browsers er wel eens een compatibiliteitsprobleem zijn maar de aanpassingen zijn nihil als je dat vergelijkt met het uren aan werk die we vroeger mochten presteren om een site goed te krijgen in diverse browsers. Of laat het mij anders zeggen de wereld vs IE.

Echt de dingen waar jullie over klagen (extra regels, kleine quircks,...) verbleken daar bij. Jullie zijn echt f*cking rot verwend en het ergste van al is dat jullie geen enkele notie van besef daarover hebben. Soms denk ik dat moest frontpage opnieuw worden gelanceerd (shiver) dat jullie echt het doelpubliek zijn.

Trouwens werkend in een bedrijf die redelijk grote websites aflevert kan ik je zeggen dat anno 2013 het nog altijd in grote lijnen Microsoft is t.o.v. de rest of dat het Microsoft platform wel vaak problemen oplevert. We moeten trouwens het grotendeels nog altijd doen voor die grote groep IE versies die niet bepaald de versies zijn die standaarden zo goed opvolgen.
Een levende standaard is leuk en aardig, maar hiermee houdt je toch altijd nog wel wat bugs in de sites en applicaties. Er hoeft dan maar wat te gebeuren en het resultaat is ineens volledig anders.
Dat is de verantwoordelijkheid van site ontwikkelaars, niet van de browsers. Dat is hetzelfde met wat je implementeert. Iemand met een beetje verstand kan verdomd goed inschatten wat min of meer stabiel is.

[Reactie gewijzigd door simplicidad op 3 april 2013 11:45]

De prefixes zijn in principe goed, zolang de prefix wordt weggehaald als een bepaalde CSS property 'af' is en gestandaardiseerd. Dit is nu helaas niet bij webkit het geval: Webkit blijft de properties met prefix ondersteunen, omdat heel veel sites alleen de -webkit versie gebruiken.

Resultaat: herhaling van de geschiedenis waarin sites alleen in bepaalde browsers werken, en er eigenlijk niet meer aan de standaarden worden voldaan.

Meer: http://kevinjohngallagher...at-lady-singing-prefixes/
Die browser prefixes zijn juist een goed iets.
Dat lijkt me niet. Het werkt fragmentatie in de hand, en developers raken er aan gewend om niet aan de algemene standaard te voldoen (ook al is er geen specifieke oplossing in de algemene standaard).

De verschillende browsermakers zullen prefixes ook aangrijpen om alsmaar functionaliteit toe te voegen die niet standaard is en niet aanwezig bij concurrerende browsers. M.a.w., met prefixes creeert elke browsermaker zijn eigen standaard. De "echte" standaarden HTML5 en CSS3 zullen dan ver te zoeken zijn.
Het W3C heeft al gewaarschuwd voor de prefix-dominantie van Webkit. Het is waarschijnlijk ook een van de oorzaken waarom HTML5 final er nooit zal komen: iedere browsermaker (stakeholder) heeft nu namelijk een manier om vast te houden aan zijn eigen ideeen: prefixes.

In de praktijk kan het zo zijn, dat elke fundamenteel nieuwe browsermaker zijn eigen prefixes introduceert. Als webdeveloper moet je dan met elke browser engine rekening houden dmv prefixes. Dat lijkt me nauwelijks een ideaal.

Prefixes zijn uitzonderingen, niet de standaard. En uitzonderingen maken het geheel alleen maar troebel.

[Reactie gewijzigd door Fireshade op 3 april 2013 16:10]

Prefixes zijn een goed iets, ze worden alleen verkeerd gebruikt.
De browser-prefixes bieden de mogelijkheid om experimenteel de specificatie te vervolmaken voordat hij definitief wordt met feedback vanuit de hele web-community. Het massale gebruik van de prefixed css-properties door jan-en-alleman in iedere website is het kwaad dat je niet zou moeten willen.
Prefixed css-properties moet je gebruiken voor proof-of-concept en experimenteer sites om passende feedback te kunnen geven aan de opstellers van de standaard en om vast wat hands-on ervaring op te doen met de mogelijkheden die er aan zitten te komen. Slechts bij uitzondering als er echt niet onder uit te komen is zou je ze moeten gaan gebruiken in een reguliere site.
Safari gebruikt webkit en als je in chrome ontwikkelt zal je website er vrijwel altijd hetzelfde uitzien in safari. De ondersteuning op jQuery en andere libraries daarentegen wil nog wel eens problemen bij mij geven!
Helaas is het niet zo'n feest. Kijk hier voor een interessante blik op de verschillen en overeenkomsten tussen de diverse WebKit implementaties: http://paulirish.com/2013/webkit-for-developers/
Daar kun je bijvoorbeeld lezen dat Form controls verschillend gerenderd worden in diverse WebKit browsers. Ook is het bijvoorbeeld interessant dat Safari en Chrome verschillende vendor-prefixes ondersteunen.

M.a.w. zelfs binnen WebKit land zijn er nog wel "compatibiliteits problemen" te vinden :)
Het is vooral de mobiele Safari die wat eigenaardige dingen heeft. Zo hebben ze eigen tags, metatags, css en javascript toegevoegd. Ook zijn sommige native elementen (zoals een selectbox) onmogelijk om aan te passen, tenzij je het helemaal om gaat gooien met divjes en javascript (iets wat bv jQueryMobile doet).

De desktop safari is meestal niet zo'n probleem, maar als je voor mobiele apparaten gaat ontwikkelen, zul je snel merken dat de browsers qua (javascript) performance, ondersteunde html5 elementen en css3 toevoegingen, maar ook systeemelementen aardig verschillen en het ontwikkelen daardoor erg omslachtig maken. Hierdoor is een applicatie niet zomaar over te zetten en dat is natuurlijk erg jammer.

Het is qua performance met de Samsung Tab 2 en de iPad 4 inmiddels wel een grote verbetering (veel vloeiendere css3 en javascript animaties) maar heeft nog een lange weg te gaan om aan te voelen als native applicaties. Zeker als je meer wilt dan een handvol pagina's met simpele opmaak en een handvol animaties. jQueryMobile is erg krachtig om veel mee te kunnen doen, maar is vooralsnog niet geschikt om complete applicaties mee over te zetten. Tenzij je een 13/12 applicatie wilt maken die verder niets nieuws brengt en meer aanvoelt dan een normale website dan applicatie.
IE8 en lager misschien wel. IE9 had ik zelf nog weinig problemen mee, maar met IE10 is het eigenlijk helemaal geen probleem meer. Enige waar IE9 steekjes liet vallen is dat het nog niet alles ondersteunde van HTML5. Gradients en box-shadow bijvoorbeeld. IE10 heeft dat wel en meer, dus dat werkt meestal ook wel.

Sterker nog, ik moet de laatste tijd steeds vaker bugs voor Chrome oplossen dan voor IE en Firefox bij elkaar. Nog afgezien van het feit dat Cleartype/Antialiasing voor tekst bij Chrome het gewoon volledig af laat weten.

[Reactie gewijzigd door Martinspire op 3 april 2013 10:12]

Nou alleen nog hopen dat microsoft binnenkort ook een keer de 'geen selectie' naar 'selectie gemaakt' van een radiobutton uit een groep als een change gaat zien wanneer de focus nog op de radiobutton staat. Dat zou weer een IE-only fix schelen op de radio onChange event.
In theorie klopt dat natuurlijk, maar zoals wel vaker is theorie en praktijk niet altijd gelijk. Het daadwerkelijk testen op meerdere platformen is hoe dan ook nodig. Door het houden aan de standaarden wordt het aanpaswerk uiteraard makkelijker en minder werk.
Dat hebben ze al gedaan in 2011, verbeterd in 2012 en in 2013 wordt het nog beter (respectivelijk IE9, IE10 en IE11). Als jij als ontwikkelaar je website niet test in verschillende browsers "omdat ze zich maar aan de standaarden moeten houden", ben je niet echt een goede ontwikkelaar...
Dat ligt er natuurlijk aan wat er van je gevraagd word. Als je een site moet maken welke in browser a werk en je doet dit zoveel mogelijk volgens de standaarden, men wil (bewust) geen middelen steken in het testen van andere browsers dan doe je het prima. Als je hier wel extra tijd insteekt en dit is niet de wens van de klant/werkgever dan ben je juist inefficiënt bezig.
Het lijkt me niet dat de klant/werkgever wil dat hij helemaal niet werkbaar is. Je zult de basis in ieder geval wel moeten hebben (werkende navigatie, zichtbare inhoud en een functioneel geheel). Dat je daarbij wat zaken mist zoals schaduw, kleuroverlopen of javascript effecten is wel jammer, maar als het helemaal niet werkt heb je natuurlijk wel een probleem.

Als je nu problemen hebt met IE10, dan ligt het vooral aan je eigen programmeerwerk of design. Wat niet wil zeggen dat je niet een controle moet uitvoeren. Deze hoeft dan niet intensief te zijn en waarschijnlijk kun je het pixelneuken achterwege laten, maar het lijkt me niet echt goede reclame als blijkt dat je niet hebt getest en je daardoor grote problemen achterwege hebt gelaten.

Het testen in andere browsers kan je erop wijzen dat er toch wat zaken niet op orde zijn die bij jou wel goed lijken te gaan. Vooral Chrome heeft wel eens de neiging om bepaalde zaken in zijn cache te laten staan, waardoor je pas te laat opmerkt dat je toch wat fouten erin hebt zitten.

[Reactie gewijzigd door Martinspire op 3 april 2013 11:09]

Ook al heeft de klant geen behoefte aan een goede werking in Firefox en Chrome (omwille van het feit dat de klant dan blijkbaar niet weet wat-ie wil), dan nog zorg je dat het daarin werkt. Al was het maar uit respect voor je eigen werk. Niet omdat de klant het wil, maar omdat je gewoon goed werk wil afleveren.

[Reactie gewijzigd door _Thanatos_ op 3 april 2013 13:07]

En wie betaalt voor dat "respect"? NIet de klant die er niet om heeft gevraagd lijkt me. Eigen tijd?
Het is meer en meer juist Safari die de bitch uithangt. Er vinden zeer weinig updates plaats, het houdt zich aan nét even andere standaarden dan Chrome en andere Webkit-browsers, en het is de defacto standaardbrowser op OSX. Lang leve de standaarden dan maar?

Zeker als je qua HTML5 nieuwigheid en CSS3 het onderste uit de kan haalt, zie je dat IE8 en IE9 keurig doen wat je verwacht (niets of een werkende fallback), terwijl Safari juist de boel op stelten zet door rare dingen te doen, of compleet te weigeren waar support geclaimed wordt.
je vergeet even dat ook bv chrome zich niet aan de standaarden houdt.
naast het feit dat 'html5' nog steeds geen standaard is, maar nog steeds in ontwikkeling is (en daarmee eigenlijk schandalig dat het al zoveel gebruikt wordt).
Ontwikkelaarsmenu in Safari/ChromeOS heb je voldoende aan, gewoon rendering aangeven voor welke engine.

Dus nee dit soort pakketjes heb je niet nodig.
De 25 dollar kostende kit bevatte een Windows 8 Pro-licentie
Is dat niet een heel goedkope manier om aan een Windows 8 Pro licentie te komen?
Of zijn er beperkingen aan die licentie?

[Reactie gewijzigd door i8086 op 3 april 2013 09:57]

Dat pakket bevat ook Parallels, dus het zou wel eens zo kunnen zijn dat deze Windows 8 Pro licentie alleen werkt binnen virulisatie software (misschien zelfs Parallels in het bijzonder). Dit kan ik echter nergens terug vinden, maar lijkt mij aannemelijk voor die prijs.
De website zelf zegt dat het om een volledige Windows 8 licentie gaat...
Ligt het aan mij of lijkt het net alsof Microsoft dit buiten de schijnwerpers heeft uitgebracht?
Ligt niet aan jouw, voor zover ik weet is de enige aankondiging hiervan geplaatst op de Internet Explorer Blog en Modern.ie site zelf.
Logisch, het ging om een inzameling van geld, niet om de echte verkoop van het product. Een bedrijf stelt dan x aantal producten ter beschikking om te verkopen en het geld gaat niet naar het bedrijf maar naar het fonds waar men het geld voor inzamelt.
Het geld ging in de vorm van een donatie naar Watsi.org, de Kahn Academy of Code.org
Voor Microsoft een handige manier om enkele ontwikkelaars goedkoop een licentie te bezorgen (wat de development voor Windows 8 en modern IE ten goede kan/zal komen). Microsoft tevreden, wie doneert tevreden en Watsi.org tevreden :) Maar daarom moeten ze er natuurlijk geen grote publiciteit rond hangen. Dan loop je tevens meer risico dat doorsnee gebruikers ermee aan de haal gaan in de plaats van ontwikkelaars.
Is hier iemand anders die zich verbaast over de prijs hiervan?
De kit komt met een betaald virtualisatie pakket en is nogsteeds stukke goedkoper dan de huidige prijs van Windows 8.

Lijkt erop dat mac gebruikers dit nog wel is interresant kunnen vinden als een goedkope manier om windows te gebruiken in plaats van het ontwikkelen van IE websites.
Vandaar ook het gelimiteerde aanbod natuurlijk.
Volgens mij krijg je hiermee toch alleen een IE10 browser en wat mogelijkheden om apps te testen? Lijkt me stug dat dit helemaal Windows 8 is of anders zal er vast een andere beperking zijn (dat het ook alleen op de stick draait bv).
het gaat hier om een normale windows8 PRO licentie, eelke normaal ook nog duurder is dan de gewone licentie die de meeste gebruikers hebben.
Wilde voor iedereen in mijn team een kopie aanschaffen maar helaas is het al uitverkocht.
Het is al uitverkocht....
Shit, die had ik wel meegenomen als ik hem had gezien. Wat mij betreft is dit een prachtige stap van Microsoft. Als webdeveloper is het namelijk erg lastig om hetzelfde klaar te spelen met OS X als je geen Mac hebt; VM's zijn irritant om op te zetten voor OS X maar het is ook de enige manier om Safari en zelfs andere browsers op het OS te testen (en dat is weldegelijk nodig als je eigen fonts gebruikt). En laat staan testen op iOS, daar heb je dus ook echt een VM voor nodig, aangezien er geen andere manier is om een emu te draaien.

Ook altijd leuk, die reacties van mensen die zelf niets tot weinig met webdevelopment doen maar wel grote beweringen durven te maken. De realiteit?

- IE10 is niets mis mee, die mag je gerust naast de andere browsers zetten. Ondersteunt aardig wat CSS3, houdt zich behoorlijk aan de standaarden, rendert snel, heeft een degelijke JS engine. IE9 was al een grote vooruitgang, maar vooral het stukje standaarden volgen ging daar nog mis (even afgezien van het achterliggen met CSS3).

- Safari (desktop) is een misselijk product; het mag wel WebKit zijn, maar het is ook Apple, en software is nu eenmaal niet Apple's sterkste punt. Er zitten belachelijke bugs in, de updates komen maar erg traag en de JS engine is ook niet bepaald indrukwekkend. Heeft even veel controle nodig als een IE8 of 9.

- Safari (iOS) is net zo'n vervelend stuk stront; helaas is er geen realistisch alternatief op iOS; zelfs met Nitrous werkt bijvoorbeeld Chrome niet 100% op iOS. Zelfde redenen als hierboven en als iemand interesse heeft kan ik je browser laten crashen met 1 regeltje CSS en een inline style. Geen foutmelding, niks, Safari sluit dan gewoon af. Laatste "voortgang" op m'n bug report was dat het probleem zich nog steeds voordoet op 6.1.2, 6.1.3 nog niet getest.

- Onder dezelfde noemer als beide Safari's mag je IE6+7 en Android's stock browser in 1.x/2.x scharen.

- Chrome is geweldig wat betreft vooruitstrevendheid, maar zoals iemand eerder al aangaf is het daardoor ook een buggy product. En omdat zij zo'n belangrijke speler in WebKit zijn, sijpelt dat vaak door. V8 draait gelukkig wel als een tiet.

- Firefox is belachelijk traag, maar heeft wel zelden problemen. Ik gebruik deze wel nog steeds voor veel van m'n werk, omdat Firebug gewoon fantastisch is. Chrome's inspector komt aardig in de buurt, maar is het gewoon nog net niet.

- Opera is het minst vooruitstrevend, maar hebben wel een geweldige JS engine en houden zich ontzettend goed aan de standaarden. Het duurt vaak wat langer eer ze iets implementeren, maar dat doen ze dan ook wel meteen goed. Het feit dat zij nu WebKit gaan gebruiken vind ik zonde van Presto, maar voor WebKit betekent het wellicht dat er wat meer controle en QA plaats gaat vinden.

Edit disclaimer: ik heb zelf gewoon een MBP 2012, dus voordat Apple fanaten mij gaan lopen bashen, ik weet echt wel waar ik het over heb. Apple heeft de ballen verstand van software ontwikkeling. Ik kan tal van idiote fouten aanwijzen, ook in OS X zelf.

[Reactie gewijzigd door Werelds op 3 april 2013 10:58]

Helemaal mee eens. Ik heb met de ontwikkeling van een jQueryMobile app ook aardig wat keren lopen prutsen om het geheel op iOS (en Android) werkend te krijgen. Het feit dat je 0 controle hebt op bepaalde formulier elementen (of zij het met een enorme omweg of eigenaardige html/css) is gewoon echt belabberd. Documentatie van dergelijke aanpassingen zijn er ook niet en daardoor ben je dan ook al lang bezig met zoeken naar wat het probleem precies is en hoe je het op moet lossen. Tel daarbij dat de performance enorm wisselend is en je verhaal is compleet.

Chrome begint zo ook zijn eigenaardige trekjes te krijgen, maar blijft desondanks nog wel mijn voorkeursbrowser. Vanwege de vele problemen draai ik inmiddels niet meer de beta of dev versies, maar gewoon stock. Te vaak gehad dat problemen lagen aan mijn browserversie of een foute update.
http://neverbland.com/ioscrash.html

Open dat maar eens op je iOS Safari. Veel plezier. Het is geen veel voorkomende situatie, maar dat ene CSS regeltje + de inline style die je ziet zorgen ervoor dat de browser crasht. Het mooiste is nog dat ik Apple er inmiddels 4 maanden geleden van op de hoogte heb gesteld en ze het nog steeds niet op hebben kunnen lossen, terwijl geen enkele andere WebKit implementatie dit probleem heeft.

En jawel, grote websites stem je weldegelijk af op iOS; of beter gezegd op mobiele apparaten. Als jij alleen maar standaard grids en Bootstrap gebruikt kom jij vast wel daar met jouw setup, maar diegenen onder ons die iets ingewikkeldere sites bouwen hebben daar niet genoeg aan.
Sowieso is Microsoft goed bezig met het ondersteunen van niet-Microsoft omgevingen, dit was een paar jaar geleden nog wel anders (de IE-images die ze al geruime tijd aanboden waren slechts met moeite aan de praat te krijgen in iets als VirtualBox), nu stellen ze alle images beschikbaar voor verschillende virtualisatieplatformen die je mag downloaden met cURL. Ik snap dan ook niet echt de meerwaarde van een fysieke distributie. Parallels is wellicht leuker dan het gratis VirtualBox natuurlijk, maar ik vermoed dat het een light-versie zal zijn van Parallels, wat in de praktijk betekend dat je dan liever ook gewoon een image hebt dat je in je standaard virtualisatieomgeving kunt draaien waar je 'alles' mee kunt.
Ik las Windows 8-bit :P
Dat zal toch een hele andere windows zijn, haha.
Apple mag dit ook weleens doen voor Windows mensen. Het feit dat het zo moeilijk is om OSX binnen een virtuele omgeving draaiend te krijgen, is ronduit schandalig.

Gezien het feit dat Microsoft al langer dit soort VM's aanbiedt (die ook in het begin met meer of minder moeite op OSX te draaien waren) bewijst wel weer hoe koppig Apple is. Je dient maar een Mac te kopen.

[Reactie gewijzigd door _Thanatos_ op 3 april 2013 13:10]

Doe maar niet want dan gaan er allerlei mensen weer klagen over dat het niet goed draait omdat het geheugen niet compatible is. Dit zie je in de praktijk regelmatig gebeuren bij gebruikers die ongeschikte geheugen in een macbook stoppen (omdat ze liever zo goedkoop mogelijk uit waren, maar dat werkt niet altijd).

Op dit item kan niet meer gereageerd worden.



Populair: Samsung Gamecontrollers Smartphones Processors Sony Microsoft Apple Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013