5 ms·
Flash ran in Safari on MacOS until 2020.
by pram 5y ago
Flash ran in Safari on MacOS until 2020.
- noduerme 5y agoSure. But it was dead by then. Apple led the charge to kill it, and the main argument given was that Flash was susceptible to past, present and future use-after-free attacks, like the Java VM or anything else that ran as a black box and managed its own memory. And now we're close to square one on that, which is a natural result of people wanting functionality in-browser that mirrors a desktop experience, including APIs that reach out beyond the sandbox. From Apple's point of view, Safari itself is probably one of their biggest liabilities. If they could eliminate browsing the open web completely, that would solve all these problems (except, obviously, whatever they miss in app store review).
- aspyct 5y agoFlash was a nightmare on mobile and made pretty much half of the internet unusable on a smartphone (yes, half. Remember those menus in flash?). It was also indeed full of security flaws that Adobe was suuuper slow to patch, if at all. Eye candy was their priority, not the web's wellbeing.
- GhettoComputers 5y ago>Eye candy was their priority, not the web's wellbeing. It was very easy to make stuff on it it was developer and artist friendly (still has lots of cool stuff that doesn't exist), it was a standard, but performance wise it sucked, and I would find it interesting for you to tell me what "web wellbeing" is. I would say that any analytics, advertising, and (my most controversial opinion) javascript is bad for web wellbeing. Every issue you leveraged against flash is the same with javascript.
- aspyct 5y agoI didn't say we're making good use of javascript either...
- GhettoComputers 5y agoShould we ban it?
- noduerme 5y agoI think Apple's end goal in ten years is to ban browsers in general. They're just a way for people to get content without paying Apple for it.
- noduerme 5y agoThe way poorly written JS clogs up web pages is worse than Flash ever was. Flash didn't have access to the DOM, except to send messages. Pages now are slower and heavier than ever. And back in 2010 or so, when Flash plugin was still available in beta on iOS and Android, but was declared "too slow" or too heavy on the battery, I wrote an extremely fast-for-the-time <canvas> based screen graph to do some side by side comparisons of manipulating sprites, animating vectors, masking touch areas, blitting some basic particles, etc. Javascript performance was not even close to Flash performance in an iPhone. It really has never gotten close, even with much faster processors and with v8, to replicating on canvas what Flash was doing. Only via WebGL has it become possible to get mobile graphics performance in the browser now resembling what Flash could do in 2010. So the performance complaint was, as far as I'm aware, a lie. The security complaints were, indeed, legitimate; and it's true that Adobe sucked at patching them, and Flash was a dangerous point of failure for corporate networks. That being said, it would have been a lot better if Adobe and Apple could have come to an arrangement to base a standard off of it. Instead what we have is a million workarounds to achieve the same effect, and we still have a huge amount of terrible, web-choking code all over the place. It's just in untyped JS, which is worse. Bad code is always bad code. At least with Flash you could kill the process without killing the page.
- aspyct 5y agoI didn't say we're making good use of javascript either...
- duskwuff 5y agoWhile security was one of the concerns which Apple brought up in "Thoughts on Flash" [1], it was a relatively minor one. The big highlights were standards compliance and performance. [1]: https://web.archive.org/web/20100501010616/http://www.apple.com/hotnews/thoughts-on-flash/ https://web.archive.org/web/20100501010616/http://www.apple....
- jmull 5y agoSecurity was just one reason Apple didn't like Flash. Also, it was really Flash's own limitations that killed it on mobile (which, it turn killed it on desktops). Don't forget it was on Android for a while and aggressively marketed as an advantage over iOS. But it was also a poor UX (slow, power-hungry, designed for mouse & keyboard not touch) and a propriety third-party black box. Apple didn't so much kill Flash as just be the first to see it coming and act on it.
- noduerme 5y agoAs someone who was developing browser-based games in the space at that time, there was hardly a better option for touch interaction then. True, lots of older hover/highlight code just didn't work, and that was a pretty common thing with Flash. But all UX in Flash was built by coders who are now working in JS. It was entirely up to coders what to do within the box. Now the box is the whole window of the browser.
- jmull 5y ago> there was hardly a better option for touch interaction then Native. That's what Apple wanted (and still wants) you to be doing. To address your point more generally, though: that HTML 5 -- or some other technology -- was as bad as Flash in some ways is not a sufficient reason to support it. Flash was worse than the alternatives is some ways (and critically so in some cases, e.g., wrt power) and didn't offer any unique killer capabilities.
- noduerme 5y agoIt had a couple killer capabilities (to me). I did a lot of work with the Starling engine, and Away3D. And although this conversation is about browsers, a lot of my work was deployed via AIR, which still limps along, but I wouldn't invest in it now. Being able to deploy the same 2D/3D games on any platform and on the web with native GPU access is a killer app - and the best contender now is probably Unity. The ability drive fast vector animations without recourse to SVG or something, all within one dev environment and without many dependencies, provided an incredible workflow from artists to coders. Certain things that were taken for granted in Flash, like the native engine for determining mouse/touch position over layers and layers of different vectors (not bounding boxes) are still incredibly hard to replicate. Whole new platforms had to be written in JS to support these kinds of occlusions and improve rendering performance to a tolerable point. Things we have now like Pixijs would have absolutely destroyed the battery life on a 2010 iPhone. You're spot on that Apple always wanted native code, and still do, but what small studio has time to write everything three times? The idea of deploying and maintaining totally separate code for a casual game on Android and iOS and the web is a deal-breaker for a 5-person team, and putting all your energy into one walled garden is not what's best for the developer.