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.

I finished JavaScript: The Good Parts, and... well, I did like the book. It's clear the author has mad skillz, too, writing jslint.com. First, the positives.

Speed & Hackability

It's clear JavaScript, like Lua and Ruby (and some Python) lends itself well to speed and hackability. If you grew up in the ActionScript 1 days (ActionScript 1 was basically JavaScript), and then lived through the AS2 and AS3, you clearly saw how quick and simple AS1 was, and thus the same for JavaScript as a language to write quick programs in.

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 can see how JavaScript has helped the web projects in the exact same way.

Small & Agile

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.

The one thing that impressed me the most about Lua for Corona SDK is the how little Lua code does so much. Lua is almost exactly like JavaScript (excluding lack of Object.prototype, inclusion of block syntax to make the C guys happy, and configurable global namespaces vs. being confined to 1).

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

What is also interesting is the ways in which people have wrapped the language in a variety of ways to scale. I don't mean the .NET or GWT techs, I mean those writing frameworks on top of JavaScript to provide classes and packages and access modifiers (public/private). They've also included unit testing suites, online tools like jslint and jshint for code coverage, and other libraries and techs for helping continuous integration.

Instead of waiting for the browser vendors to agree on a baseline, they've just forged ahead. What is also impressive is the lack of tooling has forced them to get lower level. They use a variety of middle tier technologies to compensate. Using Ruby to create Object Oriented CSS via SASS/LESS, minifying tools used to reduce JavaScript to as small as possible and into a single file for optimal browser delivery, and even compilers like Google's Closure to help mitigate common issues.

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.

JavaScript devs, on the other hand still have pathetic IDE's (well... Visual Studio is pretty epic and WebStorm is getting there) for a long time, their language is SOOOO slow to improve based on the needs of application developers, their compilers a mish mash of tooling both client side and server-side that have to be tweaked to work together. And their runtimes... all act different and improve in spurts, only recently gaining momentum and a nice iOS HTML5 bastion. It really shows how talented and determined some of these devs are in accomplishing so much with so many challenges.

...and now the bad parts.

Operators, Parsing, and Prototype

I never realized how much AS1 improved on JavaScript. While both were based on ECMA Script 1, 2, and some 3. The low level differences are AMAZING and horrifying at the same time. The simple fact that people use === vs. == everywhere is... alone just insanity. I get, and agree with the reasoning, but you never do that unless you're doing really weird or edge cases in ActionScript... even with 1. With ActionScript, 1, 2, and 3, == just works.

Some of the parsing bugs that JavaScript has in some browsers/runtimes causes coding styles to compensate. For example, I've worked with an AS2 guy who NEVER used semi-colons. That would only break in 1 place; if you didn't include one at the end of an # include file; it was a challenging bug to track down if you didn't know what you were looking for. Cool, no problem.

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). Mainly:

- 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 Even in ActionScript 2, a "classes in JavaScript", we still had mad scope issues as the whole language wasn't really based on classes, so Delegate became a main stay in the language. The paranoid still littered their classes with "this" everywhere.

That still exists in JavaScript. Now, in my dabbling with Sencha's Ext JS and Touch, that problem seems to go away (at least in their classes). And in my own classes, now that I know what to look for, it's fine… but just like Lua, every library seems to use it's own coding style, and each handles scope differently. For small projects, whatever, no big deal at all, but in larger ones with larger teams… it seems some sort of conventions ( like idiomatic https://github.com/rwldrn/idiomatic.js ) 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.

Interestingly, while I've gained a new appreciation for CoffeeScript, I still don't know enough to really dive head first in because it seems most of the JavaScript problems it's attempting to solve aren't what I need solving. That's where Google's Dart comes in: Strong-typing. Unfortunately, they don't seem to have Sencha level resources involved around the components, which is exactly what Flex Developers need, so… pipe dream. JavaScript it is.

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 like JavaScript. It reminds me of fond memories of my ActionScript 1 days, except I'm way less of an idiot now. For the types of applications we Flex Developers do, though… I'm not buying it. Again, trying to keep an open mind, but I fail to see how this stuff scales in both performance (both code and GUI refresh) as well as developers managing it (moar unit tests to compensate for lack of strong typing? riiiiigghhhttt… that'll happen).

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
Shared publiclyView activity