in Future

Can we save the “save-the-web” conversation?

Dries Buytaert, the founder of Drupal asks the question on his blog about whether or not we can “save the open web”.

Everything is says is exactly right, but somehow reading it makes me sad because it seems like he’s preaching to the choir. It’s important to get the “this is a problem” message out there, but I can’t help wishing it ended with a “and… here-is-the-solution” message.

The reason he doesn’t end with this is of course because there is no obvious solution. There’s an Einstein quote that says something about you can’t solve a problem with the same level thinking that created it, and I think that’s what we’re dealing with here.

The problem with the “save-the-web” message is it sounds like a “let’s go back to the good ol’ days” message which sounds a lot like “PrOgReSS BAd!!!“, which everyone knows isn’t true. Even when it is true, it can’t be stopped, so listening to messages about why we should is considered a waste of time.

To have more of an impact, I think messaging like this should be framed, not as a “reverting” of technological advances of today, but as the fantastic positive message about how great the future is going to be when we progress past where we are now to get to where we can be (if we work together).

I have an internet dream.

Thenable = Promises in 2k library

Just ran across Thenable which is a full-compliant promises library in just 2k library which is much lighter-weight then something like blue-bird. I’m making a note of it here so I’ll remember to try it on my next project.


myAsyncMethod = function () {
    return new Thenable(function (fulfill, reject) {
        doAsyncOperation(function onResult (result) {
        }, function onError (error) {

Building websites on websocket with Meteor.

I’ve got a prototype built for my current project using Meteor. I really like Meteor and I even though we’re at pre-1.0 days, I’ve got a good feeling about the community.

What’s fascinating to me is the concept of build a website that doesn’t use http. I mean it does use HTTP to download initial assets and stand up the client “app” in the browser, but after that everything is running over web-sockets (with fallbacks).

I was following Derby.js for a long time to see where they we’re going, and there was a couple other websocket based frameworks in the running for a while (Something, something real-time?), but meteor seems like the most robust to be starting a project on.

Here goes. I’ll post updates here with notes about my experience.

WebPack is Awesome!

Just found this new module bundler called WebPack by Tobias Koppers.

The big feature I like is what he calls “Code Splitting”. There are ton’s of bundlers, tools and packages that will help you produce the “One-big-asset”, but that’s a waste if you’re pushing new fixes and features every day, but your vendor libs change rarely.

I can see it being much better to have two static js asset files, one that changes when you upgrade vendor dependencies, and one for your application code.

Or what if your site has an “/admin” section that gets used by only a few users? Why push all that code down to every site user who is never going to instantiate it?

WebPack. This is gonna be huge.