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.
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.
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.
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]
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?
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
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.
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?
> 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.
... 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.
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.
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.)
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.
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.
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.
> 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.
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.
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.
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.
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. ;)
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.
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.
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:
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?
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.
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).
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...
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?
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".
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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 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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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 ;) ).
Google basically killed off Google Finance last year because it was Flash based. There's an HTML version of Google Finance but it doesn't have anything close to feature parity with the Flash version.
Kronos (the timeclock company) still uses flash in the enterprise timeclock application that my company uses for its hourly employees.
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!)
Now if only ADP would update their timesheet software so it did not rely on Flash, that would be great. I'm going to have to install Flash manually once Google drops it from Chrome.
Well, that will get momentarily interesting, then. Perhaps our company will finally abandon ADP for the last few services we still contract with them for.
The flash player was awful on Macs back in the day. Adobe refused to support OSX properly, and Steve rightfully did not trust them to make a decent job.
Is up to the user to decide that, not the platform middle-man.
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?
> Is up to the user to decide that, not the platform middle-man.
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?
> Each and every time a costumer buys an iPhone they're deciding.
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.
Last night I backed up some old swf games that I enjoy(ed) playing but wasn't able to answer the question how to be able to run the files in the future. Should I install a VM and never run updates, similar to my Windows XP VM for games, or does anyone know of some (preferably open source) flash implementation that I can run standalone?
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!
My favorite new feature (by far) that Google has released recently is the ability to insert images in cell of Google Sheets. It's a fantastic way to keep track of anything visual: screenshots, bug notes, app walkthroughs, etc.
They even have a shortcut to create a snapshot and insert it directly in a cell. Sadly, it requires Flash.
In theory I see no reason someone couldn't create a WASM implementation of Flash. Flash is closed-source though so I imagine that would be rather difficult to do without Adobe's cooperation.
I remember using Actionscript to build some UI widgets for embedded devices and ... not hating it.
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.
I can't say I understand the decision to stop indexing SWF files. Does Google stop indexing every obsolete file format? Do they not index .doc files, tiff files, rtf files?
One part of flash that's definitely appreciated in the artist/animator community is the editor. It's surprisingly simple and intuitive, while still being powerful for power users. Some of the features made it into after effects, but at least currently nothing really compares. Lots of YT/NG animators are still using flash. Newgrounds has an open source utility that can convert flash animations into HTML5 for the sake of preservation iirc.
Considering it appeared on google webmaster blog, the argument about "Flash going to bed" is very childish and juvenile. When your son is not willing to go bed, you probably insists, because he will have problems with focus in school next day, but that doesn't really apply to Flash. Article should clearly state why Flash should be gone.
Is that going to run afoul of IP ownership? To my knowledge, Flash was never open-sourced, and Oracle v. Google casts shadows on API-compatible reverse engineering.
Not sure but that is a good question. Although the VM bytecode spec is published by them. Not sure why really, they even release the file format spec. I would link but the links I knew changed recently and did not work for me.
> Google Search will stop indexing standalone SWF files.
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?
If the zip files not password protected I dont see why they cant crawl the filenames inside zip files. They probably keep all crawl info cause you are able to do Google searches for specific file extensions and I wouldnt be surprised if you could for specific file mime types too.
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.
After all.. I did like more flash than html5 .. browser APIs for videos and audios are really ruined. It's like chrome wanted build fast something to kill flash.. but now we have Totally ruined webrtc left. Thanks Google. Just what we want :)
Sure you could, but you need to build a swf runtime first ... There were a few projects (one from Mozilla - Shumway), but nothing really great. SWF is a complicated format.
I'm not intimately familiar with the SWF standard but I think it's well defined, just complicated (because Flash did a lot) and with potential patent and licensing minefields.
Oh, it's not. Adobe themselves were too scared to change anything, and just shipped multiple versions of their runtime under the hood to account for all the different versions.
Flash was arguably never part of "The Web" in the first place. Not the open web anyway. It's a proprietary technology with a single implementation controlled and developed by a single company (Adobe) which is now ending support for it.
The difference is that with Flash, you could write once and run it everywhere. This was huge at a time when cross-browser differences were major enough to require something like jQuery.
Sure, that's the advantage of having a single implementation. The disadvantage is what we're experiencing right now: once that implementation is no longer maintained you're left with no alternative.
That's true. My point was that even with Flash announcing several years ago that it would be sunset, nobody stepped up to build tools that worked with the open technologies of CSS, SVG and JS.
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.
For Apple, definitely. Jobs' opposition to Flash was rooted in the business case for the App Store and the technical limitations of the first couple of iPhones.
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.
The triumphalist note in many of these posts makes me sad. Flash had a ton of warts, yeah I get that. But there is a failure to acknowledge the collateral damage done to Actionscript that I find troubling. Itemrenderers, the ability to inline functions in MXML components and a decent OO framework gave me a powerful platform for rapidly iterating UI designs. The tools I currently use just don't measure up (I'm looking at you, C#) and it's left a bitter taste in my mouth.
Steve was right very briefly but in hindsight it's pretty irrational to expect a piece of software to not run on a powerful CPU without contrived restrictions like being "banned". We'd have the full Adobe Flash IDE on the iPad next year if Jobs had no grudge and we just waited for the software and hardware to improve. Photoshop's halfway there and SQL Server made it to Linux and Windows made it to ARM.
The solution was to wait for the software to get better, the hardware to get better, the batteries to get better - today the Flash IDE could run on Windows tablets not much bigger than the iPad Mini, authoring content where before it couldn't even play it back.
Why should Apple wait for some other company when they were perfectly capable of shipping something way better? Adobe had the opportunity, and they missed.
I think a better question is why should Apple persecute anybody's software? Especially just because it's not yet performing well on a new, power-sipping processor and architecture. It will be years before anything complex runs well on their watches, that's a stupid reason to sabotage anyone's efforts.
Adobe could have made a great player for the Mac, but they deliberately chose not to. It was awful, power hungry and laggy on Apple desktops and Macbooks. Adobe didn't care about the Mac ecosystem, the player was/is closed source and Apple couldn't not do anything. Why on Earth should Apple invest on a tech that is proven to not work reliably on their platform. Adobe blew it, Apple just made the right decision.
Harsh. I'm sorry they invested their own time and effort into building a search crawler atop a closed-source, proprietary data format (risking not just capital and engineering time, but possibly lawsuits if Adobe had gotten pissy like Oracle) and, having looked at the field of users and decided that there is insufficient interest in the data format to justify maintaining that crawler, they're decommissioning it?
They made a product decision; they didn't shoot your dog.
And it's not even like their product decision removes the ability of the orgs you've listed to keep using Flash. Those orgs just can't keep relying on a free-but-proprietary search engine provided at the largesse of a corporation they have no business deal with anymore to index their proprietary-format media, for free.
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.