- it was owned and controlled by a single company and thus a target for other companies instead of other companies helping to improve it
- that single company was unable or unwilling to fix security holes in the sandbox and browser makers eventually got fed up with that
- while there were some ways to interact with the underlying browser environment, ultimately a Flash instance lived in its own little bubble, creating usability problems
Putting the HTML+CSS layout engine into a separate module doesn't mean that it wouldn't remain the standard way of doing document-layouts on the web, it would just mean that higher-level solutions wouldn't need to use hacks and workarounds to map their concepts to HTML+CSS (same way as Javascript had to be used as a less-than-perfect compile target before WASM because it was the only option to run code in a browser).
The thing is, most people don't want a blank canvas to go nuts with for the general use case. It's too complicated. Suddenly you need to learn entire SDKs and pull in many dependencies just to render text on the screen.
The reason HTML and the web was so well accepted back in the day was all you had to learn were a few HTML tags, a couple of properties and then drop it onto a Geocities site and you were good to go. It was something you can do and see real progress on in 10 minutes with very little background knowledge.
Compare that to now where if you wanted to be a "trendy front-end dev" you would probably reach for Vue / React + Webpack* and go SPA style for all of the sites you make because you learned something and now you want to apply it everywhere. Meanwhile to serve a document such as a blog post, you just went from having 15 HTML tags in a single HTML file and some CSS to pulling megabytes of Javascript sprawled across hundreds of dependencies and now you have build tools, an entire runtime environment (Node) and are using APIs that don't exactly match up with HTML exactly, and then your entire site isn't even crawlable by search engines unless you introduce even more complexity to do server side rendering and before you know it, you're dealing with something that's even more complicated than Flash was back in the day.
* I personally use Webpack to handle my assets too, but I don't write SPAs for sites that are document based (which tbh are most sites).
Are you kidding me? Flash was an absurdly popular platform. Careers were launched on Newgrounds!
I'm not saying it wasn't popular, but what do you think the percent spread was between sites that were fully driven by Flash vs not Flash?
I don't have the stats in front of me, but I would guess it was probably 2% Flash vs 98% non-Flash. Now, a lot of sites had sprinkles of Flash but very few sites in the grand scheme of things were solely rendered with Flash. Part of the 2% were sites like 2advanced studios.
...yeah, because that's not what Flash was about. Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.
And this is exactly what I'm trying to say.
Back in the day you would very likely reach for Flash if you wanted to build an FTP client that ran in a browser. Totally reasonable use case because that's a highly interactive app that doesn't really follow the request / response style of a document style page. But you likely wouldn't reach for Flash to build some type of site that presented data in a document style (pretty much the general use case of what a website outputs).
But if you fast forward to today's technology, some front end developers are bringing in the complexity of creating SPA style applications that are primarily rendered with JS for everything -- even document style websites like a personal blog and the original comment I replied to is hinting they want to remove constraints from browsers to give us more of a FFA style of doing whatever we want to render pages. I was just saying that model didn't really take off for the general use case with Flash decades ago.
Fortunately we still live in a time where web developers can choose what they want to do, but browsers shouldn't change the concept of being something that renders HTML that is optionally combined with other things like CSS, fonts, JS and images.
If people really wanted a no constraints platform to build any UI they want with a blank slate then web development as we know it today would be a completely different environment.
Instead, 20 years later, we're still trucking along with HTML as being the primary focus, and everything else can be loaded as needed.
You can build some pretty amazing things today with a combination of HTML, CSS, JS, fonts and websockets. But at the same time, if you don't need an application and just want to serve a HN style site, you can render HTML with a bit of CSS and everything works well. To me, that's one hell of a success story.
I'm not sure that happened. My friends and I got on MSN Messenger and shared flash sites all the time. Kongregate and similar gaming sites were part of it, but so was YouTube, and so were greeting card sites, ESPN, various other news sites and many, many others.
At least from my POV, maybe a few people hanging out places like here didn't like flash, but the general population had no problems with it until Steve Jobs did his best to kill it. Even then, people not on iPods/Pads/Phones didn't seem to have any problems with it. AFIK, the fast majority of people still installed it years later.
- It wasn't visually scalable. (Today we say "responsive", mostly, but that's too easy to confuse.)
- It didn't integrate with HTML and CSS in any interesting way other than sitting there in the middle.
- Performance was mediocre to terrible.
- A rent-seeking company was in charge of it.
As you say, eventually JS supplanted it.
Regarding integration, some text elements featured basic HTML capabilities. Nothing terrific, but you could extend on this. (And, of course, XML parsing, but this is another story.) Also, later Flash Player applications (Air) featured a full-fledged WebKit element for rendering web views. That said, it was good thing that Flash had eventually to go, and, at times, the state of the web today is pretty reminding of this.
For the user, flash applets where super easy to block in general and to whitelist on pages where you wanted to use that particular flash application. Basically the same was true with Java. And for a certain extend JavaScript -- until the ugly DHTML menus arised and websites stopped to be usable without JavaScript.
Nowadays there are only two options: Either you block JavaScript --- and percieve a 1995's web view, in general --- or you let it run on your browser, having tons of programs running which you probably don't want (ads, tracking, that particular application that replaces flash).
Flash tried to do this 15-20 years ago. Flash was basically "here's a canvas, do whatever you want within reason". It had its use cases back then but the general web vastly preferred good old HTML and eventually CSS and JS.
There's a lot of value in having constraints, especially when those constraints (HTML) are specifically designed for displaying documents.