From a programming perspective, teaching advanced JavaScript is quite challenging because it wasn’t designed for traditional OOP concepts and large application design. Many of the more popular languages today are either built on, or support and promote OOP usage. On the same token, once you know OOP you better appreciate Functional languages, parametric polymorphism, and other dynamic language features.

However, I don’t believe you can effectively teach OOP in JavaScript as it stands today, mainly because JavaScript doesn’t have a de-facto way to approach OOP. You have Douglas Crockford of JSON/JavaScript The Good Parts/etc fame promoting closures, various others promoting through their actions of having x-compile languages exporting to and/or optimizing the Object.prototype way, and still others keeping with the compromise of sticking to Functional roots via Object.create. Of those, you have a variety of implementation standards.

The more I read, the more you can see implementations based on preconceptions from other languages that the developer(s) have experience with, not ECMAScript suggested (with the exclusion of TypeScript). However, teaching cross compiler/transpiler ways of doing OOP for JavaScript defeats the purpose because anyone who has experience with prototype based languages, or even just dynamic ones, recognizes the broad flexibility they provide to communities and learning potential of those who deploy them since developers effectively “create their API” from extending existing prototypes.

Case in point, a n00b can use Promises without knowing what promises are in 3 lines of jQuery to make his/her site “work” as can an Enterprise dev, whether coding by hand, cross compiling (Gmail, Oracle ADF, .NET, etc), or both scale hundreds of thousands of lines of code. Both can extend the language via Object.prototype modifications for both back porting or simple utilities, and those who write libraries differently can, with knowledge of JavaScript scope, relatively easily borrow those for their style of coding assuming the algorithms are contained within JavaScript vs. CSS.

Additionally, you CAN market to the n00bs, the Functional crowd, and the traditional OOP developers simultaneously.

So skipping JavaScript to teach CoffeeScript or Java GWT instead of teaching JavaScript defeats the purpose, and cheats the student of that value.

Instead, it helps to be pragmatic, and explain what’s really happening: There is enough business demand for traditional OOP developers to get the features they desperately need in a standardized fashion, whether syntactic sugar or true implementation. This means asynchronous modules and OOP syntax. Harmony, of which much already supported, and ECMA 6’s better class support, shows that the OOP developers have made their case, and that the Functional crowd has made theirs as well: both can co-exist.

Thus, it seems more prudent to teach the vision of JavaScript OOP that is real, and actually coming vs. teach a like-minded OOP language and apply those concepts to JavaScript with it’s various incarnations. That and it’s more relevant to their present AND future.

If you teach the architected future, you can easily dissect various strategies employed currently to use that future today.

I wish I had done that with ActionScript 1.0. I learned OOP after the fact and was basically taught for reasons both valid and invalid that dynamic Functional languages don’t really help you build software and I think that was a shame. I hope to remedy that in a future set of videos to help prevent developers going through what I went through.

Supporting links below video; I’ll add more + annotations to the video itself when I get time.

Supporting Links

• Corona Physics in 5 lines
• Corona API’s
• John Lindquist’s blog with videos on Lua OOP/inheritance via metatables
• OOP Inheritance via Closures (I like this way vs metatables)
• Collision Filter Chart (utter win here)
• Corona Debugger
• Plane Shooter Game I’m working on w/source code and assets
• Robotlegs for Corona/Lua

If you’re not on the list, the quick summary is Adobe’s suing Wowza for patent infringement caused a lot of frustration in a already-extremely-pissed-off-at-Adobe user base.

I wanted to point out Adobe’s proven history at making money from defending their patents, some misunderstandings of how this is related to Flash’s second PR problem, and trying to crush some of the mobile hype misunderstandings.

First, litigation….

Macromedia built some phat tabs into Photoshop. Adobe sued Macromedia for copying back in 2000. They won $2.8 billion dollars. That’s almost 3 Ominiture purchases, not counting inflation. Macromedia then reverted GUI work they had done in 2 of their products (which probably cost a few hundred k + valuable software dev time).

Macromedia sued Adobe back the following year saying they owned patents on Photoshop, and won  $4.9 million. This kind of sue/counter sue went on for awhile.

Even a shareholder with a litigious history sued Adobe for hurting Macromedia shares during the original buyout.

So, there is money to be made in such suits vs. innovating on your software. Additionally, you need to defend certain aspects of your software/brand, otherwise it becomes public domain.

Second, Flash dying…

Incorrect. Flash isn’t dying. People’s passion around Flash is. The marketing around HTML5 has successfully identified this trend without naming it, yet fails to recognize the reality is you have zero choice for reliable, cross platform delivery of highly visual experiences at a reasonable expense unless you use Flash.

Like Stefan said, there is a ton of Flash and Flex work. If you’re having problems finding work, talk to me. While performance on mobile blows compared to Desktop, 2 things are happening: Adobe is iterating and continuing to invest money in making it perform better. Also, phones are constantly increasing in performance. Some of the experiences you can create right now on mobile using Flash CS 5.5 and Flash Builder 4.5 are good enough for certain types of work. More on that in a bit.

On the Enterprise side, they still generate ghetto fab AJAX from 2004. Whether .NET and Atlas, Java’s Tapestry derivatives, or Oracle’s ADF… it all looks like forms from the early 2000’s. These aren’t RIA’s, they’re just really large form applications in the browser, not experiences that can be easily sold unless they make up a large, boring product portfolio for a specific, non-tapped niche. Until GWT generates Flex on the client vs. HTML/CSS/JavaScript, we’re golden here too. Cross platform/cross browser drag and drop, high performance visualizations, and video with REST/SOAP/JSON/XML/binary socket connectivity? Thatâ€s all us. Being able to actually integrate with those technologies I mentioned above? That’s also all us.

Yes, iOS, Android, and Corona are hot right now. They are different markets than traditional Flash/Flex Development. If you wish to quit Flash/Flex, there is plenty of room & opportunity for you in those tech spheres. You can have while working there and making a great living. You can have fun and pay you’re mortgage.

Third, Mobile hype…

While the press will lead you to believe that the only jobs currently being hired for, and done, are for mobile, itâ€s a complete untruth. Many companies, specifically Design Agencies, are running into challenges in selling reasonable mobile packages. If youâ€re selling a $100,000 website, and itâ€ll take another $20,000 to get your team to make a mobile version, most clients (currently) arenâ€t buying. They just opt for the desktop website. While you could reduce scope in the desktop website, most clients contacting design agencies arenâ€t willing to bend on the Quality part in the Quality/Time/Cost circle, thus, you donâ€t really have a lot of room there.

For mobile apps that make use of native code speeds and functionality, itâ€s worse. If I pay an iOS dev $16,000 to knock out a small mobile app, I usually have to hire another skill set to knock out an Android equivalent one… for another $16,000. This assumes, too, that we add the standard 20% for past device support (iPhone 3Gs with 4.0 SDK, iPhone 3Gs with 4.1 SDK, etc). This, in addition, to usually some marketing website advertising the brands campaign around the new mobile applications for all devices.

Right now there IS money floating around for the larger companies willing to fit the bill. Thatâ€s not sustainable for the industry at large since not everyone is Coke or Turner. Eventually, lower fidelity HTML/JS/CSS or Flash code bases that allow cross device, and sometimes desktop web support are more cost effective. While theyâ€re not native, they do work, have positive customer perception, and can be sold at reasonable prices. Both HTML/JS/CSS and Flash are just now beginning to make this type of work a reality. While the code is write once, and deploy… the design still requires some rework, but the skills required can be learned, optimized, and made into a reasonable workflow.

This is the future. It isnâ€t here yet. If you ask many agencyâ€s, yes, their mobile work is increasing, but itâ€s not the sudden “death of radio because TV came out” that the press would have you believe. There’s opportunity here, folks, not death of your career. Growth!

Conclusions

Adobe has the right, and should, defend their patents.

Macromedia traditionally was extremely good at asking honest, forthright, non-assuming questions to community members & customers. This helped drive product direction, and ensured their products actually did what we needed it to do both now. They still put innovation in as well. It wasn’t always right (Behaviors Panel in Flash), but when it it was, magic happened (YouTube).

…except the velocity in FMS was excruciatingly slow compared to the other product lines. If you only occasionally did a Flash streaming project, oh well. If you built a career around doing Flash video, it was quite frustrating. The only community I ever saw throw so much vitrol back at Macromedia was the ColdFusion community; they did this in an Emo, I-just-need-a-hug way, and usually things worked out for them. For the FCS/FMS crowd, not so much; they were, and still are, pretty pissed off, even before the lawsuit. If history’s any indication, they’ll keep using FMS.

For whatever reason, Macromedia, and later Adobe, didn’t seem to see ROI in investing in higher velocity feature sets for FMS releases in relation to customer expectations. At least compared to other product offerings. Maybe it’s a niche market.

Bottom line, people would love to utilize this incident as a way to say Adobe needs to reep what they sow with regards to ignoring their most valuable assets: product evangelists & community engagers.

…and as an incident that will cause their existing customers to move to Wowza/Red5 away from FMS. Um, no, not going to happen in a large enough capcity to matter, methinks. We’d all prefer they spend the litigation money on buying out Wowza instead.