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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 116 reacties
Submitter: HjavanDalen

Apple heeft een versie van zijn Safari-browser uitgebracht voor ontwikkelaars. De Safari Technology Preview zorgt ervoor dat webontwikkelaars vroegtijdig toegang kunnen krijgen tot nieuwe elementen in de browsers voor OS X en iOS.

De Safari Preview kan apart van de gewone Safari browser worden gedraaid en slaat ook al zijn data apart op. Wel synchroniseert de browser favorieten en geschiedenis via iCloud wanneer dit is ingeschakeld. Dat is een verschil met testversies van Safari, zoals Apple die tot nu toe uitbracht. Ook krijgt de browser elke twee weken een update via de Mac App Store.

Op het gebied van JavaScript biedt Preview ondersteuning voor EcmaScript 6. Ook wordt het geleverd met de B3 JavaScript JIT-compiler en heeft het een verbeterde IndexedDB-implementatie voor dataopslag en toegang. Wat html-verbeteringen betreft is gekozen voor de toevoeging van de nieuwste versie van Shadow Dom voor het tonen van elementen op webpagina's en hoe die samenwerken met een andere applicatie. Verder is er ondersteuning voor Content Security Policy Level 2.

Ook staat de browser ontwikkelaars toe om gebruik te maken van de meest recente versies van Web Inspector en Responsive Design Mode. Deze laatste wordt gebruikt om te websites te maken die werken op verschillende apparaten zoals pc's, tablets en smartphones.

Safari Technology Preview is voor iedereen te downloaden via de ontwikkelaarssite van Apple. De browser werkt alleen op apparaten met OS X 10.11.4 of nieuwer. De browser verschijnt in het dock met een paars Safari-icoontje, in plaats van het klassieke blauwe icoon.

Safari Technology Preview

Moderatie-faq Wijzig weergave

Reacties (116)

Prachtig hoor, maar je hebt er als Windows gebruiker helemaal niks aan!

Waar Microsoft netjes Virtualbox/VMWare images beschikbaar stelt, met verschillende versies van Windows en IE, zit je bij Mac OSX en dus Safari met de gebakken peren. Je moet een iMac (oid.) aanschaffen om Safari mee te nemen in de browsertests.
Ik ben web dev van beroep, maar ook al jaren aan het sleutelen aan mijn persoonlijke website/CMS voor eigen gebruik: denk je nou echt dat ik geld ga uitgeven (aan hardware danwel virtuele omgevingen) om die site in een bepaalde browser of op een bepaald platform te testen? Ik kan onder Windows kostenloos praktisch alle browsers redelijk tot goed testen - met uitzondering van - surprise, surprise - Safari (ongeacht OS) - tenminste niet zonder links- danwel rechtsom de knip te moeten trekken.
Ik weet dat ik hierdoor een flink deel van de markt een ongeteste website voorschotel, maar tough luck, so be it: zodra Apple besluit om gewoon normale ontwikkel-tools voor web bouwers beschikbaar te stellen voor ontwikkelaars die werken op Windows (zoals de rest het wel doet), dan zijn zij als eerste aan de beurt. Tot die tijd: hopelijk is Safari's webkit-implementatie robuust genoeg om zich als een normale Chrome browser te gedragen.

[Reactie gewijzigd door w00t00w op 31 maart 2016 14:17]

*geeft w00t00w een biertje*
Zo denk ik er ook over, al werk ik op Linux. Still same problem.

[Reactie gewijzigd door hackerhater op 31 maart 2016 15:07]

Ze hadden een Build versie voor Windows. De gedacht was meer Safari gebruikers - Ún - tools voor ontwikkeling. Maar ondanks alle inspanningen lukte het ze niet om op Windows dezelfde resultaten te boeken als die Safari in iOS. Div's werden niet goed uitgelijnd etc. Afijn, lang verhaal kort - dat gaan we niet meer mee maken. Apple is zijn eigen eco-systeem aan het redden. Die hebben op dit moment geen behoefte aan een Microsoft die ze gaat vertellen hoe het moet.. die tijd komt nog wel :Y)
Je zegt het goed, ze 'redden' hun eigen.. Voor de rest bakken ze er dus niks van, waar een microsoft dat wel kan.. Daarnaast, Chrome werkt toch ook gewoon op Linux/Windows/ Mac? Dus je zegt eigenlijk zelf al dat Apple minder goed is in software schrijven dan zelfs een Microsoft, die wel veel systemen port naar andere OS. :)

[Reactie gewijzigd door DutchKevv op 1 april 2016 16:04]

Ik denk dat Microsoft zijn gratis systeem toch nog net iets beter is dan BrowserStack zijn minimum bedrag van 30 euro per maand.
Ja dat is natuurlijk een hele mooie oplossing, maar niet voor iedereen interessant. Kost je toch 29 dollar per maand, terwijl het gebruik van de genoemde images van Microsoft gratis is.
Apple maakt erg mooie producten, maar die bovengenoemde instelling van Apple laat mij er instinctief met een boog omheen lopen. Ze proberen de consument echt op alle mogelijke manieren arm te maken en tot zijn dood te 'binden' aan het Apple eco-systeem. Vaak noemen ze het zelf 'quality-insurance'.. Met andere woorden, ze kunnen alleen garanderen dat een stukje code werkt als het binnen hun eigen systeem/app-store draaid. Maar vreemd genoeg brengen ze dan Apple-music wel uit voor android, want 3x raden, daar valt geld mee te verdienen.. Maar een fatsoenlijke app om je gegevens over te zetten vanaf IOS/OSX zullen ze echt niet doen hoor, alleen een 'zoethoudertje'

Ik ben trouwens zelf een Javascript developer en hoop dat Apple weer wat meer aandacht aan Safari geeft.. Hij begint langzaam maar zeker de nieuwe IE te worden, gezien hij aardig wat 'quirks' begint te krijgen door te tijd heen

Bijvoorbeeld:

typeof window.FormData;

Chrome -> Function
Firefox -> Function
Safari -> Object :s

window.FormData is een constructor, die je oproept als 'const formData = new Formdata', dus per definitie een function. En zo zijn er nog wel meer

[Reactie gewijzigd door DutchKevv op 31 maart 2016 12:34]

Een function is in JavaScript altijd een object (per definitie). Returned Safari niet gewoon altijd "object"? (Ik weet het niet, nooit op getest, maar dat zou een vrij logische verklaring kunnen zijn)

Ik heb trouwens letterlijk nooit problemen ondervonden met Safari, zolang ik me netjes aan de algemene specificaties hield. En de web-dev tools vind ik persoonlijk veel prettiger werken dan Chrome en Firefox. (Dit is persoonlijk natuurlijk)
Technisch gezien heb je gelijk inderdaad, een functie is inderdaad een Object (alles is praktisch een object in Javascript geloof ik).. Maar toch returnen alle browser 'function' ipv 'Object'.. Als je in Safari bijvoorbeeld een 'typeof' doet van alle andere functies, returned hij ook 'function'..

Bijvoorbeeld in Safari -> typeof Array.prototype.indexOf = 'function'.. Dus persoonlijk zie ik het nog wel als een quirk, gezien alle andere functies wel gewoon als 'function' ge-returned worden door Safari, behalve de constructor van FormData

[Reactie gewijzigd door DutchKevv op 1 april 2016 11:41]

Apple maakt erg mooie producten, maar die bovengenoemde instelling van Apple laat mij er instinctief met een boog omheen lopen. Ze proberen de consument echt op alle mogelijke manieren arm te maken en tot zijn dood te 'binden' aan het Apple eco-systeem.
Leg eens uit? Waarom kan je niet overstappen van Apple producten naar iets anders? Ik heb het zelf diverse keren gedaan. Begonnen met een Mac, toen Windows PC, later weer Mac, nu Linux, Windows en OS X, iPad, Samsung tablet en Sony Android telefoon. En vanaf alle devices bestanden beschikbaar middels mijn Synology NAS, Dropbox en Google Drive. Ik speel films af van mijn NAS op mijn Apple TV die ik start vanaf mijn Android telefoon, en kijk in de slaapkamer films op Chromecast die ik start via mijn iPad. En dat allemaal met standaard producten.
Tot zover de mythe van het gesloten Apple systeem.

[Reactie gewijzigd door GJvdZ op 31 maart 2016 18:14]

Ik neem aan dat je je NAS verbind met icloud? Je agenda netjes gesyncd word met je android apparaat als je je @me account gebruikt? Je telefoon nummers niet stuk voor stuk /1 op het einde toonde toen je je nummers overzette????? Je via IMessage niet andere gebruikers op kosten jaagt zodra je een foto als MMS verstuurd? Zoja dan ben ik benieuwd hoe je dat gedaan hebt.. Want het feit dat jij iets 'kan' streamen vanaf je android naar tv zegt natuurlijk compleet niks.. Wellicht gebruik je er compleet ander stuk software voor

[Reactie gewijzigd door DutchKevv op 1 april 2016 17:06]

Als niet-webdeveloper verbaast het mij dat dit nog niet bestond.
Safari is een beetje gaan achterlopen in de afgelopen jaren op veel zaken. Wellicht heeft dat ook iets te maken met het feit dat google voor chrome al enige tijd geen webkit meer gebruikt maar zijn eigen fork hiervan.

Sowieso leek het also Apple safari op de desktop niet zo heel belangrijk vind. Zo hebben ze recentelijk hun developer programma's gelijk getrokken. Wat in theorie natuurlijk prima is, ware het niet dat vanuit het niets extensie developers nu iets van $100 moeten betalen om een extensie gepublished te krijgen. Iets wat voorheen geen geld koste.

Dit allemaal zorgde er voor dat je de afgelopen tijd meer gemopper kon horen binnen development kringen over safari. Wellicht dat dit een reactie hier op is.
Maar of die fork van Google nu zo'n goede ontwikkeling is... Ik kan me nog maar al te goed een tijd herinneren van IE6.
Dat heeft er toch niets mee te maken? Zolang Google zich aan de standaarden houd moet dat te doen zijn
Geen ÚÚn browser houdt zich voor 100% aan de standaarden. Iedere browser heeft bugs of kleine interpretatie verschillen. Des te meer afwijkende render engines er zijn, des te meer verschillen er zullen zijn en ook verschillen in wat wel en niet wordt ondersteund.
Webkit nightly bestond al. Nu krijg je de opties erbij die integreren met OS X/icloud.
En daarnaast ook updates te ontvangen via de Mac App Store. Het doel hiervan is het een stuk makkelijker voor ontwikkelaars en net-niet-ontwikkelaars om de nieuwe functies van Safari te testen.
Apple heeft best veel kritiek op Safari gehad de afgelopen paar maanden omdat ze vrij ver achter lopen/liepen qua de implement van nieuwe web techniek, dit is denk ik bedoelt om meer inzichtelijk te maken dat ze er mee bezig zijn
Waarom ze nog steeds het required attribute voor input elementen niet ondersteunen, is me een raadsel.
Super tof dat ze eindelijk met een ontwikkelaars versie komen zoals andere grote browser makers dat ook al doen, maar wat een faal actie weer dat het alleen op OSX beschikbaar is.

Ik wordt zo gek van die vendor lockin, terwijl overal gewerkt wordt aan multi-platform apps/games, je moet op deze manier eigenlijk constant twee development environments onderhouden.
<blockquote><div class="quote">maar wat een faal actie weer dat het alleen op OSX beschikbaar is.</div></blockquote>Wat een faalreactie aangezien heel Safari Darwin-only is. Waarom zouden ze in godsnaam een developerversie voor andere platforms uitbrengen?
En juist dat is zo irritant. Dit heeft tot gevolg dat de sites die ik maak dus niet meer getest worden onder Safari. Ik ben nog bereid een Windows versie onder Wine te draaien of een speciale VM onder Virtual box te gooien (a la hoe MS het op lost), maar ik ga geen mac kopen puur om met een browser te testen.
Tsja, als je professioneel websitebouwer bent is die overweging wellicht anders. Niet in de minste plaats omdat Safari('s) engine de enige browserengine is op iOS.
Ik doe het professioneel. Ik heb een machine (Op Linux) hier staan waar je u tegen zegt qua specs. Die machine draait rustig 3 (Windows) vm's tegelijk zonder morren.

Als ik die specs op een Mac zou moeten krijgen (als het al kan!) praat je rustig over 8000+ euro. Sorry hoor, maar dat heb ik er niet voor over om onder een browser te testen die net misschien 5% marktaandeel heeft.
Buiten dat ik zeer betwijfel of het uberhaupt zou kunnen omdat je de hitte van die octa-core op volle kracht niet kan afvoeren in die behuizingen. Die machine van mij heeft niet voor niets waterkoeling erin zitten.

Nu test ik wel onder Konqueror (KHTML) dus het gros van de bugs zal er wel uitgehaald worden, maar bepaalde dingen die Safari only zijn? Tjah, pech gehad. Had die browser maar een manier moeten hebben om het zonder Mac-hardware te testen.
Mac OS X El Capitan, en oudere versies ook, zijn gewoon te draaien in een virtuele machine.
Kunnen ja, mogen nee. Dat is het probleem.
Als bedrijf hou ik me ver van illegale spullen.

[Reactie gewijzigd door hackerhater op 31 maart 2016 13:31]

<blockquote><div class="quote">Als ik die specs op een Mac zou moeten krijgen (als het al kan!) praat je rustig over 8000+ euro. Sorry hoor, maar dat heb ik er niet voor over om onder een browser te testen die net misschien 5% marktaandeel heeft.</div></blockquote>Als je ook 8k gaat uitgeven aan een browsertestmachine ben je ook een idioot. Je kunt ook gewoon voor 600 euro een mac mini kopen.<blockquote><div class="quote">Had die browser maar een manier moeten hebben om het zonder Mac-hardware te testen.</div></blockquote>Je fuckt je bezoekers hoor, niet de browser.

[Reactie gewijzigd door CyBeR op 31 maart 2016 12:21]

En dan?
Dan zit je met een extra machine aan je bureau waardoor je weer dure KVM-switches nodig hebt als je geen dubbele toetsenborden en muizen wilt neerleggen.

We hebben juist die zware machine om niet tig machines nodig te hebben om te testen. Die VM's worden namelijk ook door mijn vennote gebruikt.
We hebben als VOF namelijk alleen een thuiskantoortje en daarmee een serieus gebrek aan ruimte........
Ik snap je probleem echt niet. Ik ben zelf IOS/ OSX developer en heb gewoon van ieder apparaat waar ik voor ontwikkel eentje thuis staan. Dus een macbook, een iPhone een iPad en Apple TV.
Ik vind het niks anders dan de normaalste zaak van de wereld eerlijk gezegd
En dat is bij mij anders dan?
Ik ben een web-ontwikkelaar, geen OS X ontwikkelaar.
Effectief zou ik zelfs met zo'n mini ruim 1000 euro moeten uitgeven (mini + KVM-switches + extra kabels) voor een browser die nog geen 5% van de markt heeft voor de kleine situaties dat Safari anders reageert dan andere webkit-browsers.

Dat is wellicht leuk als je geld te over heb, maar ik moet als kleine zelfstandige dat allemaal zelf betalen.
Er dan is er een punt dat het financieel niet meer te verantwoorden is.
Waarom moeilijk doen met switches etc? Ooit gedacht aan remote desktop?

Voor 569 euro (inclusief btw) heb je een Mac Mini, deze configureer je goed en sluit je aan bij je andere browsertest machine. Remote desktop en tadaa.
Ik verwijs naar een reactie van mezelf :
Als het feilloos zou werken niet nee, mijn ervaring is helaas dat OS X en Linux elkaar niet lief vinden over VNC. Ben er nog niet achter aan welke van de 2 het ligt.
Teamviewer. Werkt prima.
VNC werkt prima om te testen.
Ik google even voor je: Windows browser based on webkit:

http://midori-browser.org
Euhm lezen?
Ik heb een machine (Op Linux)
Ik gebruik al Konqueror om webkit te testen, dat is het punt niet. Evengoed zijn die browsers niet Safari en merk je daarmee Safari-only bugs niet mee op.
Klikken? Je kan hem ook voor Linux downloaden. Ik dacht dat Konqueror alleen KHTML deed.

Maargoed, als jij echt 100% Safari wilt testen (welke versie?), dan koop je inderdaad gewoon een (tweedehands) Mac mini. Het is zakelijk, cost of doing business. Zo betaal ik ook honderden euro’s per jaar aan MSDN.
Ik ben nu eigenlijk wel benieuwd waar je die 5% marktaandeel vandaan haalt. Op meerdere sites waar ik Analytics draai ligt het gecombineerde gebruik (iOS, OS X) van Safari tussen de 25 en 30% van de bezoekers.

Op Statcounter kom ik al gauw rond de 22% marktaandeel. Die 5% was misschien 5 jaar geleden.

Dus los van het feit dat het inderdaad niet handig is dat Safari alleen draait op Apple devices is Safari iets waar je niet omheen kan als je een serieuze webdeveloper bent.
Het marktaandeel van 1 site zegt niks over het globale marktaandeel. Ik neem aan dat bv. op macrumors.com Safari heel populair is en op KDE.org zal Konqueror dan weer heel populair zijn. Bij de site van de bejaardenbond zal Explorer waarschijnlijk de populairste zijn.
Dus je neemt dan ook aan dat @hackerhater, die zegt een professionele webdeveloper te zijn, alleen websites bouwt die allemaal zo erg afwijken en specifiek zijn dat het aandeel Safari-gebruikers 5% is i.p.v. het gemiddelde 22% gemeten over 3 miljoen sites?

Als je overigens vind dat 5% van je bezoekers het niet waard is om te ondersteunen weet ik niet of webdevelopment het juiste beroep is.
Niet ondersteunen en geen moeite in kleine afwijkende bugs steken is een groot verschil.
De sites zullen prima werken, dat is het punt niet. Wellicht staat het plaatje in Safari 5 pixels verder naar links dan hoort. Dat soort bugs.
Als het martkaandeel zo groot is moet het toch geen probleem zijn om te investeren?
Als je het professioneel doet, gebruik je toch iets als browserstack?
Edit - dubbel

[Reactie gewijzigd door bskibinski op 31 maart 2016 14:39]

Hoe debug je IOS safari dan? Want dat kan alleen met een Safari op een MAC OS..
Niet, simpel.
Het gaat me nog niet eens om het OS. Als het 300 euro zou kosten om in een VM te mogen gooien is dat prima. We willen gewoon niet nog een apparaat in dat kleine kantoortje hebben.
Dus alle sites die jij professioneel maakt zijn niet getest op iOS apparaten?
Vraag ik me ook af.
Dat zou ik (ook web-dev) me niet kunnen permitteren.
Niet door ons nee, wel door de designers die de HTML en CSS aanleveren (als het goed is, dat is aan de klant).
Daar zijn we ook heel duidelijk over tegen de klanten : we hebben niet de apparatuur om te kunnen testen op Safari, dat is voor ons op dit moment financieel niet te verantwoorden.

We testen de sites op Gecko (Firefox), Webkit, Blink (Chrome), Trident (IE) en Edge. Een enkele Safari-only bug kan er doorheen slippen.
Nu zal het nooit zo erg worden dat de boel onbruikbaar is, maar een enkele pixel off omdat Safari raar doet zou kunnen.

Note : we zijn primair een hoster die ook wat website bouw en onderhoud doen. We zijn op dit moment blij dat de boel zwarte cijfers draait. Even ruim 1000 euro uitgeven voor zo'n kleine prutsbrowser is geen optie tenzij de klant dit betaald.

[Reactie gewijzigd door hackerhater op 31 maart 2016 15:50]

Want zo'n Mac mini neemt enorm veel ruimte in. Vandaar de naam...
Het apparaat zelf niet, maar het spul wat erbij komt om hem effectief te kunnen gebruiken om te testen wel.
Een netwerkkabel en een VNC client zijn teveel spul?
Als het feilloos zou werken niet nee, mijn ervaring is helaas dat OS X en Linux elkaar niet lief vinden over VNC. Ben er nog niet achter aan welke van de 2 het ligt.
Vreemd. In mijn bedrijf draaien we uitsluitend Mac en Linux en het werkt feilloos. En niet aanvallend opvatten maar weet je zeker dat je niet iets verkeerd doet?
Dat is niet uitgesloten. Ik ken Linux heel goed, maar OS X niet.
*edit dubbel*

[Reactie gewijzigd door hackerhater op 31 maart 2016 14:47]

Wellicht is Sauce Labs of BrowserStack een oplossing?
Daar zit ik inderdaad aan te denken, maar het is belachelijk dat je niet gewoon een licentie voor een VM mag kopen.
Weet je wat bedrijfs strategie is? Verdiep je er eens in. Apple heeft haar eigen hard- en software. Het ondersteunen van andere platformen past niet in de strategie en dus ligt daar de focus niet.

Andere bedrijven hebben een andere strategie en die ondersteunen wel standaard meerdere platformen. Les 1: vind je niche.

edit: Jammer dat het als -1 wordt gemarkeerd, aangezien het wel degelijk een goed argument is om NIET alle platformen te ondersteunen in een developer versie.

[Reactie gewijzigd door LarBor op 31 maart 2016 11:41]

Precies. En iedereen lijkt te vergeten dat je ook niet "native" Edge en Internet Explorer kunt draaien op een Mac.
Maar je kunt en mßg wel een Windows VM draaien op je Mac.
Maar dat is in principe weer het verschil in business model. Waar je voor de VM een Windows licentie moet kopen, werkt Apple zonder dergelijke licenties voor OS X omdat ze er voor kiezen om het besturingssysteem bij de fysieke computer "gratis" te leveren. Goed, de Windows licentie kost minder dan een willekeurige Mac, maar uiteindelijk betaal je wel voor het gebruik van het besturingssysteem. Ook als je enkel een paar sites in een browser wilt testen.
Waar je voor de VM een Windows licentie moet kopen
Dat is gewoon niet waar, MS levert al sinds jaar en dag special VM images waarop je (bijna) alle IE versies kan testen

https://developer.microso...oft-edge/tools/vms/linux/
Oh, okee. Dat is wel een betere dienst dan de laatste keer dat ik er naar gekeken heb. Toen ondersteunden ze niet zelf alle VM hosts, en waren de licenties maar een paar dagen geldig. Dat vond ik best een vervelend nadeel.
Scheelt een factor 10-20
Dit is gewoon heel logisch voor beta previews, Apple optimized namelijk voor hun eigen hardware eerst. Door deze previews te beperken tot hun eigen hardware kunnen ze ook goed testen of de nieuwe safari op zijn minst fatsoenlijk draait op hun eigen hardware voordat ze verder gaan kijken. Ook kunnen ze makkelijk zorgen dat deze beta previews altijd up to date zijn. Zodra de 1.0 release of de x.0 release uitkomt dan kunnen ze het altijd nog beschikbaar maken op andere platformen.

EDIT:
(Voor de mensen die hier de assumptie maken dat ik hiermee zeg dat Apple Windows of Linux oid. support: Die uitspraak doe ik hier niet. iOS en OSX draaien beide safari maar zijn wel degelijk verschillende platformen.)

Waarom is dit een -1? Dit is gewoon on-topic?

[Reactie gewijzigd door Donvermicelli op 31 maart 2016 12:40]

Uhm, what? Safari is Mac OS X-only, waarom zou dat nu plots terug veranderen?
Nee hoor, het draait ook op iOS, vroeger inderdaad ook op andere platforms maar daar zijn ze inderdaad mee gestopt. Mijn punt was meer dat het logisch is voor de ontwikkelaar van core software om beta versies eerst te testen in hun eigen eco systemen voordat ze verder gaan kijken.

Moet je eens voorstellen als Apple safari wel goed draaiend heeft op Windows bijvoorbeeld maar den zelf op zijn eigen OS het nog niet helemaal lekker heeft draaien. Dat zijn toch verkeerde prioriteiten?
<blockquote><div class="quote">Nee hoor, het draait ook op iOS</div></blockquote>Ja, dat kan iedereen wel concluderen, maar valt niet binnen de context van dit nieuwsbericht.<blockquote><div class="quote">...vroeger inderdaad ook op andere platforms maar daar zijn ze inderdaad mee gestopt. Mijn punt was meer dat het logisch is voor de ontwikkelaar van core software om beta versies eerst te testen in hun eigen eco systemen voordat ze verder gaan kijken.

Moet je eens voorstellen als Apple safari wel goed draaiend heeft op Windows bijvoorbeeld maar den zelf op zijn eigen OS het nog niet helemaal lekker heeft draaien. Dat zijn toch verkeerde prioriteiten?</div></blockquote>Misschien. Maar daar gaat jou reactie helemaal niet over, je zegt dat het logisch is dat Apple Safari eerst goed werkende krijgt op OS X en dat ze dan zouden uitbreiden naar andere platformen alsof het een feit is dat ze dat gaan doen terwijl het dat niet is. Sterker, het is niet eens een gerucht...
Ik zeg alleen dat het logisch is dat ALS je het uitbreid naar andere platformen dat het logisch is dat ze eerst alles goed werkend willen hebben op hun eigen OS. Ik heb het nooit gehad over welke platformen Apple wel support en welke niet.
Onderdeel van Apple's strategie is: eigen hardware met eigen software. Daar past het ondersteunen van andere platformen helemaal niet in. Prima lijkt me. Een goede bedrijfs strategie maakt duidelijke keuzes.
Daar ben ik het mee eens en dat is dan ook precies het punt waar ik ook op doel. Het lijkt alleen dat Loller1 mijn opvatting verkeerd interpreteert.
Nee, jij schrijft het verkeerd neer: "nog beschikbaar maken op andere platformen".
Soms vergeten dat safari al tijdje alleen voor os x beschikbaar is?
Kan ik Edge op mn mac gebruiken ? Nee. Op deze manier hoef je maar 1 development environment onderhouden.
Je kunt Edge in de cloud draaien, niet op OS X. Je krijgt dan te maken met restricties waaronder:<blockquote><div class="quote">Remote is built on top of Azure RemoteApp Preview. You are running IE as a service from a virtualized environment shared with other users so the performance will not be the same as if you were running it natively. Because it is virtualized, GPU acceleration is disabled. This means that WebGL websites will be software rendered.</div></blockquote>

[Reactie gewijzigd door curumir op 31 maart 2016 11:38]

En wat maakt dat uit? Punt is dat Microsoft het wel gewoon aanbied terwijl je bij Apple gebonden bent aan OS X hoe dan ook.
Nooit van BootCamp gehoord?
Maakt dat uit dan dat je nog steeds een Mac nodig hebt ervoor?
Nope. Immers heb je een OS nodig om je PC te kunnen gebruiken. Er werd gesteld dat je op een Mac gebonden bent aan OSX, wat domweg een leugen is.

Sterker nog, je kan zelfs enkel Windows als enige OS draaien op je Mac, als je dat zou willen. Niet aan te bevelen ivm drivers en dergelijke, maar het kan.
Op een Mac ben je niet gebonden aan OS X dat klopt, maar om legaal OS X te draaien moet je een Mac hebben.
Dat staat veel mensen tegen.
En dat puur om een browser te testen.

[Reactie gewijzigd door hackerhater op 31 maart 2016 15:21]

Dan test je het niet voor Safari en blokkeer je de boel voor Safari browsers.... ALs het platform groot genoeg is, is de investering in een Mac niet het probleem. Als je als developer geen 1000 euro kunt investeren rammelt het bedrijf toch al een beetje. I.p.v. een redundant Windows/Linux PC koop je dan gewoon een Mac en sla je 2 vliegen in 1 klap.
Ja, dat kan al tijden. Hier heb je een Virtual Machine voor op je Mac:

https://developer.microso...osoft-edge/tools/vms/mac/

Safari is echt een zwart gat voor ontwikkelaars onder Windows. Gelukkig gebruiken de meeste Apple-bezitters tegenwoordig Chrome, want Safari heeft ook enorm veel beperkingen.
Ook wordt het geleverd met de B3 JavaScript JIT-compiler en heeft het een verbeterde IndexedDB-implementatie voor dataopslag en toegang.
Dat werd eens tijd, Safari is al tijden de meest brakke browser, al lijkt het erop dat IndexedDb nog steeds niet beschikbaar is in webworkers 8)7

https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26

Misschien dat we over een jaar de ervaring op iOS gelijk kunnen trekken met die van Android en Windows Phone. Er is een reden waarom iOS gebruikers gewend zijn om apps te downloaden en de reden is niet dat de browser zo goed werkt.
lol browser werkt prima en snel, op mobiel en op desktop, zie je probleem dan ook niet.
Dan weet je simpelweg niet wat er mogelijk is. Als ontwikkelaar kan ik je vertellen dat het op de andere browsers is het bijvoorbeeld mogelijk om sites te optimaliseren zodat je praktisch geen laadtijden hebt. Daarnaast heb je voor Chrome en Firefox ook nog eens zaken als Service Workers, wat je kan zien als een opzichzelf draaiende proxy in de browser voor je website. De mogelijkheden zijn enorm (updaten op de achtergrond, push notificaties), maar niet op iOS.

Snel is subjectief. Wat jij snel noemt op iOS noem ik retetraag. Secondes wachten tot een pagina is ingeladen. Moet je niet willen.

[Reactie gewijzigd door Bar˘ZZa op 31 maart 2016 15:07]

browsertestjes laten meer dan genoeg zien waar je verhaal rammelt.
En over javascript al helemaal niet te praten.

Dat ie misschien niet alles ondersteunt kan ik in meegaan, maar traag is niet 1 van de issues.
Je kan geen browsertest doen van functies die niet beschikbaar zijn.

Het traagste op mobiel is het heen en weer verzenden van data, niet de uitvoer van Javascript. Dat kan je voorkomen of op de achtergrond laten doen met de eerder genoemde technieken (zonder bijvoorbeeld de UI te blokkeren).

Zie verder voor uitleg: http://www.raymondcamden....edDB-on-iOS-8-Broken-Bad/

Het is verder vrij sneu om te beweren dat mijn verhaal rammelt als je er zelf niet veel van begrijpt.
Je verhaal rammelt omdat je blijft miepen over functies die men 99 van 100x niet nodig heeft, dat maakt de browser niet traag, maar niet functioneel (genoeg voor jou).

Safari is 1 van de snelste browsers qua dom rendering en javascript performance. Dan kun je hoog en laag springen, maar blijft een feit.
Nodig hebben? Het gaat om developers die hun site bloedsnel kunnen maken(praktisch native app snelheid), behalve op Safari. Mag je mij uitleggen hoe je dat niet nodig hebt.

Je klinkt als een fanboy die z'n aankoop verdedigt in plaats van iemand die daadwerkelijk zich verdiept in de onderliggende technologie of die ermee moet werken. Dat rammelt.
Ik surf de elke dag retesnel al jaren met safari, wat mis ik precies?
Je klinkt als zo'n gebruiker die jaren lang IE8 gebruikt en blijft beweren dat hij niks mist omdat hij geen idee heeft wat er tegenwoordig mogelijk is. Jouw retesnel is niet retesnel. Retesnel is 0 seconden laadtijden. Mogelijk in alle browsers behalve Safari.
Dus de data verzint de browser? Nice!
Inmiddels is Chrome hard op weg net zo'n groot probleem te worden als IE met alle -webkitt- prefixes. IE is tegenwoordig (mits je de laatste versie hebt) redelijk okÚ.

[Reactie gewijzigd door Sephyros op 31 maart 2016 11:23]

Ik weet niet of jij laatst nog aan web development hebt gedaan, maar tegenwoordig heb je meer last met WebKit gebaseerde browsers dan wat dan ook. Projecten zoals Bootstrap lijsten meer bugs in Chrome en Safari en ook projecten zoals jQuery moeten de ene uitzondering na de andere inbouwen. En als het op standaarden aankomt is het nu juist Apple die het minst te vertrouwen valt.
Ik ben met jQuery nog nooit problemen tegen gekomen onder webkit. Maar misschien ligt het soms ook aan de programmeer stijl die veel javascript programmeurs aanhouden.
Het zijn de ontwikkelaars van JQuery zelf die de uitzonderingen moeten maken zodat jij inderdaad geen problemen heb en inderdaad geen uitzonderingen hoef te maken. Daar doelt hij op.
Dat zal wel maar als ik kijk naar sommige javascript code, bijvoorbeeld:

(function() {
var h, l = this, n = function(a) {
return void 0 !== a
}, p = function(a, b, c) {
a = a.split(".");
c = c || l;
...

Met dit soort programmeer methodes verbaast het me ook totaal niet dat er continu problemen zijn. Misschien heeft het daar mee te maken?

[Reactie gewijzigd door BoringDay op 31 maart 2016 12:14]

ja, maar dat is niet on-topic. Het ging hier over JQuery die uitzonderingsregels in hun code plaatsen omdat Google en Apple er blijkbaar een potje van maken....
En voor IE geld dat niet? staat er evengoed vol mee
Voor IE geld dat zeker ook, hoewel Edge dit een heel stuk beter doet. Juist met de historie van IE achter de rug moet het toch niet meer kunnen dat dit nog een keer gebeurd?
Jij niet misschien, maar daar heb ik het ook niet over. Ik heb het over jQuery zelf.
Ondanks jQuery handig kan zijn, code van meer dan 10000 regels onder elkaar geplakt ... :?

[Reactie gewijzigd door BoringDay op 31 maart 2016 13:39]

jquery is a library/api, de code die poste is a door een tool verkleind om zo min mogelijk ruimte in te nemen.

Omdat Javascript in de browser geladen moet worden is het efficiŰnt om zoveel mogelijk code in 1 bestand te zetten om het aantal calls dat de browser moet maken om bestanden op te halen te verminderen.

Wat je dus ziet is niet de code waar programmeurs mee werken, maar een ingepakte versie die een snelheidswinst oplevert en alleen bedoeld is om te draaien binnen websites.
Ok daarvan was ik niet bewust. Het leek me al zo onbeheersbaar, maar je uitleg is helder.
Ik begrijp waarom je wat aanvallend reageert met betrekking tot standaarden en webkit, je reactie bevat absoluut een kern van waarheid. Het voornaamste probleem ligt mijns inziens echter meer bij de leken die experimentele features (vendor prefixes zijn een indicator voor "experimenteel") in productie zijn gaan gebruiken. Vanaf het begin af aan zijn de vendor prefixes bedoeld om non-standard features beschikbaar te maken, dat gegeven is echter (ondanks herhaalde waarschuwingen vanuit de community) een beetje vergeten door webdevelopers.

Deels is het probleem voor in ieder geval de echt nieuwe features opgelost door deze achter configuratie opties van de browser te verstoppen, zodat ze simpelweg alleen beschikbaar zijn in je eigen omgeving. Er zijn echter nog steeds heel wat features die de browsers niet zomaar achter een vlaggetje kunnen stoppen, juist omdat deze zo veel in het wild gebruikt worden.

De browsers zijn anno 2016 meer compatible dan ooit, kijk bijvoorbeeld alleen al naar hoe sterk de footprint van jQuery is geslonken sinds het de support van een aantal browsers heeft gedropt (v2.0+).

We zijn er nog lang niet, er zijn nog meer dan genoeg verschillen en bugs in alle browsers. Safari is daarop zeker geen uitzondering, deze heeft vrij veel nieuwere features Řberhaupt niet ge´mplementeerd, echter is de absolute koploper op het gebied van "onjuist/onvolledig ge´mplementeerde standaarden" (om het woord "bugs" te vermijden) op dit moment toch echt Blink (Chrome), waarschijnlijk omdat zij ook het snelst nieuwe features proberen te implementeren (zelfs al voordat de specificaties ervan de "candidate" status krijgen).
Het probleem ligt niet echt bij leken die experimentele features gebruiken als je het mij vraagt, maar eerder bij Webkit/Blink in dat die experimentele features nogal te vaak in de engine zetten zonder flag en/of experimentele functies er zo lang in laten zitten dat het zich gewoon te wijd verspreid.
Ik gebruik het alleen, omdat het soms niet anders kan. Maar ik heb echt een zware hekel aan Chrome. 't Is een enorme batterij- en geheugenvreter. Ik bedoel, mijn MacBook Pro heeft een accuduur van zo'n 10 uur. Maar dat is zeker een paar uurtjes korter als je gebruikmaakt van Chrome. En dan is het nog eens zo dat Safari perfect integreert met iOS-apparaten en daarnaast iCloud-ondersteuning biedt, dat heeft Chrome allemaal niet (alleen op beperkte wijze).

Het is dat bepaalde sites simpelweg niet of slecht werken in Safari, anders had ik Chrome allang van m'n Mac gegooid. :P

[Reactie gewijzigd door DutchTech op 31 maart 2016 11:45]

Ik hang altijd aan de lader ;) dus daar heb ik nog nooit op gelet :) en iCloud gebruikt ik niet, gebruik one drive business..
Mijn Mac hangt ook voor het grootste deel aan de lader, maar dan nog ben je niet helemaal van de issues af: geheugen schiet gelijk vol, zelfs met maar ÚÚn of twee tabbladen. Niet dat Safari zo lief omgaat met m'n 8 GB RAM, maar die gebruikt het nog wel op efficiŰntere wijze.

Ach, gelukkig is het echt alleen maar voor bepaalde zaken. En wie weet wordt Safari dusdanig verbeterd met de volgende OS X/macOS-versie, dat Chrome helemaal niet meer nodig zal zijn. :)
Haha Chrome komt er bij mij niet meer op. Chrome trekt na 5 uur de accu geheel leeg waar ik met Safari 10 uur haal.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True