Blocked is the wrong word. It implies that Apple had to take some action to stop Flash from working, which would otherwise be the natural way of things.
They didn't implement flash in Safari, which is where you're right.
But they also disallowed any interpreter on iOS, so even if Adobe wanted to make a flash player on iOS (there was a rumored prototype), it wouldn't be allowed in the app store anyway.
I understand why stuff like this had to be made in Flash in 1999, but in 2014, client-side web development is in a much better place. When Apple blocked Flash on iPhones, we were forced to adopt and improve open standards instead of relying on proprietary software.
Maybe you're only considering one aspect of it, namely if it runs everywhere or drains certain batteries faster? I certainly had a lot more fun coding GUI on Flash than I've ever had with the three donkeyman of the apocalypse. It was a much higher level of abstraction than what can be provided by current tools.
* Because I can use any editor I like - free, open-source, paid, whatever.
* Because I can build and use tools which are themselves built on top of the standards, and choose which tools I want (SASS, LESS, CoffeeScript, etc).
* Because I can build responsive websites that work on screen sizes from watches to 60" TV screens.
As IT support:
* Because my users don't have to frequently upgrade a bit of software which most of the time offered little benefit, but big security risks.
As a user:
* Because I can use just about any browser I like, and (usually, at least) get at least some experience of the website more than "Sorry, you don't have Flash installed, so bugger off."
* Because the user experience has become a lot more consistent. Weird navigation controls have become outliers rather than standard.
I have no ideological opposition to Flash, more to the way it was used. While Flash was popular, the progress of open standards was slow because it was less urgent.
>* Because I can use any editor I like - free, open-source, paid, whatever.
You can write .as files in any editor and compile via the command line...
>* Because I can build and use tools which are themselves built on top of the standards, and choose which tools I want (SASS, LESS, >CoffeeScript, etc).
There was a very active OS community, lots of frameworks, tools and libs.
>* Because I can build responsive websites that work on screen sizes from watches to 60" TV screens.
I'll give you watches, but responsive design is a concept that can be carried out in any language. Flash apps actually responded quite well to screen resizing, more so than the table layout HTML that was the alternative for most of it's life.
>As IT support: * Because my users don't have to frequently upgrade a bit of software which most of the time offered little benefit, but big security risks.
Could make the same argument for most software at the time, even now most browser and OS updates are security based.
>As a user: * Because I can use just about any browser I like, and (usually, at least) get at least some experience of the website more than "Sorry, you don't have Flash installed, so bugger off."
This is a good point, but these days people are only developing for <your browser> version x and above. So no real change.
>* Because the user experience has become a lot more consistent. Weird navigation controls have become outliers rather than standard.
The same people that designed flash websites are now designing HTML ones, the technology hasn't dictated that change, I expect it is down to the prevalence of UX.
>I have no ideological opposition to Flash, more to the way it was used. While Flash was popular, the progress of open standards was slow because it was less urgent.
Indeed, but the progress of Flash was very fast as it didn't need a commity, without it the web would likley be very far behind.
So what did the kids do? "Oh no, our tools are fine, but those annoying problems? Hey, let's bolt on more tools, like various flavours of compile-to-CSS languages, client-side frameworks, framework generators, package managers, test frameworks, test framework generators, etc. etd.". I'm learning about a new tool that is "absolutely needed by any self-respecting JavaScript developer" literally every week.
The web nowdays is run by fashion designers and fashionistas.
[0] - and I hope I'll be able to find something more interesting to do soon, but for now, one has to eat and pay the bills.
This generation is only just starting to learn important lessons that the wider programming community learned decades ago about maintainability, portability, the pros and cons of standardisation and of rapid prototyping/evolutionary development, how to design systems of non-trivial scale that can remain useful for extended periods, how to balance the overheads of introducing external dependencies with the benefits of using ready-made, tried-and-tested code and tools, and many other similar issues.
Consequently, that new generation is also only just learning how limited and unfit for modern purposes a lot of the foundations of front-end web development really are. As a direct result, we're now seeing a vast wave of tools, plug-ins, libraries and frameworks designed to paper over the cracks that should never have been there. And because there is little co-ordination or standardisation in the industry, there is also unfortunately a huge amount of wasted work, both for developers of those tools and libraries who are doing the same things repeatedly for no great benefit, and for the potential users who have permanent analysis paralysis.
That much will improve as the industry matures and consolidates, though I fear we are now stuck with HTML/CSS/JS as our foundation, at least until the successor to the Web comes along with things like interactive sites and security-by-default as primary design goals.
If you live in NYC, let me buy coffee/beer/whatever sometime - I don't know anyone personally that agrees with me on those things.
Client-side web development (meaning HTML/CSS/JS) in 2014 is in a much better place than client-side web development in say 2009 or 2004.
Whether it is in a better place than what could be achieved with the main plug-ins in 2009 or even 2004 is more debatable.
HTML/CSS/JS has won, but I'm not sure that victory had much to do with the technical capabilities of the development platform or the quality of its surrounding ecosystem. If the browser+plug-in model hadn't been such a security disaster and if Apple hadn't forced the issue for iOS devices, things might have been very different today.
In particular, we might by now have evolved a safe, fast, flexible plug-in system to add rich content to web pages and control how everything interacts. Instead, we rely on underpowered HTML5-based alternatives like canvas, SVG, and HTML5 media elements, all controlled with only a single, far from ideal programming language.