Hacker News new | past | comments | ask | show | jobs | submit login
Goodbye, Flash (googleblog.com)
331 points by tech234a 14 days ago | hide | past | web | favorite | 333 comments

Designers loved Flash because it was WYSIWYG. It's also why PDF lives. You usually only had to test it on one computer, not different versions of different browser brands. The client-side "auto-flow" of HTML browser drives designers batty. I can relate: I make CRUD GUI's and different browser variations butcher their placement to hell and back, requiring me playing Whack-A-Mole to fix it. The online forums say, "Shut up and learn layout rocket science!" A few snotty Sheldons mastering auto-flow math doesn't scale well.

The browser should have a WYSIWYG mode for when your application needs it. The server could re-scale as needed for different devices based on a layout engine of the designer's choosing. That way one is dealing with one layout engine instead of say 50 (browser brand/version combos). Seems more logical to me. We don't need auto-flow rocket science if we just partition layout engines logically.

I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers. If they had focused on just UI "serving", they could have been small enough to be manageable.

WYSIWYG mode, unfortunately, ignores the needs of screen readers and other methods of accessing content. The risk of WYSIWYG tools is they lie to you; not all your users can actually see what you see. And that's to say nothing of the less exotic scenarios like different screen sizes or devices.

... unless you're working in a space allowed to discriminate against users that need assistive access to your content of course, in which case you can spring for the WYSIWYG dream.

If screen reader accessibility was the only thing holding us back from a WYSIWYG dream, I would advocate just maintaining separate content-only versions of all pages.

I don't think that's actually where we are though. As you touch on, code is inherently necessary in order to build responsive pages. A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior.

>"A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior."

I know what you mean wrt fixed-width layouts, but want to point out that reflow is the default browser behavior in the absence of problematic markup and styling rules. That's the beauty of mobile-first RWD and progressive enhancement when done right; the starting point is just the content, full stop. The first media query is the absence of support for media queries. Then min-width rules to guide layout changes across progressively larger breakpoints.

> A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior.

This is no longer true. CSS grid solves this completely.


Changing the layout of a page just because the window was resized is moronic.

Because if a page designed for ~1200 pixels across looks like crap on a mobile phone in portrait mode, it's the user's fault for using a damn phone?

I don't think it's realistic to declaratively define a UI that works well under both a 15 inch screen and a 2 inch screen. One is probably going to have to programmatically take different courses of action under each of those scenarios. For example, for mobile you'll probably want to split actions into multiple screens that are best done in a single screen with a big monitor.

Visually designing is by definition allways for people who can see.

And for those who cannot, there can and should be a simple htmltext fallback.

But that should not cripple the manority who enjoy nice looking things, which are way easier to achieve with WYSIWYG tools which is why flash was loved among designers.


You know that the "j" and "n" are next to each other on the keyboard?

And apart from that, are you sure that I am the ignorant one, when I wrote "there can and should be a simple htmltext fallback."?

Anyway, since your needs seem to be, being self righteous, I won't interfere with that anymore.

One should not go using terms like "discriminate" against people who are clearly not doing so.

Assistive access to content is an afterthought for almost everyone in software, and that's perfectly fine. It's an extremely uncommon and unnecessary use case for nearly the entire device-using population.

>Assistive access to content is an afterthought for almost everyone in software, and that's perfectly fine.

It's not perfectly fine - it's illegal.


That’s actually just straight-up not true, and there is case law that shows it. [1] [2]

In addition, the ADA wouldn’t apply to non-US entities, either way.

Not saying I disagree with the idea in general; in fact, I think we should make our websites accessible because there is a large population of disabled folks who use the internet and should have access. But it’s absolutely not illegal, unless your online presence very closely mirrors a physical store. [3]

[1] https://en.m.wikipedia.org/wiki/Young_v._Facebook,_Inc.

[2] https://en.m.wikipedia.org/wiki/Ouellette_v._Viacom_Internat....

[3] https://en.m.wikipedia.org/wiki/National_Federation_of_the_B....

Show me where the ADA says that software developers must think about assistive access to content, and that not doing so is illegal.

What you have cited here is an issue of compliance for certain public services and commercial products, and you are attempting to justify thought police and the private regulation of development of software standards/protocols with it.

EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?

It's in title III of the ADA, if you want to read it.

However because of the way US law works, you probably need context on court cases, such as the recent supreme court ruling:


Going back to GG(G?)P, if you're writing software outside of the commercial or government space in the US, then maybe you're fine not complying with accessibility guidelines in the ADA, e.g. screen readers or what have you.

If you're outside of the US, then I don't know what protections there are.

But in the US, for commercial or government purposes, then yes, it's illegal in the above sense.


borski above describes context pretty well too, since it depends on the commercial context in which you're operating

Edit 2:

also this latest ruling is new enough that we'll have to wait to see how the dust settles w.r.t. new lawsuits

That case has not yet been decided. There has been no ruling. The only thing SCOTUS did by denying cert was to allow it to proceed to trial.

Robles hasn't really shown that Dominoes failed to provide a _reasonable accommodation_, which is typically the key phrase in the ADA. Depending on the business, making a site accessible can be quite a costly project for quite a small number of customers. Finally, that case is only up for debate due to Dominoes' _physical presence_; Robles is arguing that he's being denied access to the physical stores, which pertains to prior rulings.

Robles claims Dominoes failed to comply with the Web Content Accessibility Guidelines 2.0. Keep in mind that this standard has been created by private industry and _not_ by the government.

Interestingly, if anything is going to get Dominoes, I bet it will be the coupons available only via the web site or app. Anything else they could probably make the case phone/physical options are fine.

9th Circuit's over-ruling of the dismissal by district; can't say I agree with all of it, but worth reading: https://cdn.ca9.uscourts.gov/datastore/opinions/2019/01/15/1...

To my (IANAL) nose, this is a good dissection.

The risk with making business decisions around language like "reasonable accomodation" is that the criteria for "reasonable" can change. I'm not an expert in the space, but the watchdogs I read are smelling a change in the wind direction towards increased scrutiny of web accessibility (relevant interest groups are watching the web eat e-commerce and are concerned about what that looks like if the accessibility drum isn't beaten hard early on in the process). Lawsuits like this are expected to increase in 2019.

> Show me where the ADA says that software developers must think about assistive access to content, and that not doing so is illegal.

The ADA is not software specific, but specifies that you must provide access. Courts have been increasingly interpreting that to include websites. See the recent Domino's case where the circuit court ruled the website must be accessible (the Supreme Court declined to hear the case, so it is technically only binding precedent within the 9th circuit - western states, including California) https://www.reuters.com/article/us-usa-court-dominos-pizza/u...

> EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?

It isn't the ADA, but Europe has explicitly adopted WCAG 2.1 accessibility standards: https://www.w3.org/blog/2018/09/wcag-2-1-adoption-in-europe/

> Europe has explicitly adopted WCAG 2.1 accessibility standards

This is precisely how we get closer to the achievable goal of assistive accessibility becoming a non-concern in software. The WCAG is nowhere near the same thing as the ADA. In fact, as a person with one of the things that qualifies me as a person with a "disability" I consider the ADA an offensively non-viable and absurdly non-enforceable "law."

I'm curious in what way. Because I have friends who are very active in the local community ensuring compliance with the ADA, so if there's a blind spot they should know about, I would like to pass it on to them.

The blind spot is in using legal violence to coerce people into being "considerate" of people with disabilities. Assistive accessibility is a god damned gold mine for whichever company solves the problem in each industry. Flash's use on the web led to far more good things than bad, and this one bad thing is really just being heightened because the media places falsely high emphasis on being worried about people with disabilities.

The fact is that we have many, MANY advocates who are all a lot nicer, more helpful, and more effective than Washington, DC.

You can't force people to be considerate.

... which is why we have laws to force people to do the right thing even when they don't have the right emotions behind it. I think we're coming at this from two different directions; the people I work with have come to learn that if you don't beat the drum more or less continuously, things don't get better.

Not nearly enough folks are inclined to be considerate; consideration without force of law just isn't good enough.

The law says "reasonable accommodations". Spending 30% more on IT is not "reasonable" in my book. Spending millions to help a handful of people is not "reasonable".

Of course, it is situational. Your main product or service should be accessible, but ancillary and blue-moon information is too expensive to keep compliant.

One org provided statistical reports to the public. But the format was not ADA-friendly, and reworking hundreds of reports would cost tens of millions. So they stopped providing the reports.

Weird. I wonder which org.


That sucks for me. I'll have to tell my friends in the disabled community they hate me. :(

Passive discrimination is still discrimination. Changing the terminology doesn't change the reality.

Which is why it's not a bad idea to stick close to the base HTML spec unless you have a real good reason to deviate from it or use advanced features, JavaScript based animation, etc. Because HTML is a document format not a render format, staying close to home on the spec gives you a lot of accessibility for free. Not all of it, images of course are still just binary blobs without more metadata, but you cover a lot of ground.

A website in flash got approximately zero of that for free, and it was a known issue in that era. Accessibility suffered.


Two things:

a) the context of the entire conversation is Flash and the web. If you can point me to developers that are writing airplane autopilots, astronomy signal processors, reactor core monitors (oh God), or video compressors in Flash, you are welcome to bring those categories into the conversation.

b) you're applying moral judgement to a statement of fact. I'm not. Everyone discriminates. There is no such thing as universally-accessible software (if nothing else, it fails the first test "Not everyone has hardware to run it"). The reasons we discriminate and the consequences of that discrimination are what matter. I'm personally against the casual, thoughtless discrimination that can result from declaring the HTML render model "too hard" and throwing up one's hands without considering how all relevant user agents that can consume the model do, but if one has considered those user agents (and the users behind them), it can be a valid decision a company can make.

... all of that having been said, for at least the set of developers whose primary target is "the web," not having thought once about assistive access is a mark of an amateur. You can cover a lot of ground in this industry as an amateur, but you'll be held to a higher standard by huge swaths of potential jobs (banks care, universities care, government websites care, consumer websites that do enough business to notice if they lose ~2% of users care). And the nice thing about HTML as a technology is that more often than not, if you do almost nothing, you'll cover 90% of use cases for assistive access.

Ohhh, I came really close to finding that astronomy signal processor that I wrote in Flash in 1999, but nope.

(No, of course it didn't go into production; Flash VM was way more complicated than the custom hardware we were using. I did a Flash one because I wanted to see if I understood some of the details, and wanted a little animation. I didn't. I learned a few things, though.)

No points. Dang.


See (a). My opinions change if we aren't talking about websites intended for public consumption.

So by that logic we shouldn't bother with wheelchair ramps because nearly the entire population has working legs. Nor should we bother with Braille on signs, since nearly the entire population can see just fine.

I've had to do the reverse... building an accessible application meeting specification requirements because it's used by government bodies. On the flip side, the core functionality of the application (reviewing scanned documents) requires a sighted person to use it.

It really does and should be determined by the specific use case. Yes, most sites should be and many are pretty accessible by default. Using Axe, Wave, Lighthouse and other tools is easy enough and should absolutely be done as part of a web application's development. That doesn't mean that everyone who doesn't do it is someone who should be ostracized and cancelled by reactionary mobs.

I agree, and I don't think anyone is calling for anyone to be ostracized and cancelled by reactionary mobs.

Why the hell would you jump to this conclusion?

Any software professional knows just as well as I that these concerns are specialized and people with a particular interest in complying with these special use cases are paid for their particular interest and capability in worrying about, and complying with, regulations within the realm of assistive access.

Most software developers think about getting their software to work correctly, not about edge-cases dealing with the UI for tiny, specific disenfranchised groups of people.

EDIT: Even if we were just to stick to the US, only 2.7 million people use a wheelchair here. That's 0.9 percent of the US population. That's really, REALLY freakin' specialized. Don't stoop to heaving virtue my way when the facts hurt.

EDIT#2: Perhaps you can quantify your ridiculous statement by telling me how the developer of this [0] application should be punished for not building assistive access into his GPLv2 project, and how he should have & could have actually done so.

[0] https://github.com/falkTX/Carla

> Why the hell would you jump to this conclusion?

Why wouldn't I? Your argument appears to boil down to "well not caring about blind users is the status quo, so no reason to change it". I can guarantee you there were similar attitudes among construction workers and architects before wheelchair ramps became mandatory in various jurisdictions (and hell, even after): "well the vast majority of people wanting to enter this building have working legs, so why should I be assed to build a ramp when a staircase will do?".

If you can't be assed to write software that's accessible to blind people, then that is - by definition - discrimination against them. It's not even hard to make a web page reasonably accessible; plain HTML (with or without CSS) is typically perfectly usable with a screen reader, and it's only when that gets mucked up by a tangled mess of DOM-mangling JS (or Flash or Java or Silverlight once upon a time) that anyone needs to actually put any significant effort into accessibility.

> Most software developers think about getting their software to work correctly, not about edge-cases dealing with the UI for tiny, specific disenfranchised groups of people.

The whole point of the ADA (and its counterparts in some other developed nations), is that building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.

I agree, that

> building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.

should be the thing we pursue. This will happen when people who care about assistive access technologies finally make solutions that are easy to implement into normal contemporary software development workflow. Online video had the same challenges but due to corporate and commercial interests we solved that problem already, arguably a much harder problem to solve than assistive access. I know because for many years I worked on precisely these kinds of assistive access concerns in the audiobooks industry. I am certain that we are not there yet, but we will get there one day.


> The whole point of the ADA

None of this is the point of the ADA. The only "whole point" of the ADA is to regulate particular aspects to certain commercial and government services/products.


I love automatic door openers for those days I have to heft some big dumb package in and out of the office.

... and I'm extremely confident that without the law forcing them to, no office I ever worked in would have spent $2,200 per door on that feature, no matter how useful it is to everyone on the odd day.

The curb cut effect. It turns out that accessibility features are often useful for able bodied people.

One thing I like about accessible websites is that writing scrapers for them are so much easier.

At this point it would be cheaper to make a large investment into Boston Dynamics to develop walking chairs, instead of continuing with ramps and other things meant to accommodate wheelchairs.

How does that help the person with a baby stroller, or people who walk well enough for everything but stairs?

It doesn't until the robots become cheap enough, but even before that baby strollers are much less sensitive to some amount of stairs than wheelchairs are.

Do you want fewer small businesses? Do you want everything to be more expensive for everyone? There are jobs where people realistically have to be able to carry over 50 pounds. Not everyone can do that, do you want anything over 50# to simply be banned?

Why are “number of small businesses” and “price of goods and services” relevant metrics here? We don’t create accessibility laws because of economics, we do it because it’s the right thing to do. If that means fewer small businesses, so be it.

Because not everything can, or should be usable by all of the population... Should all countertops have adjustable motors to change height before you can sell a house? Someone who is 6'7" tall can't really use the same counters comfortably as someone in a wheelchair.

The fact is, nothing is, has been or ever will be completely fair. And that's okay. Everyone makes decisions based on their environment. Most accessibility laws are only applicable to organizations of a certain size, which isn't even most

You're arguing scale, and I agree that it's probably not possible to make everything accessible (not until we get those brain-controlled robots, anyway ;) ).

But if the question is "Where do you set the bar," we already have laws for that. Are they too many?

I think in some cases yes, in others not so much... I mean in Cali, there are places that literally don't have a restroom for customers because of risk of suit over buildings nearly half a century old.

For others, maybe not as much. In the end, it's a balancing game, and I keep seeing discussion (especially political) lose all sense of nuance or negotiation.

Treating people with disabilities as an afterthought is very much a form of discrimination.

WYSIWYG does not preclude accessibility. Macromedia and/or Adobe could have added accessibility features to the Flash player.

... and they chose not to. Which is one of many, many reasons why their products have fatal flaws in the eyes of many.

That's not true. Flash had accessibility features added to it some time ago:


I disagree WYSIWYG or coordinate-based positioning inherently "can't do accessibility". It perhaps may take more discipline to make sure the necessary meta data is supplied to the client, but it doesn't outright prevent it.

PDF's, for example, can be made accessible if created properly.

Nothing says accessibility needs to be immediately incorporated into the same content as the non-accessible content.

Restaurants can offer Braille menus. They aren't forced to put translations in Braille immediately next to every piece of text on the menu they give to everyone.

Sure, but if they offer Braille menus, but then they just render photographs of menus on their website (instead of the text itself), they're likely opening themselves up to a lawsuit.

... granted, they're also screwing themselves over because anyone trying to integrate something like UberEats against them to provide delivery is gonna skip them over for the competitor with the more-easy-to-scrape online presence. ;)

>It's also why PDF lives.

PDF lives because it's ubiquitous and stable, despite really rough tooling. If you don't have Acrobat it's a bit of a nightmare to work with, simply because it's so opaque. Yes, you can decompress a PDF to text and look through it by hand, but you need to learn the syntax and know how to use an extensible text editor with the write add-ons; this isn't something your average person in an office will know how to do.

The lack of discoverability is evidenced by the number of posts on Stackexchange etc. that answer "how do I losslessly recompress a PDF?" by giving a command that actually performs lossy downsampling. Or the accidental inclusion of secret layers underneath what were supposed to be blackout redactions. Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer.

I'm hoping that one day we'll get a good, stable, powerful, reflowable PDF-like format. HTML+CSS+JavaScript works, but it's a huge standard, rendering is not exact, performance (in terms of memory usage in particular) isn't great, it's best created by hand (requiring programming and/or technical knowledge), and it's not really self-contained or sandboxed from network access.

> Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer.

Can you write more about that? And what was the initial format of a monochrome image in the PDF, and why wasn't it JBIG2?

I can't recall exactly what steps I went through. It took quite a lot of time. It was one of those rabbit holes where I spend two hours thinking I'm just 10 minutes from being done. If I recall correctly, I did the conversion in hopes of getting my aged Chromebook and phone to load the PDF more quickly; scrolling and page turns were just choppy and slow enough to be an annoyance.

As to the conversion itself: I think every page was just an image (which was fortunate, as I'm not sure how I would do this otherwise) so I extracted all the images with something like mutool, converted them using jbig2enc after figuring out the flags to use to ensure lossless compression, then use some tool (ghostscript? imagemagick? some dedicated image-to-pdf program?) to smush it all back together.

So the flow was original.pdf -> [page1.png, page2.png, ...] -> [page1.jb2, page2.jb2, ...] -> new.pdf

I can't recall the original format of the images. Obviously it was something less efficient, but it was lossless. Presumably the images were compressed using the less efficient scheme because whoever scanned the pages didn't know they could twiddle some knob on whatever scanner or scanning software they were using. Or there was no knob for them to twiddle.

To this excellent defence of PDF I would like to add that it works perfectly well offline and, crucially, is just a plain old file that can be emailed, WhatsApp’d, backed up, etc. without anyone’s permission or any ongoing dependency on centrally managed servers.

My next website project will be published in PDF, not HTML.

HTML also works perfectly well offline, though, if you don't reference online assets.

And if your objection is that it can run JavaScript and make web requests, then I have some bad news for you about PDFs.

PDF/A cannot run JavaScript.

the problem with html is that it's hard to pack it in a single file like a pdf.

No, the EPUB format is basically a self contained zip format that includes a bunch of (X)HTML files and their connected assets.

There is tension between two fundamental ideas: is the server offering content and allowing the client to interpret it as they see fit; or is the server offering an experience that is out of the hands of the user?

Out of these two conflicting ideas come all sorts of issues. Accessibility is one, but so are things like scraping, copy/paste, DRM, confidentiality, artistic integrity, cross-platform compatibility, new devices, peformance & resource consumption, etc.

Agreed, but web standards don't support the second choice very well. Different groups, scenarios, or apps will want one or the other depending on circumstances, but we don't have "other" right now.

The server having more control doesn't necessarily harm accessibility. It's a matter of making sure sufficient meta-data is included. It's possible accessibility is more work under the second, but not outright impossible. (I've stated more about accessibility nearby.)

In terms of predictable layout and control, Flash is still lightyears beyond HTML+JS; and that's nothing short of a catastrophic failure on the part of browsers.

That said, Flash was/is an accessibility nightmare. It broke screen readers, and the animations and custom interfaces regularly created unnecessary cognitive load and confusion.

I always thought one of the biggest plusses of the early web was that you didn’t have to hire a graphic artist and designers in order to publish. In fact best practice was just don’t worry about whether it’s pixel perfect.. just publish your data and organize it into headers and paragraphs. The browser will display it however the user wants it displayed. If that means turning your links orange, that’s fine. If it means displaying it as fixed width green text in a 40x25 terminal, that’s fine too. If the user wanted a textured brick wall background, fine, let them. If it would be read through a screen reader, great!

Later, the designers showed up and started abusing <table> and <img> and body background, thinking the web was a word processor or Photoshop, and everything started going to hell. Now we have JavaScript and <canvas> and I as a user have pretty much lost all control over my browser. It’s just been handed over to the web site publisher, who tries to get rid of my scroll bars and worries whether some element is rendered 3 or 6 pixels wide on different browsers.

In my view, we sacrificed a lot at the altar of “predictable layout”.

> I as a user have pretty much lost all control over my browser.

> It’s just been handed over to the web site publisher

This is an illusion. It is a fact that the evolution of the web as a medium empowered publishers with more control. However, the browser is running on our computers. The truth is we let them have control. We trusted the publishers and allowed execution of foreign code on our machines.

We gave them that power. We can take it away. It began with popup blockers. Then people created ad and script blockers. Now we have general content blockers. I bet one day people are going to make GPL'd custom clients for popular websites.

"I bet one day people are going to make GPL'd custom clients for popular websites."

People do, it's just hard to do so against any website that has an incentive to prevent you from creating a third-party custom clients, which is every site that serves advertising, which is... uhh... basically the internet.

But, see Hacker News: https://play.google.com/store/apps/collection/cluster?clp=gg... (At least, I hope that link sends you to a search on "Hacker News" on the Google Play Store. If not, well... search for "Hacker News".)

If people can build and maintain huge ad blocking databases, I don't see why custom clients and APIs for sites would be out of reach. For example, youtube-dl has handlers for specific sites, gets constantly updated to deal with changes and has a generic video scraper it falls back on.

I posted about this idea on reddit and someone showed me this:


Something like this could change the web.

Except this time around, browsers are on the side of the publishers[0]. They keep removing useful functionality that gave users control, while adding more and more ways for publishers to impose their will on people. And every now and then you get blatant attempts at neutering the users' decisions, like e.g. Chrome's recent extension API changes.

[0] - Except maybe Firefox, but it has to follow Chrome on most things to stay relevant.

In the very early days, before Flash, making a website was a difficult proposition. HTML was an esoteric structural markup language, and much of the effort of early browsers was focused on "correcting" mistakes made by individuals attempting to build websites.

<map> was the true monstrosity, <table> and <img> were improvements upon it, but were burdened by padding and margins added by early browsers that were difficult to modify and retain consistency.

The situation hasn't really improved much; creating a website nowadays is a matter of dedicating yourself to a custom content platform, like Blogger/Squarespace/Wordpress, or learning the arcane language of HTML+CSS+JS.

That's a far cry from the drag, drop, click, publish or share of Flash. Just how does an individual create a .EXE of their animation/game/document and send it via email, nowadays?

Have you forgotten Dreamweaver and Front Page? You didn't need to write HTML directly.

I had forgotten about it. That takes me back though. My mom made a website using Dreamweaver way way back to post stories she'd written. She was so excited about it and the fact that she'd been able to do it all herself. It was fairly tasteful as far as sites from that era went, There were only one or two animated gifs at the top and the background was pretty easy on the eyes.

Those were almost contemporary, almost, with Flash. There was also plenty of websites made by exporting HTML from Word.

They also weren't nearly as good as Flash at creating layout and appearance that would be consistent on all browsers.

I've been building web applications since 1996, I don't really recall what you are describing ever really being the case in my own experience. Yeah, I could push back on some variance of "pixel perfect" as a meme, but in the end it really needed to be very close to as-designed. Before CSS became the norm (early 00's), it wasn't much fun at all on that side of the fence.

I don't think that it's particularly difficult to make extremely predictable layouts in HTML+JS if you have the same constraints as flash (particularly a fixed canvas size).

In Flash it could be done in minutes, with no prior experience, and only using a mouse.

...and the closed, proprietary authoring tool

That was widely available to huge numbers of designers who already had Adobe's Creative Suite, whether through work or school or from the high seas.

There's nothing wrong with using proprietary software. Sometimes it's good to support developers.

This has been a very interesting change in Hacker News. Back in 2010 when I first learned about it, I was coming from Slashdot. And for me it was a (refreshing) surprise that people here were not anti-paid software, anti-business, etc. After all, it is a forum within a VC firm that looks to fund startups to make a profit. The discussion was more pragmatic.

Somehow nowadays the group think has kind of changed into what Slashdot was 10 years ago. Which is funny, since the objective of YC has not changed.

I like how both of you assume that just because someone wants free software they don't support developers. They may be donating, which is what I do, on the other hand I guarantee you that you're making use of several pieces of free software daily and yet your mindset seems to be, if it's not proprietary, or requiring payment, then it's not worth supporting.

I mean I knew this mentality exists, (after all Bill Gates was rather influential), but it's not the OP who is not willing to support developers...

> people here were not anti-paid software, anti-business, etc

neither am I

The software isn’t the issue. The lack of an open standard for content presentation is.

This is not to claim that what we have isn’t less than ideal, but the fundamental problem with Flash is not the authoring tool itself, but that it effectively monopolized the space.

The problem was that it was the only option and Adobe just wasn't committed to being a good software development shop so when you found a bug you were stuck living with it. I did a modest sized project a decade ago where we kept hitting this cycle:

1. Find a bug in the Flash IDE where something basic (e.g. the debugger) crashes or doesn't work in an obvious, easily tested manner.

2. Report it under the paid support plan (hey, that's what we're paying for, right?) with a straight-forward test case

3. A year later, get an email telling you that a new paid upgrade is out and could you pay another $800 to have the privilege of testing whether the problem is fixed?

Because Flash and it's tooling were proprietary, the format is now dead and the content created in this format is becoming inaccessible.

For as rough as PDF tooling is, flash is even worse.

You know what's _really_ rough for open data standards? The information diaspora that is the modern web. We're in an archival and interoperability dark ages, despite that the presentation layer is "open".

I'm not saying there is anything wrong with it. I'm just pointing out that there is a significant hurdle that doesn't exist with HTML.

On the other hand adobe ist sucks up money.

Re: "In terms of predictable layout and control, Flash is still lightyears beyond HTML+JS...That said, Flash was/is an accessibility nightmare."

The key question is if these are mutually exclusive goals or not. Can we take the simplicity of Flash's concepts and improve the accessibility, or will fixing accessibility inherently ruin the simplicity?

It seems to me that accessibility meta data can be supplied to the client independent of layout info. If Paragraph A comes after Paragraph B, the meta data can indicate that regardless of where A and B show up on the screen. Ideally they don't contradict, but my point is that they can be independent.

Conceptually think of two different markup tag sets. Set A is for visual positioning only, and Set B is for semantics (accessibility). The visual rendering engine would ignore tag Set B and an accessibility "reading machine" would ignore Set A. For practical/convenience reasons we may want to tie them together at times, but it's not a requirement for making both the visual screen "happy" and making ADA devices "happy" at the same time.

They can be independent info.

This is nearly the opposite of what I would want from HTML or the web.

A fixed layout is not going to work for all devices.

Such a choice is tantamount to deciding that some classes of devices are not going to be supported, which may be a reasonable choice but better to make good choices in the HTML and CSS and let the devices try to make something usable of it rather than giving them a fixed window into a layout intended for another.

> A fixed layout is not going to work for all devices.

Designers are also making their choice with HTML nowadays : Desktop is not supported anymore. Look e.g. at twitter, a billion dollars company switching to mobile web only. Flash could easily implement media queries to re-layout itself.

> Look e.g. at twitter, a billion dollars company switching to mobile web only

Source? Twitter.com currently works just fine on Desktop. Even dynamically adjusts its layout to look good on a bunch of different screen sizes.

Just by the padding in the buttons it's obvious that twitter's current site was built for mobile. Sure, it's responsive, and i bet flash could become responsive if it was still alive. HTML games however are also non-responsive most of the time just due to the nature of their use case.

They might have meant mobile-first and not mobile only. Their desktop site is very clearly designed for mobile, the main content does not change at varying screen widths. The sidebar and header do a bit of restyling, but thats about it.


> The site has an updated look and feel that is more consistent with the Twitter you see on other devices

Flash could be used for responsive layouts. They were actually far easier to design in Flash than in HTML/CSS. No floating, flexing, grids, nesting HTML elements. You just set the objects x and y axis in Flash to the bottom center or wherever you wanted the object to remain, and you were done.

One hundred times, THIS!

The layout engine in flash was REALLY well thought out, and allowed for simple constraints that would allow for things to grow or shrink based on screen size. You could anchor buttons and they would move properly, all without having to worry about things breaking across browsers.

If someone would re-implement just this feature along from flash i would be REALLY excited to use it!

So far i dont think there is really much in the way of "constraint based" layout engines that are easy to use for the web is there?

Almost all GUI toolkits work that way, except HTML, because HTML is not designed for GUIs.

For instance look at AnchorPane in JavaFX. You can lock things to the edges or offsets from the edges. You can nest layout managers if you want something different like a table or HTML style wrapping text flow.

In the end HTML is just being abused. It was never designed to be a Flash replacement. If the web was a more pluggable platform Flash would still be alive and kicking for sure, the creation tool itself was lightyears ahead of anything HTML ever had, but the browser makers have killed it pretty ruthlessly. Looks like groupthink to me, tbh.

This is how I code html nowadays, positioning divs using js, works like a charm.

I bet you didn't test it on enough browser brands and versions.

Re: "A fixed layout is not going to work for all devices."

Agreed, but not all apps need watch-to-wall scaling. All our internal "productivity" apps run on desktops and nobody has complained. Certain check-status-of-project kinds of apps may be something people want on mobile, but not heavy data chomping/sifting.

Different things need different tools and standards. Even web apps don't really work right on mobile unless you test and adjust for mobile. Using Twitter Bootstrap etc. does not guarantee an app is usable on mobile.

And sometimes it seems it would be easier to make two different apps for different devices rather than one-size-fits-all, as it's nearly impossible to optimize the UI to automatically adjust to both using Bootstrap etc. Workable on both, maybe. Optimized for both, no. There may be handful of people in the world who can pull that off, but you won't find them.

What you see might be what you get, but it's not what I get, for reasons that are innate to the web.

My mother still uses an iPhone SE with a 4.7" screen, while I use a gargantuan phablet. My grandmother has poor eyesight and runs her browser on a 720p screen at 175% zoom, while I have a large high-resolution monitor and normally open browser windows to 1280x2160 portrait. My monitor is color-calibrated and extremely bright during the day, but after sunset it's deep amber and very dim.

If you think that WYSIWYG for the web is desirable, you haven't understood the web.

Wasn't he talking about a "special mode" for places where WYSIWIG might be the better case? Not for ALL content, but for some web applications (complex CRUD apps maybe as a good example) I feel like there is still very much a case to be made for this.

Maybe the form it takes would be a good place for discussion, but really there is no reason things like this have to be inaccessable to screen readers any more than a native app would be.

> I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers.

Let’s be fair here: every major web browser also implements an entire virtual OS by this metric, probably even moreso than Java or Flash ever did. Yes, they absolutely do invite hackers with their absurdly complex designs, but advances in security-in-depth have made them fairly hard targets (not invulnerable, though, as Pwn2Own demonstrates annually). Flash and Java never really had enough attention paid to real, in-depth security engineering by comparison, and browsers learned from those lessons and improved. The JavaScript engine and API scope in a modern browser is easily multiples of what you could access from ActionScript in Flash, but the security is much better.

HTML has <canvas> now. Flash is essentially no different than that , except for the security holes, which are not unfixable. The other HTML equivalents of it are just too heavy resource hogs, including video players.

What made Flash AMAZING was its authoring environment. Scripted multimedia content (via SWF) I could run and share in the browser in 1998! The first time I ever bought software was Flash 4. Watching, then sharing animations probably caused me to go to Art school. It was incredibly impressive stuff back then.

I just to make or consume that sort of content anymore though. I couldn't even tell you how to do it using HTML, or how to author it. Speaking of school,

<aside>I remember when I signed up for a Director course (Director!), and it was re-done into an advanced internet art class, and all I did was hand in HTML/Javascript assignments. I failed the class, as I worked on all that stuff during my job, the teacher didn't know anything about the tech, and I was inundated with questions on how to do cool stuff. </aside>

It got to the point where it was too annoying to visit all those different websites with animated intros, weird menus, sounds etc. It was like 1000000 cdroms on the browser. But yeah, thanks to 20 years of progress we can now stare at 1000000000 identical bootstrap homepages.

At the time, I remember being pretty OK with taking the terrible with the good - it all felt like experimenting to me, and I gravitated towards more of the designer-y/artsy sites, rather than the games and cartoons.

This was back when David Carson was highly influential designer (for good or ill), and I was coming from skateboarding/snowboarding culture, which (and I sound so old) was a lot different, 20 years ago. Like it was COOL to be really into Typography, and the messier, the better. Because, "The 90's" I guess.

I would be extremely happy if I saw "1000000000 identical bootstrap" websites every day. They're (usually) simple, and they (usually) work.

I don't mind them either - i use bootstrap myself. But , i can't help to feel that i use it because i've given up on thinking i could do something functionally useful in today's web with my own CSS. It's become boring, tedious work, because mobile changes everything, you just can't do visually challenging designs there.

Flash was overused as well - it was annoying. However, i believe that something being removed without having a better HTML equivalent is a bad sign of technological regression.

> What made Flash AMAZING was its authoring environment.

Which hasn't gone anywhere, but has been renamed Adobe Animate.


Well, I've gone places now. Now it's not something I can budget a monthly price towards as a hobby, in perpetuity.

Flash is essentially no different than that

This isn't some defense of Flash and its attendant problems but Flash is very different from that. Canvas is a drawing surface, Flash has a full-blown component model. You can't put a canvas in a canvas.

Canvas is also a bunch of pixels without vector support.

All we are is a bunch of pixels without vector support in the wind, dude.

Having worked on content in eLearning while Flash was king, it was far from a panacea. Especially for government related training content. Almost everything was meant to be run full-screen at 1024x768. Can you imagine if everything were still VHS quality today for video?

In the end, technology moves forward. And frankly, there are enough libraries for grid/layout that really close to just work. I find that material-ui with react is insanely easy to use compared to what came before. Every time I do anything more custom, yeah, I have to google it and play around witht he CSS rules. However, for CRUD guis, material-ui library all the way.

In the end, you aren't going to get away with knowing nothing. Even in the Flash days, if you wanted to do anything interesting you had to know ActionScript and the quirks that went with it. For forms and crud apps, you had Flex, which had its' own niceties but wasn't a panacea either and wasn't WYSIWYG either.

What could have saved Flash was opening the runtime and creating an interoperable specification and let browser vendors work with Adobe (Macromedia and I forget the company before that) etc. Silverlight was much closer, but still sucked in a lot of ways that held it back in the end. Flash's tooling still exists and iirc targets HTML5 these days, so you can still pay and use it.

If Flash had simply been a bundle spec for a zip archive with a manifest file, JS, SVG and MP3 (or other audio) and video files it could still be a thing. I had hoped that would be the direction it would go when Adobe bought Macromedia. It wasn't. It was the source of too many bugs and crashes and it died because of it.

You are supposed to design your UI based on general principles ("three vertical blocks", "list of elements with a label", "text with paragraphs", etc.) and let the user agent lay it out as it wants and accept whatever result happens, and not attempt to test or micromanage it to get a preconceived result.

At any rate, HTML layout is determined by the spec barring rare bugs, so you can design something that lays out exactly how you want regardless of browser, except that you must decide and specify the layout for any possible width/height combination.

> Designers loved Flash because it was WYSIWYG.

I hate designers who think they are typographers. Typography is an engineering discipline. It is not something you want to leave to designers. Especially not insecure designers (and customers) who need constant novelty.

Computers are not paper. Get over it and adapt.

Most graphic designers are typographers, by definition of the word. The move from print to screen hasn't changed that.

No, they are not. Thinking they are does not make it so and it just leads to poor typesetting. The typographers I know typically have a BA from an engineering college. The advent of desktop publishing and later other forms of electronic publishing has hollowed out the field.

LaTeX makes them obsolete in either case.

When web browsers support LaTeX-like hyphenation and justification with microtypography (tiny tweaks to the tracking tightness), then I will be obsolete and happy.

I would accept less than 60 frames per second.

I worked on a WYSIWYG HTML editor (Pagedraw) for a while, and came to the conclusion it's overkill for the problem of browser layout.

For CRUD apps, you really just want HStacks, VStacks, and ZStacks like they have in SwiftUI.

They nicely express reflow behavior without driving you crazy or bloating your code. They're a bit more work than drag-and-drop because they make you be explicit about resizing/reflow, but you should be thinking about that anyway.

You'll want to skip that step when iterating quickly on design, but that's why you design in a separate design tool, which is visual and uses position:absolute.

When you're ready to parameterize the design over varying content and screen sizes you'll have to specify resizing constraints somehow, and in my experience, VStacks/HStacks in code are a pretty good way to do it.

I recommend adding building these abstractions on top of flexbox, and adding them to your standard library.

This is all specifically for CRUD apps. If you're making an animation, or something else that would feel wrong to call a "document", you probably want a completely different set of tools.

You can have WYSIWYG with HTML. You just have to use pixel values for everything and assume some fixed pixel width of your application. Flash can rescale also, but it runs into the same layout/rescaling problems as you do with HTML.

This is just not true. you did not have to specify fixed width in flash any more than you do with HTML. Flash's approach used something like a constraint solver to allow some areas to grow and some areas to have anchor points. It was reactive by design.

I think the key is that what the browser (client) gets should be coordinates. If the server side wants to use some wazoo auto-layout engine, that's fine. And that gives one a wide choice of layout engines/algorithms, unlike browsers.

Yes, browsers do have different layout engines available, but they all go through buggy and inconsistent JavaScript and CSS in the end: the chain is as strong as the weakest link.

Doesn't work well for text in my experience. Perhaps a bounding box can be defined as pixel coordinates, but there's no guarantee the text will fit right across browser brands or versions.

I'm not a web front-end dev, so pardon my ignorance ...

Would a canvas and/or SVG GUI be acceptable?

Doing it with canvas / svg is a bit like saying you can do a videogame because you have access to webgl and web audio API.

In the most technical sense, yes, but it's way too low level an abstraction to be practical. Flash's entrypoint abstraction was the timeline, which already bundles up a huge amount of complexity around time-based transformation of content that you'd have to build atop canvas to approach Flash's convenience.

I haven't seen it work well. Part of the problem is that JavaScript is needed emulate many common GUI idioms, and the emulation or rendering is sometimes buggy on different browsers. It's back the the brand/version combinatorial explosion.

The industry really needs a dedicated GUI-friendly standard. Emulating GUI's keeps failing. If you fail 30 beauty contests, the blunt truth is you are ugly. Get a clue and change direction.

There's hope. If you look at the GUI for Figma (an Illustrator and Sketch vector drawing competitor), they've built it using the Canvas tag...and it works AMAZINGLY well. I don't know how they did it, but it feels more like butter than Sketch, and I love Sketch. I'm waiting for someone to come along and basically build the Flash equivalent of a canvas tag renderer. But it's going to take some serious smarts.

There is some precedence. Rich Harris (of Rollup & Svelte fame) has been toying with the idea of a precompiler for Web GL...

This is called “forms”. The people who are failing to do better do care—they just also see the limits of the work.

Context matters. If you're building essentially square box with interactions (essentially flash) , it would probably be fine.

But if you're trying to optimize across several displays HTML can re-flow for you and isn't generally terrible unless you're doing things that need to be pixel-perfect.

I believe we need 3 different UI standards:

1. Page and document centric (HTML may be close enough)

2. Productivity and data-oriented GUI's ("cubicle" stuff)

3. Games, art, and diagrams

Doing everything in HTML/CS/JS keeps proving too clunky. Even the big wealthy sites have odd rendering bugs that pop up.

> Doing everything in HTML/CS/JS keeps proving too clunky.

Clunky, sometimes sure. It has largely been fine in my experience.

> Even the big wealthy sites have odd rendering bugs that pop up.

This will always be the case.

Re: It has largely been fine in my experience.

That's not my experience. It requires too much fiddling and diddling to get things right that wouldn't be drama under 90's GUI IDE's. (Early versions sucked, but they got better with time.) Maybe a few experts somehow master all the arcane CSS/DOM rules, but that's the exception. Arcane fiddling may be great job security, but it's not economically logical on a planet-wide view.

In other words, designers want to control my experience, which conflicts with my desire to control my own experience.

If the "designer" of a web page were able to send me plain text and links only, with my client application in control of the font, size, line width, layout, etc, I would prefer that to current state of the web.

Layout isn't rocket science until someone makes it more complicated than it needs to be. I don't remember flash being very adaptive to different resolutions.

Flash's approach used something like a constraint solver to allow some areas to grow and some areas to have anchor points. It was reactive by design.

Sounds like tables with a mix of absolute and relative sizes. This isn't 'reactive by design' this is how basic computer UIs have worked for decades.

> A few snotty Sheldons mastering auto-flow math doesn't scale well.

How about we quit ignoring the elephant in the room?

CSS sucks. It was designed for a time when Javascript wasn't required for every website.

Now that we've thrown in the towel and every single website is dependent upon Javascript, we should toss CSS, too.

10 years on after that Jobs letter, the market for WYSIWIG web animation is nearly non-existent. All I want is a tool that lets me draw animations, allow tweening controls and exports to HTML/JS, without needing to open a code editor.

The only tool that does this to my knowledge is Tumult's Hype: https://tumult.com/hype/. I'm glad it's using an old-school pricing model of one-time payment and not the subscription model that Adobe and everyone else switched to.

Adobe Animate used to be a thing, but that got sunset years ago. There is Adobe After Effects + Lottie, but that assumes you are a front-end developer and know how to integrate those tools together and use the resulting JSON.

No wonder then that the only visually interactive websites out there these days are things like "Spotify Year in Music" stuff that probably takes an entire team multiple sprints to build.

> Adobe Animate used to be a thing, but that got sunset years ago.

Adobe Animate received two feature updates last year and at least one bug fix update this year.

So, it's not dead yet. Maybe wait until after Adobe MAX (which starts in a few days) to write its obit?

My mistake, I was referring to Adobe Edge Animate, which was sunset in 2015. Animate CC is still around and kicking. Unfortunately, it renders to HTML5 Canvas, which is bitmap-based and thus unreadable by screen readers. Hype is a better option as it renders to SVG.

Flash never rendered to anything but an output similar to canvas either.

https://alternativeto.net/software/hype/ says the top alternative is Google Web Designer.

It is not. Google Web Designer is a very limited product with a specific audience: marketers who are building those banner ads that everyone of HN blocks anyway.

Hype is a desktop app that give you much more control and is targeted at Flash game devs, web designers and others.

Check out https://www.2dimensions.com/ it's very promising.

Tumult Software makes Hype


Checkout svgator (not free). I recently used it to animate an svg, the same way I would have done in Flash years ago.

I don't miss the vulnerabilities that came with Flash, but I do miss the ease of creating animations, training, games, etc. that came with Flash.

Back in the day I worked with a team that created training modules for products. We had a team of animators that was creating beautiful stuff. We had a cast of characters, voice talent, the whole shebang. It was very popular, especially in Asia where they loved the animated training.

Then the iPad came out. Our customers informed us that they were going to adopt the iPad for their on the floor training. Well, the iPad didn't support Flash so we had to rebuild everything to be HTML/CSS/JS only. It has been nearly 10 years and we are still using plain text, images, and the occasional video. We tried bringing back the interactive animations over the years, but nothing has come out that comes anywhere close to working as well as Flash did. It really sucks that despite nearly a decade no Flash replacement has emerged. I really feel like we lost something when Flash died. Interactive animations have been replaced with youtube videos and boring text and image web pages.

On the vulnerabilities... working with flash made me abandon it at home years before the iPhone. Flash, Java and PDF are some of the biggest sources for browser security flaws historically... and that doesn't even touch the complexity of some nearer term flaws that would have been found eventually.

One of the biggest sources of browser security flaws was browsers during that era, also. Moreover browser makers had access to the Flash source code, and Flash was an open spec anyone could implement.

I don't think it's as simple as "web secure, everything else bad". For the very longest time only Chrome and Safari had working sandboxes, and there wasn't a huge difference in the exploit stream between WebKit, Flash, Java and Adobe Reader. They all had somewhat similar feature sets.

For games, game maker studio is a pretty good replacement I’ve found. The interface is pretty idiosyncratic (so was flash’s!), but I have a similar experience coding in that.

I believe with Haxe you can use OpenFL to get what you're looking for. FWIU, that provides a nice migration path from Flash.

Oof. Organizing the world's information, except the information that's unfortunately stuck in a file format we don't like anymore (for good reasons), that knowledge clearly isn't worth anything. I get disabling Flash support in browsers by default, but actively pretending Flash content doesn't exist so no one can find it anymore seems unnecessarily destructive.

Google operates on a live-code model. Anything running requires some level of active maintenance and support, so there's always incentive to trim. In this case, the Flash crawler is an obvious thing to trim (what's the point of indexing something that the average user lacks the tools to open and read?).

One thing I do wish they would / could do in situations like this though is open-source the core of that crawler, so if someone else finds a purpose for it, they could run their own on whatever corpus they care to index. But, such is the price of relying on closed-source software for things.

Information is still information. Sure I hate having to deal with flash, but if that information I need is nowhere on the web except this one flash or pdf deep down the interwebs, I will take a look.

I'm all for downranking it to the last page, but when your google results only has 2 pages total, every single result matters, including that flash content.

Who is paying to maintain the codebase to dissect Flash as the libraries it depends on change?

It's also kind of meaningless to show you search results that point to a flash file your browser can't handle.

I hope they meant just parsing swf-files or extracting their meta-data. Purging anything related to the file itself would be quite counter productive for a search engine.

They're not getting rid of their existing indexes of Flash data, are they?

It's kind of odd for a web search to index information that your browser can't display. Although I suppose paywall sites and book search are similar.

Google indexes plenty of other binary filetypes.

Yeah, it's not great. I figure not being able to display specific things is something people who really need to can work around, but not even being able to find things means surrendering information to the void.

Just because one can't open the information by default doesn't mean the information doesn't exist - in this case, Flash content is exactly like your paywall and book examples. The searcher can decide if having access to the information is worth the added cost...regardless of it's buying the book, paying for the subscription to bypass the paywall, finding an old computer or setting up a VM to use flash.

Flash tried to be everything to everyone. While it did some things very well (like those amazing little games), it did other things very poorly (like information websites and accessibility).

- Every page had its own navigation style.

- Every page had its own font which you could not change. Remember the trend with 8px bitmap-like fonts where you used a special setting so they would render very sharp?

- Every page had its own scrolling style. Want to use the mouse wheel? Nope.

- Caret navigation for the impaired or people who prefer keyboard navigation? Forget about it.

- Stop sound? Only if we give you a button for that.

- Here's our looping video intro, you must watch it before accessing this website.

- Deep hyperlink to the next "page"? That came very very late. A bit too late for Flash.

- View on mobile? Even if you had the plugin somehow installed (some people did back in the day on Android) pages would still be unusable.

- An error has occurred within this SWF blob, good luck debugging.

- Later came the exploits.

I was a fan for a while and used it since Macromedia Flash 4, but I'm glad it's dead and buried. It was poor tech which subverted progress in the HTML/CSS/JS space for many years.

I would also add to that list the awful CPU usage of Flash, every time you had a page with Flash opening, the fan would start to spin and your computer just became very slow...

Flash, ActionScript and the associated IDE were amazing web development tools at the time (in the era of Macromedia) - way ahead of any competitors. No one/nothing has really filled those shoes.

At this point, the only thing I think about is Homestar Runner! Not sure I've come across a Flash site in a long time otherwise.

There's quite a few flash games/etc. that will be lost to the ages.

Quite interesting if you think about it! A bit of an antithesis to the idea that what's on the web is preserved forever.

There is an emulation project trying to save as much as possible https://bluemaxima.org/flashpoint/

There's nothing to run Flash media outside a browser? Obviously that wouldn't help anything dependent on proprietary server functionality, but that's true of any software.

I went through this a few weeks ago and found a site that explains how to run Flash games standalone: https://www.howtogeek.com/438141/how-to-play-adobe-flash-swf...

Basically there is a program you can download from Adobe called Flash Player Projector Content Debugger, then you just point that at the .swf and go.

An open source emulator would be better in the long term, but for now this is easier than trying to find a browser that still supports Flash natively.

You really don't need a tutorial to use Flash Projector. :)

• Windows: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...

• Mac: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...

• Linux: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...

Download the version for your platform and open the swf file you want to run. That's it.

Linux users can also use the community-packaged Flatpak: https://flathub.org/apps/details/com.adobe.Flash-Player-Proj... All other links come from https://www.adobe.com/support/flashplayer/debug_downloads.ht...

There's actually a project just for that. It aims to archive every single flash games on the internet in a playable format outside of the web browser. It can even simulate situations where the flash game needs to access asset files from the original server. https://bluemaxima.org/flashpoint/

I think newgrounds (a big flash games/videos portal) is offering such a tool, but I didn't tried it, since flash was still working in the browser.

There's this: https://www.gnu.org/software/gnash/

Looks like it got dropped from Ubuntu though.

There is, but it doesn't work very well or at all depending on your source flash file.

Isn't there some way to preserve them, kind of like what people did with DOS boxes?

I'm sure there will be, there are a few implementations/emulators out there. Gnash, Shumway, Lightspark, and Ruffle. Ruffle seems to be pretty promising, it's being worked on by Newgrounds people and it's written in Rust to target the desktop and WASM. It looks like they can do animations and audio now, and they're working on the various versions of ActionScript.

Sadly Flash is incredibly hard to write a 100% implementation for. That's why there are so many attempts; they've all failed (but they can work well for specific Flash games/apps).

It would be great if Adobe could open source their existing Flash Player at some point.

I struggle to see how doing so would harm them commercially. Even if an open source player is available, browser vendors have no interest in supporting it, so it won't be supported with browsers. It isn't going to take away interest in their newer pure HTML5 authoring tools.

There are frameworks that let you compile flash games/apps/videos into native executables with pretty good compatibility (so minimal porting effort). That's probably the best we've got besides using an out-of-date insecure browser.

The adtech industry embraced flash in a big way, youtube was defaulting to the flash player until four years ago. Plus the dozens of flash ads and trackers that were (and still are) placed into many ad networks.

Now that the adtech firms switched to building the browser and the cluster of html5 technologies have matured it's easier to track people natively. That's really the only reason flash went away.

There was no Flash on the most popular smartphone (before Android took over). When ad tech went mobile they couldn't use Flash. So, ad tech shifted to web tech.

https://www.ferryhalim.com/orisinal/ had some fun little games written in flash.

And yet, there's still no good replacement for building those types of Flash games. HTML5 game development isn't close.

Have you seen some of the html5 games on itch.io? Very impressive https://itch.io/games/html5

It's a lack of IDE. There's nothing stopping a game riding atop the browser's engine from being performant and fun, but the tooling to get there is nearly non-existant for a lot of people.

We desperately need an HTML5 based game dev IDE with feature parity of Flash. Is such a thing even possible?

Wouldn't unity qualify? Personally I think the decline in browser based games has more to do with a lack of interest in that gaming format, not the limitations of current web technology.

Complaining for lack of tooling and doing some research require different efforts :)

Unity is just one example that can export to web. There's https://playcanvas.com/ too and a plethora of other stuff :)

Unity demo: https://wasm.bootcss.com/demo/Tanks/

This is what I figured, that today's equivalent of Flash gamers are just on mobile games instead. I do miss the anarchic quality that the Flash ecosystem had in the 2000s, but I think that's more a function of the type of people who spent time online back then.

The major components of Flash are a vector graphics engine, a timeline based video editor, and a scripting language. Leaning on browser SVG support and exec(), you could write an extremely bare-bones version in a couple of weekends.

It'd be a great open source project. As a commercial product, it'd probably be enough to support a small team, but I don't see a way for it to get huge.

Construct 3 is pretty good, but it's just not as easy to deploy self contained applications, and browser variations are an issue.

I'm curious whether Adobe ever looked at outputting HTML5 with their Flash tools, and what the outcome of that was.

They did and it was pretty good 3 years ago when I last used it. It's possible to merge it with your own code, but it was bad at managing images and SVGs. Flash's strong suit, at the time, was the vector rendering.

They did. They renamed Flash to Animate.

Shooting from the hip:

Technically, yes. Commercially, no.

Construct 3 is not a perfect solution but is one of the best;

I created quite a popular tower defense in flash back in 2007 and I’ve been thinking about redoing it in HTML5 but realized some major issues around tab backgrounding that will cause complexity in the remake vs Flash.

Construct is suitable for that.


Haxe plus OpenFL or HaxeFlixel?

Isn't Haxeflixel built on top of OpenFL? So by using it you should get both the higher level HF stuff along with lower level Ofl stuff.

>>Flash, you inspired the web. Now, there are web standards like HTML5 to continue your legacy.

remember that time when Steve jobs kept out flash from iPhone /iPad vs Google's stance to go full on support for flash on mobile :)

Adobe claimed that it was Apple’s fault that Flash didn’t run on the original iPhone. But even if Apple has allowed it. Adobe still wouldn’t have been able to do it.

When Adobe finally did make it to Android, it required a gig of RAM and a 1Ghz processor. The original iPhone had 256MB of RAM and a 400Mhz processor. An iPhone with those specs didn’t come out until 2011.

One of the big selling points of the Motorola Xoom was that it would run Flash. Adobe was six months late leaving the Xoom in the embarrassing position that you couldn’t view its Flash enable home page from the device for at least the first six months.

Flash on mobile was always going to be shit because it was built without mobile in mind. It doesn’t support touch, it doesn’t make controls big enough to be usable by touch and it doesn’t implement the behavior people expect on a touch device.

Just running the plugin on a phone isn’t the hard part.

Not even referring to the interface. Adobe couldn’t get Flash performance, memory footprint or energy usage acceptable for mobile.

If the other problems would have been solved, the hardware has improved so much the performance issues wouldn’t have been much of an issue anymore. A modern phones performance can compete with a low end pc.

It was five years before an iPhone met the minimum requirements that Adobe gave for Flash on mobile. Even then, a VM based runtime per app would be more memory intensive and more battery intensive. iOS devices just this year have start coming with 3GB of RAM across the board. iOS was able to get away with less RAM precisely because all code ran natively.

Apple is able to optimize its OS, compiler chain, and processor in sync.

Not to mention that an even more stripped down version of the core OS with tighter constraints is running on the watch.

Not even mentioning that the average $250 Android device is much lower specced than the average iPhone. It wasn’t until last year that even high end Android phones were matching the performance of an iPhone 6s (released in 2015) in single core performance.

Remember when it was possible to have interactive animated vector graphics on the internet?

I know you're making a joke, but thought SVG has been there and working since before Apple outlawed Flash for its battery draining behaviour.

On paper you’re right. The most interactive svg content I’ve seen are small demos and even those have to be hunted for. You don’t have to (or at least you didn’t in the past) have to look very hard to find large amounts of quality flash content. Good tools were ripped out of artists’ hands and the internet is worse for it. Where’s the replacement?

It has been 10 years yet nobody has created a true replacement for Flash using SVG, Canvas, JS, etc. I wonder why?

I wonder if it's because, if one needs an expressive language, for vector graphics or whatever, then redundant things like XML and JSON are horribly non-concise choices, whereas Flash didn't suffer such problems, along with having excellent authoring tools.

Yeah have you tried authoring and animating SVG in 2008? Full of (browser support) holes and extremely poor performance, even on the "powerful" iPad in 2011. Flash by comparison would have been a breeze even on mobile.


Not really, by 2005 or so we all knew flash was terribly problematic and making the web much worse. Some people embraced it for sure, but in my experience most people involved with the web at this time had objections to Flash (and Adobe more widely).

Flash was fine for specific purposes .. animations and games mostly. Doing your whole site in Flash was dumb, but Homestar Runner and Newgrounds used it in really good ways.

Yet I’m not sure we would have reached that point now without the “dick move” then. Apple has always taken an aggressive stance to cut out things that reduce battery life. Blocking Flash and background processes were natural consequences

Good riddance, I remember when web browsing on Linux was obnoxious because every other site used Flash but the only plugin available was an older version for Firefox that had serious glitches like desyncing audio. It wasn't until like 2009 that Adobe started providing better binaries.

I wonder what NewGrounds is going to do about all their older content?

it was the right move. at that time flash was the biggest vector of attacks and the largest battery drain, why would you ever consider putting it in in the first place?

apple was just bold, big and loved enough to survive the backlash from flash fanboys who, outraged, went buying android phones and proceeded to never use flash there either.

I work in marketing and spent years trying to convince people to use less Flash ... but hey look at this snazzy thing a designer just cooked up. This got the to the point where they launched a site and were like "why isn't google indexing our home page?" and I'd have to say "well, I told you so."

Turned-out the creative people that matter listen to dicks like Steve Jobs where they don't listen to me. Note about 80% of where we were using flash were replaced by he trivial JS/CS or maybe a jquery plugin, it simply wasn't needed.

I worked on Flash when the iPhone came out. Back then it still only had software rendering and the performance on early mobile CPUs was atrocious. They had Flash and Flash Lite but they both were terrible on the early Android phones that supported them. I love Flash games but putting it on the iPhone would've just made the users mad at the 5 FPS performance.

Rubbish. Flash on Android was always an awful experience. The best you could say about it was that it existed.

Eh, I remember traveling in the early days of tablets and being delighted that it worked as an almost complete replacement for a laptop (or at least, the limited use of a laptop that one needs whole traveling), in a way that iPads didn't remotely approach. They couldn't even play embedded video!

I'm not a big fan of the tablet form factor in general, but it didn't make a lot of sense to hamstring it further by removing Flash.

> Flash on Android was always an awful experience.

Flash on anything but Windows was an awful experience.

Flash required a 1Ghz CPU and 1GB of RAM when it came to Android. An iPhone with those specs didn’t come out until 2011.

It was basically his revenge to Adobe, which hesitated to migrate Photoshop to Intel processors, requiring user to run Photoshop in powerPC emulation mode (slow).

Are we really sure it was Apple's fault? Their browser market share was always rather small and smaller outside the US. But Adobe seemed to reeeeeally abandon the thing after apple's decision. They could have at least open sourced it

We'd be in a very different world of Adobe and Macromedia never merged. Adobe really killed flash, but maybe it was inevitable. From what I read, Flash's test suite was subpar to non-existent and people were afraid to touch anything in the codebase.

It's so sad too because Flash is still amazing when it comes to animating vector graphics in a crossplatform way. Nothing in the HTML5 world remotely comes close.

You can upscale Homestar Runner to 4k and it renders beautifully. Now that it's all YouTube videos, whatever resolution they rendered it at, there it will stay for forever (plus you lose all the clickable eastereggs in the Strong Bad e-mails!)

> From what I read, Flash's test suite was subpar to non-existent and people were afraid to touch anything in the codebase.

If that's the case, Flash should be held up as a case study for the utility of robust tests. Because the amount of refactoring needed to make it fit the mobile world was significant, and if the codebase was fragile because of lack of tests, that refactoring may have proved expensive enough to kill the whole technology stack.

Some folks are blowing this out of proportion:

1. Adobe announced Flash's EOL by the end of 2020. Google isn't killing Flash, it's already dead.

2. Indexing Flash means parsing site structure embedded within SWF files. When was the last time you saw a website with Flash navigation? Your SWF web games are embedded in normal webpages that will still be searchable via H1 tags, backlinks, and so on.

Surprising number of Flash lovers coming out of the woodwork after nearly a decade of Flash hate on HN (proprietary, security holes, etc).

All credit for the demise of Flash belongs to Jobs: https://www.apple.com/hotnews/thoughts-on-flash/

Adobe refused to make the flash player work reliable on OSX back in the day. It was Adobe's fault, and anyone that used the web on a Mac in the 2000's can confirm that.

Flash could have survived if Adobe open-sourced the codebase. But they kept it in-house and didn't have enough resources to mutate it in light of rapidly-evolving demands placed on web technologies by mobile architectures. I suspect there'd have been plenty of volunteers stepping up (including, possibly, from Apple itself) if Adobe hadn't decided to dragon-hoard its IP.

But in the web era, IP isn't king; communications is.

OTOH, Apple could have bought flash and built their mobile platform on top of it. It was arguably better than Obj-C

iPhone apps were fast and responsive on low end hardware precisely because apps were natively compiled and didn’t run in a VM. Did you ever try running Flash on early high end Android phones?

I 'm sure they were slow. but i m talking about the authoring tool and scripting language. I presume apple could optimize that to be fast natively. Judging from how HTML UI frameworks evolved over time, it's as if we ended up reinventing Actionscript

So what was Apple going to do during the first 4 or 5 years? Every single mobile platform that tried using HTML frameworks for their apps failed and were slow.

Blackberry, Palm, and Microsoft all tried it. Android itself was slow as molasses for years because of its dependence on a VM instead of a completely native stack.

The last thing I want is Electron for mobile.

I hate Flash as much as the next guy who remembers web pages slowing to a crawl or crashing because of Flash.

But I also think this is a bad idea, just from an information retention scenario. What ever happened to "to organize the world's information and make it universally accessible and useful?"

What will Google decide the world doesn't need to know about next? HTML2? JPEGs? non-Google-hosted javascript?

This is what we get for allowing a private company to be the gatekeeper of our culture.

The gatekeeper here is Adobe, not Google. This is what you get when you store information in a proprietary format with a single implementation controlled and developed by a single private company. There's always the risk they'll kill the product (like they're doing here) and your information will become inaccessible.

Also, it's not just Google doing this. Pretty much every major browser vendor is dropping support for Flash in 2020.

Adobe didn't kill Flash, Apple killed Flash with Mobile Safari. Adobe is just accepting Flash not having a future.

Flash was incredible. Not just for the animation and games, but also for the audio and video streaming from a server to you, or from your mic/cam to a server, or between you and other users via P2P, all of that live and with the ability to embed arbitrary metadata as cue points at specific times in the stream. The feature set and creativity it unlocked were out of this world.

One of the first "commercial" games I worked on was a Flash (Flex) game that I licensed to a few of the big Flash games sites at the time. I haven't looked at that stuff in years and years... I wonder how feasible it would be to port those games to the modern web.

The web was a much more interesting place when Flash was around. Browser games, in particular, have never really recovered.

There's plenty of new browser games being made, but both developer and user interest in mini-games has shifted to native mobile apps, which wasn't really a thing in Flash's heyday.

Two of my favourite flash games (late era flash)

- Abobo's Big Adventure (abobosbigadventure.com)

- Super mario bros crossover (http://supermariobroscrossover.com/)

Many phone games are (or were) browser games at heart. Just an app that served a webpage.

The fact that they weren't very imaginative or fun or free is what the hyperconnected mobile web brought us.

To be fair, the absolute bulk of browser-based Flash games weren't imaginitive or fun either (and I can assure you, would probably not have been free if drop-in-and-use ad plugins for Flash had been around, if the ads that framed those apps can be taken as any indication ;) ).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact