Without Flash the current web tech stack might look different
trzeci.eu
trzeci.eu
Sure, when it came down to it you can say it had poor performance, security, filesize bloat (all things that were fixable or you could work around). But in reality, it allowed for developers to create amazing things in a fraction of the time it would take in any other environment.
As for myself, I've moved on to OpenFL and Haxe. It's fast, it's lean, it's cross-platform, it's open source... but it's still not the same.
The other issues could be left to consenting adults. But browsers and IT departments turned against plugins in general. Now even Java is almost gone (from browsers) for the same reason.
Imagine that instead Flash went the way of App Permissions: asking users for permission to access, read, and write different things to the browser. Could you imagine? Advertisers wouldn't be able to pull as many annoying/shady things, and security would start to become a non-issue.
If anything, Flash gave developers too much freedom at first to tap into the browser. Then they tried to backpedal by adding more sandboxing rules that still connected to their awkward security manager. And so, advertisers contently continued on abusing all the ways they could get their ads to become as intrusive and in your face as possible, and people began to be angry with Flash because of it.
- it was a lightweight and compatible way to insert animated ads. The animation consumed a lot of CPU. This is why most people blocked flash, and why most Apple refused to support it on ipads.
- it had horrible security record. For some reason, Adobe could not fix the bugs in the Flash plugin. This is why IT departments started to block it.
For more details, see this very interesing Steve Job's letter why Flash would never run on i-devices: https://www.apple.com/hotnews/thoughts-on-flash/ (note it does not even mention sandboxing model)
They've since done a double-take and have accepted games built in Unity and apps built in website-wrapper frameworks (also many of which are proprietary).
Apple had many reasons to want to rightfully kill off Flash. But the thing is, it wasn't all bad.
Note that I do agree however that slow security fixes and Flash causing crashes / consuming lots of CPU are real concerns.
I think this is overstated. Sure there were Flash 0-days, but then it was probably also the highest-value 0-day target in the world. In those days Flash was more widely installed than any single browser, or even OS. It may well have been the most widely-installed application period.
The point being, if Flash was inherently horrible for security (in some way that, say, Java wasn't) there would have been exploits every day of the week and half the planet would have been owned. I think the reality is that it was just a really big target, which Adobe (with a lot of help from Google) kept relatively secure, all things considered.
Java may be worse (or it may not be, but I would avoid installing either on most client machines), but blowing a bigger hole in the system's defenses doesn't really make the slightly smaller hole any less of a problem, it just changes your priorities in patching.
The only thing impressive about Adobe's security record is the number of times their source code was compromised.
The point being, in its heyday Flash was a bigger target than any web browser, and I don't think its attack surface was much smaller. If Flash had 10x more vulnerabilities than browsers did that'd be bad, but I don't think that was the case.
A similar lack of comittment is also what doomed AIR which had a chance to succeed - after all there was a tonne of existing content waiting to be ported for native release by eager developers already familiar with the AS/Flex stack. Adobe dropped the ball hard by moving the R&D to Bangalore during the most critical time period and things went south really fast. By the time the product managed to stablise most developers have moved on.
Of course, this also means alternative editor implementations, and this decreases business value. This is also a lot of work. And at some point, it became too late -- if format would be published today, very few people would care. So I am not surprised Adobe decided to let the Flash die, rather than open it.
Here's the current spec (PDF):
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/swf/p...
(edit: removing a now-obsolete comment wondering why I'd been downvoted)
This is as opposed to what you do nowadays; use one piece of software for drawing, possibly another for animating, then export those images and/or animations to some format, linkit together with a separate language and/or framework, and maintain assets separately of code. Flash pulled all of these things into one, but in a way that allowed for really complex projects to be made.
A litany of tools for manipulating images and building animations right in the program, without needing to write a single line of code.
And then, on top of that, you can actually.... write code! And it works quite well!
Flash is one of the funnest programming environment to use for "interactive art". Straightforward things are almost always straightforward, and it's much easier to WYSIWYG your way through a lot of tedium.
The interesting thing is, the most comparable environment I can think of today to Flash is Scratch, as it is a drawing, animation and programming tool all in one.
Of course, as the goals of Scratch mostly lean towards being a kids learn-to-program tool, all three parts are much, much, much simpler.
Last year, I had the awesome fortune of meeting Rand Miller and got to chat with him a bit about HyperCard and how they used it for Myst. Though, I barely remember what we discussed because I was so excited to meet him, hahaha :'D
Though I've got nothing to suggest for the interactivity part.
It didn't have ActionScript yet, but if I remember correctly, it did have the ability to link visual elements to arbitrary frames within the animation timeline (as well as to other URLs), so it was actually pretty powerful (a bit like HyperCard for the web).
I was still in elementary school at the time, but I remember creating original animations that my friends all thought were produced by professional animators (or templates), and it certainly expanded my vision of what could be accomplished with a computer. The fact that you could deliver such rich (and interactive) graphics/animations in such a small package - over a 28.8 kbps modem - was like magic. Keep in mind, this was before streaming video became practical for anyone, and simple things like JavaScript[1] rollover effects on buttons still had questionable browser compatibility. Apart from tiny GIFs[2] (usually flames or "under construction" signs), some random <blink> tags and scores of Java applets trying to make text scroll across the screen, the web was largely devoid of motion. I would argue that FutureSplash was the first technology to show us that the web was capable of delivering high-quality motion graphics (things that looked like video) - i.e., content delivery that would eventually compete with television. Indeed, its successor (Flash) would go on to build off that idea by incorporating streaming video support (responsible for most of the early video content online).
Not only was the technology impressive under the surface, but as dyarosla mentions, the animator software struck a unique balance between being powerful and extremely approachable for beginners. That combination continued, for the most part, through Macromedia and Adobe.
[1] Strangely enough, I seem to recall a few years later (probably when it was under Macromedia's control) a player was released that could play Flash animations in pure JavaScript (eliminating the need for a plugin). It's interesting to think about how far we've come since then, yet how similar that was to our modern web tech stack, at least in concept.
[2] Actually, I don't think they were even animated GIFs as we know them. Client pull and server push animations: http://www.oreilly.com/openbook/cgi/ch06_06.html
The CreateJS suite covers most, if not all, of what Flash could do in JavaScript. In fact, it is the library used by Adobe Animate professional to export Flash programs to HTML5 target. It may not be as user-friendly, but it's as comprehensive.
BTW, to those that downvoted this comment to -2, in HN we generally don't downvote to express disagreement.
The ubiquity of the Flash player transformed the Internet into a true entertainment platform. Prior to Flash, technologies like RealAudio/Video, Quicktime, and animated gifs were clunky and couldn't compete with traditional media. With Flash came the first high-quality, streaming, web cartoons/animations; web games; and eventually Youtube (after the release of the FLV format). Flash should be recognized as a true innovation that paved the way for the modern web. The modern web stack of JS, HTML5 Video/Audio, SVG has finally caught up, but I don't think we'll ever see such seamless integration and power in one tool (for better or worse).
HyperCard.
I actually think it didn't hurt the web, it was a massive driver for change, Flash highlighted the lack of functionality in html/js and was part of the reason that forced html to finally get canvas, etc.
If you're completely honest with yourself, you'll realise that html/js are still years behind what you can do in Silverlight and Adobe Air.
Now it's mobile apps that are forcing the web to carry on evolving and highlight just how backward html/js is. In years time we'll have people saying that phone specific apps were terrible, but in reality, without something to show us the flaws of html/js are, it wouldn't move forward.
Personally I'm no fan of the mono-culture of the web, the idea that you can only use one language, either for markup or for programming, should be anathema to all of us and instead it is bizarrely celebrated. I'd far prefer to be using Python or Ruby or whatever than javascript and in reality I think it's probably costing the world billions or trillions in wasted effort as we schlep around with javascript.
The only thing I'm using Flash now any more is watching videos. Where I'm living it is sadly still the standard for some TV stations video websites.
The trend of restaurants around me is to just have a single png scan of their menu and nothing else. I was talking to one owner and they were wondering why their SEO was so bad
I suspect it just became a sort of arms race with everyone competing on sizzle rather than usability.
What you're describing is pretty much small businesses everywhere. Presumably this is a lot of Squarespace's target market.
The template sites are obvious because the owners chose a feature-filled template with all of the bells and whistles but have no use case for all of the frills. There are empty carousels, tons of extra white space, empty link slots, and a halfway responsive mobile experience.
Considering the above, a static, zoom-able HQ image of the menu is not a bad option. It's not optimal, but it's not bad. It tells the restaurant's name, phone number, business hours (possibly), address (again possibly), plus the entire menu. That ticks all of the major boxes for information that a customer may need.
If you want vector graphics, you have SVG. If you want imperative 2D graphics, you have Canvas. If you want 3D, you have WebGL. If you want video, you have the Video tag. If you want dynamic audio processing, you have the Web Audio API. If you want duplex, real-time or peer-to-peer communication, you have WebSockets and WebRTC. If you want client persistence, you have localStorage, sessionStorage and IndexedDB. If you want complex layout, you have CSS Flexbox and CSS Grids. If you want dynamic caching, you have Service Workers. If you want parallelisation, you have Web Workers. You have APIs to create, upload and download files from scratch, to instantiate typed arrays and get byte-level access.
I have a lot of gratitude to google, mozilla (and even Microsoft and Apple, as they come around to it) for making my job easier/possible.
It's the same thing that Delphi & Visual Studio did for modern programming. If you were used to working in Turbo Pascal/C and switched to Delphi, it was just amazing what a productive boost you'd experience from having a true integrated development environment with all the little tools and drag&drop builders and ready-made components.
All jest aside - it's true that Flash is way more productive than the "true" web environment today. It has its drawbacks, but developer tooling was awesome.
I may dislike javascript, sure, but it doesn't make me any less right that it's stupid that we still have no choice but to program in a particular language in today's effective OS, the browser. I generally use typescript now, but it's still rubbish compared to C# or Ruby or Python or [insert your favourite language]. And I feel the inanity of the present build infrastructure that we end up having to use is such an utter waste of my life.
Just think how much you'd chafe if you were forced to use a language you thought was substandard for 30% of your development time and waste hours or days every now and then wrestling build problems that I shouldn't even be thinking about it.
I certainly don't feel it's a chip, I think it's a perfectly sane response.
I really wish that we had a persistent, non-ephemeral web api for local storage. One that has to be manually deleted by the user, searchable by domain, just like a mobile app. It should ask you to allow it just like notifications or webcam usage, and allow you to set a maximum size with a reasonable fallback default. Until we have that, and full support for service worker features, mobile apps will be a necessity for many developers unfortunately.
You're describing modern, client rendered web applications.
I wholeheartedly agree the host of power than Flash brought, but I'm glad for its demise because — among other reasons — of this: that rich interactivity on the web is now largely standardized and open.
Indexing was fixable by some additional effort and it's the same with these days SPAs.
Basically most of those complains apply to a lot of modern web sites.
All I remember from the Flash days, and I was a flash developer bear in mind, was clunky, contentless, CPU hammering folly. None of which I think I miss.
Also lots of indie game devs (e.g. team meat of super meat boy or binding of Isaac) got their start there, a lot of the early "upload your flash game here" might have paved the way for getting so many games on the app store model when it got going.
Not so many practical tools spring to mind but on the arts and creative side of things most definitely.
> Google Maps
Here you go.
Less facetiously many web based games would not have been possible with other options available at the time. I can't think of as many significant tools that it was in part responsible for and it massively outstayed its welcome (a few years before Google maps and http://www.elizium.nu/scripts/lemmings/ I expect flash or java applets would have been needed to achieve the same effect both because of browser performance & compatibility issues at the time and the fact then JS was disabled in many environments too), but thre were some things it was still the least bad option for until a few years ago, video (thing youtube and similar) being the main one.
> clunky, ..., CPU hammering
Definitely, though there were some great programmers out there making efficient things in flash, it had the issue of making it easy to create a sub-optimal mess (some would say the tooling made it overly hasslesome to create something efficient, though I was never a flash programmer so I can't comment there myself).
> contentless
The same can be said of a great many things not involving flash; before, during and after flash's heyday!
> folly
One man's folly is another man's comic (or otherwise artistic) genius. There was a lot of dross, but flash allowed the creation of some great pieces in its time.
[0] https://en.wikipedia.org/wiki/The_Binding_of_Isaac_(video_ga...
Small cultural artifacts move humanity in more subtle ways than the utilitarian behemoths mentioned by you.
Weebls Stuff and Rathergood influenced my thinking a lot by introducing 14yo me to absurd. I'm sure less popular creations made in Flash had some effect too.
Quite an ambitious achievement for a simple animation tool.
One thing I know to be true. The corporate world is run by insecure, ill informed pretenders who fear accountability above all else. People who only make a decision when someone under them has put their neck on the line.
Flash and Flex's success in financial services was not based on merit. It was based on fear of deviating from the norm.
What really made flash better than the rest (and still make it) was the ability to use a familiar interface for creatives (a timeline is a timeline) to to build resolution independent artifacts that they could test on their own, on their personal computers, just by pressing ENTER or frame by frame
Director
The tamarin project on Mozilla mercurial with tamarin-central [0] and tamarin-redux [1]
Then after the project got abandoned, Adobe renamed it to avmplus and moved it to github [2] and made a couple updates.
Later on, they moved it to another repo [3], updated it on December 2015 to the equivalent of Flash Player v19.0 and updated it again on Mars 2016 to the equivalent of Flash Player v20.0 (codename rankin).
I maintain a fork/extension named redtamarin [4] which focus mainly on adding native API to make ActionScript 3.0 run on the command-line, shell scripts, server-side, etc.
imho FlasCC/Alchemy/CrossBridge did not take off because it is much harder for dev to produce a project in C++ than in AS3, also why redtamarin took an opposite approach: bring the C API to the AS3 context instead of forcing users to actually write C/C++ code.
[0]: https://hg.mozilla.org/tamarin-central
[1]: https://hg.mozilla.org/tamarin-redux
[2]: https://github.com/adobe-flash/avmplus
I wrote a uploader in flash for our photo hosting website many years ago using alchemy. From memory I wrote a wrapper for libjpeg that could do the resizing in C which was then compiled into flash bytecode. That could then be imported into the swf that would handle multiple files drag-drop resize / upload. That all interfaced with the page through some sort of JS bridge.
I'm amazed any of it worked to be honest, somehow it managed to chug along for a decade without issue.
I don't think so.. I can imagine any of my musician friends installing $FRAMEWORK and building a web site full of their own animations, menu's, and music playback..
Flash for all its "evilness" still IMHO hasn't been matched.
Easy to use, powerful and proprietary. As a consumer, flash sites were often horrible. Get a few minutes into using it, find out that there's a bug keeping you from advancing any farther in exploration and your task, so you need to reload. Oh good, you have to start from scratch again because it's not actually using URLs to keep track of your location. Want to know how to find a manual on a manufacturer's site? Oh, good, they used flash, so their site isn't indexed correctly by any search engines, and you have to navigate their poor idea of what made a good UI in 1995.
Flash was good for media delivery. For everything else, it just broke how the web was expected to work.
I get where you are coming from, but being snide when supporting something that was misused so badly is a bit one sided.
Excel is great and has enabled millions of people to accomplish things that expensive coders were previously needed for (and that was a net good) but when misused these things can cause terrible problems[0].
[0] https://www.bloomberg.com/news/articles/2013-04-18/faq-reinh...
I readily agree that Flash was horrible, but none of the things you mentioned has improved with the demise of Flash, at all.
Of course indexing has improved since the demise of flash, compared to the heyday of flash. Flash contained all text in an unindexable binary blob.
Accessibility was very poor since, again, flash prevented the use of any browser features for that without offering its own.
Flash was also a leading security hole for years.
- There are four different browser engines, but no website ever asks you to install a different one (except some Google Cloud stuff tsktsktsk)
- You can develop a complex javascript application and, at the very end, discover that it works in all browsers.
- You can develop a complex javascript application
- seriously, this point needs repetition. In the past I'd spend more than half of the time trying to get something working at least in both firefox and IE, with the fix for A frequently braking B...
- websites cannot open 100 popups, maximise the window etc.
- almost all websites are usable on screens of every size (flash liked to insist on, for example, 800x600. which almost never was the right size)
- Even worse than Flash: Java Applets, Active-X. Seeing a Swing UI today is like a reunion with your childhood tormentor after you've succeeded in life and he has three marriages and a stint in jail behind him: you still have vivid memories of the pain, but it can no longer hurt you.
- Most important: Flash broke everything that makes the web a web. It was simply a delivery platform for binaries with URIs. No links, no way to spider content, access limited to the select platforms Adobe felt like supporting etc.
- The javascript complexity that can run in browsers is an achievement. Relatively speaking, flash was the one runtime Java promised to be, and Java applets however clunky looking back were as futuristic as today's tools are in some use cases.
- Responsive flash apps were perfectly possible if you wanted. Most never learnt that though. That resolution was painful tho.
- Ajax apps are the original JavaScript apps. It was possible to build desktop apps in the browser just fine. 1999, Outlook web app was one of the first complex JavaScript apps in 2000.
- Flash also developed the ability to index content. Same flaw though can exist in js apps too.
I don't want to guess how much of the stuff you wrote about you have used, but those were my experiences in that time. A lot of bleeding edge stuff much like today. I'd still take today though because there's so many more folks online.
It does feel like there has been a lot of constant reinvention and a loss of forward progress. We just keep rebuilding browsers, flash as webassembly, and no shortage of frameworks to extend programming languages to the web, and recreating libraries. I like choice and being a polyglot as much as the next person but at a certain point it seems like our tools are getting broader instead of deeper.
Flash was far from perfect but probably could have stuck around for a few more years while the future of progressive apps matured. They never really got their security game together, but flash lite powered graphical guis on more mobile phones than anyone knew and it was possibly a threat to iOS as no other rich experience existed in mobile.
Instead we all had to wait painfully for JavaScript apps to mature to what flash could do 10 years ago with flex and air (although I wasnt a fan of either they laid a lot of ground work for the rich internet application space.)
Granted it probably helped push things along that flash wasn't around as a crutch...
Some would argue developing mobile and js apps as as painful in the past 5 years as web dev was in the 90s.
I'm just pleased to see the ubiquity and js apps on any medium continue to converge. Hope the high level tooling is coming next to create a whole new segment of beginners.
Sure, the real problem is the people who made poor decisions and made sites like that in the first place, and still do.
The reality is just that HTML in those early days was grim - IE and Netscape were making up tags willy-nilly, and any kind of interactivity or media playback was nigh-impossible to achieve without plugins. (Even for static layouts it could be a significant challenge to make things work the same way across browsers and platforms.)
So the result was, for interactive media-driven sites, developers used Flash outside the bounds of what it was meant for, and the back button broke. The alternative wasn't to not break the back button, the alternative was having a big "This site only works in Netscape!" banner, or having no interactivity at all.
I'm well aware of what you state and the entire point of my statements is that those decisions were wrong.
The solution I would have preferred to those issues you describe is actually not that at all. It's to make simple, usable sites like the one we are currently on.
As far as what you're saying about intent, i am not so sure that adobe never intended or encouraged flash to be used to make whole websites. I suppose one could research that, but it's beside any point i was making.
Neat, but many companies in 2004 wanted sites that couldn't be made out of styled text - minigames, product configurators, branded media experiences or whatever - and they wanted interactivity more than they wanted the back button to work. If you think they were wrong to do so that's fine, but it hasn't got much to do with Flash.
> I suppose one could research that, but it's beside any point i was making.
Its part of the point I was making - that Flash was originally a technology for inserting interactive animations into web pages, and all the significant usability concerns arose from people using it for more than that, which they did because the alternatives were so lacking. (Of course this put pressure on the alternatives to improve, which is what TFA is all about.)
IBM OS/2 had a Parts Workbench that was easier than Visual Basic and Borland had Delphi based on Object Pascal.
Ruby on Rails comes close and Python is the new Visual Basic for a new generation of programmers now.
None of the other parts of the .Net universe are comparable, though; most are either kind of clunky (Webforms) or require a much bigger learning curve to get going.
Been around for a long time, was formerly called RealBASIC.
That being said, Flash definitely had a learning curve that wasn't entirely trivial. So much of the javascript community seems focused on using JS for the really big applications and large scale stuff these days, but I think it'd be nice if innovation were happening in accessibility and tooling for light programmers.
Light programmers is my idea of people who want to build basic functionality but not huge applications and may not be formally trained or have any experience programming, like how small and medium businesses used Flash for cheesy website animation back in the day.
There's a lot of overhead knowledge needed to create in HTML/CSS/JS, and a lot of the beginner tutorials feel like they assume you're intending to become a web dev.
There's more tooling and better libraries for JS today than ever before, but these things are hard for beginners. Stuff like webpack is great but it seems like the focus is in that space.
You could argue that the high complexity large application space is where the focus needs to be, and where js is at its weakest, but I can't help but feel like we could do better. The best thing (imo) for beginners using JS (who don't intend to continue learning to become a developer) is JQuery. Yeah people abuse it but it does simplify basic animation stuff for inexperienced developers.
End rant I guess?
I started my career as a programmer but always had a mind for creative designs. When I discovered Flash around 2002-2003, I was all over it. ActionScript was my ultimate weapon to make Flash sing and dance to all my tunes.
I was so involved then, Macromedia picked me as one of their "Professional Expert" or something in that line. Those were the times when I made good money, lots of friends, clients, met few interesting business partners.
In the summer of 2005, just as it was about to be acquired by Adobe, I got an email that I was invited to their office in San Francisco. I was one of the 20-odd people from around the world picked up for something called the "Lego" Team. I was overwhelmed, humbled, and scared - to meet all the authors from whose book I learned ActionScript, all those developers whose files I downloaded to learn Flash/ActionScript. It was a blast.
If you were into Flash during those times, you'd remember names such as Guy Watson (FlashGuru), Brandon Hall, Peter Hall, Colin Mook, Aral Balkan, Jesse Warden, Peter Hall, Marcos Weskamp, Grant Skinner, etc. Well, it was the congregation of the whos-who of the Flash world at that time.
Well, all of our names were then featured on the credit screen of Macromedia Flash. Some of us also realized that Flash was dying and something needed to be done. Adobe came along and well, Macromedia and Flash became just another archive on Wikipedia.
Next year, 2006, the company I founded was acquired by a Startup from Silicon Valley. That's when I started my very bumpy Startup journey, and I'm still chugging along.
Here are some of the Macromedia Flash Lego Summit photos - https://www.flickr.com/photos/brajeshwar/albums/720575940814... (who do you recognize).
I believe "Lego" was the code name for Flex Builder aimed at developers. "Duplo" was the unfortunate code name for a corresponding Flash authoring application aimed at designers who didn't write ActionScript.
Adobe's sudden and not at all inevitable betrayal of Flex devs was a huge shock and absolutely killed Adobe in the field of Rich Internet Apps which at that point they were dominating.
If they'd pivoted Flex to compile to Javascript then the world as we know it would be a very different place, one where we would have been happily producing web apps in MXML markup for the last decade rather than recently rediscovering it through the medium of React and JSX.
Also checkout the last FlexJS Summit at ApacheCon Miami 2017 [1]
[0]: https://cwiki.apache.org/confluence/display/FLEX/FlexJS
[1]: https://www.youtube.com/playlist?list=PL4EsaSA9xpnnraJX7NzpX...
Having said that 80% of my time is still spend writing AS3 in Flex ;)
Too bad it isn't used more in the real world - it really is a fantastic prototyping tool.
I forgot about that. Does anyone have any info about this? I didn't pay much attention at the time, but in retrospect it seems like it was one of the main reasons everyone stopped using flash.
Did Adobe try to get Steve to pay a licensing fee, or was he just inherently against implementing flash?
The excuse Steve made at the time was that it was too CPU intensive to run flash. I'm not sure how true this was, except for the earliest iPhone models. I've always wondered what the real reasons were.
It was certainly a good decision in retrospect, but it's an interesting bit of history.
That was almost two years after the opening of the app store, and almost three years after the release of the iphone. I'm unsure whether they really had a fully thought out app store strategy initially, or whether they stumbled into it sort of by accident. Even if an app store was planned, I'm not sure they really knew what to expect. I seem to recall them initially saying you didn't need native apps, and then finally realizing the demand was so great (and performance too poor with Safari) that they needed to open one so scrambled to do so. That may just be a narrative I latched onto and remember though...
I wish I saved the pamphlet that Apple sent to developers during the iPhone 1 era. It was hilarious. It was all about how to use Safari to write webapps. They even highlighted how you could save a bookmark as an icon on your home screen so that your webapp launched like a native app. But of course it was just Safari.
I'm only going to discuss interpreted code. The operating system prevents the execution of any object code that isn't signed by the App Store. The only exceptions are system processes, like JavaScript just-in-time compilation performed by WebKit.
Let me go through the changes in section 3.3.2 of the Apple Developer Program License Agreement. I'm going to skip over some things, because I can't find copies of the very earliest agreements, and I haven't read every single one since.
iPhone SDK Agreement, revised 2008-10-20:
3.3.2 An Application may not itself install or launch other executable code
by any means, including without limitation through the use of a plug-in
architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application except for
code that is interpreted and run by Apple's Published APIs and built-in
interpreter(s).
In 2009-03-17, it was changed to this:
3.3.2 An Application may not itself install or launch other executable code
by any means, including without limitation through the use of a plug-in
architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded or used in an Application except for
code that is interpreted and run by Apple's Documented APIs and built-in
interpreter(s).
The iPhone Developer Program License Agreement, revised in 2010-06-07, says:
3.3.2 An Application may not itself install or launch other executable code
by any means, including without limitation through the use of a plug-in
architecture, calling other frameworks, other APIs or otherwise.
Unless otherwise approved by Apple in writing, no interpreted code may be
downloaded or used in an Application except for code that is interpreted
and run by Apple's Documented APIs and built-in interpreter(s).
Notwithstanding the foregoing, with Apple’s prior written consent, an
Application may use embedded interpreted code in a limited way if such use
is solely for providing minor features or functionality that are consistent
with the intended and advertised purpose of the Application.
A year later, iOS Developer Program License Agreement (2011-06-06):
3.3.2 An Application may not download or install executable code.
Interpreted code may only be used in an Application if all scripts, code
and interpreters are packaged in the Application and not downloaded. The
only exception to the foregoing is scripts and code downloaded and run by
Apple's built-in WebKit framework.
On June 5th of this year, the Apple Developer Program License Agreement (which applies to both the iOS and Mac App Stores) was revised to:
3.3.2 Except as set forth in the next paragraph, an Application may not
download or install executable code. Interpreted code may be downloaded to
an Application but only so long as such code: (a) does not change the
primary purpose of the Application by providing features or functionality
that are inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store, (b) does not create a store or
storefront for other code or applications, and (c) does not bypass signing,
sandbox, or other security features of the OS.
An Application that is a programming environment intended for use in
learning how to program may download and run executable code so long as the
following requirements are met: (i) no more than 80 percent of the
Application’s viewing area or screen may be taken over with executable code,
except as otherwise permitted in the Documentation, (ii) the Application
must present a reasonably conspicuous indicator to the user within the
Application to indicate that the user is in a programming environment, (iii)
the Application must not create a store or storefront for other code or
applications, and (iv) the source code provided by the Application must be
completely viewable and editable by the user (e.g., no pre-compiled
libraries or frameworks may be included with the code downloaded).
It's funny, but no one has seemed to notice this except for The Register.
https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...
Even today the best apps are still native.
I'm sure the unstated reasons included that it generally made for poor UX across the web.
Aside from security issues others have mentioned, Early iPhones employed HTML5 as the only 3rd party app API: no flash, no java, not even native Objective C apps. The only reason Apple opened up the Cocoa API to 3rd party developers was because HTML at that time was insufficient for powerful offline experiences (only recently has tools like services workers made deploying offline apps via browser HTML possible). Many would argue Apple's exclusive embrace of modern HTML on its phone was pretty helpful in ensuring HTML5's success accross all platforms.
It was like when the Mac eliminated the floppy drive. Seen as gutsy (or arrogant) at the time, but no one really doubted that's where we were headed.
Had Adobe shown even the slightest sign of responsibility it might have been a different call but at any point after maybe 2002 it was pretty obvious that you shouldn't depend on Flash because Adobe was just milking the customers.
I'm not going to defend the quality of the flashplayer architecture and implementation (due to it's crapness) but it was perfectly fine performance wise - it was a 'resource hog' because of the terrible, terrible code that people wrote for punch the monkey flash apps.
Similarly, the fact that Flash was competitive with IE5 is the problem: browser vendors invested heavily in making that platform faster and richer. Adobe executives thought they had a monopoly and did not.
1. Apple couldn't improve the Flash player like they could with WebKit and Nitro to make Flash content run well on their phones.
2. Most of the complex content on the web was in Flash, by not supporting it the web was fast and light weight for a very low powered mobile device.
If you try and load a JS heavy website on an original iPhone now days it will likely crash.
Flash was the great motivator for browser vendors to improve [their] technology
Part of why the HTML5 group got so much traction was that everyone else realized that the web's rich application platform couldn't be a company which wasn't serious about maintaining it.
Is there another tool capable to compile to iOS and Android over Windows with no need of a Mac with XCode? I loved that in Flash.
"You either die a hero or you live long enough to see yourself become the villain". Harvey Dent, The Dark Knight.
Sorry for poor english. I am not native.
Try doing that with closed-source software.
There was no sudden-change: they kept on maintaining Director, years after its main use-cases (kiosk applications, magazine cover demo disc launchers and CD autoplay software) stopped being relevant.
If my experiences at other software companies are anything to go by: Adobe's staffers probably wanted to open-source it but were held back by licensed third-party components.
I haven't seen any true Director Shockwave content on the web since the original Shockwave.com - it was a handful of games that today could be built in JavaScript without any trouble.
Yep, it was death by neglect rather than violence. Shockwave was much more powerful than Flash for gamedev, it had true 3D baked in and fantastic audio and video support - in 2001. IIRC lack of a timely OSX version killed it.
Arguably it was the same neglect of the Flash plugin on Mac that partly caused Apple to deep-six iOS support, decimating Flash's marketshare.
Without Flash you couldn't do anything at zombocom[1]!
[1] http://zombo.com
// Now that HTML+JS has has the features necessary to implement the "flash intro page" experience, I have yet another reason to leave javascript disabled.
If Visual Basic (and Delphi, and others) had this basically solved twenty years ago, why is it still something that's so hard to do for HTML?
This is exactly the problem we're solving with Anvil (https://anvil.works). It's explicitly VB-like - one language, drag and drop design, and object oriented components. But it is only possible because we took the deliberate choice to do it all with one language (Python) with an appropriately simplified display model.
https://www.elevatesoft.com/products?category=ewb&type=web
(Examples at the bottom)
Here's an (older) video that shows the IDE in use:
I wouldn't consider what we're doing as "hard". The main thing is that the developer has to be willing to do some odd things relative to traditional web development, such as:
- Don't use JS as the development language, and only use it as a target for a statically-typed, compiled language. It's basically impossible to do a decent IDE without the type information. Even simple things like getting method signatures of event types for selecting/creating event handlers is impossible without types.
- Don't use CSS and, instead, use per-element style modifications via code. CSS is too broad a brush for component-based development where you want to allow the developer to customize the look and feel of every visual control on a per-control basis. Also, it lacks the flexibility required for dealing with weird/odd control state transitions.
In general, one has to take a step back from the HTML/CSS/JS world and virtualize everything in code in order to allow for dual design-time/run-time usage (we're adding server-side right now). Unfortunately, this also has the side-effect of not being "normal" web development anymore, so we're definitely swimming against the tide. But, I think it's the way to create more reliable and dependable web applications in a must more productive manner.
Macromedia Fireworks was a raster editor like Photoshop, but was heavily geared towards "web graphics" (think: Adobe ImageReady). It had neat features such as text templating, integation with Dreamweaver, and decent sub-pixel positioning. I used it from 2001 until 2005. I felt it was primarily for making websites using now-obsolete techniques like tables-for-layout, spacer.gif, and using heavily manually-optimized graphics and techniques to achieve effects that CSS was not yet capable of. I may be wrong, but I don't believe Fireworks changed much since the Adobe acquisition, ensuring its declining relevance in the post-CSS3 web world.
Not sure about PS, but even this circa 2001 version of Fireworks blows Gimp out of the water in terms of ease of use and basic image manipulations.
I was taking a high-school C++ class at the time, but the whole "everything is an object" concept just didn't stick. It was still in the abstract sense and not tangible.
You start to play with Flash and ActionScript, however, and suddenly each instance is a physical thing you can see and interact with. Each copy of the thing you make inherits those properties and that action script.
It was a very useful learning experience for me. I worked through a Pong tutorial and then tried to extend it as a personal project to be a four-corner pong. It became very clear the benefits of making a position-agnostic "Paddle" class when the left-right paddles' collision detection went haywire upon copy-pasting them to the top and bottom of the screen.
Alchemy wasn't very well documented initially but worked just fine once we got it working. It integrated with the Flash code nicely. Saved me a ton of time when updating the two platforms and testing the changes.
When Jobs murdered flash I transitioned to web waiting for it to come up to parity, but it never did.
We've had incremental improvements, but IMO they have been scraps, and the priority is out of wack. Why are we adding MIDI to a platform that still can't efficiently do layout?
I recently gave a talk about building a new browser without the DOM, instead using native UI primitives driven by javascript for our sites: https://www.youtube.com/watch?v=WEQx3wz8QeY
Wherever we land, I just hope to someday get the kind of performance on the web that I got 8 years ago with Flash.
The year I speak of is 2001 and my task as an intern was to create a CMS for the company that could power a "plain" website at the same time as dynamic content for the fancy Flash website. It was hell of a lot of fun coming up with a solution that made this possible. Even managed to make the company migrate from PHP3 to PHP4 for it.
But not so soon after (let's say 2005? 2006?) I wasn't missing Flash (or it's cousin, Shockwave) anymore. Good for games, but the more I did proper web development the more it showed that it was just interactive movies (surprise) and not so good to work with for plain (html) text.
Personally I don't see these as features but deficiencies.
I liked the Flash creator tools; I haven't used a vector drawing + animation system quite like it since.
Flash also allowed creators to publish, many cartoon shows today still use Flash [1]. Many have moved to ToonBoom or others but many still use it.
Flash will always be an impressive moment in the web and interactives/games.
Macromedia was quite the company, Flash/Director both really died from Adobe's hands. I wonder if Microsoft would have bought Macromedia if it had gone different. Macromedia really created fast web video with Flash/ASF formats/RTMP streaming and saved us from Real Player, Quicktime, and Windows Media Player. Flash made possible Youtube.
Flash is still around as Adobe Animate and OSS as OpenFL[2], lime[3], Haxe [4] and more. Though it is more focused on compilation to target platforms natively from script and AOT compiling or WebGL/html5 output rather than to the AVM or runtime ActionScript.
[1] https://en.wikipedia.org/wiki/List_of_Flash_animated_televis...
Then I did Java, C++, Python and all the others before going to JavaScript. I've been using mostly JavaScript for the past 5 years.
I actually don't miss any of the other languages, not even ActionScript 3.
I think that you don't really need classes, private methods, protected methods, abstract classes, inheritance, etc... For web-related stuff.
Games are a bit different because, in a game, unusual edge cases happen all the time (a game can be in a practically infinite number of states), so static type checking can help take care of a lot of issues. That said, with automated testing, you can also get similar stability without having types.