Shared publicly  - 
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 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.


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


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 ( ) 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
Robert Penner's profile photoMichael Ritchie (ThanksMister)'s profile photoGabriele Giannotti's profile photoEmanuele Canavesi's profile photo
Blogs are so last year, all the cool kids are doing google plus ;-) I love the write up man. I kinda out of it a bit so probably going to read it again in the morning... I am going to be starting up a contract using Flex/AIR/Unity3D/MongoDB (going to be freaking awesome!) and honestly I still think it makes ton of sense to use Flex for enterprise stuff... Although I do believe in the next few years it may start becoming harder to find Flex people and will probably make more sense to do work for my clients in Sencha so they feel more secure knowing some one else will be able to pick up the job after I leave.

Things are changing, although it may not make a lot of sense in some aspects the fact is it's happening and we can't really stop it (especially in the tech world).

#mustKeepAnOpenMind #mustKeepAnOpenMind #mustKeepAnOpenMind
Thanks! MongoDB is web scale.

I get the business angle, but it's open source at this point; and the tooling still beats the JS stack. JS is basically open source with all the libraries... so... I don't know. More wine? Yes.
I am super curious to see what the landscape will be like in the coming year or two... There will obviously always be Flex devs, but even though many are moving to js dev I wonder what will happen after the hype begins to die down a bit. There are already tons of articles popping up with people beginning to complain that the mobile web sucks and for people to get over the hype...

Of course i'll learn the html5/js stuff simply because I just want to be prepared for the future, but still going to be interesting to see how things turn out.
Mobile web is different: (A) no money in it for Enterprise and (B) performance of web is absymal. It's not responsive at all; even Flex is faster.

I agree, it will be interesting; I just wish I could beat Skyrim for the 3rd time AND Mass Effect 3 and complete #P90X all at the same time... and then the next day I'd get my coffee, and an email from you saying, "Hey bro, the hype has officially died down."
At the moment you are totally right! Mobile web is a mess, it has lots of issues, but for the type of project I am doing it's perfect and my customers have actually been requesting it... So I want to make it happen. I have ways to make money off of it an am excited to work in the mobile web. Going to be a really interesting challenge! What I have found really interesting is that more people using mobile web then actually using the apps... (really blows my mind, but it's true).

Haha, the hype will never die... I am just happy that we are starting to see smart js devs being honest and starting to agree and say it's not ready yet. Facebook been pretty vocal on the mobile web being crap.
Let's pretend it will, and you can magically detect this, thus, I'll just expect an email and will be working out and playing video games until I get it.
Just keep plying Skyrim and you will be fine :-)
The pattern seems to be every 4 to 5 years, there is some browser renaissance or fad. Like, all the HTML5 stuff that was released in the past 2 months gets enough penetration 4 years from now (as opposed to 8 months for a new Flash Player).

Second, JavaScript performance should be up to par. Right now, it's amazing how slow it is even with all the benchmark hypes I've been seeing. It seems many somehow magically leave out the "render that stuff in the DOM" part. I don't really know what par, is though. Some of the hardware accelerated CSS stuff I've seen is really great, but some of the hardware accelerated Canvas stuff I've seen is pathetic, specifically in Chrome. The point is, I've seen a ton of activity in this area this year, so 4 years from now we should have more people with the latest browser, and more kinks worked out so it'll actually work as advertised.

Third, we'll know what the true fate of Flex is. While Flash still has a ton of hybrid opportunities because you still can't provide the speed an UX of a whole SWF with "part of the page in jQuery an part in Flash" for some apps, Flex is in a tougher spot because it's value is usually doing the whole app in Flex, not partially. By then, it'll be clearer if we're at a point where the tooling is up to part (you've seen how far Visual Studio and the JetBrains crew have taking things for JavaScript in the past 2 years), integration of that stack (Sencha recognizes the hodge podge setup will NOT work for traditional Enterprises who expect a stack to purchase and be supported by vendors), and hopefully we'll start seeing better support of advanced language features; whether better source maps for debugging CoffeeScript/ClojureScript like languages, Dart getting an actual foothold, or Sencha's amaglmation of the above... actually running on a platform that can support the size of Flex apps that we're used to building.

Fourth, most telling and validating/invalidating of the hype, all of the above being supported by more than 1 vendor. It's clear with Windows 8 that Microsoft is behind the HTML5 toolset even if they want you to build windows apps vs. web apps with it. Once you get Sencha, Adobe, JetBrains etc. actually integrating everything into 1 IDE (like IntelliJ does for Flex + AIR + mxmlc + fsch), you'll start getting that speed of development thing that made Flash and Flex so awesome. If you can start whipping out web apps without being a genious and needing a local webserver + middle tier, THEN we'll start seeing traction based on factual results vs. bs hype.

Fifth, and most important; we'll start having a lot more designers making an impact on the developers and how we develop for mobile. My hope is by then the #'s will start to shift enough where larger companies will start to start seeing ROI for mobile initiatives. Right now, unless you're doing consumer stuff, none of my Enterprise clients see any ROI for mobile which sucks. Even if they did, it's hard as you know; while the code tends to be smaller, the design challenges are insane. Thankfully, there are a ton of people already tearing this apart right now than there were in the Nokia days, so I'm positive a lot of this will get figured out and you won't have to memorize both Apple's and Android's UI guidelines to not make suck.

So yeah, 4 years. In the meantime, there's alcohol.
I thought you were announcing your presidency, but this makes much more sense. I think a new pattern will emerge in 2 years because mobile is just changing that fast.
It's notoriously hard to predict tech, but bottom line, I have a feeling JavaScript + DOM speed (not CSS) will be decent enough for a lot of the apps that aren't just form based. Some of the charting and drawing apps are making some headway. We just need the under pinnnings of that tech to get faster, just like AS3 revamped the speed of AS2. It's more gradual, hence putting a stake in the ground. I'm not really make a statement, more of internalizing all the variables to make sense of what some of these companies who are switching from Flex to Sencha are possibly thinking/smoking.
I was hoping for a completely new language to develop in, outside of js/HTML stack. I still can't see mobile os companies abandoning app store for web-based apps without it being somehow proprietary and getting slice of $$. But I could be wrong and its all web-based apps in next four years, and Google/Apple dismantle their profit schemes to support open standards 100% this time.
" hah, screw GUI's, use the command line for a lot of this stuff."
Right on, love it...

" 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."
Oh how true this is!!
Well, CoffeeScript is one, ClojureScript another, and Dart another. Or you could just go the .NET route or Java Tapestry/Play framework/GWT route (Gmail uses GWT) to never code client code again.

There are a variety of annotation frameworks that help add type inference to JavaScript such as Google's Closure ( via type annotations and TypedJS ( ) does something similar.

The problem is none of those make the HTML/CSS not suck compared to designing in Photoshop > import into FLA > skin in Flex 4 or wrap in Sprite in pure AS.

So... either keep at your Android, start hearting Objective C (lol!). I hear you though; PhoneGap does mitigate it, but they're low on resources; their recent com.phonegap to com.cordova was a perfect example of "omg, needs moar Michael Labriola type leadership". Even so, while it works, it's still slow as balls compared to native. That and developing native extensions is about the same for AIR; the difference here is you actually have a good set of creative tooling + development tools for AIR whereas for Phonegap, it's an amalgamation of native + web + their stuff. I'm still trying it, but so not impressed. I get the value for web peeps, though; now they have an option just like AS3 people for mobile apps.

History has shown that no one technology dominates. Even in the Ajax craze there was plenty of Flex, Flash, AJAX, C++, Python, and Fortran work.
It might end up like native mobile dev, each using it's own language flavor to code. Mobile browsers might require specific language or process to access native libraries from the browser sandbox... think web app store. I figure that will reveal itself in next couple years.
Well, right now you can use JavaScript to access all of it; PhoneGap just extends what the browser doesn't support, or supplement things for half features. If you're a web dev, that's what you expect, just like we expect to access Open GL audio on Android via ActionScript vs. Java.
But if all is web-based apps as the HTML/js hype would have us believe, then someone will pipe web browser apps to native libs from browser sandbox. My theory anyways is html/js hype is temporary until mobile peeps invent a way to get 30% from web-based mobile apps.
Add a comment...