4 ms·

> the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security ho

by leokun 13y ago

> the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. 3. It works on mobile devices, flash doesn't. 4. The tools are out there. Check out appcelerator or unity's tools. 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. 6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript? With source maps to help? 7. Flash avoids all kinds of privacy settings and plugins in your browser. Flash gives you less control. 8. Even Adobe has moved past Flash, these arguments are all done, why haven't you moved on?

sanxiyn 13y ago
> Compiled other languages to ActionScript? For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.
- kevingadd 13y ago
  Alchemy didn't compile to ActionScript, it compiled to the underlying VM bytecode and it relied on special bytecodes added to the runtime specifically for Alchemy. A more direct comparison in this case is NaCL - Alchemy-compiled outputs would not work on an old ActionScript VM, while one of asm.js's benefits is that the generated code will work on any javascript runtime, because it's just JS.
philh 13y ago
> Compiled other languages to ActionScript? Haxe compiles to the same thing ActionScript compiles to, which seems like the appropriate comparison. http://en.wikipedia.org/wiki/Haxe http://en.wikipedia.org/wiki/Haxe (And looking it up, apparently it does compile to AS, though I don't think it typically goes via AS when generating a swf. I might be wrong though.)
captainmuon 13y ago
I think there are a couple of misconceptions here: > 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Flash was sandboxed (just as Java). You were strongly restricted in what you could access with ActionScript. Of course, the security was poorly executed. I blame it on the fact that it was developed in a different time, without the experience and tools we have today, and that it was closed-source. Still, native plugins don't have to be inherently insecure. > 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. True, but I'm starting to think "Open Standards" was a huge Trojan horse. - It lead to, or continued, a huge monopolization of platforms. Only a few large companies are able to maintain modern browsers (see the demise of Opera). This is bad, because they can push politically motivated restrictions on their users. (Firefox has a whitelist to only allow certain media codecs to play, although the system would support more. I could modify the source for myself - I did - but it's of no use, as the people visiting my sites won't be able to use it. I don't have the marketing power of Mozilla or Google.) - The "open" "web" platform limits what kinds of apps you can write. You can't really write apps without an (accountable!) central server. Without sockets, you have no Bittorrent, no P2P, no Tor, no Instant Messaging... - I think it also pacifies people who would otherwise be worried about today's locked up platforms. "You can always write a web app if you don't get in the app store." > 3. It works on mobile devices, flash doesn't. Which was a political decision, not a technical one. There used to be thousands of free Flash games, that would have ran with minimal porting on mobile devices. But Apple couldn't control flash, they wouldn't get their 30% cut from Flash apps, and they couldn't censor apps. So they forbid Flash on iOS, and crippled it on OS X, which was one of the main reasons for its demise. > 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. Flash had support for native video playback before HTML. It had 2D acceleration for animations before there was canvas, and Shockwave Flash had 3D acceleration years before WebGL.
- leoc 13y ago
  > True, but I'm starting to think "Open Standards" was a huge Trojan horse. - It lead to, or continued, a huge monopolization of platforms. Only a few large companies are able to maintain modern browsers (see the demise of Opera). Free-slash-open-source programs are like banks in this way. In principle, a bank that fails can always be shut down rather than bailed out, and this is what justifies the existence of private-sector banks. In principle, an open-source program can always be forked if you can't persuade the maintainers to make the changes that you want, and it's always been agreed that this is a central, essential requirement for a program to be considered free-slash-open. But some programs are, in practise, TBTF - Too Big To Fork. A program can be "big" not only by having a large codebase but also through network effects, such as having vast amounts of client software tied to one of its interfaces. The big-boy Web browsers are TBTF in both these ways. So if, for example, you're insulted by Google's decision to knife MathML (as everyone should be), it's relatively easy to roll a Chromium with MathML inside, but you'd still effectively be just maintaining a branch, because you'd have no hope of maintaining "your" browser independently if Google took the whole Chromium codebase in a direction you didn't like - and more importantly, good luck getting users to use your browser or developers to create MathML webpages to support it. A second example of the phenomenon is the Gnome/KDE mess - part of the reason that the Linux desktop sucks is that, even if you have a clear idea of how it could be better, it's still a whole lot of man-hours to spin up an alternative implementation, get apps customised for it, and so on. In general, an area is the domain of TBTF to the extent that you have to win a political persuasion battle or spend a truckload of your own money before you can produce a viable implementation of your alternative idea. The solution, to the extent that there is a solution, to these problems is a technical one: find a way to shrink large programs and/or break them up into small, reasonably independent ones. (Of course all social/political problems are technical problems in disguise just as all technical problems are social/political problems in disguise. ;) ) In the case of the web, this is why the vertically-integrated Web browser must go away https://news.ycombinator.com/item?id=6720793 https://news.ycombinator.com/item?id=6720793 .
NinjaWarrior 13y ago
I think the above poster is talking about UX... > 3. It works on mobile devices, flash doesn't. False. Many (120000+) Flash apps are actively running with Adobe AIR on App Store and Google Play. AIR is a technology to package SWF as a native app. > 4. The tools are out there. Check out appcelerator or unity's tools. Unity can not export for HTML5 yet. Apparently they are working on it but I don't think it's that easy (As for the original article, I DO MIND the initial load time. That will be a big problem for Unity as well). > 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. False. plain (non asm.js) JavaScript is slow. Don't trust micro benchmarks. And at least ActionScript is faster than plain JavaScript (http://j15r.com/blog/2013/07/05/Box2d_Addendum http://j15r.com/blog/2013/07/05/Box2d_Addendum). And Flash Player 11+ has Stage3D which utilize GPU acceleration as well as WebGL. For instance, please watch this Facebook game (http://www.youtube.com/watch?v=vBIJVt05jwc http://www.youtube.com/watch?v=vBIJVt05jwc). Note that this is a commercial product. Not an experiment. Moreover, the same "Epic Citadel" demo was released for Flash on Mar 2012. One year earlier than HTML5 (http://epicgames.com/news/epic-games-releases-epic-citadel-in-flash/ http://epicgames.com/news/epic-games-releases-epic-citadel-i...). > Compiled other languages to ActionScript? Adobe Alchemy... Please don't denounce Flash without a knowledge of Flash. I'm already not a user of Flash and currently developing with Unity and Cocos2d-x instead, but I feel I need to advocate Adobe guys from unfair bashing.
ris 13y ago
> 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Right, (and I'm also in part replying to my sibling replies here) can we stop talking about "sandbox"ing as though it's something concrete and real? Something being "sandboxed" doesn't really mean anything - or rather it does, but only in an abstract way. Everyone who uses the word "sandboxed" means something slightly different, and every time in history someone has implemented a "sandbox"ing" system, their idea of "sandboxing" is slightly different. One person's "sandboxed" means "disables language access to the functions that could affect the system" where another person's "sandboxed" means "uses clever os features to isolate all execution into a separate container". This is why you can endlessly debate whether x or y is or isn't "sandboxed".
Recoil42 13y ago
1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Flash actually was sandboxed. Poorly, yes -- but so were JS VMs until very recently. It was only a matter of time. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. While the Flash IDE itself was closed-sourced, the format itself was almost entirely open-source -- and third-party tools have been available for a long time to compile SWFs on the level: http://en.wikipedia.org/wiki/Adobe_Flash#Open_Screen_Project http://en.wikipedia.org/wiki/Adobe_Flash#Open_Screen_Project 3. It works on mobile devices, flash doesn't. Entirely a political argument. 6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript With source maps to help? This is a tautological argument. "Javascript is better because Javascript is better"

by leokun 13y ago

sanxiyn 13y ago

> Compiled other languages to ActionScript? For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.

kevingadd 13y ago
Alchemy didn't compile to ActionScript, it compiled to the underlying VM bytecode and it relied on special bytecodes added to the runtime specifically for Alchemy. A more direct comparison in this case is NaCL - Alchemy-compiled outputs would not work on an old ActionScript VM, while one of asm.js's benefits is that the generated code will work on any javascript runtime, because it's just JS.

philh 13y ago

> Compiled other languages to ActionScript? Haxe compiles to the same thing ActionScript compiles to, which seems like the appropriate comparison. http://en.wikipedia.org/wiki/Haxe http://en.wikipedia.org/wiki/Haxe (And looking it up, apparently it does compile to AS, though I don't think it typically goes via AS when generating a swf. I might be wrong though.)

captainmuon 13y ago

I think there are a couple of misconceptions here: > 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Flash was sandboxed (just as Java). You were strongly restricted in what you could access with ActionScript. Of course, the security was poorly executed. I blame it on the fact that it was developed in a different time, without the experience and tools we have today, and that it was closed-source. Still, native plugins don't have to be inherently insecure. > 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. True, but I'm starting to think "Open Standards" was a huge Trojan horse. - It lead to, or continued, a huge monopolization of platforms. Only a few large companies are able to maintain modern browsers (see the demise of Opera). This is bad, because they can push politically motivated restrictions on their users. (Firefox has a whitelist to only allow certain media codecs to play, although the system would support more. I could modify the source for myself - I did - but it's of no use, as the people visiting my sites won't be able to use it. I don't have the marketing power of Mozilla or Google.) - The "open" "web" platform limits what kinds of apps you can write. You can't really write apps without an (accountable!) central server. Without sockets, you have no Bittorrent, no P2P, no Tor, no Instant Messaging... - I think it also pacifies people who would otherwise be worried about today's locked up platforms. "You can always write a web app if you don't get in the app store." > 3. It works on mobile devices, flash doesn't. Which was a political decision, not a technical one. There used to be thousands of free Flash games, that would have ran with minimal porting on mobile devices. But Apple couldn't control flash, they wouldn't get their 30% cut from Flash apps, and they couldn't censor apps. So they forbid Flash on iOS, and crippled it on OS X, which was one of the main reasons for its demise. > 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. Flash had support for native video playback before HTML. It had 2D acceleration for animations before there was canvas, and Shockwave Flash had 3D acceleration years before WebGL.

leoc 13y ago
> True, but I'm starting to think "Open Standards" was a huge Trojan horse. - It lead to, or continued, a huge monopolization of platforms. Only a few large companies are able to maintain modern browsers (see the demise of Opera). Free-slash-open-source programs are like banks in this way. In principle, a bank that fails can always be shut down rather than bailed out, and this is what justifies the existence of private-sector banks. In principle, an open-source program can always be forked if you can't persuade the maintainers to make the changes that you want, and it's always been agreed that this is a central, essential requirement for a program to be considered free-slash-open. But some programs are, in practise, TBTF - Too Big To Fork. A program can be "big" not only by having a large codebase but also through network effects, such as having vast amounts of client software tied to one of its interfaces. The big-boy Web browsers are TBTF in both these ways. So if, for example, you're insulted by Google's decision to knife MathML (as everyone should be), it's relatively easy to roll a Chromium with MathML inside, but you'd still effectively be just maintaining a branch, because you'd have no hope of maintaining "your" browser independently if Google took the whole Chromium codebase in a direction you didn't like - and more importantly, good luck getting users to use your browser or developers to create MathML webpages to support it. A second example of the phenomenon is the Gnome/KDE mess - part of the reason that the Linux desktop sucks is that, even if you have a clear idea of how it could be better, it's still a whole lot of man-hours to spin up an alternative implementation, get apps customised for it, and so on. In general, an area is the domain of TBTF to the extent that you have to win a political persuasion battle or spend a truckload of your own money before you can produce a viable implementation of your alternative idea. The solution, to the extent that there is a solution, to these problems is a technical one: find a way to shrink large programs and/or break them up into small, reasonably independent ones. (Of course all social/political problems are technical problems in disguise just as all technical problems are social/political problems in disguise. ;) ) In the case of the web, this is why the vertically-integrated Web browser must go away https://news.ycombinator.com/item?id=6720793 https://news.ycombinator.com/item?id=6720793 .

NinjaWarrior 13y ago

I think the above poster is talking about UX... > 3. It works on mobile devices, flash doesn't. False. Many (120000+) Flash apps are actively running with Adobe AIR on App Store and Google Play. AIR is a technology to package SWF as a native app. > 4. The tools are out there. Check out appcelerator or unity's tools. Unity can not export for HTML5 yet. Apparently they are working on it but I don't think it's that easy (As for the original article, I DO MIND the initial load time. That will be a big problem for Unity as well). > 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. False. plain (non asm.js) JavaScript is slow. Don't trust micro benchmarks. And at least ActionScript is faster than plain JavaScript (http://j15r.com/blog/2013/07/05/Box2d_Addendum http://j15r.com/blog/2013/07/05/Box2d_Addendum). And Flash Player 11+ has Stage3D which utilize GPU acceleration as well as WebGL. For instance, please watch this Facebook game (http://www.youtube.com/watch?v=vBIJVt05jwc http://www.youtube.com/watch?v=vBIJVt05jwc). Note that this is a commercial product. Not an experiment. Moreover, the same "Epic Citadel" demo was released for Flash on Mar 2012. One year earlier than HTML5 (http://epicgames.com/news/epic-games-releases-epic-citadel-in-flash/ http://epicgames.com/news/epic-games-releases-epic-citadel-i...). > Compiled other languages to ActionScript? Adobe Alchemy... Please don't denounce Flash without a knowledge of Flash. I'm already not a user of Flash and currently developing with Unity and Cocos2d-x instead, but I feel I need to advocate Adobe guys from unfair bashing.

ris 13y ago

> 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Right, (and I'm also in part replying to my sibling replies here) can we stop talking about "sandbox"ing as though it's something concrete and real? Something being "sandboxed" doesn't really mean anything - or rather it does, but only in an abstract way. Everyone who uses the word "sandboxed" means something slightly different, and every time in history someone has implemented a "sandbox"ing" system, their idea of "sandboxing" is slightly different. One person's "sandboxed" means "disables language access to the functions that could affect the system" where another person's "sandboxed" means "uses clever os features to isolate all execution into a separate container". This is why you can endlessly debate whether x or y is or isn't "sandboxed".

Recoil42 13y ago

1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Flash actually was sandboxed. Poorly, yes -- but so were JS VMs until very recently. It was only a matter of time. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. While the Flash IDE itself was closed-sourced, the format itself was almost entirely open-source -- and third-party tools have been available for a long time to compile SWFs on the level: http://en.wikipedia.org/wiki/Adobe_Flash#Open_Screen_Project http://en.wikipedia.org/wiki/Adobe_Flash#Open_Screen_Project 3. It works on mobile devices, flash doesn't. Entirely a political argument. 6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript With source maps to help? This is a tautological argument. "Javascript is better because Javascript is better"