Meteor – A Copperfield-esque Javascript Framework

I’ve been going over Javascript frameworks for the past couple of days. Everything from Processingjs and raphaeljs to Jquery and Mootools (a longer post on this later), and I hit something that just pretty much blew my mind.

Meteorjs (or just Meteor, if you want to get semantic) is a framework being built by a gifted, prolific group of scientists, which uses the binding and instant update techniques found in Handlebars, Nodejs, etc, but does it in a way that at first glance may actually qualify as magic. No, seriously.

After you watch the introductory video, you will say “how the heck did they do that??!??”

That’s the definition of a magic trick, is it not?



Betchu money if the fellas at read the above, one of them will say, “illusion, Michael!…


At any rate, for the love of all that is holy, go check out Meteor. It’s got some serious, serious potential.



An “Aha!” moment

I’ve been reading a lot lately (rather than posting, sorry kids) and Chris Coyier asked for people’s “Ah ha” moments with Javascript in a recent article.

Well, I had such just such a moment last night at about 3am, and even though it wasn’t for Javascript, Chris’ solicitation inspired me to share it.
Nope, it wasn’t for Javascript. It was for HTML. Specifically, it was for HTTP requests, and website development in general.

So, the old school website philosophy, which is tried and true, is pretty easy to grasp. A full web application is an “enterprise” level MVC design pattern:

  • You have your database and interface to that database (Model)
  •  You have your web server, which processes requests, reads/writes from the database, and servers web pages (Controller)
  • You have your web pages, which submit information to the server in the form of POST or GET calls (View)

Simple, straightforward, and proven.

Well, with the introduction of AJAX methodologies almost a decade ago (has it really been that long??? Man, I’m getting old…) we now have a significant portion of the processing / logic being done on the web page itself.
This is a good thing! I’m definitely not saying it isn’t. I’m just punching your ticket on my thought train that led me to my “Aha!” moment…

…as I was saying, the “clean” MVC pattern has been enhanced now, making HTML/Javascript pages become applications in their own right, using MVVM or MVP or other design patterns (I promise, I’m coming up on the point here, just bear with me).

These new patterns utilize JSON, AJAX, and Websocket calls, to interact with online services.  Meaning, the webpage itself is now the application, with its own controller/presenter/view model component, and Jquery/Javascript calls to get information from a service is now the model. There is no longer a need for the webpage to make GET/POST calls. In fact, the only thing the web server is needed for now is the downloading of the initial HTML for the web page, and serving up JS and CSS files.


And this is the “Aha!” moment:

HTML is now an application.

(The paradigm of ‘Site’ is dead)


Webpages aren’t webpages anymore. They’re applications. GET/POST should now be looked at as just-another-data-source for the Model of that application, and for “downloading” the application (FKA webpage).

That may not be an “Aha!” moment for anybody else, but the implications of it most definitely were for me:

  • You don’t need Site Maps anymore.
    – What formerly was a separate webpage is now just another view / attribute of the webpage ‘application’.
    – For e.g.: Preferences (it used to be a separate page. Now it’s a panel, just like it would be in a fully-installed app)
  • You can treat a webpage literally as you would a full application:
    – It’s ‘downloaded’ and ‘installed’
    – It has different modes / views (instead of separate pages)
    – It stores information locally (instead of just using cookies)
    – It consumes web services (instead of it being the View of a web service, ala POST/GET calls)
    – It can live on its own, outside a browser (e.g. PhoneGap)

So there you have it- You can start treating HTML as an application. Not a pseudo-application. An actual application. The call to the web server is now the download+installation process, and nothing else.

I’m 100% sure I’m not the first person to think about it this way, but it was definitely a paradigm shift for me, and qualified in my mind as an “Aha!” moment.



Was watching a great intro video about CSS positioning from CSS-Tricks, and found a great site:

It’s a pretty boss CSS / HTML renderer, in that you don’t have to reload the page every time like jsfiddle
And it integrates with github so you can save your code directly there, which is pretty sweet.

Here’s an example URL:
(don’t make fun of my code!!)

And the corresponding github gist:

Best of all, you can use Gravatar as a login.

It doesn’t do Javascript at all, so is still wonderfully needed, but thought I’d give it a shout out.


Find your principles (and get a haircut!)

Inventing On Principle – Bret Victor


Would you call Elisabeth Cady Stanton a community organizer?
You are defined by your cause, not your title.


That‘s just one of MANY gems in this talk by Bret Victor.

Very effective way to spend your lunch hour.


Thanks Flash & Math

Just wanted to give a shout out to Flash & Math.

I’m working on a (not-so-hush-hush) multi-touch app, and the standard drag and touchdrag functionality just wont do.

I had to roll my own, but this proved very difficult. That is, until I found this article:


You saved my life, fellas. Thanks!



TextInputs, StageTexts, & Scrollers (oh my!)

Any scrollers I’ve used (up until today) on mobile devices have been through lists, so I have created my own custom ItemRenderers.

Well, today I decided to be lazy and just add TextInput controls, along with labels and spacers, directly into a VGroup.

Compiled, debugged, and tested, all will great success….. until I tried to actually put text in the text boxes!!!
If you enter text, you get very odd text placement, and often the text will disappear entirely:



Well fancy that!

I did some digging and found out it’s intentionally this way, for performance reasons.  The parent component for TextInput and TextArea is StageText, which really REALLY hates scrollers (must have done something to StageText as a child!).

It’s a pretty straightforward fix: Adobe provides a custom skin that will heal the hatred, and all you need to do is reference it, like so:

@namespace s "library://";
.myTextInputStyle {
skinClass: ClassReference("");
.myTextAreaStyle {
skinClass: ClassReference("");


Then add a reference to your TextInput / Text Area Field:


<s:TextInput id="txtSignName" width="415" styleName="myTextInputStyle"/>



I get the logic behind it – mostly because let’s face it, how often are you NOT going to reskin / use an ItemRenderer?- but it’s still pretty troublesome to find the solution.
(btw, I got the answer from the Adobe Flex 4.6 reference, found here)

I’m curious to see down the road, as processors get faster in tablets, what the default settings will be. I suspect we’ll find that settings/optimizations like this will become increasingly rare as performance improves.



Steve Jobs’ Vision of the World

Ironic (if you know me) that I’m starting off with a Steve Jobs quote, but hey, he said something that has changed me in the middle of the day. And how often does that happen?

Continue reading…


After a good, solid year under my belt, I’m ready to start sharing some of the excitement I’ve felt since joining the Adobe team.


We’ll have code snippets, walkthroughs, product / book reviews, and of course the obligatory ramblings that we all delude ourselves into thinking are interesting and poignant pieces of blogging art.

Stay tuned, and I hope you find at least some of the posts inspiring or at the very least helpful in some way.