Having worked with both I would disagree with this statement. Image assets are the same size whether you're making a Flash site or a javascript site (both use z

Having worked with both I would disagree with this statement. Image assets are the same size whether you're making a Flash site or a javascript site (both use zip compression, both support JPG's, PNG's etc). What you're referring to is bloated microsites that went overboard on k-weight. If we're comparing apples to apples, there actually was a lot of things Flash did more efficiently. For instance, efficient storage of vector shapes, more complex masking which allowed the use of JPG images in place of PNG's (which resulted in a smaller file size), and a large API that reduced the need for external dependencies (and thus code size). Flash also had far more advanced animation capabilities that HTML5 is still struggling to reproduce. HTML5 still lacks decent tooling for producing such animations that work in an efficient, cross browser way. Think about why GIF's and autoplaying videos are so popular now. They provide the most reliable way to add motion and interest to a page and they those things are huge file size wise. One concrete example - we're making the move from Flash banners to HTML5 banners and finding that we'll need a much larger file size to even approach the same level of polish that we did before. Whereas before Flash banners were typically limited to 40-50k, the IAB is going to recommend 200kb banners as the standard for desktop HTML5 banners. Now I'm not saying the world should stick with Flash, but instead of just ripping on Flash, I think as web developers we need to be pushing for better tools and better capabilities that will allow for more creativity and expressiveness than we are typically able to produce now. And just as a disclaimer, I've tried Adobe Edge, Google Designer, and coded many things by hand using Canvas, SVG, CSS3, etc.