The Pew Pew Manifesto

This is the last post of the Pew Pew Chronicles – a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store.

I would like to end this series with summarizing the underlying ideas of my work on Pew Pew.


Please wake up now

Last month I gave a talk about creating Metro applications using ActionScript. In order to spice up the Q&A segment at the end of my talk I thought it would be fun to add a final slide with some provocative statements. I called that slide The Pew Pew Manifesto, which I am going to share with you in a minute.

I suspect that not everybody will agree with what I put into the Pew Pew Manifesto. But before we enter a religious war about dynamically versus statically typed languages, or whether JavaScript can be used for large projects, let me stress that I didn’t write the Pew Pew Manifesto in order to pick up a bar fight. I wrote it in order to wake up my colleagues that fell asleep during my talk! (Just kidding, nobody fell asleep.)

That said, let me present the Pew Pew Manifest:

  1. JavaScript is not suitable for large web apps.
  2. JavaScript is the browser’s assembly language.
  3. Choose a high-level language for developing web apps.
  4. Cross-compile from a high-level language to JavaScript.
  5. Use Google’s Closure Compiler for optimizing JavaScript.
  6. Optimized JavaScript is obfuscated and protects your intellectual property.
  7. Let your app degrade gracefully when OS features are missing.
  8. Invade every Web Platform!

I’ll walk you through the list…


JavaScript is not suitable for large web apps.

I am serious: Don’t write large web apps in JavaScript. As mentioned in Planning A Death March I don’t think JavaScript is suitable for implementing large projects. Last year I was asked to help out with an internal project that used JavaScript. Over time the code had grown out of control and there was only one person left, who really understood how it worked. The project had also become unscalable, because adding more developers would not have increased the overall productivity. It would have taken those developers too much time to come up to speed and work on this particular code base written in JavaScript. I looked at the code and suggested this crazy idea: Why not porting the existing JavaScript code to ActionScript and then continuing development in ActionScript while cross-compiling to JavaScript?

Porting JavaScript to ActionScript in order to cross-compile back to JavaScript? Was that crazy-talk? Perhaps, but it surprisingly worked and probably saved that project. Here is what happened when I ported the JavaScript code to ActionScript:

  • The code naturally distributed itself from about 10 files to over 100 files when creating ActionScript classes.
  • Porting JavaScript to ActionScript revealed inconsistencies and at times incoherent uses of types.
  • My cross-compiler automatically added type annotations necessary for compiling with Closure’s Advanced Mode.

I don’t know why but JavaScript programmers tend to put all of their code into few files. That’s not so useful, though, if you want to have multiple developers work on the same project. Splitting up the code into multiple files enabled us to scale the project.

You wouldn’t believe how many inconsistencies I found when porting JavaScript to ActionScript. Often JavaScript code, which looked perfectly fine at the first glance, revealed itself as incoherent the moment I tried to compile it with an ActionScript compiler. Sloppy usage of types were to blame for most of the inconsistencies. A very popular anti-pattern seemed to emerge: functions, which return incompatible types:

// (bad) JavaScript
function createBunnyOrToaster(createBunny)
  if( createBunny )
    return new Bunny();
  return new Toaster();


Of course if you start writing this kind of code your receiving end gets quickly contaminated with inconsistencies:

// (bad) JavaScript
function feedBunnyOrToaster(bunnyOrToaster)
  if( bunnyOrToaster instanceof Toaster )
    bunnyOrToaster.insert(new Toast());
    bunnyOrToaster.feed(new Carrot());


Nobody in his right mind would write this kind of code. But I have seen it more than once. In fact I have written that kind of code myself. My point is that it’s not necessarily the developer’s fault that we end up with bad code like the examples above. I would argue that dynamically typed languages like JavaScript are too tolerant and don’t slap developers on the fingers when they start mixing up bunnies with toasters. It might cramp your artistic programming style if you cannot mix up bunnies with toasters but where I come from doing so results in bad projects.

Just to be clear: You can write bunny-and-toaster code in ActionScript, too. But I would argue that you get immediate feedback of something being fundamentally wrong as you are typing that code, just by being confronted with questions like “what should be the return type?”. Of course you can choose to use “*” or “Object”. But most people pause and rethink their design at that point.

Not everybody is as smart as Gilad Bracha or John Resig and those that aren’t – like this author – are probably better off with writing their code in a statically typed language. Many will probably disagree with this statement. It might make more sense after reading the next Manifesto statement.


JavaScript is the browser’s assembly language.

In the following week after I gave my talk about creating Metro apps using ActionScript I ran into a few colleagues and I was surprised that it was this statement that they found most intriguing.  One colleague argued that the definition of assembly language implies a one to one correspondence with the underlying machine code. Another characteristic element of assembly languages are that they are also generally understood to be non-portable. Since JavaScript is neither, where does this idea of JavaScript being an assembly language come from and what is this about?

The first time I heard about JavaScript described as an assembly language was through Gilad Bracha’s blog. In 2008 he wrote in java’scrypt:

I’m not advocating writing clients in Javascript directly. Javascript is the assembly language of the internet platform (and the browser is the OS). It’s flexible enough to support almost anything on top of it, and poorly structured enough that humans shouldn’t be writing sizable applications in it.

To illustrate his point let me show you my cross-compiled and optimized JavaScript code of SpriteExample, which is included in Adobe’s online documentation about the Sprite class. As you can see the JavaScript code is extremely dense and no longer readable. In that sense the code looks more like binary code to me. It turns out that this kind of “binary looking” JavaScript is the most efficient version in terms of size and performance.

If you are interested in the discussion about JavaScript as an assembly language I recommend listening to JavaScript is Assembly Language for the Web: Semantic Markup is Dead!


Choose a high-level language for developing web apps.

Implementing your project in JavaScript  leaves you with some tough choices: If you ship the development version of your JavaScript code with your product, it is not obfuscated, and also bigger, and slower. If you want a faster, smaller app that also protects your intellectual property you have to optimize your JavaScript. But then you also have to annotate your code with type hints. If you don’t annotate your code with type hints the Closure compiler won’t be able to optimize as much and your code is less obfuscated, bigger, and slower. If you do find yourself writing JavaScript with type type annotations then why not using a high-level language instead and use a cross-compiler that automatically generates the type hints for you?

That’s really the point of this Manifesto statement.


Cross-compile from a high-level language to JavaScript.

You have several choices:

Some folks are even experimenting with cross-compiling Scala to JavaScript.

In the case of Pew Pew I used my own ActionScript to JavaScript cross-compiler. In Planning A Death March I made the argument that if you had to implement Photoshop in six weeks you wouldn’t pick an assembly language. Being able to cross-compile from a high-level language to JavaScript was a crucial element of my plan.


Use Google’s Closure Compiler for optimizing JavaScript.

In Optimizing cross-compiled JavaScript I wrote a whole article about the importance of optimizing your JavaScript code. As far as I know Google’s Closure Compiler is still the best JavaScript optimizer out there.


Optimized JavaScript is obfuscated and protects your intellectual property.

A nice side effect of optimizing your JavaScript is that it becomes unreadable as I illustrated with my SpriteExample snippet. You would never write “binary JavaScript” code like that manually. But for professional software production it is important to be able to write code in a maintainable high-level language while deploying a product that does not reveal the ideas of your source code.

In my opinion the current version of Visual Studio 11 for Metro is missing this important point. There is no built-in JavaScript optimizer and no support to hook one in. Microsoft seems to assume that nobody wants to optimize JavaScript code. Their current IDE only outputs Debug JavaScript code. There is in my opinion essentially no Release option for JavaScript apps in Visual Studio 11 for Metro. I really hope Microsoft will change that.


Let your app degrade gracefully when OS features are missing.

This might be an obvious statement. But what I am saying is, if you write a Metro app in a high-level language like ActionScript make sure that your code “degrades gracefully” so your app would also run in most modern browsers on other platforms.

I’ll give you an example from my Pew Pew code:

const domWindow : DOMWindow = adobe.globals;
if( domWindow.hasOwnProperty("Windows") )
  var appLayout : ApplicationView = Windows.UI.ViewManagement.ApplicationView;
  appLayout = appLayout.getForCurrentView();
  appLayout.addEventListener("viewstatechanged", onViewStateChanged, false);


The code above only registers onViewStateChanged if the environment is known to support the Windows namespace. In other words, if this code runs in a browser without Metro support, it won’t register for view state changes.

Why going through the trouble? The last statement of the Pew Pew Manifesto will answer that question.


Invade every Web Platform!

I think, being able to write code once and reuse the same code on different platforms without  compromising neither functionality nor aesthetics of your app’s user interface is a very desirable goal.

This might sound like science fiction, but what if all of your apps in the near future were just custom browsers? Like Flash Player playing SWFs your custom browser would run your JavaScript, that is, code written in a high-level language and then cross-compiled to JavaScript. There are many cases where your JavaScript code could run in the browser as is. But how would you get your app into the Apple App Store, or the Android Marketplace? How would you make money?

This is why I find PhoneGap (now an Apache incubator project called Apache Cordova) very intriguing. In many ways PhoneGap’s architecture might lead to a new type of apps that you could call “custom web browser apps”. You can look at the PhoneGap architecture as a framework that provides custom browsers for multiple platforms (iOS, OSX, Android, Blackberry, Windows Phone). All you have to care about are the HTML, CSS and JavaScript parts you have to provide. PhoneGap even supports special JavaScript APIs for features like Camera, Location, or Accelerator, that are not accessible via standard DOM APIs.

For example, if I wanted to get Pew Pew into the Apple AppStore and Android Marketplace I would simply cross-compile my ActionScript project to JavaScript and plug it into the PhoneGap architecture. As far as I know I can even write my own native plug-ins for PhoneGap. If that’s really the case I can pretty much invade every web platform that PhoneGap supports.

Maybe that’s what I should be working on next…

86 Responses to The Pew Pew Manifesto

  1. It’s nice to see some adobe employee finely writing some statements that every Flex developer can feel since years, instead of some irealistic assumption about HTML5/JS becoming the way to develop large scale enterprise application in the future.
    However it would be even greater if we finely could try the cross compiler ourself.
    The work seems quite in a good state (at least for the as->js part) and we can’t even try to make some prototype using it.
    I can’t really understand the Adobe strategy here, why waiting the end of 2012 to give it to apache, or at least to publish a beta on the lab ?
    During that time more and more customer ask us to create HTML5/JS application, and we have to use javascript directly …
    If we could at least try the compiler we would able to decide wich direction we take from now …

  2. oups sorry i end up putting this comment in the wrong place

  3. Bernd, your page is an example of what I have called a “Propositional Manifesto”, (see ) – where the headings are the basic content (as opposed to just describing the content), and what comes after the headings explains or expands that content.

    (Note: in the page you mis-spelled “Manifesto” as “Manifest”.)

  4. Hunter Blanks says:

    I’m not sure I can agree. Plenty of in-browser apps go awry, but that’s most often because the tools people start using (notably jQuery) just don’t work well once you have a large collection of UI components on the page.

    That said, the bulk of Google’s web applications, for instance, are not written in GWT, but rather in JavaScript using Closure Library, and compiled using the Closure compiler. I don’t think the answer here is to not use JavaScript (although I can understand why people at Adobe would argue for that), but rather to use tools like Closure or Angular that make the process more straightforward.

  5. Joshontheweb says:

    Theres a conversation happening about this post on Hacker News

  6. Hi,
    First, congrats on these articles, i just found them and there are some really good ideas in there.

    I am also a Flex developper and started developping js apps at work (using google closure library and compiler) and recently started diving into Metro style apps for Windows 8. So far, i’m not using the closure compiler for Win8 dev because i’m just doing simple stuff and tutorials i write.
    Do you also use CC for Win8 dev? Can you even do it? i didn’t even try but i believe the WinJS dependency wouldn’t play nice with that kind of merging (+ you can’t have any goog.provide / goog.require instruction in those file so i can’t see how it would work). CC is nice until you have to make it work with third-party libraries, then it becomes really tough in my experience.

    From what i saw it looks like you like the google compiler as well so i was wondering if you used it as well for Windows dev and how you manage these provide / require issues.

    Thanks !
    PS: Were you the one who presented the work on the Falcon Compiler at the Flex Dev Summit in December in SF when they explained how it would get to Apache? I was in the audience 🙂

    • Bernd Paradies says:

      Hello Fablen,

      unfortunately I couldn’t make it to the Flex Dev Summit in December in SF.
      I do use the Closure Closure compiler with ADVANCED_MODE. But I can only do that because my ActionScript to JavaScript cross-compiler generates the type annotations that CC relies on.

      Best wishes,

      – Bernd

  7. Tim says:

    “I don’t know why but JavaScript programmers tend to put all of their code into few files.”

    I don’t know, either, which you’re seeing this (as I’ve not seen it myself), but you don’t have to abandon the entire programming language to solve this problem. Baby, bathwater.

    “My point is that it’s not necessarily the developer’s fault that we end up with bad code like the examples above.”

    At this point I was well and truly puzzled. Who else’s fault could it possibly be for a bad program, other than the programmer’s? These aren’t places where someone was caught by a subtle corner of the language, or where a much-needed language feature is missing so they had to implement it themselves: there are places where programmers walked straight into a rookie mistake.

    “I would argue that dynamically typed languages like JavaScript are too tolerant and don’t slap developers on the fingers when they start mixing up bunnies with toasters.”

    Does Actionscript have a concept of “units” attached to all numeric values? In my experience, that’s a much, much bigger problem, because getting “3” (assumed feet) when you expect “3” (implied meters) is very hard to detect at runtime. If Javascript is too tolerant because it allows blatant type errors, then I would say virtually every programming language (notable exception: Frink!) is far, far too tolerant because it allows subtle unit errors.

    You’re complaining that a meat cleaver is not suitable for amateur cooks because they might close the drawer too quickly and bruise their fingers when putting it away, like this guy you used to know.

  8. Theo says:

    Poorly written Javascript is not suitable for large web applications. This goes for any language. Competent Javascript developers will have many files that are concatenated into just one or two files as part of their build environment. Competent Javascript developers will use code quality tools such as jslint or jshint to find potential problems.

    It’s too bad that you inherited a poorly written Javascript project, but that doesn’t mean the language you’re most familiar with was the best language for the job. This is a common response. “I know X, let’s use X!!!”

    Also, Javascript is a high level language.

  9. Scott says:

    I started reading this and quickly noticed that you are the problem. Don’t start off mentioning how poorly your JavaScript application is written and then blame it on the language.

  10. Jean-François says:

    Next time, think about googling your game’s name before choosing it!

  11. Dawesi says:

    I was about to write I can’t believe someone published this…

    Then I realised it was on an Adobe blog… and removed palm from forehead and just laughed… again!

  12. The problem with JavaScript is you don’t know how to use it, which I find surprising in an ActionScript developer. Don’t blame your inability to use a language on the language. That one’s on you.

    Quit being a bad JavaScript developer.

  13. Tell that to LucidChart ( Their full-fledged diagramming web app is built using Javascript. Easily one of the most powerful apps on the web today.

  14. If you wanted to cross compile ecmascript (actionscript-like) to js, you should’ve just used Haxe. The syntax is nearly identical, and the compiler is very advanced. It’s at least as big of an improvement from haxe to coffeescript as it is from coffeescript to js.

    • Bernd Paradies says:

      Hello Justin,

      I like Haxe, but last time I checked Haxe does not emit type annotations that allow using Closure Compiler with ADVANCED_MODE.
      That would be a nice feature. Or am I mistaken?

      Best wishes,

      – Bernd

    • Zach says:

      ecmascript = js, there is no cross-compiling there. Haxe or coffeescript are different languages that do cross-compile to js

  15. TJ Holowaychuk says:

    or you know.. just don’t write retarded javascript. stupid people write stupid code, so just dont write stupid code, language forcing structure on you has pretty much nothing to do with it

  16. wut says:

    You sir are a moron, there’s absolutely nothing wrong with building large scale applications in JavaScript and for you to even suggest JS is a low level language is absurd. How ever did you get a job at Adobe? No wonder their stock is in the shitter.

  17. Rick Viscomi says:

    Code minification does nothing to protect intellectual property. Sure, you can never go backwards and get comments or the original naming convention, but it’s entirely possible to infer the underlying algorithm or technique solely from the production code. Don’t let the lack of whitespace fool you.

    • Bernd Paradies says:

      Hi Rick,

      I agree with you: You can reverse-engineer minified JS. But is there any better method out there to protect IP of your JavaScript code?
      The main reason why I use the Closure Compiler is because I want to optimize my JavaScript.
      But I also like that by doing so I am also obfuscating my JavaScript.

      Best wishes,

      – Bernd

      • Anentropic says:

        Yeah I bet you like marking methods as ‘private’ too… it feels good even though it doesn’t achieve anything useful. I know, I used to be an actionscript developer…

  18. I think there are two sides here, side one “javascript is fine once you know it, just learn it”, and side two “javascript is expensive to learn, there may be other options”. Which are perfectly fine and compatible arguments.

    The problem is that in this post, they encountered a situation where a project was developed by people who didn’t know javascript as well as they thought they did, and the project got out of hand. Which happens all the time!

    Now side one would argue, okay just properly train everyone in javascript or bring in some javascript experts to take over. However that isn’t always the best solution, which the author goes on to explain. For them It was much more feasible to rewrite the javascript in a language they already new, or rather a language that is easier to master (and get up to speed on) than javascript.

    Both sides are valid. Just accepting that one side is not always best is essential. This is where I feel all the uproar has happened, as the author perhaps went a bit too sensationalist with their message, giving off the vibe that side two is the only good way.

    I feel there was good meaning behind this post, but was indeed lost. Both sides hold weight, and it is essential that everyone picks the side that works for them.

  19. Is this…. real life?


    Sound ridiculous? Yeah. It does.

  20. Anon says:

    Haha. Amused at your massive fail. You’re awesome. Please don’t stop. This is fun.

  21. I’m annoyed, but not surprised, at this being posted on Adobe’s blog. Of course people are going to be eating their own dog food, but this is ridiculous (Adobe blog or not).

    You say, right in the examples of JS code, that it is poor Javascript. Poorly written actionscript is terrible for a large enterprise application (and small ones to boot). Javascript is a pretty damn good language, even though it surely has some surface warts (see: Javascript – The bad parts).

    Serious Javascript developers (the ones really writing large enterprise applications) don’t throw some js in a couple of files like you say. They abstract out there code in organized and maintainable classes/objects just like any good developer would do.

    Javascript is proving to be a powerhouse (people are just realizing it lately) in the future of the web. There is a reason Basecamp is written with Flex. There’s a reason Soundcloud didn’t decide to use Flex for their latest feature (or is it a new version of the whole site?).

    I’m working on an enterprise government level application, mainly written in Javascript. It’s working fantastically and our clients agree. I wouldn’t dream of writing it in Flex (to be honest, I wouldn’t dream of writing Flex any day of the week… or I guess that would be a nightmare).

    With javascript coming to the server side and getting some serious results, you’re insulting an entire industry of people, just so you can peddle your close sourced, dying technology.

    Pretty ridiculous in my opinion. My opinion of Adobe has already been waning recently over some poor decision that you’ve made and then reversed (we won’t go into that here). Let’s just say this is another notch in the “don’t need Adobe” belt for me.

  22. Robert says: cross compiles to JavaScript and Flash

  23. Jason says:

    How.. the… fudge.

    “JavaScript is not suitable for large web apps.”
    Everything you mentioned in all parts of the paragraph are the DEVELOPERS’ FAULT

    “JavaScript is the browser’s assembly language.”

    Seriously? You use an optimized bit of code to show an example of how it’s “low level”? Are you joking?

    “Choose a high-level language for developing web apps.”
    JS is a high level language.

    “Cross-compile from a high-level language to JavaScript.”
    JS is a high level language.

    “Use Google’s Closure Compiler for optimizing JavaScript.”
    AKA: learn best practices

    “Optimized JavaScript is obfuscated and protects your intellectual property.”
    *copy, paste into an editor, format as JS* And now I see all the logic that was implemented.

    “Let your app degrade gracefully when OS features are missing.”
    Wait… I thought we were talking about web apps here. You basically can’t access ANY OS features in a web browser that aren’t explicitly allowed in the sandbox.
    So…. wtf is this entire paragraph about?

    “I think, being able to write code once and reuse the same code on different platforms without compromising neither functionality nor aesthetics of your app’s user interface is a very desirable goal.”
    No it’s not. Making an app that looks the same on OS X and on windows using the same visual and interaction paradigms on both is stupid. Why? Because the OS paradigms are different and WARRANT building your app differently to work fluidly with the environment they’re in.
    Using phone gap for anything other than getting a product into a market as quickly as possible while you’re building the native apps is asking for a lifetime of crappy software.

    You haven’t built a large JS app.
    You ported one from crappy code.

  24. Chris says:

    Your examples indicate a lack of knowledge on how to use JavaScript effectively, not that JavaScript sucks for large applications. To be fair, it’s not very restrictive so if you just start banging code out of course the code base will be terrible. On our team we’re moving away from flex slowly by making several small prototypes and figuring out what patterns work and which should be avoided (like returning different object types). We haven’t been able to justify rewrites, but for new applications especially targeting mobile devices, it’s a great option.

    Also I think part of the problem is not treating JavaScript code with the same standards — that is keeping files small and developing a modular object hierarchy, writing unit tests, etc. for the record, we have some awful awful actionscript code that has the same problems you mentioned. Think ‘classes’ thousands of lines long. It’s the developers, not the language.

    We’ve avoided GWT, I don’t think adding another abstraction is the answer. But we have explored js frameworks like sencha’s extjs for a more defined architecture.

  25. droope says:

    Flash is dead, face it.

  26. roberto rodriguez says:

    We’ll if you are going to create an Large App the Jquery Way; It is crazy;

    There are profesional ways to build JS Apps; Just like there are profesional ways of creating Actionscript Apps and crazy ways of creating Flex Apps….

    I believe you can compile in AS3, but is easier and closer to code in Coffeescript; use CommonJS Modules and problem solved.

  27. Andrew Trice says:

    We understand your frustration and understand that JavaScript can be difficult to manage on large scale projects. However, there are ways to manage these complexities and deliver sophisticated applications using open web technologies.

    Our own Brackets modern code editor ( project is an application built entirely using HTML, JS, & CSS, and we actively sponsor, or are involved with strategies for building complex and interactive JS applications. For example:!/CreateJS, or
    We are also actively involved in helping other developers understand the complexities and MVC/templating paradigms necessary for large scale and distributed web applications, for example:

    Adobe Evangelist Christophe Coenraets’ tutorials on Backbone.js

    Aaron Hardy’s tutorials on requireJS

    My (Andrew Trice’s) open source UI framework for HTML/JS apps:

    The web platform team is actively considering ways that we can contribute to make JavaScript applications easier and more manageable. You can read more about the activities of the web platform team at:

    Also, let’s not forget the examples on the Adobe Developer Center:

    Clearly, there are areas where JavaScript frameworks and tooling can be improved, and we would love to hear from you on ways we can help make it better.

    Andrew Trice, Adobe

  28. Josh says:

    Your Bunnies or Toasters examples have another smell, anytime you are creating a different type of object depending on the parameter, you have a problem. Why wasn’t that two functions. Kind of a beginner mistake IMHO.

    Your point about statically typed languages is somewhat valid, but if you like the goose, you have to like the gander. Then you start liking ducks…

  29. Jlb says:

    Let’s fet real for a second. Plain old JavaScript is missing compelling language features present in most other widely used programming languages today including: java,c++,python, Ruby, Scala, Objective-c…etc. Some of the most crucial : 1) classes and methods, 2) modularity. Note that I said ‘language features’ not third party libraries. I’ll opine that these features are what JS is most sorely missing. The amount of focus it takes to discern a ‘class’ equivalent or a private variable or included module (on the browser side) far exceeds that necessary in these other languages. Similarly, the amount of focus it takes to discern a for loop in assembly far exceeds that which it takes in C. Tortured, less readable coding patterns (or various 3rd party implementations/various cross-compiling languages) are the result. Hence I agree that large applications written in JavaScript are il-advised despite whatever sophistry you may have with these techniques.

    • Josh says:

      You don’t know prototypical inheritance? There isn’t only one true OOP. Also, how do you do mixins with class based inheritance? If it wasn’t for templates and generics, OOP in C++ and Java wouldn’t be near as much fun. There are design pattern for JS (like for Ruby), however, it is somewhat like C where you have to learn to read between the lines.

      • Josh says:

        “In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.” — Bjarne Stroustrup.

        In JavaScript, you blow up the world…

  30. Joe says:

    I agree for the most part, but I think we should embrace, rather than replace, many of Javascript’s features which are nicely suited for the browser (objects are key/value stores, events, anonymous functions, etc). Coffeescript is a great example of this: nice syntactical changes, classes, but also 1:1 with the output javascript. The problem with javascript is its lack of structure, not the underlying language

  31. Yaron Ben David says:

    What is the tool used to obfuscate the code at ?

  32. Disclaimer: I am also an Adobe Employee.

    I have struggled with a lot of the same issues as Bernd coming back to JavaScript. It’s always felt clunky and hard to manage medium to large projects and even more so since learning and adapting to Flex, and coming back.

    I have been tempted to write shell script or ANT tasks that allow me to write the way I used to, but work the way I do now. But ultimately these efforts are me trying to turn a car into a boat.

    Seeing the success that others have had in making large scale JavaScript applications, and making them work, I’ve come to the conclusion that I need to learn more about doing JavaScript the right way.

    Some of the efforts that Andrew highlighted in his comment show a lot of promise. I think our job as a tooling company is to make it easier for developer to achieve their vision in the medium they need to work in. For some, that’s going to mean making it easier for them to work with their experience. However, for some that’s going to mean helping them make the leap to JavaScript as it is, not as they are.

    But in the end, large scale applications are being built in JavaScript, they will continue to be. If your path has made this easier for you to accomplish, more power to you. But I think their are multiple paths here, and using plain old JavaScript is also accomplishable.

  33. Michael says:

    I think every big app should work correctly without javascript

  34. Bernhard says:

    It looks like you have pissed of a lot of JavaScript developers 🙂 Well, everybody should use the tool he likes most. And of course there are huge web applications written in JavaScript, but nevertheless it’s a pain to write big projects in JavaScript (imho). The even bigger problem is maintaining those projects and scale them to many developers.

    So i agree with you and i am very happy about projects like GWT, Dart or your AS-to-JS compiler. Thumbs up!

  35. Nils says:

    I’m not much into web dev these days, but one thing about the compile to js languages that I wonder is how to debug it. So you compile your coffee script or whatever (I also never used action script before) to js (and eventually optimize it) and then you need to debug the code created by the coffee script compiler? So you write in coffee script but still need to debug javascript or is there a way you can see the coffee script code in the debugger?

  36. Emre Toprak says:

    i just look to url i see hmmm. yes yes javascript is bad adobe.

  37. Tom Maslen says:

    Large web apps can be made in JS if you use AMD and pubsub and don’t base the architecture around a DOM manipulation library.

  38. Frank says:

    judging from the comments here and on Hackernews, it seems your article overstepped the mark a bit. As you know, we at Jangaroo do something very similar to your approach, and also claim that for Enterprise JavaScript, a statically typed language is superior.
    However, what we do not claim is that JavaScript is not a high level language / an assembly language, or that it is impossible to use a modular approach with “native” JavaScript, or that JavaScript is to blame for bad code per se. We opt for a peaceful coexistence of JavaScript and ActionScript!
    Not surprisingly, insulting JavaScript rather seems to discourage JavaScript developers from being eager to use your tool (whenever that will be possible) or reading your blog, which would be a pity, since there are interesting insights to be found here also for them!
    Greetings, -Frank-

  39. says:

    Point 6: is your friend

  40. Brian Clark says:

    I had many of these thoughts about a year or two ago in regards to GWT, which I’m a proponent of, specifically the notions that Javascript is the assembler of the browser and that Javascript should never be used to develop large applications. Glad to see someone has take then time to write this down.

    At a previous job, we inherited a large Javascript application that had gotten to the point where simple modifications often required a whole day to determine what the existing code was doing and what unexpected side effects might occur if we made a change. We ended up redoing the application in GWT. GWT made sense since we had a staff of Java developers. Actionscript or another technology might make sense if this is not the case.

  41. Ahmed Nuaman says:

    Yes, JS is a bit of a lame language for large applications and AS3 would be much better suited, but let’s face it: Flash Player is an absolute ball ache and that’s the killer here; the VM rules, not the language.

  42. Nathan says:

    lol @ internet hate.

    I think you make a lot of good points. However, some newer libraries such as RequireJS make writing modular Javascript much easier. So, since it’s possible to write in a more modular style (and with a static analysis tool such as JSLint), it really boils down to working with the language you’re most productive in. For myself, I’ve started using James Burke’s “require-cs” plugin with RequireJS, and haven’t looked back (

  43. Steve Fenton says:

    “My point is that it’s not necessarily the developer’s fault that we end up with bad code”

    It almost certainly is!

    In the case of ActionScript vs JavaScript it sounds like you have an IDE that type-checks and pre-compiles your ActionScript in the background in order to point out things such as different return types in a method. I have an IDE that does this for JavaScript – so is there any other compelling reason to move to ActionScript if I am getting all of the IDE safety directly in JavaScript?

  44. Joe says:

    There’s also ClojureScript, a (large) subset of Clojure that compiles to Javascript. It also uses Google’s Closure in the compilation.

  45. bob says:

    It seems to me like this has more to do with the importance of teaching JS devs how to properly code than it has to do with javascript being bad. For example, I don’t know any (good) js developer who would combine classes for bunny and toaster. And just because you *could* run into problems with typing, doesn’t mean you *would* — and that’s where good devs versus bad devs comes in, and the importance of teaching younger devs proper chops.

    As someone who writes javascript apps for a living, I can say if the app is well written and truly OO, then a newcomer won’t have any more getting up to speed time than a new java developer would with a java app.

    I think the JS community has suffered in the past from bad code and bad coding practices being spread across blogs, and most JS devs (myself included) not having come from a CS background. But that seems to have been changing in recent years.

    Though I do agree that it’s faster to write in coffeescript than it is to write in js. I prefer writing in coffeescript. But it doesn’t mean i can’t write an app properly in JS.

    And you shouldn’t be writing a JS app at all, even a compiled one, if you can’t properly write the JS to begin with. It’s bad practices.

  46. dgdfg says:

    You are working too hard for Adobe.
    Get a hold of yourself.

  47. Paul Grenier says:

    This “manifesto” should be read as a satire of application building to encourage good coding practices, somewhat like how Machiavelli’s The Prince is read as a satire of government to encourage democracy.

    Proper app organization and structure does not come easy–in JS or any language. And a failure to properly grasp the language will only highlight that. I work on a large JS project by every definition of the term and the business loves the result. The app is fast, fluid, and easy to configure. That was not an accident. It took 2 years of planning, several iterations of refactoring, and a couple dozen trained engineers.

    Like anything, just do it right or you’re gonna have a bad time.

  48. Jay says:

    if( bunnyOrToaster instanceof Toaster )
    bunnyOrToaster.insert(new Toast());

    That’s just silly. You don’t insert toast into a toaster…

  49. Barry says:

    I’ve been a part of some fairly large JS projects. I think you can develop solid software in either case. It boils down to the developer in most cases. Having said that, there’s no doubt you’re given the ability to do a lot more around enforcing structure with constructs such as abstract classes or interfaces. the timing of this post is interesting as I recently put a project up on github ( for essentially coding JavaScript in a .NET-ish environment. I think maybe even as valuable as some of the thing strong typing brings is the ability to make use of the IDE (you get Visual Studio, assembly referencing etc). For building reusable components I feel like it’s definitely the way to go. For annotating a page to add UI features, I’d push for JS. Then there’s a lot of area between that where it could vary depending on other factors. Overall I can agree on some levels with the post. But I think, as in most things, it’s important to understand the underlying technologies. Abstracting away JavaScript and the browser related APIs will inevitably lead to bad results.

    • Bernd Paradies says:

      Hello Barry,

      Blade looks interesting. It reminds me on Script#:

      Or is your project aiming at something completely different?


      – Bernd

      • Barry says:

        Yes, it’s somewhat similar. I’ve used Script# in the best with good success. I built Blade for a couple of reasons. First being to get C#4 support (Script# is still on 2.0 for the most part) and second to try and stick more closely to the browser APIs so that it looks very close to what JavaScript would. Of course you can then build whatever sort of layers on top of that you’d like.

  50. Eric says:

    I would recommend you learn how to write JavaScript properly and then re-write this article. It’s painfully obvious that you learned the syntax and base rules of the language but have absolutely no idea how to design the architecture for a large-scale app.

    • Eric says:

      “I am serious: Don’t write large web apps in JavaScript. As mentioned in Planning A Death March I don’t think JavaScript is suitable for implementing large projects. Last year I was asked to help out with an internal project that used JavaScript. Over time the code had grown out of control and there was only one person left, who really understood how it worked. The project had also become unscalable, because adding more developers would not have increased the overall productivity. It would have taken those developers too much time to come up to speed and work on this particular code base written in JavaScript. I looked at the code and suggested this crazy idea: Why not porting the existing JavaScript code to ActionScript and then continuing development in ActionScript while cross-compiling to JavaScript?”

      I’d also suggest, based on the quoted paragraph, that you or someone in your group learn how to manage a team of developers properly. There are so many things wrong in this paragraph that it boggles my mind how anyone involved in this project even got through the interview process.

  51. Pingback: The Pew Pew Manifesto « All My Circuits

  52. phee says:

    I don’t think it would be smart to compile to javascript from a higher-level language… you wouldn’t be able to debug it in your browser at all…

    • Bernd Paradies says:

      Hello Phee,

      you can’t really debug cross-compiled JavaScript that is optimized (although I have done it). But you can debug unoptimized JavaScript. That works very well.


      – Bernd

  53. Jeff says:

    it really just sounds like you’re promoting an adobe language. there are a lot of large applications written in JavaScript. it seems to me like whoever wrote this example application didn’t know how to write JavaScript.

    and if you yourself don’t like JavaScript, that is really no way to say it can’t be used for large applications just because it’s not your preference and/or you may not know how to write a proper JS app yourself.

  54. Pingback: Room Full of Mirrors

  55. Seeing comments on this article i’m little worried of the sanity of a part web developer community.

    – The fact that most of the framework try to emulated features that javascript does not offer natively is a proof of the lack in the language itself. Even the ECMAScript harmony proposal goes this way …
    – Large scale application are made by team, in a team developers skill vary from “high” to “medium” in the best case, the fact than a language allow medium or bad developer to do everything they want, make that language not suited for large scale application development.
    – There is also a fact that can’t be denied : There is no tools that make javascript suited for enterprise class development, ide are poor, no maven plugin etc etc.
    – Finely when i see people arguing that Bernd is a bad developer when he did something as complex as a cross compiler, what should i conclude except that your point of view is bloated and that your obsession at defending your favorite language make you blind to any valid argument ?

  56. Pingback: Revision 76: Testen, Dokumentieren und Abhängigkeiten verwalten | Working Draft

  57. Pingback: State of Technology #64 « Dr Data's Blog

  58. Steve says:

    I also recommend looking at vaadin ( uses GWT but has a lot of improvements on top of it.

  59. anon says:

    Great ideas in this article. I hope the negative comments from the JS fanboys don’t deter you from actively pursuing the approach you have outlined in the manifesto. ( I love it when the typical response is..”its not the language..its your fault because you did’nt bother to get the PhD in JS, which would have enabled you to create these awesome JS apps ” 🙂 )

    There is a significant number of developers and companies invested in AS who would pay for a robust implementation of a toolset you have outlined.

  60. Alex says:

    Just because one project grew out of control does not mean the language cannot support large scale projects. It’s more likely a case of bad planning and insufficient knowledge of the language than an issue with the language itself. And let’s not forget, there are some really big javascript projects out there!

  61. Santanu says:

    The Pew Pew linke to Microsoft Apps site saying “Sorry, we can’t find this page. The address might have changed or been removed.” (?)

    • Bernd Paradies says:

      Hi Santanu, thanks for pointing out that the links are broken. I noticed that too. It looks like MS removed all apps that are not compiled for Windows 8 RTM (build #9200). Unfortunately getting the old app into the store is not just a matter of recompiling the code. Let me see what I can do…


      – Bernd

  62. Joshua Beall says:

    This post is spot on. Microsoft’s TypeScript is yet another validation that industry heavyweights recognize the fundamental problems with JavaScript and are working to provide solutions.

    You will always have the folks that refuse to improve because what they’ve got is “good enough”. And we’re seeing a lot of those folks complaining right now because “JavaScript is great, you just don’t know how to use it!”

    Um, right. You keep using a 90s era scripting language for your RIAs. Let me know how that works out for you. The rest of us are moving on.

  63. I feel so sorry for that programmers, that doesn’t like to learn diferent languages then they selfs born in.

    Now because javascript is not a language with lots and lots of chains to slow down and make you look again and again to your code to make you see that you misserable doing it wrong, that’s why is an assembly browser language. Please, go back to school.

    Can’t make real big prograns with Javascript? Hey Google and Facebook did you hear that?!?

    You can write in lot of files in javascript, you have many ways for that. You can even script for a nodejs or something like that, that will be very like you are doing for ActionScript.

    But I don’t want waste mutch my time here, lot of people read the article but not the comments. So, let’s talk about DEBUG.

    How you do that with your cross-compiled high awsome language? Oh you can’t?!? You need to cross-compile, to test, see where is the bug, then go back to your code, try again, go back to the cross-compiled, go back to your code, go back to me, I’m on a horse, you forgot to cross-compile this time.

    Man, you can lear AMD pattern, you will be able to do lots of file as you like, you will be able to debug, and when it’s done, you can uglify your code, but try uglify2, you will get results very like your very awsome Google Closure Compiler. But wait… You even can still debug your compiled code using with .src extension… Oh man!

    Serious, Gnome3 is doing it wrong, Microsoft too, Google, facebook, twitter, I can do this all day.

    Java, C#, ActionScript just make you slow down. Lern TDD, AMD and JS, you will code faster then ever, but make a good team, because poor programmers will slow down your development in any language you chose.

  64. Pingback: Which JavaScript Recipe Is Right For You? | ShadesColour & Associates

  65. Pingback: Which JavaScript Recipe Is Right For You? - Goodfav Howto