Just got back from a week in Florida; had the interwebs turned off for the week. Posting this to my blog next week, but it's more fun to talk about things here on G+, so.... posting here first.
. First, the positives.Speed & Hackability
I remember in the AS1 days 3 things that AS1 empowered:
- the prototype syntax allowed people to extend Flash's native features, everything from Object, String, to our basically building blocks (MovieClip, Flash's Div/DOM).
- people could fix bugs doing the above, or quickly provide utility classes with a simple # include; code sharing was UBER easy. No library configuration, no futzing with a compiler, no creating folders to get the package path right... just copy-pasta.
- you could hack and modify the language itself. This helped some SERIOUSLY screwed up projects get done on time. This helped some serious bugs in Flash be worked around. Most importantly; you could hack things at runtime. This really helped do some crazy stuff; sometimes you needed to do crazy stuff.
I remember using it via Rhino in Flash Media Server, and really liking certain aspects of it, like how simple the syntax was, and how easy it was to do a ton of cool stuff in only 100 lines of code.
Doing the same in SmartFox Server, same effect. You only needed to do a little, but sometimes the logic was extremely important, and having a light-weight syntax to do a lot of logic, and play with it to get it right was WAY more fun, and quick, to do it in JS. This is why I never got into doing Java on Red5 or PHP in general, and really liked Django/Python and Ruby on Rails for server work that required complex things that I wasn't really good at (ie server-side stuff), and needed to play around, quickly, to get results.
I can see if you're trying to hack around a challenging display issue, a complex browser incapability with XML parsing, or quickly iterate on a component to tweak to what a client wants... it's cool for that. You don't need public/private, nor strong-typing for those types of things. You need speed, and things to get out of your way.Scale
It's fascinating how differently things evolved; us Flash devs got better a language that continually evolved, better compilers, and better IDE's... as well as our runtime covering every other base.
...and now the bad parts.Operators, Parsing, and Prototype
I've worked with some who like cuddling of the brackets, and some who don't. Fine, both work, and I can read and work with both. However, this can break in some situations, so certain coding practices, such as cuddling and using brackets vs. omitting in 1 line if statements.
Fine, so I use === (or == if I and my team can remember the why's) and ensure my tooling can detect the bracket non-cuddled bugs.
But the Object.prototype is truly interesting. The same reason the JS crew is abandoning it (from Mr. Crockford's prototype abstractions or his closure suggestion to Sencha's as well) is the same reasons the purists in the ActionScript community (myself included.. very late in the game… ahem
- you can't prevent name collisions (classes or packages)
- you can't prevent, nor debug, if someone clobbers your class, function, or instance via modifying the prototype chain somewhere
- it's really hard to emulate privacy without the setup and syntax getting whack
It's neat they went the same way the Lua community went in creating classes by merely wrapping Object instances vs. messing around with the prototype via closures/anonymous functions.
It's also crazy how we AS1 dudes managed to hang on so much longer because a lot of the problems were mitigated. For example, we got a super keyword. We also had some inheritance bugs fixed in the language and our ECMAScript implementation. Just the super word alone prevented so much pain; even using the closure mechanism in Lua, I still hate inheritance. It just screams, "OMG I'M UNNATURAL, KILL ME!!!".
We also got around the initialization order of classes via a # initclip pragma before our compiler later solved it; you never had to worry about load order of class dependencies after that.
And scope. Holy. Effing. Cow. Remember this insanity? (<-- see what I did thar) http://www.actionscript.org/resources/articles/205/1/The-Delegate-Class/Page1.html
) will have to be formalized on because even in Lua, while they spell out how to get correct scope, people still don't use it for a variety of reasons.Conclusions
Fine. You use ===, cuddle or compensate w/tools, and use WebStorm if you use t3h Mac. If you're on a small project, you can use Object.prototype abstractions and jQuery. If you're on a larger project or a Flex developer, you can use Sencha and closure classes. You can use the kitchen sink of tools together like Google Closure, jshint, jslint, and SASS for both. While Flash just needed the Flash IDE, you now need an IDE + a local web server + a middle tier runtime like Ruby and/or Python and GUI's.. hah, screw GUI's, use the command line for a lot of this stuff.
What I'd really like is to talk to some Lua devs who used Squirrel ( http://www.squirrel-lang.org/
) and ask, "So… uh… how'd that work out?"
I'm struggling to keep an open mind. At least for 4 more years, I fail to see how the DOM and CSS help us create the same type of applications we were doing in Flex in HTML. Obviously the amount of text needed is inversely proportional to the value of the Flex SDK, hence why progressively enhanced sites have dropped Flash in favor of jQuery. Even Mr. Crockford laments about how horrible the API for CSS and HTML is for developers, hence leaving the DOM and CSS out of most of his book.
I'm convinced that a lot of these Enterprises moving to HTML from Flex will have buyers remorse in some aspects (obviously not the consulting and ability to hire parts, lulz). It makes zero sense to me. For the media and design agencies, I kind of get it. Still, I feel for some of those guys and gals because not only do they have to learn that myriad of tools and a "stack", but also have to keep fresh on their Flash/Flex and native stuff at the same time… and the while trying to hit insane deadlines. Man, sooo not for me. It still seems for them, plus what I'm seeing for my video clients, that hybrid solutions will exist for a long time. I find it odd, too, in those cases they keep hiring the "Flash and Flex" dudes for the "hard stuff" and farm out the jQuery stuff to cheaper resources. That says something, especially when it's consistent.
On the flip side, the Sencha gigs we've been exposed to, or even the Flex hybrid solutions, all expect enterprise developer/architect caliber. That also says something.
Maybe if I can make Ext JS/Touch easier to work with, my mind will change. While I love their syntax and components, I'm disappointed in how hard some simple things are whereas in Flex, they were easy (like... throw dynamic JSON into a List... 4 days later and I still am like wtf).
#mustKeepAnOpenMind #mustKeepAnOpenMind #mustKeepAnOpenMind