The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.
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?
For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.
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.
Haxe compiles to the same thing ActionScript compiles to, which seems like the appropriate comparison.
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.)
> 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.
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 .
> 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). 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). 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-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.
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
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"
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".
Mobile markets have also demonstrated tightly controlled walled gardens, where fast iteration, platform independence and openness have been replaced with strict rules and controls by the market controlling entities. Is that really a direction you want to move in?
The web as a platform is still lacking in terms of User Experience, but id argue its catching up quickly and already far ahead in most other areas.
The web has had quite a long time to get there, yet it is still easier to write a decent application on NEXTSTEP that spawned the web then on the web. You would think we could at least make it as easy as HyperCard or Visual Basic 1.0, but we are still trying to push UI into a format that wasn't designed for it. I'm not sure the ultimate solution, but I get the feeling it will be what comes next and not more iterations of the same.
It may not be suited for app development, but people want to run applications in their browser. I'd rather use gmail than outlook, google docs than microsoft office. If I can have photoshop in the browser, I'd rather use it there than install it separately.
This is the new reality. Deal with it. HTML is no longer just a document markup language.