One thing Flash had that nothing else has really seemed to replicate as well since, is an environment that both coders and artists could use. I'd collaborate with an artist, they'd make their animations within an FLA, send it to me, and then I'd copy+paste into the project file, and it'd just work. I could even tweak their animations if need be to remove a frame here or there to tighten the animations and make it feel more fluid, etc.
That being said, I'm not sure I could go back to it now. I've been working with Love2D lately, and I prefer that (especially for the version control). FLA version control was always me going 'GameName-1.fla', 'GameName-2.fla', or when I got a little smarter 'GameName-Date.fla'. Eventually they let you split out the actionscript files into its own files, and that was better for version control, but you still had the binary mess of the FLA file.
But all these sprite-based game editors just can't handle the crazy intricate animations that vector-based Flash games could handle. Porting one of my old games (Clock Legends) that had hundreds of frames of hand drawn animation for a boss that filled the screen would be ridiculously huge nowadays, but the FLA for that was like 23MB, I believe (I'll need to hunt it down, I have it somewhere), and several MB of that were for the songs in the game.
Excited for this project though. It deserves to come back in some form.
I built a flash crawler to index all Flash while at Adobe. It started with Alexa top 1M I think then crawled. This was 2008-2010 I think so we had to do a lot of custom stuff, but we basically crawled then ran a headless Firefox with a custom headless Flash player that dumped a ton of data so also analyzed every flash at runtime and indexed all of that.
We built a dedicated cluster in a colocation center in Bucharest to handle all of this. Had issues with max floor weights and what not. Then had to upgrade the RAM on on the cluster. No remote hands. Every operation was a trip to a really cold place.
Used a lot of early stage stuff like Nutch, Hadoop, HBase etc. Everything was then processed and dumped to an SQL database with a nice UI on top. It took a few weeks to set it up, then we passed it to a team of interns that built the SQL database and UI on top. They learned a ton of stuff. Some are now in the Bay Area.
The tool uncovered a ton of security issues.
It was fun building it. I wonder if Adobe kept the data. It could be useful and/or good donation for the Computer History Museum.
Thanks for sharing. It's stories like these I've read since childhood that got me into this. Those little adventures into remote places to work on some computers. This was my version of Indiana jones.
Think in this day and age starting your project off saying it's open source but making sure to open the patreon first and take money before the repo is a bad start when the reason for the project existing is a closed source paid product is being discontinued.
Especially if the dev is working on a sound editor, something Flash doesn't actually need before even having an outputted example up and running or even a video of it working.
> .fla / XFL import — This is the one I’m most proud of. You can open your old Flash files. As far as I know, this is the only open-source tool that functions as a full authoring environment and can actually import .fla files. Not just play them back — edit them.
The backwards compatibility here is pretty clutch. I agree -- if he can build something that is compatible with old files AND pushes things forward for new, then this could do some really awesome stuff.
AFAIK the .fla format was never fully documented or reverse engineered by anyone (FFDEC has an exporter, but not importer), so this alone would be a bold claim.
".fla / XFL import — This is the one I’m most proud of. You can open your old Flash files. As far as I know, this is the only open-source tool that functions as a full authoring environment and can actually import .fla files. Not just play them back — edit them."
I wish Adobe had open sourced Flash - it really was a pretty amazing tool. They could have owned the proprietary developer tool market to support themselves...
A lot of people - including studios who use it for projects that can take years to complete - were very unhappy at the prospect of having the only tool that can read their mountains of FLA files (the file format the Flash/Animate editor uses, and used to compile into a SWF) stop working because Adobe turned off the auth servers. Adobe has pulled back to "okay we're, uh, putting it in maintenance mode, expect no new features, ever, just security patches".
Exciting! But I can't seem to find any where I can take a peek. It looks like a lot of UI is at least there, and the post makes some big promises about what's already done.
The vector icons in the side bar have the distinct cruft of LLM-generated SVGs, so just ideally hoping it isn't a quickly-made UI shell. The big claims about .fla import make me a bit skeptical. Though even so, we're not owed anything and I think it's a cool idea to share!
Apart from the HTML5 export mentioned by another commenter, there exists Ruffle[1], a Rust + WASM reimplementation of Flash that can play swf files. It's used a lot on archive.org or on some websites like https://homestarrunner.com.
They may but note that this isn't an official Newgrounds project - this is just a user ("Bill") posting on his own Newgrounds blog that he has made this (its not Newgrounds' official blog).
Approximately a quarter century of editor UI muscle memory in everyone who's used Flash/Animate professionally. And a quarter century of people being used to the precise quirks of how Flash/Animate organizes the parts for a cartoon. And a quarter century of source files in a private format that can only be read and understood by Flash/Animate.
I remember trying out Macromedia Flash 6.0. My GUI apps were ugly at the time. Learning to build something like I saw in the movies could take years. Then, Flash let me throw together beautiful, animated interfaces like it was nothing. One could do quite a bit after one tutorial.
(Note: Quick shoutout to Dreamweaver 6.0 which was a power, WYSIWYG editor. Today, things like Pinegrow might fill the niche.)
It's death as a hugely-popular tool was largely due to Apple and Adobe. SaaS model isn't helping it far as wide adoption goes. It also got popular through piracy which hints the replacement should be profitable and widely deployed like open source.
I think this might be a good opportunity for a license like PolyForm Non-Commercial. Free users either can't commercialize their content or, like CompCert Compiler, must make the outputs GPL'd (or AGPL'd). The Flash replacement would have a fair, one-time price for unrestricted use with source or you share like they shared with you. What do you all think?
Of the two, I think Adobe is most responsible for the decline of Flash. Even if smartphones had never entered the picture, laptops (where efficiency is important) were quickly becoming the most common form of PC, which would've eventually made Flash as it existed under Adobe untenable as well. The timeline was just accelerated by smartphones.
Honestly I can't understand the mental calculus that went on in the heads of Adobe execs at the time. Yes, cleaning up the ball of mud that the Flash codebase had become and making it not so battery hungry wouldn't have been an easy task, but it would've futureproofed it significantly. Instead they decided to keep tacking on new features which ended up being entirely the wrong decision.
EDIT: The constant stream of zero-days certainly didn't help things either. A rewrite would've been worthwhile if only to get a handle on that.
I think Apple is more responsible. One of Flash's chief benefits to the customers who paid the big bucks was that it 'just worked' everywhere. Once Apple stopped supporting Flash on the iPhone, that story was a lot less attractive.
The bugs were definitely Adobe's fault: as with most tech companies, they were far more interested in expanding the feature set than they were on fixing the bugs and stabilizing the platform.
Flash was not particularly battery hungry (My go to example when HTML 5 demos started coming out was rebuilding a HTML 5 demo that was using 100% of 1 core into a flash app that used 5%).
The reason it burned CPU cycles is that non-coders could make programs with it and they would produce the world's worst code doing so that "worked". The runtime itself was fine (efficiency wise, not all the other things).
The "pay to sell your work" model is basically what Autodesk does to provide a version of Fusion that's free/accessible to the hobby 3d printing market while still protecting their b2b revenue.
I haven't looked in a while, but I believe there's music and audio production tools with similar approaches.
I don't think a modern flash would come after web app UI in the same way it once did. The niche this would fill would be in web games/interactive media I think.
One thing Flash had that nothing else has really seemed to replicate as well since, is an environment that both coders and artists could use. I'd collaborate with an artist, they'd make their animations within an FLA, send it to me, and then I'd copy+paste into the project file, and it'd just work. I could even tweak their animations if need be to remove a frame here or there to tighten the animations and make it feel more fluid, etc.
That being said, I'm not sure I could go back to it now. I've been working with Love2D lately, and I prefer that (especially for the version control). FLA version control was always me going 'GameName-1.fla', 'GameName-2.fla', or when I got a little smarter 'GameName-Date.fla'. Eventually they let you split out the actionscript files into its own files, and that was better for version control, but you still had the binary mess of the FLA file.
But all these sprite-based game editors just can't handle the crazy intricate animations that vector-based Flash games could handle. Porting one of my old games (Clock Legends) that had hundreds of frames of hand drawn animation for a boss that filled the screen would be ridiculously huge nowadays, but the FLA for that was like 23MB, I believe (I'll need to hunt it down, I have it somewhere), and several MB of that were for the songs in the game.
Excited for this project though. It deserves to come back in some form.
We built a dedicated cluster in a colocation center in Bucharest to handle all of this. Had issues with max floor weights and what not. Then had to upgrade the RAM on on the cluster. No remote hands. Every operation was a trip to a really cold place.
Used a lot of early stage stuff like Nutch, Hadoop, HBase etc. Everything was then processed and dumped to an SQL database with a nice UI on top. It took a few weeks to set it up, then we passed it to a team of interns that built the SQL database and UI on top. They learned a ton of stuff. Some are now in the Bay Area.
The tool uncovered a ton of security issues.
It was fun building it. I wonder if Adobe kept the data. It could be useful and/or good donation for the Computer History Museum.
But everyone's in an AWS world right now.
Especially if the dev is working on a sound editor, something Flash doesn't actually need before even having an outputted example up and running or even a video of it working.
The backwards compatibility here is pretty clutch. I agree -- if he can build something that is compatible with old files AND pushes things forward for new, then this could do some really awesome stuff.
We can't trust closed source software for content creation tools.
What happens when he gets bored?
However, I LOVE C# and would totally be down to contribute if it's open source.
as to when they share the source, idk!
A lot of people - including studios who use it for projects that can take years to complete - were very unhappy at the prospect of having the only tool that can read their mountains of FLA files (the file format the Flash/Animate editor uses, and used to compile into a SWF) stop working because Adobe turned off the auth servers. Adobe has pulled back to "okay we're, uh, putting it in maintenance mode, expect no new features, ever, just security patches".
The vector icons in the side bar have the distinct cruft of LLM-generated SVGs, so just ideally hoping it isn't a quickly-made UI shell. The big claims about .fla import make me a bit skeptical. Though even so, we're not owed anything and I think it's a cool idea to share!
Is it targeting the web? If not then it's not going to be useful for the same things as Flash was.
[1] https://ruffle.rs/
> HTML5/Canvas export — Export to self-contained HTML5 with JavaScript Canvas 2D playback.
(Note: Quick shoutout to Dreamweaver 6.0 which was a power, WYSIWYG editor. Today, things like Pinegrow might fill the niche.)
It's death as a hugely-popular tool was largely due to Apple and Adobe. SaaS model isn't helping it far as wide adoption goes. It also got popular through piracy which hints the replacement should be profitable and widely deployed like open source.
I think this might be a good opportunity for a license like PolyForm Non-Commercial. Free users either can't commercialize their content or, like CompCert Compiler, must make the outputs GPL'd (or AGPL'd). The Flash replacement would have a fair, one-time price for unrestricted use with source or you share like they shared with you. What do you all think?
Honestly I can't understand the mental calculus that went on in the heads of Adobe execs at the time. Yes, cleaning up the ball of mud that the Flash codebase had become and making it not so battery hungry wouldn't have been an easy task, but it would've futureproofed it significantly. Instead they decided to keep tacking on new features which ended up being entirely the wrong decision.
EDIT: The constant stream of zero-days certainly didn't help things either. A rewrite would've been worthwhile if only to get a handle on that.
The bugs were definitely Adobe's fault: as with most tech companies, they were far more interested in expanding the feature set than they were on fixing the bugs and stabilizing the platform.
The reason it burned CPU cycles is that non-coders could make programs with it and they would produce the world's worst code doing so that "worked". The runtime itself was fine (efficiency wise, not all the other things).
I haven't looked in a while, but I believe there's music and audio production tools with similar approaches.