Goodbye, Flash
webmasters.googleblog.com
webmasters.googleblog.com
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.
Would a canvas and/or SVG GUI be acceptable?
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 is some precedence. Rich Harris (of Rollup & Svelte fame) has been toying with the idea of a precompiler for Web GL...
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.
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.
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.
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 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.
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.
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 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...
neither am I
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.
For as rough as PDF tooling is, flash is even worse.
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?
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”.
<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?
They also weren't nearly as good as Flash at creating layout and appearance that would be consistent on all browsers.
> 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.
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".)
I posted about this idea on reddit and someone showed me this:
Something like this could change the web.
[0] - Except maybe Firefox, but it has to follow Chrome on most things to stay relevant.
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.
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.
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.
Source? Twitter.com currently works just fine on Desktop. Even dynamically adjusts its layout to look good on a bunch of different screen sizes.
> The site has an updated look and feel that is more consistent with the Twitter you see on other devices
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?
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.
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.
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>
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.
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.
Which hasn't gone anywhere, but has been renamed Adobe Animate.
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.
... 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.
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.
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.
This is no longer true. CSS grid solves this completely.
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.
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.
It's not perfectly fine - it's illegal.
https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac...
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?
However because of the way US law works, you probably need context on court cases, such as the recent supreme court ruling:
https://www.scotusblog.com/case-files/cases/dominos-pizza-ll...
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.
Edit:
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
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...
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.
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/
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."
The fact is that we have many, MANY advocates who are all a lot nicer, more helpful, and more effective than Washington, DC.
... 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.
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.
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....
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.
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.
> 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.
BUT...
> 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.
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.
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
But if the question is "Where do you set the bar," we already have laws for that. Are they too many?
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.
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.
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.
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.
... 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. ;)
PDF's, for example, can be made accessible if created properly.
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.
My next website project will be published in PDF, not HTML.
And if your objection is that it can run JavaScript and make web requests, then I have some bad news for you about PDFs.
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?
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.
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.
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.
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.
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 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.
I would accept less than 60 frames per second.
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.
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.
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.
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.
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.)
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.
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.
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.
Hype is a desktop app that give you much more control and is targeted at Flash game devs, web designers and others.
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?
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.
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.
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.
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.
- 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.
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.
Quite interesting if you think about it! A bit of an antithesis to the idea that what's on the web is preserved forever.
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.
Looks like it got dropped from Ubuntu though.
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.
• 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...
Technically, yes. Commercially, no.
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/
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.
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 :)
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!)
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.
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.
Just running the plugin on a phone isn’t the hard part.
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.
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).
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.
But in the web era, IP isn't king; communications is.
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.
Also, it's not just Google doing this. Pretty much every major browser vendor is dropping support for Flash in 2020.
- Abobo's Big Adventure (abobosbigadventure.com)
- Super mario bros crossover (http://supermariobroscrossover.com/)
The fact that they weren't very imaginative or fun or free is what the hyperconnected mobile web brought us.
It seems that Google is already using WebAssembly in its products, Google Keep [0], so it is likely that they will continue to use this.
[0] - https://webassembly-security.com/google-keep-webassembly-mod...
This is a rather creepy equivalence.
They've told us that replacing it is "on their roadmap," but haven't told us when they plan on replacing it. (I also think that Verifone's vault for credit cards was flash based until earlier this year!)
They also told us that replacing it is "on their roadmap," so we replaced Kronos.
Same for Firefox: https://support.mozilla.org/en-US/kb/npapi-plugins
Not 100% sure about IE, but it doesn't seem like you'll be able to make Flash work there either: https://blogs.windows.com/msedgedev/2017/07/25/flash-on-wind...
I think Firefox ESR might still support Flash for a while, at least until the next release.
Its funny how many people are willing to give up their freedom to decide what works best for them, and let others decide, in the name of "im doing all this for your own good".
You should always have the right to decide what technology to use, what you install and download on your device.
The whole app store deciding what they allow or not, not giving you any other alternative, should be deemed inconstitutional in a society who knows whats happening, when people have nowhere else to go because the digital dictatorship is in control of your digital life.
This whole trend smells digital feudalism to me, and it was Jobs that started this whole dangerous trend to the bottom of our civil liberties.
Why are you defending this new feudal lord who are mining your right to choose what you do with your own property?
If after having bought a house, the guy(or company) who have selled to you, had made some demands of how you could use the kitchen, or the bedroom, would you think its within his right to do so?
Each and every time a costumer buys an iPhone they're deciding.
Adobe decided to do a half-assed flash player for the Mac. That decision proved to be wrong.
Or do you really expect that Adobe would do a decent job supporting an new platform when they couldn't even bother supporting the big cash cow Apple had at that time?
You can buy the house from the company defining rules of how you should use the house you bought from them and denying you access to the things they forbid.
Lets suppose you have options to buy a house from the ones that does not do this, ok.. until the company who are ruling over your property are making a big buck, and they decide to play by the same rules..
so hey, where are your options to buy a house without vendor rules? thats right, their gone..
Only that we are talking about something much more important here which has to do with data..
Private companies should never be allowed to do this, unless they offer options (other app stores should be possible), and have rules to filter who can offer apps to your device that dont damage your freedom of choice (dont forbid things on political views, taste, harassing competition, etc..).
Android is becoming more akin to Apple each day, and what you have in the end is a false sense of choice.
This is why the rule of law and a functioning government is so important.
> Adobe decided to do a half-assed flash player for the Mac.
Than if it will deliver a crappy experience, let the user decide for his own. Suppose the user agree with Apple/Jobs here and dont like to use it, but theres that tool that are available only in Flash, you need it for your mechanical enginnering job for instance.. You had a choice, a bad one, yes, but now you have none. Just because 'simon says' so..
And we are not even thinking about the small players with less resources than Adobe, that will not have the resources to make the "good experience" by whatever standards imposed by the overlord dujour.
And thats because we are assuming good faith, because the ruler of your own property, can even lie about be doing this for your own sake, and just use this to bar the competition.
By the way i never touch anything Apple because of this, but because they were the ones who leaded the smartphone industry, the rules they have specified in the beggining tend to be copied by the competition, and to become the norm.
Its not the same as creating a new car company in the XXI century where we have standards, good rules, etc..
The pioners have the power to define the reality of the industry in years to come. And giving its about our digital life, its becoming more and more important each day.
Data and digital platforms are in the XXI century what the oil was in the XX century. Pervasive, powerful, defining everything else.
Edit: I just found this subthread: https://news.ycombinator.com/item?id=21388405 Quite a few alternative implementations are mentioned. Doesn't sound like anything will be perfect, but this looks more future proof than I was afraid it might be!
They even have a shortcut to create a snapshot and insert it directly in a cell. Sadly, it requires Flash.
I understand the reasons behind this but it seems like over 15 years of flash content is about to be rendered unaccessible.
The devices used proprietary level 7 protocol sitting on top of regular TCP/IP (could easily debug using netcat).
Actionscript made it easy to work with this proprietary protocol.
How would one do this with Javascript these days?
You probably couldn't do it with WebSockets since WebSockets are at the same level 7 as the proprietary protocol, so you'd need to run some server to translate.
Maybe, this https://www.w3.org/TR/raw-sockets/ ?
Please write to leisenming AT protonmail DOT com
Does Google no longer index .zip files and the like? Obviously they can't process any content in those formats, but if the file name contains the right keywords... shouldn't search be file type agnostic?
I've had .exe's show up in Google results. It was a long time ago—so maybe things don't work like that anymore—and it was never common, but I know I've seen it happen. I'm sure Google could look inside the binary for text strings, but I can't imagine they do.
There is perhaps an argument that standalone exe's shouldn't turn up in results for security reasons (how can you possibly verify its safety without some context?), but I liked to think that search results could at least theoretically include any file type at all.
so much is said and implied in those sad, sad words
I've never understood why it was necessary to ban it from browsers and practically kill nearly 20 years of games and animations.
Let’s be honest. It is not going to replace flash. It’s a real shame that flash couldn’t make it. Perhaps for good reasons. But it’s a real shame.
That runtime is likely to end up looking a lot more like a console hardware emulator than a data parser.
Instead, what we have is a situation where pretty much only corporations with designers and devs on staff (Stripe and Spotify being the major examples) are building the types of sites that used to be doable by a single person using Flash.
Here’s to hoping the future comes back a little sooner, rather than later.
Same thing with hypercard and other cool-but-abandoned platforms.
I remember when the first 7" Galaxy Tab came out in late 2010. Jobs mocked its size, saying you'd need to file down your finger to use it, while at the same time working on the iPad Mini, which wouldn't launch until after his death.