Have they? I would say the subsequent ~10 years of the web have vindicated Flash. HTML5 video hasn't made websites lighter or less annoying - quite the opposite (indeed video ads are a worse problem than Flash ads ever were). Meanwhile creativity and innovation on the web have taken a hit. 10+ years on there's still nothing that allows a lone auteur to produce a web experience as easily and effectively as you could with Flash (it seems to be possible to match Flash, a la the NYT's Snow Fall or the previous Madogatari intro, but not at a level that's accessible to an individual creator), and we're all worse off for it.
As someone that helped a little bit in bringing Flash to WebOS, it was a battery stuck because there was no HW acceleration. Additionally, the software was very very bad. Used a crapton of memory, was really slow, and horribly insecure. Adobe was caught really off guard by mobile and never prioritized flash. If little else, the modern web is infinitely more secure than the flash player and Adobe would never have prioritized it. We also have ~3 major open source browser engines that independently implement the web compared with one closed source vendor. So structurally things are also infinitely healthier. That the web is a cesspool in turns of content is an orthogonal problem that would have always been the case (but also a flash laden website are up way more RAM and CPU than the equivalent html)
> it was a battery stuck because there was no HW acceleration. Additionally, the software was very very bad. Used a crapton of memory, was really slow, and horribly insecure.
Surely lack of hardware acceleration and poor implementation are incidental, not fundamental issues. Just as browsers eventually got their own PDF implementations because Adobe's sucked, I expect the same would have happened for Flash eventually.
> We also have ~3 major open source browser engines that independently implement the web compared with one closed source vendor.
We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
> Surely lack of hardware acceleration and poor implementation are incidental, not fundamental issues.
Of course not. These are just some of the many many needles of crap that broke Flash.
> I expect the same would have happened for Flash eventually.
Perhaps you underestimate just how complicated "Flash" is: It's 2023 and despite everything you can do in a modern Web browser with HTML5, SVG, JavaScript, Video and so on, we still don't have a second full reimplementation of Flash. No emulator or converter that preserves all of the authors intentions, not even with a server-side-helper to cover the differences in networking policies between the web and Flash. I still think it would take serious cash/time to do this.
And for a large company to do it would risk being sued by Adobe. They promised. I think if Adobe couldn't fix the crap-needles for whatever reason, nobody else could either. Adobe made sure of that. And nobody wants to pay the Adobe tax when Flash hurts users so bad.
PDF on the other hand, is easy enough to implement on screens in a month or less, spec-in-hand. Users who use Adobe's PDF reader deserve what they get.
> We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
I do feel a little better off. I remember a time when every flash bug was an opportunity to airdrop malware, just buy an ad and get on every desktop PC in the world for chump change. I had to browse the Web in a VM, back when VM's on workstation PC's were still painfully slow, because I needed the ability to rewind state so often. I really don't miss that.
A small number of players working (largely) openly (i.e. we have webkit and gecko's source code!) allowed features to the Web be deployed relatively quickly, and problems fixed fast and usually with the smallest-possible harm. And I think people are sufficiently suspicious of closed-source infrastructure that people (mainly purchasing VPs at big enterprises) will be able to resist any attempts to change that.
Lovely points you bring to the table, agreed on all fronts. Just wanted to add that there is definitely a decent attempt at creating that implementation though: https://ruffle.rs/
Thanks for a nice writeup! Regarding "for a large company to do it would risk being sued by Adobe" - what do you know about "Pepper flash plugin", which was shipped with Chrome at some time? Back then I had an impression that it was an alternative implementation of flash player, but developed by Google.
I think Pepper was just the name of Google's extension API, and so Pepper Flash was just a (re)packaging of the flashplayer artefacts from Adobe. My memory of this was that it was pitched (to users) as a "safer" flash, since it could take advantage of Google's isolation/sandboxing features, but I don't have any special knowledge here: I just made a shittonne of flash stuff back in the day.
We also have iOS, Android, ChromeBooks, Tizen, macOS, GNU/Linux, games consoles, TVs, tablets, home assistants like Echo Show, and a dozen other platforms I’ve not thought of.
Whereas back in the flash days there was basically just x86 desktop Windows and the few other web enabled devices were niche and didn’t properly support Flash.
The Dreamcast had a browser (based on IE) but suffered from an ancient version of flash. PDAs were uncommon, also had a browser based on IE, and also suffered from a crippled version of Flash. Smartphones were a few years off and when they did arrive also had a crippled version of Flash (or no support at all).
Flash was a format for a different era. An era when Microsoft had suffocated the tech industry. The fact that we can now view basically any website on any hardware is a massive step forward.
I agree that the modern era of the web has its problems too (I’m looking at you Google, Facebook, etc) but having been a developer and early adopter of the web, I’d still take modern web technologies over Flash any day of the week.
> Whereas back in the flash days there was basically just x86 desktop Windows and the few other web enabled devices were niche and didn’t properly support Flash.
It wasn't quite that bad. I was running FreeBSD at the time and Flash was fine there. In fact I remember for a few years it was easier to have working Flash than working "web video".
I ran FreeBSD too but FreeBSD didn’t have the official Flash plug-in. In fact for a long time Flash didn’t support anything aside IE. Not even Firefox nor Opera (remember that?). And even when Flash did eventually get ported to more platforms, half the time it still required a bunch of jacks to get working (like Firefox using Chome’s Flash plugin)
And as good as the 3rd party hacks were, they didn’t work all of the time. I remember a few sites I needed for work which required me jumping onto a Windows VM just to use.
There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
> And even when Flash did eventually get ported to more platforms, half the time it still required a bunch of jacks to get working (like Firefox using Chome’s Flash plugin)
I had to put some kind of wrapper in, and I think it was actually using the Linux version of the plugin, but it all worked pretty reliably once it was there.
> There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
I'm talking about slightly later, when people were pushing "web video" as a replacement for Flash for e.g. YouTube. Flash was more reliable and better supported on FreeBSD for some time, is my recollection. Although honestly straight-up <embed> also worked fine and I never felt that the move away from that was really justified.
I seem to recall the Linux plugin used to ramp up the CPU load. Which wasn’t so much of an issue on desktops but was extremely annoying on laptops where battery life was dependent on heavy CPU throttling and most laptop fans spinning up sounded like jet engines.
As for the early days of web video, I think half the problem was that nobody could agree on what video format to support. Some wanted patented formats while others (namely Firefox) wanted open source formats.
I’m not sure what the end outcome was of all that but it does feel a resolution has at least now been found.
Blink (Chrome/Chromium-derived browsers) is a fork of WebKit but has diverged for many years. To treat them as the same, you should call them KHTML as that’s their common lineage. But that would be obviously absurd.
Apparently, the x86 version of Flash was extremely well-optimized and as a result very spaghettified. So even porting to 64 bits took Adobe years of effort.
One thing that helped was ability to have shapes with fill on each side of the edge, allowing smoothly joined scenes that can be animated at real-time. All without the use of high-precision math, Flash used integers only with some fixed-point data!
> it was a battery stuck because there was no HW acceleration. Additionally, the software was very very bad. Used a crapton of memory, was really slow, and horribly insecure.
That’s like saying there’s nothing wrong with Word because you could just build your own version. Adobe controlled the format and since they didn’t care about quality, performance, security, or tool quality that doomed it.
The other big thing which hit Flash was mobile. Rearchitecting it to support the equivalent of the web’s responsiveness was a huge problem which got lost in the “Steve Jobs killed Flash” narrative. Battery life wasn’t the only thing which made it unpopular on mobile – that could have been improved even though some aspects of the platform made that hard – but also the fact that Flash was based around mice and fixed-size displays. Very little of the existing content worked well (often at all) on the mobile devices which did have Flash.
Vector graphics designed for a desktop display or a printed page generally do not work well on small displays unless scaling to fit or scrolling is acceptable. I can hardly imagine what one would do to make something like SVG reflow in a sensible way. Line of business (web) applications often have the same problem, i.e. there is often a display size below which they simply are not usable, and that should be no surprise to anyone.
Flash Lite was not really "Flash". It didn't support older ActionScript, it had extremely limited codec support (relying on a device's hardware support), and was missing a lot of the network features the desktop plugin had. Generally it wouldn't be able to load arbitrary SWFs off the web. Even to run a SWF the developer needed to write to the Flash Lite profile, like targeting a MIDP profile in J2ME.
Flash Lite was usually used on the devices you mention as the "app" environment instead of J2ME, BREW, or whatever.
This keeps coming up, but it keeps seeming hogwash & backwards.
There are dozens & dozens of really really good html/svg animation products that give Flash like capabilities. But there's vastly less interest in this stuff today. Fun/simple/quirky Flash-like stuff isn't nearly as unique or novel, now that we have much more upscale products & experiences. It was a magical time & Flash helped, but we've changed & these rose-colored glasses views on Flash never point out all the myriad of ways it was awful, choppy, poorly integrated, quirky to work with, & otherwise difficult.
If you want higher there are hundreds of web-dev targeting game dev systems which can be put to use. Many of these actually do have popularity. In spite of their being good Flash-ish animation toolkits, it doesn't feel like there's a ton of demand or clear winners. It's hard to imagine what we'd want it for today.
The loss of the mouse and keyboard as primary input devices is an underrated part of why everything feels worse now compared to the flash era. Web is a very different target now than it was. Also, the flash game ecosystem was intertwined with the animation ecosystem and the advent of streaming full motion video devalued animation skills.
Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
> The loss of the mouse and keyboard as primary input devices is an underrated part of why everything feels worse now compared to the flash era.
It's okay to say "please visit this from your computer" when someone opens something that requires a keyboard from a phone.
> Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
The barrier to entry is considerably higher with these things. They require programming from the beginning. The coolest part about Flash was that you could get started without writing a single line of code. Then you could build up your understanding of the thing iteratively. You could build a simple quest-type game with just one line of code that you copy-pasted from somewhere, `goToAndStop(frameNumber)`. And then you go from there — variables, flow control, all that. Flash got a sizable number of people interested in programming. This ease of use is extremely important and it's still unmatched by any purported modern replacements.
I think the demand is there, but you underestimate how much difference the tiny inconveniences make. Like, maybe there's stuff out there that can do the same thing, but the people who are just starting out don't know where it is (hell, I'm an experienced programmer and I don't know where it is) or what to pick up. A lot of those great Flash works were made by literal schoolkids, or more often by young adults who'd got their start as schoolkids and gradually refined their craft, because you could just pick up Flash and start doing things, and kids did. From what I hear maybe Roblox is filling the same niche now, but that's only happened in the last few years, and for all that Flash was notionally proprietary and poorly-integrated with the open web, having it right there in your browser was still a win.
I wouldn’t touch any of those game systems with 10-ft pole. Their user bases are too small to be worth using. They also don’t at all compare to the Flash IDE.
Flash was great because it was popular and supported with the weight of a big company that loved its own child. Their love translated to great tooling.
Whereas the web is “community-owned” and community/committee-designed things rarely get super cool and fleshed out things like well-integrated for-everyone tooling. Instead, you mostly get self-serving projects that serve the creator’s own need primarily. Usually half-baked. And it’s not interoperable with anything else.
I was a Flash developer and have searched everywhere for a comparable tool. None exists. Recently I have worked on interfaces for touch screen kiosks, and digital signage. Flash was excellent for these kinds of projects and 10 years later nothing compares.
Flash games and animations were cool, but it seemed like for every cool thing made with flash there was also a terrible SWF-as-a-website that didn't play nice with browser window resizing and was more frustrating to use than even the worst modern JS-mudball monstrosities. At least content blocker extensions and reader mode can somewhat salvage bad sites… with flash pages you got the whole thing or nothing.
Oddly enough your comment made me think of electron apps vs native apps, because they are usually impenetrable to accessibility APIs so they appear as completely opaque apps with no a11y affordances.
To me that highlights how important it is for UI frameworks of all types to have accessibility affordances not only built in, but as one of the pillars of their designs. That makes it so even apps developed without any regard to accessibility are reasonably accessible by default.
This doesn't gel well with the bring-your-own-everything nature of the web, unfortunately. Even if you look just at React there's 50 ways to build the same thing, which I'm sure makes rolling in accessibility that "just works" across all React apps without additional effort from the developer extremely difficult. It's much more practical with UI frameworks that are strongly opinionated with only a single well-supported "happy path" for most things.
Seems like a solvable problem in the medium term - Electron apps are, in effect, a web page; build an accessible page, the Electron runtime _should_ be able to join the dots same as a full browser does.
It seems like a lot of frameworks used with Electron are the "reinvent every HTML tag as a component with divs" variety. So unless a developer hangs a bunch of event handlers off some widget they don't have default handlers for a lot of accessibility. If they used a real tag they'd get a bunch of free accessibility/functionality but instead they use components.
This brings back memories. 20 years ago, I was managing a band in New Orleans (by an amazing coincidence I'm in New Orleans for a 2 day trip now), and I decided to make them a website. It being 2003, I did the website in flash, and with my zero coding skills at the time ... it still came out pretty awesome. Wish that still existed.
I don’t get the love for Flash on Hacker News. It’s very odd to me to see people say they prefer Adobe’s proprietary format and software to the open web.
I'm all for open source but I don't let that blind me to product quality. Same thing with Discord - yes, I'd definitely prefer an open system, but if this specific proprietary thing has a better UX then we should be honest about that.
Technically it's not the fault of the videos that web standards now allow easy embedding, it's still the people abusing it to show you video ads. Just saying it's worse than Flash... it's like saying browsers should not show non-animated images because you can have ad banners.
Sure, but that was an argument used by anti-flash people at the time. (And if anything it was a lot easier to block flash on some pages than block web video on some pages - indeed I remember some browsers started to be click-to-start-flash by default).
