How Adobe Flash Lost Its Way 354
snydeq writes "Despite early successes on the Web, the latter years of Flash have been a tale of missed opportunities, writes Fatal Exception's Neil McAllister. 'The bigger picture — which I've touched on before — is that major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps. That's long been the case on iOS and other smartphone platforms, and now it's starting to be the norm on Windows. Each step of the way, Adobe is getting left behind,' McAllister writes. 'Perhaps Adobe's biggest problem, however, is that it's something of a relic as developer-oriented vendors go. How many people have access to the Flash runtime is almost a moot point, because Adobe doesn't make any money from the runtime directly; it gives it away for free. Adobe makes its money from selling developer tools. Given the rich supply of free, open source developer tools available today, vendors like that are few and far between. Remember Borland? Or Watcom?'"
Native Apps? (Score:5, Funny)
major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps.
Really? Who? Where? and will it run on the cloud?
Re:Native Apps? (Score:5, Insightful)
Aside from discussions on workstation software, the term "native app" has now become moron speak for "embeded webkit".
Offline use (Score:3)
Re: (Score:2, Insightful)
In modern browsers, any web site can cache application data and logic on a device so no internet access is needed. Google does this for their mobile gmail site and it works quite well.
Quota for offline application cache (Score:2)
In modern browsers, any web site can cache application data and logic on a device so no internet access is needed.
Only up to 5 MB on certain popular devices, I've read.
Re: (Score:2)
Which allows you to pop up a message saying "would you like to increase it ?"
Re: (Score:2)
There are plenty of apps on iOS that cannot be done as Web apps. There are many apps from the Mac like Keynote
I don't see how not now that SlideShare has switched from Flash to HTML [slashdot.org].
An iOS is running on a workstation class core
Which is inaccessible unless you jailbreak or pay $649 plus $99 per year.
Re: (Score:2)
The real question is "Will it run on an HTML5 Beowulf cluster of virtualized CSS3 clouds with AJAX, microblogging and crowdsourcing support?"
Re: (Score:2)
The real question is "Will it run on an HTML5 Beowulf cluster of virtualized CSS3 clouds with AJAX, microblogging and crowdsourcing support?"
No. But it comes with a FULL, MONEY-BACK GUARANTEE to pocket-dial your spouse, mother, or boss when you're in a compromising situation.
Re:Native Apps? (Score:5, Insightful)
There will be a very big opportunity for something that ties all these platforms together in the near future.
My iPhone has its own development platform
My wife's Android phone the same
My LG TV has its own App API
My Philips Blue ray player has its own App API
Samsung just announced its going to develop yet another OS for mobile phones...
The market is fragmenting so fast its with all these "App" platforms, that there will be a great incentive for the first to create the "write once" , "run everywhere" tool chain. This will of course take a few years, but so many different platforms cannot be sustained.
Re: (Score:2)
The market is fragmenting so fast its with all these "App" platforms, that there will be a great incentive for the first to create the "write once" , "run everywhere" tool chain. This will of course take a few years, but so many different platforms cannot be sustained.
To start, they should create a distribution like that for Windows. There's more than enough libraries that should make it possible.
The problem is that we already have splintering caused by attempts to create one. As of now, the crossplatform stuff includes Allegro, OpenGL, QT, SDL, SFML, wxWidgets as well as many other libraries. It's quite bad if you want to use Mingw to develop, which is too minimalistic to include even headers to fully use your system (requiring the user to download a w32api package,
Re: (Score:2)
It's quite bad if you want to use Mingw to develop, which is too minimalistic to include even headers to fully use your system (requiring the user to download a w32api package, by then you'd wonder why it isn't in the stock download).
I was under the impression that the MinGW package manager application let the user download MinGW and w32api at once.
Re: (Score:2)
To start, they should create a [write-once run-anywhere environment] for Windows. There's more than enough libraries that should make it possible.
It's called Java
Windows Phone 7 runs only CIL (.NET bytecode). Is there a compiler from Java source code to CIL that's still supported? As I understand it, Microsoft has stopped development on J#.
Re: (Score:2)
The market is fragmenting so fast its with all these "App" platforms, that there will be a great incentive for the first to create the "write once" , "run everywhere" tool chain. This will of course take a few years, but so many different platforms cannot be sustained.
You mean something like Java, or Python?
Re: (Score:2)
It was/is being tried... Java (of which I believe three of your devices use or use slight variants thereof...)
Re: (Score:2)
Those are already all tied together by HTML5. That is how you make a single app to run everywhere. Native apps are the opposite, they are how you make an app to run just in one device. To exploit the specific features of that device. To be an alternative to the Web. Between the 2, you can have any kind of app you like. If you only had one or the other, then you are hopping on one leg.
I don't see how a camera is a "specific feature" (Score:2)
Those are already all tied together by HTML5. That is how you make a single app to run everywhere. Native apps are the opposite, they are how you make an app to run just in one device. To exploit the specific features of that device.
I don't see how a camera is such a "specific feature" nowadays given that virtually all smartphones and many laptops have a camera. Using HTML5, how do I request the user's permission to access a device's camera and then subsequently access the camera?
Re: (Score:3)
Yes! If only we had some kind of "world wide web" that you could deploy your application on, and then have it just work on any platform...
(I know, crazy talk)
Re: (Score:2)
There will be incentive, but the powers that be may fight it.
Apple has no incentive to support such a thing.
Google though, I don't think would care.
MS, I'm not sure.
It depends on which groups you think want to lock developers in, and which want pitch a big tent. So far Apple seems intent on fostering as much developer lock-in as possible (they might call it "commitment"), as one of the major draws of their platforms is that many apps are exclusive to them. This will become less relevant with time as Andro
Re: (Score:2)
The best-case scenario for RIA developers is to have a single code base that has multiple profiles for publishing to different devices. Adobe is using Flash Builder for this exact scenario. FB 4.5 allows a developer to have multiple profiles for Android, iPhone, iPad, numerous other tab
Re: (Score:2)
That's just the claim of lazy developers. Consumers don't want apps that are created like that. They are show and don't use any of the native features of your device. What will happen is that developers that take the time to do it right and taylor their apps will be successful. Those that take short cuts will fail.
You forgot a step... people will ask why Angry Birds 12 has feature X on their iPhone 7 but they can't do that on their Android 5 tablet.
If you don't need a native feature of the device for the functionality of your program, then you're naive to think that it's better to code natively rather than using a write once-run everywhere tool chain like html5... assuming that tool chain actually does what you need it to do, why on earth would you develop using a chain that restricts where it can be used?
Tablets aren't always online (Score:2)
Browser-based apps can be stored on the device
Until the application runs into severe limits that a device imposes on the size of the HTML5 application cache and HTML5 local storage.
and native apps can use network communication (especially when the device is always online anyway)
Phones are always online. Tablets aren't. The iPod touch, for instance, is a 3.5" tablet, and it's offline whenever the user isn't within the range of a Wi-Fi AP with a known password.
Why on earth would you run an app on a server half way around the world, when the device could easily do the work itself
There are applications for which one would need to synchronize with each transaction, such as anything related to order fulfillment. (But then I'm biased because order fulfillment web apps are
Re: (Score:2)
and native apps can use network communication (especially when the device is always online anyway)
Phones are always online. Tablets aren't. The iPod touch, for instance, is a 3.5" tablet, and it's offline whenever the user isn't within the range of a Wi-Fi AP with a known password.
...also, Flash can use "network communication" now via sockets. Java has had it for years. I don't consider Flash/Java "native".
Re: (Score:3, Informative)
No, they are not. Many, many people turn off GPRS/3G/$CELLTECHNOLOGY_OF_THE_DAY by default to save on charges. Not everyone has a "flat" plan. I'd wager to say, most don't. Also, if you leave your country of origin (I realize that's not a problem in the US), then you have insane roaming charges. People are careful whether they use their phones for online activities. Even those stupid "wheather" applications that come by default on some HTC Phones rack up considerable charges if
Turn on cellular radio while away from Wi-Fi (Score:2)
native apps can use network communication (especially when the device is always online anyway).
Phones are always online
No, they are not. [rambles about batteries, data caps, and roaming charges]
I think Anonymous Coward's point is that a phone lets the user choose to turn on the cellular radio at any time, even while away from Wi-Fi coverage. Wi-Fi-only tablets don't let the user do that.
Flash sucks, and was just waiting to be replaced (Score:5, Insightful)
Closed, proprietary, full of security holes, resource hungry, used by marketers to deliver enhanced annoyance to users.
The Internet was waiting for a replacement to come along.
Flash was living on borrowed time because of those who had an opinion most saw it as a necessary evil instead of a wonderful platform.
The replacement(s) will be shitty, too. (Score:5, Insightful)
Any replacement(s) will be shitty, too. It won't matter who creates them, or how they're implemented. They will be shitty. That's just the nature of any attempt to have the browser host remotely complex applications. The browser is merely a document viewer and navigator; it is not an operating system of some sort. It will always fail as an operating system or an application host.
Go back to when this idea of having the browser host applications first took off. JavaScript is one of the biggest blunders of all time. It wasn't just shitty when it was introduced in the mid-1990s, it was seen as absolutely abysmal and unacceptable by basically all developers at the time. These were developers who had used real languages like C, C++, Smalltalk, and Perl. They knew shitty when they saw it, and they refused to use it. That's why JavaScript went basically untouched for a decade, until those developers had retired or moved on to other endeavors. It's only been deemed "acceptable" by a much younger and more inexperienced generation of programmers, many of which haven't used any other programming language (with the exception of perhaps PHP, the next worst language ever implemented and widely used), and thus don't realize how horrible JavaScript is.
The other technologies that followed the initial JavaScript attempt have been shitty, too. Java applets, ActiveX controls, Flash, and now JavaScript again with the latest and ever-changing-not-to-be-standardized-until-2022-or-later HTML5 nonsense, have all offered horrible experiences and nothing but problems for users, system administrators and network administrators alike. Google's Native Client effort will likely be just as horrid in the long run, although their work does seem marginally more competent than, say, all of the JavaScript work ever done.
The end result is that the browser should not be used for anything more than displaying and linking documents. Real functionality should be implemented via a native application. If more than one platform needs to be targeted, use a truly portable programming language like Python, or do the right thing and create separate implementations for each platform.
Re:The replacement(s) will be shitty, too. (Score:5, Informative)
Just mentioning here the time line line is all wrong. ActiveX controls came very early in the web, 1996 as a way of exporting COM. It was an alternative to Java applets not JavaScript. Microsoft was fine with JavaScript though their main alternative was VBScript.
Over the last 8 years there have been huge improvements in JavaScript engines. It is the faster engines that made JS as an app platform possible.
Re: (Score:2)
If you seriously advocate creating separate implementations for each platform, then you and I have very different definitions of "the right thing."
Re: (Score:2)
This argument has been going on for a long time. I tend to see both sides of it. Different platforms have different features and expectations. One size doesn't fit all.
Re: (Score:2)
> One size doesn't fit all.
There are too many people who don't have room in their philosophies for any balance.
What we see on iPad is perfect: a great native C/C++ platform with rich frameworks that exponentially speed up development, heavy duty multimedia, advanced graphics and animation, deep access to the core of the device BUT ALSO a great HTML5 Web platform with rich typography, color managed graphics, hardware accelerated animations, fast JavaScript, great usability, local installation, home screen
Re: (Score:2)
That doesn't mean that you can't reuse much of the core functionality. That's exactly what any sensible and competent developer or development team would do. But to provide a good user experience, you need unique UIs for each device type.
Indeed. In my day job, I write code "mostly" for Windows. Most of these apps have a fairly GUI rich front end. Quite often however, someone comes along and says, "ooh, can I get this on my Mac/Linux box/iPad/Android device?". Now, I could just write something with a generic front end that will work on any of those, but then my apps would be suboptimal. They'd be targetting something (or nothing) and not play to the strengths of each operating system and user interface.
I much prefer to spend the time to
Re:The replacement(s) will be shitty, too. (Score:5, Interesting)
Any replacement(s) will be shitty, too. It won't matter who creates them, or how they're implemented. They will be shitty. That's just the nature of any attempt to have the browser host remotely complex applications. The browser is merely a document viewer and navigator; it is not an operating system of some sort. It will always fail as an operating system or an application host.
This is a debate with a long and storied history going back to Andreessen [wired.com], and probably beyond. Browsers have taken over much of the work done by native apps on many operating systems, and whether you like it or not, that's a trend which is accelerating, notwithstanding the recent trend for mobile binaries. There are a good reasons for the way the web has taken over our computing lives, and also good reasons why binary solutions like Flash are gradually being deprecated - they break one of the main advantages of the web, which is that it works everywhere - even on devices which haven't been invented yet. That is also why various companies have attempted to introduce binary solutions to web problems - in order to gain a stranglehold on the market again, as they can easily do with binary apps (all the solutions you list were attempts to do this, from applets, to ActiveX to Flash).
It's interesting that you focus on javascript as a roadblock and blunder, as javascript is not actually the language the vast majority of the code in web apps is written in - it's used as a simple way to add interactivity and animation to documents, and occasionally to allow requests for page fragments. I suppose it makes a good rant if you can focus on javascript which, if you know nothing about it, seems an easy punch-bag. It's actually quite an interesting language, though I wouldn't try to create something large in it. The javascript involved in creating a modern web application is typically pretty minimal, and often reliant on libraries like query which smooth out a lot of the inconsistencies between browsers, so javascript is not really the question when comparing flash to html development to native binaries. It's not the technology in which the vast majority of time is spent for web app development - on the contrary, it is strictly optional. The languages used for actual web development vary wildly from C variants, perl, PHP (ugh), ruby, python, smalltalk etc etc. You can use whichever language or framework you like when developing web apps, and the beauty of it is, your users won't care, whether they are viewing it on a mac desktop from 2005 or a Windows phone from 2011.
The end result is that the browser should not be used for anything more than displaying and linking documents.
The vast majority of the work many people do all day includes displaying, editing and linking documents - for that the web is a perfect fit - a far better fit than binary apps like MS Word. For something like photoshop editing huge image files, a binary is still the answer, but it does have downsides. The real question is what trade-offs does your app face, and do the advantages of a web app (faster deployment, cross-platform, document based, stateless, collaborative) outweigh the disadvantages compared to binaries (slower performance, non-local, network dependent, limited file access etc). That's not an equation which has the same answer for all apps or all people, but it's clearly one which has worked out in favour of web technology for huge numbers of apps.
Re: (Score:3)
There are certain other factors at play here that I think are worth mentioning.
1) The dominant platform (COM windows apps) had a huge transitioning problem to .NET. Nothing else has really stepped forward as an application library. Cocoa / IOS is arguably the first major platform and the penetration is nowhere near what COM's was. So except in gaming there has been a tremendous lag in terms of desktop applications showing their advantages.
2) Corporate desktops, who purchase the vast majority of non ent
Re: (Score:2)
Bullshit. Nobody touched JS because it had no proper APIs and it was slow as molasses. Being a shitty language or not is irrelevant, as proven by plenty of other shitty languages that have been heavily adopted before JS was created.
Re: (Score:3)
The other technologies that followed the initial JavaScript attempt have been shitty, too. Java applets
Java came out at almost the exact same time as JavaScript (1995). Remember JavaScript was originally called "ActionScript", and Netscape licensed the name from Sun in (what I assume was) an attempt to capitalise on the hype bandwagon that surrounded Java- or more specifically, client-side Java Applets- at its mid-90s launch.
(They must have paid Sun a lot of money; I can't see any other reason why Sun would have let someone dilute and confuse the Java trademark with something that really had nothing to do
Re: (Score:3)
"Remember JavaScript was originally called "ActionScript", and Netscape licensed the name from Sun "
Actually, you mean LiveScript. LiveScript is the original name. ActionScript is the JavaScript derived language used by Flash.
Maintaining native applications is too expensive (Score:2)
Do you have any idea how much support it requires to maintain multiple OS installers for a python runtime, the binary libraries, and everything else? Don't you think users will complain that the python app has a totally different UI than their native one such as if you use WxWidgets, Qt, etc? Have you thought about what happens when you need to synchronize an application update between your front end and back end? And step users through downloading, disabling anti-virus, and reinstalling your application
Re: (Score:2)
Yes, because Gmail, Gcal, and Docs are just horrible horrible things all around. There are no good webapps at all!
Re: (Score:2)
You should actually learn about HTML5, because you sound like an ass. What is in the HTML5 spec is what the browsers do TODAY. Right now. If they aren't all doing it, it doesn't go in the spec. It's not an aspirational, academic spec like the failed HTML4, that describes how the Web ought to be, it is a practical spec that describes how the Web fucking is.
All of today's browsers use an HTML5 parser by default. For some years now, actually. The overwhelming majority of HTML5 is the parts of HTML4 that browse
Re: (Score:2)
That certainly was the perception of JavaShit at the time. The other thing is that the browsers back then had crap implementations of it and were themselves not terribly stable, and lastly that the computers of the day weren't fast enough to do much interesting in Javascript.
This was back when you could expect a computer to have a 486DX, Windows 95, and Netscape 4, remember.
JS implementations are better now and so is the language itself, computers are faster & so are JS interpreters, and browsers stabl
Re: (Score:2)
used by marketers to deliver enhanced annoyance to users.
Honestly, I think this is the root of why people hate flash. Marketers use it to annoy users. But guess what? Any replacement technology is going to be immediately used by marketers to annoy users. That's what marketers do. If you think HTML5 is going to be a bucket of kittens, you've got another thing coming.
Flash is probably the best place to prototype 2d games, and get your hands dirty with programming that can actually have an interface. It
Well...no. (Score:4, Insightful)
Flash failed because it was proprietary. End of story. The web is no place for closed technologies.
Re: (Score:2)
Nah, it failed because at the end of the say it was only good for video playback and flash games - nothing that isn't disposable.
For the last five years or so it's been obvious to everybody that there's a better way of doing both those things. It's been set back because the usual suspects spent a couple of years trying to lock everybody into some proprietary, patented system but the light is starting to break through now.
Flash will be a relic in a couple more years and nobody will be sad to see it go.
Re: (Score:2)
Wrong. Flash is failing because of that, and because of its crap implementation: poor speed, stability, and security, and the latter especially because of having a shit auto-updater.
Re: (Score:3)
Re: (Score:2)
Copying HTML 5 minified Javascript is likely to be about as useful as downloading and reverse engineering the SWF of a Flash game; which is to say, you can use it to duplicate the functionality, but it'll be damn hard to edit or understand.
Lost it's way? (Score:2)
Platform apps huh? (Score:4, Interesting)
So wait, now we're NOT writing rich applications to be delivered by the browser and instead focusing on native, platform-based apps? I thought that was EXACTLY what we were getting away from. The only 'platform' apps are iPhone and Android mobile apps due to the screen real estate available, even a tablet has the size and responsiveness to work fine with web based apps. Oh wait, a Windows 8 article, that explains it... this is just Microsoft PR being propped up on the backs of mobile interfaces.
Youtube / Online Videos saved Flash (Score:2)
Re: (Score:2)
The early years of the internet were plagued with slow 300 kbps modems, and admins struggling with UUCP-to-SMTP gateways. And the early years of the web were plagued by horribly designed amateurish websites on Geocities.
Re: (Score:2)
slow 300 bps modems
FTFY. I only ever experienced as low as 1200 bps, myself. 300 kbps was either a fractional T1, or came far later with DOCSIS and ADSL.
That is not the only problem. (Score:5, Informative)
Moreover, the problem does not lie completely with *nix developers themselves. Case in point, it takes them months to fix their broken calls to memcpy which were:
traced to Adobe Flash by maintainers of glibc at Red Hat, Linus Torvalds and others.
Full story here [lwn.net].
Relevant part of the conversation:
Re: (Score:2)
I didn't have a problem with Flash, until I moved to Ubuntu. Now I can see the attraction of an open standard where stuff works out of the box (yes, even on a 64 bit OS - imagine that, I have more than 3 gigs of ram) rather than dealing with pain, glitches and crashes.
Actually, I'm, finding that Flash (10.3, at least) is finally running acceptably well on Ubuntu. In the last 3 weeks, I've had Flash crash on me (in the browser) once, and Firefox had it sandboxed, so the rest of the system continued on fine.
Frankly, Compiz is a much bigger problem these days.
Re: (Score:3, Insightful)
It's not a glibc bug, it's a bug in Flash.
Flash was using memcpy(3) incorrectly. It happened to work on older versions of glibc/x86 by chance. There was never any guarantee that it would work on later version of glibc/x86, or on non-x86 versions of glibc, or non-glibc libcs (e.g. BSD libc), or basically any other Unix/POSIX/C-based system.
The whole bloody reason for API documentation, standards and the like is so that bad or non-optimal implementation details need not be fixed in stone forever! You should b
20/20 rosy view? (Score:5, Insightful)
IIRC Apple explicitly didn't want native apps when it released the iPhone. Their original idea was to have everything web based and accessed through Safari. A lot of time and effort was put into making this work. Native apps, and the app store, only surfaced with the 2nd revision of iOS and after people had been jail-breaking their phones to be able to install native apps. Android had to allow native apps because iOS did. This drive to native apps was from the users not from the manufacturers. The whole summary is a massive rewrite of history to fit the author's viewpoint.
Re: (Score:2)
massive rewrite of history to fit the author's viewpoint.
Isn't that something like 80% of Slashdot articles and comments?
Re: (Score:3)
I think that Apple's expressed lack of interest in native apps in the first iteration of the iPhone OS were to discourage people from waiting for a feature and to maintain a competitive edge via secrecy.
Re:20/20 rosy view? (Score:5, Insightful)
No, you are totally wrong. That is the myth, not the facts.
Apple executed the iPhone launch and App Store launch exactly according to plan. Nobody bullied them into anything. When the iOS SDK was released one year after iPhone, that gave it these very significant advantages over being released earlier:
- there was a user base of 6 million enthusiastic users who were getting a little tired of their 10-12 built-in apps and had their wallets out for new apps, plus something like 3 million iPod touch users
- there was a developer base that was worked up much more than after a Steve Ballmer dance number because iPhone had seemed to them like forbidden fruit for a year, and those 6 million hungry users looked like they were walking around on plump turkey legs
- the concept of what an iOS app looks like and feels like and how it acts were better developed, and better understood by people inside Apple, by users, by developers
- there was an international version of the phone remember, original iPhone was US-only, it was sort of a beta test
They were always going to have CocoaTouch apps. iPhone very specifically cleared the way for iPad. The reason iPad had 500 full-size apps at launch and 1000 by a week later and 10,000 by a few months later was because there were already many thousands of iOS developers and lots of iOS app code in the world by then. The apps that sell iPads and iPhones are not Web apps, they are the really rich, media-heavy Mac class apps, many of them from the Mac. Of course Apple was going to leverage all the pre-iPhone OS X code when they put OS X on a phone.
Also, the SDK that Apple released in mid-2008 had been worked on for years. It's crazy to say that Apple threw it together in 6 months when they saw that the people wanted apps.
The HTML5 or CocoaTouch choice on iOS is perfectly designed. It was always going to be that way. The 2 together are a yin yang of apps. Any particular app you may want to make can be made for iPhone because either HTML5 or CocoaTouch will be perfect for it. They are much better together than if you had just one or the other.
> Android had to allow native apps because iOS did.
Android does not have native apps, it has Java-like apps running in a virtual machine. App Store launched in mid-2008, and Android launched in late 2008. There wasn't enough time there for Google to create Dalvik as an answer to App Store. Dalvik was already built way before that.
Not working (Score:2)
Ummm... (Score:2)
This part of the argument seems a little questionable. Yes, the OSS tools scene has grown and improved by considerable measure, which probably did help to murder some of the more indie and niche players(OSS has a somewhat mixed record in toppling incumbents; but it tends to sharply reduce the demand for '2nd best; but cheaper' and 'scrappy underdog with rou
Re: (Score:2)
Flash blockers made flash tolerable and allowed me to install the Flash client. Technology also caught up with a the requirements of flash. A few non-entertainment sites also began to use Flash, like
Re: (Score:2)
Well written and argued points!
Remember that flash player replaced things like java and shockwave and people loathed those applications too. End users care about performance.
Re: (Score:2)
Actually, Adobe's design tools also suck now. There is a designer revolt underway, but unfortunately, since Adobe bought Macromedia there is no competition anymore (thanks Bush administration!) You would not believe the bugs in a copy of Creative Suite, which costs more than a Mac.
Adobes core business is not flash. (Score:3)
I think flash was bought by adobe to keep control until the ris of flash could not harm them any more. Adobes core business are WYSIWYG Document systems, pdf creation, management and form server tools. There is no other integrated product suite like Adobes. You can design an excellent looking printable document which integrates well with online services.
IMHO Adobe buying flash was good for nothing else but preventing flash from becoming relevant in managing online form data.
Video (Score:5, Informative)
IMHO, Flash lost its way when they added video support to it (around the time that Adobe bought Macromedia, as I recall). Before that, Flash was all about the vectors. (You could import bitmaps into it too, but they wouldn't scale well, so those were best used just for static background elements.) It was a way to do animation without pushing full pre-rendered frames down to the client: just describe the shapes then tell the player how to manipulate them. It provided a toolset to produce rich user interfaces that you couldn't even hope to dream of doing with (incompatible implementations of) HTML3 and Javascript, and even HTML4 with CSS can't pull off the same stuff today. The Flash plugin was a lean and efficient client, and close enough to being ubiquitous. Then they tacked video support onto it (which was all about pushing pre-rendered frames down to the client), and it became a video-player plugin (with vector support). The fact that people talk today about replacing Flash with a video codec shows how completely that added feature usurped the original functionality.
Re: (Score:2, Interesting)
If I could mod this comment up, I really would. I wrote the Flash3 player for the Sega Dreamcast, and it was (at that time) a decent lean & mean format. Macromedia's player wasn't suitable for embedded use, but the format itself was fine (they'd got too many C++ dependencies and system level dependencies for embedded systems of the time). The last version I actually implemented was Flash4, and at that point the format itself was all still relatively sane and manageable.
Re: (Score:3)
Re: (Score:2)
Excellent comment, absolutely correct. And shows the problem of just replacing flash.
Re: (Score:2)
It's a good thing it's going away, because the replacement (HTML5) is a much better way to share information in the long run.
Re: (Score:3)
You assume that the sole purpose of a site is to distribute information in a robot-accessible way. Sometimes interacting with humans in a specific way is the whole point of a project. Ever hear of "art"?
Re:Video (Score:5, Insightful)
This is insightful, but I don't think that including movie playback was where Flash lost its way. I think it was when they tried to make Flash into a "platform".
As you say, Flash started out as an animation plugin for vector graphics, and it was good at that. It became used more and more for advertising, which was annoying and often overkill; advertisers used Flash for things that would sometimes be handled more efficiently by a simple animated GIF. Today, it is generally good for 2 things: playing video and making casual games.
However, somewhere along the line, Adobe decided that it wasn't enough to handle content-creation, but they had to own a "platform". PDF stopped being a print-layout format, and suddenly you could build a whole little program into your PDF. Similarly, Flash stopped being an animation plugin and became something more of a development toolkit. When you look at Adobe Air, it becomes clear that Adobe wants you to build whole applications in Flash. Someone at Adobe is hoping that the future will see developers abandon other languages and development tools, and only Adobe will control the software industry.
Still, Flash as a vector animation plugin was doomed to obsolescence sooner or later. It's too simple a function for the world to be depending on a proprietary plugin.
Re: (Score:2)
Well that's revisionist history. I seem to remember adding video to flash was a brilliant move that secured their dominance by providing a web video playing experience that actually worked. All the other solutions at the time were awful, unreliable, slow, and browser/OS-specific. Flash actually worked.
The fact that people talk today about replacing Flash with a video codec shows how completely unused flash would be if it didn't become entrenched as the de facto video player plugin.
This is just terrible journalism (Score:2)
"major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps"
Adobe Flash can build both native iOS and Android apps today. Many of the top games in both the iTunes App store and Android Market are made with Flash.
"Perhaps Adobe's biggest problem, however, is that it's something of a relic as developer-oriented vendors go. How many people have acc
Couldnt help it, sorry (Score:3)
Adobe lost its way when it decided to do stuff other then photoshop.
Adobe lost its way when they took a great new file format (pdf) and tried to add
so much more execution (javascript for one) inside, when all it needed to be was
a copyright protected document with no way to normally alter it.....
Adobe lost its way when ti came out with flash.
Adobe lost its way when they tried to deny their apps were faulty, and that
it was normal to find a 10 zero day exploits a week in your product.
Re: (Score:2)
Adobe didn't "come out with" Flash; Macromedia did. Adobe later bought Macromedia.
Links to "print" versions (Score:2)
Second FA [infoworld.com]
(Third FA is a Slashdot link, so no need to provide more).
Adobe's flop: obsession w/ inclusion at all costs (Score:2)
Part of why Adobe is struggling with Flash is its sense of entitlement.
The company believes not just that Flash is a good idea, but that you *must* adopt Flash. As-is. Without question. No matter how much it slows down your device, how it hurts battery life, how it affects the stability of whatever browser you're using (I know it's not nightmarish, but it's far from perfect). Oh, if you're making an Android phone, could you please make Flash a core part of any marketing you do, no matter how much it act
Its just the industry moving on... (Score:3)
"Despite early successes on the Web, the latter years of Flash have been a tale of missed opportunities,
Not surprising, when the Next Big Things are smartphones and tablets, and - of the two leading platforms - iOS refuses to support Flash at all, and Android has very patchy support (I recently did an unscientific test in Best Buy and although several of the Android tablets claimed to support Flash, only the Xoom actually opened my Flash applet).
One of the key lessons from failure of the original windows "tablet" PCs, the failure of the original EEE PC "Netbook" concept (subsequent "netbooks" have been more and more like entry-level laptops) and the rise of the iDevices has been that phones and tablets need custom-designed software that matches the native UI. That's why Microsoft hasn't been able to Borg the mobile market: the killer apps (Office/Outlook) which help it to dominate the desktop (on PC and Mac) are worthless on mobiles without a ground-up rewrite. Flash has a similar problem: even if your tablet does run Flash, many "legacy" Flash apps just won't work with a touch interface or, if they do, are too fiddly to operate on a tiny screen.
However, "HTML5" (i.e. all, some or fewer of HTML5/CSS3/ECMAScript/DOM/SVG/WebGL/whatever) is only just approaching maturity - so there could be a move back from native Apps to webapps (given they can be made almost indistinguishable from Native on iOS/Android). Amazon have already produced a webapp version of the Kindle reader (to get around Apple's rules on in-app sales).
Flash player itself is probably on the way out - for better or worse "HTML5" will probably take over, especially with Microsoft taking that road with Win 8. However, Adobe has a great opportunity: there's a great gap in the market for something like Flash Professional which can "publish" to HTML5, or even iOS/Android native code. It may not be the programmer's choice, but for certain types of app (e.g. relatively simple educational applets, or casual games) its a killer. Flash player dying doesn't have to hurt Adobe much.
Not that I'm a huge fan of Adobe's current bloatware offerings, but I don't currently see anything like Flash for HTML5 applet authoring...
Re: (Score:2)
but I don't currently see anything like Flash for HTML5 applet authoring
ISTR hearing about Adobe having HTML5 export options.
Remember Borland.... (Score:2)
Actually, Borland's tools (Delphi, C++ Builder, etc.) are still there and they have just released a new version [embarcadero.com] that allows development for Windows (32- and 64-bit, finally), OSX, and iOS. Called Firemonkey, it looks pretty exciting. Android targetting is promised soon.
"Remember Borland? Or Watcom?" (Score:2)
Or Microsoft? They give their compilers [microsoft.com] away, but charge you for the IDE.
Wait...er, now they give away the IDE [microsoft.com], too, but charge you for MFC.
Steve Jobs killed flash... (Score:2)
http://www.apple.com/hotnews/thoughts-on-flash/
Does The End of Flash = Death of the Web? (Score:5, Interesting)
Many people dislike Flash because of how it is used. Mainly, heavy visual advertisements which replaced the far worse era of continous pop-up adds.
Very few who criticize Flash have ever used it to any great extent. They've never explored it's benefits for rich web applications or cross-platform usability.
Many view HTML5 as the death nail in Flash's coffin. And think Adobe is greatly concerned. As the article says, Adobe makes tools. They will just as gladly make developer IDEs for HTML5. In fact, it'd probably be economical cause they could cut a large number of empoyees in both the Flash player and ActionScript development teams.
But there is something that is TERRIFYING in regards to the death of Flash. While so many rejoice in Flash's suffering. They are blind to the real horror on the horizon. They shout "Give us Barrabus".
Why is Flash dying? What killed Flash? Apple's decision to refuse the software to run on it's computers. And now Microsoft is joining Apple by proclaiming the death of the plugin in Windows 8.
And Slashdotters cheer blindly "Open source! HTML5! Yea! Yea!" failing to realize that there is something MUCH more dangerous than a closed source proprietary runtime such as Adobe's Flash.
The fact that it is being killed by closed proprietary platforms. I find it ironic that Slashdotters will cheer the death of the proprietary Flash at the hands of Apple saying "You can not run the software of choice on your own computers." And will applaud Microsoft joining the bandwagon. And call this "good"?
Seriously, Microsoft saw that Apple didn't even get a wrist slap for it's anti-competitive behavior. So is it any wonder that Microsoft has announced no more plugins. No one else's software but ours. Sure, we'll gain an open standard that will likely be split and marred by three main compatriots (Apple, Microsoft & Google).
The result is that you are being told what you can or cannot run on your own machine. And as this blends increasingly more with the cloud (ie: Kindle Fire). We will start to lose ownership and control over our own computers. We'll be locked into proprietary systems.
Ironically, for all Flash's proprietary aspects, it was still very accessible to both users and developers. Yes, Flash has it's problems. But it also has it's strengths. But most of all - it was there.
It's not being killed by a "technical victory". HTML5 is not killing Flash. Rather large companies are deciding to close their platforms. To limit what you can run on them. And THAT is what's killing Flash.
THIS IS NOT PROGRESS, THIS IS REGRESS BACK TO 1984.
You don't seem to understand computers. (Score:4, Insightful)
That's fine, but why do you hang out on a technology web site?
Apple strongly supports HTML5 (and HTML5 is quickly acquiring all of Flash's capabilities) as a means of writing un-curated apps for iOS devices. There is no regression back to anything. All Apple wants is that the Apps which run on their platform won't destroy battery life, steal data, crash, or otherwise annoy their customers. This can be done by writing curated native apps or by working within industry standard protocols for uncurated web apps. Seems pretty simple to me. But then again, I understand how computers work and you don't.
Re: (Score:3)
I'm sorry, but this is a humungous pile of crap.
Apple refuses to let flash run on its iOS (and only iOS, right now) platforms because it's been a resource hog and security concern on its desktop OSes for years. They refuse to let a 3rd party application with a history of ruining the user experience onto a new platform that has a much more limited user experience, and which fewer resources and greater constraints
This isn't about Apple being the big bad mean tech company, this is about Adobe putting out a sub
Dedicated to being displaced. (Score:2)
So... because they dedicated their product to a platform dedicated to displacing them with their own "flash" they have lost. I'm glad TFA expanded on that. He could have just written: If they would have gone full force at becoming cross platform with Linux and OSX flash would have become a popular cross development platform.
Re: (Score:2)
Of a few bucks.
XCode for IPhone development is free. But you need a developer license to publish which is a bit more expensive.
Re: (Score:3)
XCode for IPhone development is free ...as long as you already have a Mac running a sufficiently-recent release of OS X.
Otherwise, not free.
Re: (Score:2)
Yes, if you have an older version of OS X, the current version of Xcode will cost you $4.99.
Re: (Score:2)
$99 / yr. Not terribly expensive.
$99 per year for students and hobbyists (Score:2)
$99 / yr. Not terribly expensive.
That's $99 per year per platform. Want to work on Windows Phone 7? That's another $99 per year. And even if you stick to one platform, it's not inexpensive if you're a student, hobbyist, or anyone else who doesn't make money from his work. Notice the existence of a larger fraction of free apps on Android because developers don't feel they have to recover the $99 per year ante.
Re: (Score:2)
Android is a Linux. XCode is free, and there is a much larger fraction of free apps on Linux than on OSX, especially excluding darwinports/fink apps. iPhone started the whole app store concept, Apple created a huge market for small application vendors.
I just don't see the $99 as much of a disincentive. If I'm willing to donate days / weeks / months of my time why would $100 even be a question?
Some people have a lot more time than money (Score:2)
Android is a Linux.
I don't see how that's relevant. A DVR made by TiVo runs Linux, but it doesn't allow applications from small application vendors at all. That's one reason why some people refer to a "GNU/Linux" environment, as a system with many GNU components can't be Tivoized.
XCode is free, and there is a much larger fraction of free apps on Linux than on OSX, especially excluding darwinports/fink apps.
Someone is much more likely to own a machine capable of running GNU/Linux than a machine capable of (lawfully) running Mac OS X. This means that in a sense, XCode is $649 and comes with a free computer. You can code Linux apps on the Linux machine (o
Re: (Score:3)
Android is a Linux. XCode is free, and there is a much larger fraction of free apps on Linux than on OSX, especially excluding darwinports/fink apps. iPhone started the whole app store concept, Apple created a huge market for small application vendors.
I just don't see the $99 as much of a disincentive. If I'm willing to donate days / weeks / months of my time why would $100 even be a question?
Android is a fork of JAVA [wikipedia.org] (DALVIK) [wikipedia.org] that runs on the Linux kernel. OSX and iOS run on the MACH kernel and BSD *nix. Applications run on the COCOA API [wikipedia.org]. As far as iPhone starting the whole app store concept...Yeah RIGHT [handango.com]. Handango [wikipedia.org] and PocketGear [pocketgear.com] have been around since 1999 dishing out all things Palm, Windows Mobile, Blackberry, Symbian, and Android.
Re: (Score:2)
I think the point is that the same technologies can be used to make desktop applications
Re: (Score:3, Informative)
Re: (Score:2)
The Flex SDK is completely free and open source.
Re: (Score:2)
Clearly, the premises of the article are wrong.
P1: Flash sucks.
P2: Adobe has an outdated business model.
P3: Developers are abandoning Flash.
------
C: It's all Steve Jobs's fault.
Having been a long time /. reader, I know that the conclusion is supposed to be that it's all Steve Job's fault, but I'm having a hard time reaching that conclusion from the stated premises. Therefore, I conclude that the premises are wrong.
Oops, I already made a post. You're right, this is what I posted in case it gets buried:
http://www.apple.com/hotnews/thoughts-on-flash/
His letter turned the tide IMO. Even *I* tend to agree with his stance in the letter...
Re: (Score:2)