Jam - The JavaScript package manager

For front-end developers who crave maintainable assets,
Jam is a package manager for JavaScript.
Unlike other repositories, we put the browser first by using AMD modules.
Jam - The JavaScript package manager

I was talking to fnd just the other day about this and what a good idea it was. I haven’t looked at the implementation too closely yet, but it seems (to me at least) that it’s something that has been sorely missing in the past.

via TiddlySpace [source]

Winners! Innovation Nation award!

The AMBIT Collaboration are thrilled that we have won the Guardian and Virgin Innovation Nation Award under the category of innovation in collaboration.

Thanks to all our supporters who voted for the collaboration.
Winners! Innovation Nation award!

Tiddlers in action! Congratulations to al involved.

via dickon

via TiddlySpace [source]

CodeGrunt - The Brittleness of Type Hierarchies

When you write a program using a C#-like language you typically start by modelling your problem as a hierarchical set of classes which represent your domain. You then procede to ‘flesh out’ and expand upon these types with code which actually implements your program.

After a while you inevitably find an exception to the rules of the system you have created - your types turn out not to match the problem in some way. Typically this occurs later after a lot of work has already been done which is now strongly tied to the structure of your type hierarchy, so you are left with a problem - do you hack around the incongruity, usually the quickest solution, or restructure your types to adapt to the new requirement?

If you choose the former your hierarchy not only fails represent the problem anymore, it actively misleads you about it. If you choose the latter, you end up spending a long time yak shaving - working on something which has absolutely nothing to do with the problem itself and is purely a product of the system in which you are writing your program - the very definition of accidental complexity.
CodeGrunt - The Brittleness of Type Hierarchies

This is my experience almost exactly, and why I tend to prefer more dynamic languages like Python and JavaScript that make refactoring easier.

My approach tends to be to first start building, and then when refactoring/encapsulation opportunities arise, refactor and encapsulate. I find this results in something that better reflects the problem domain than defining a class hierarchy up front. Of course, I now use Python and JavaScript, which makes this all a lot easier.

via TiddlySpace [source]

Confessions of an introvert

I remember you though. I was really impressed by your story and your vision of where you want to take the company. Selling myself is not my strong suit, so I must have seemed pretty funny handing you my card and mumbling something about getting coffee. The thing is, once you get to know me, I’m a pretty funny and personable guy. Hell, I love to have a good laugh and hang out to decompress – it’s really important to me too.
Confessions of an introvert

Seems to me like being an introvert is deeply unfashionable and uncool in the web industry at the moment. That sucks. It would be awesome if it changed.

via TiddlySpace [source]


cdent writes:

So you got some action over on side A and a sizable set of web browsers that run across all these different operating systems. And then you’ve got this other browser that only runs on side B.

If Microsoft wants to show a real commitment to an open web, they need to start releasing versions of IE for other operating systems. It used to be possible to get IE for Mac and Unix. There was even a time when IE was the clear best choice of browser on a Mac.

The thought occurs to me that the exact same argument can be made for Microsoft’s mobile app development process. That being:

If people want to develop a mobile app, they need a Mac running OS X, unless they don’t want to support iOS (unlikely). On a Mac, they can develop apps for iOS, Android, and responsively on the web itself.

If they want to also support Windows Phone, they need to shell out for a copy Windows, which they must then either run inside a VM (which sucks), using BootCamp (which is a lot of hassle), or on a separate Laptop (which is expensive).

After they have Windows running, they need a copy of Visual Studio (I’m unsure of the license terms of the Express editions, but they may or may not suffice).

So the workflow for someone wanting to support Windows Phone boils down to one of the following 2 options:
  1. Develop all your apps for everything but Windows Phone. Then switch to a whole new Operating System and make the Windows Phone version.
  2. Develop all your apps for everything but Windows Phone and point people at the web site.
The solution seems fairly obvious (hint: it’s (2)).

tl;dr: Microsoft needs to release Visual Studio for OS X as well as IE.

via TiddlySpace [source]


After Mozilla’s hacks blog posted an article about how localStorage is too slow and someone else said localStorage is just fine it reminded me of how frustrated I’ve been at the various proposed “solutions” for an in-browser persistence engine. It is completely ridiculous to think it…

This is really obvious. I can’t see anything else really catching on.

(Source: mbleigh)

Michael Bleigh: LocalStorage? IndexedDB? What we need is Redis for the browser.
2 years ago 1 ♥

JSON.org License Literally Says it “shall be used for Good, not Evil” | Javalobby

But, the most important thing I take away from this license is that this additional clause adds an unnecessary complication
JSON.org License Literally Says it “shall be used for Good, not Evil” > Javalobby

It’s only unnecessary if you believe that people should be allowed to do evil things with tools you create. If anything it’s badly worded, not unnecessary.

via TiddlySpace [source]

Some thoughts on Vendor Prefixes

Remy Sharp writes]:
Browsers need to:

  1. Fucking drop experimental prefixes. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.
  2. Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 - the stable version - experimental support should not be baked in. The properties should be full available without the prefix.
  3. Work with the working groups (…Apple).
I agree with all of these points, but at the same time, I can’t see it actually happening. I just can’t see Google or Apple actually removing features from their browsers and moving them all into beta in perpetuity (because let’s face it, the standards process takes far far too long). Even if this did happen, I can well imagine most developers (and people who want these features) just switching to the beta and using that as their default browser, as most betas are fairly stable these days. That’s not solving the problem. It’s just moving it to another place.

I’ve seen two comments on Twitter that really resonated with me about all this. The first, from psd, states:
the problem with vendor prefixes is the namespace is used to target a browser vendor rather than disambiguating similar proposed features
And strikes me as the current problem with vendor prefixes. Sure, the best features win out in the end (take the gradient syntax for example), but as it currently stands, the best feature ties rather too closely into the browser that implemented it. The solution would then be to drop the browser specific prefixes, and adopt feature based prefixes that, when they become popular, other browsers can implement and test out as well.

The other comment on Twitter, was part of a conversation between Mike Mahemoff and Alex Russel and mentions the CSS Mixin proposal.

The thought occurs to me that new features and proposals, when implemented in JavaScript, are never really a problem. This is, to a large extent, due to the presence of shims and polyfills, that abstract all the browser differences away with the inclusion of a single script tag (think the es5shim for example).

Such solutions already exist for CSS, but they all involve either a build step (yuck!) or running all of your CSS through JavaScript first (yuck again!). I’m going to name this “The Dart Approach”, as it aims to solve the problems with CSS by forcing you to write something that isn’t CSS. The CSS mixin proposal would solve all of this in one step by allowing you to include a single CSS file (presumably from a CDN somewhere) that includes cross browser definitions for non-standard features. Then you just keep going as normal, and should anyone want to use a webkit only feature, they can go right ahead, safe in the knowledge that if Mozilla, for example, implement a similar feature (with their own prefix), it will just automatically work (as soon as the CDN is updated of course).

Developers are lazy. Browser makers don’t want to remove features (or relegate them to beta only). As with Piracy, the solution is not to educate the pirates (or in this case, developers/designers/browser makers); the solution is to make it easier to be cross browser compatible than to not be cross browser compatible (in much the same way jQuery does). CSS mixins seems to be a good way to accomplish this.

The only real problem now, is how quickly we can get it through the standards process (a problem in itself).

via TiddlySpace [source]

TiddlyBookmarks Chrome Extension

I’ve created a Chrome Extension for tiddlybookmarks. It’s not in the Chrome Web Store yet so you’ll have to install it manually, but you can find it at chrome-extension.crx if you want it.

via TiddlySpace [source]

If You Thought SOPA Was Bad, Just Wait Until You Meet ACTA - Forbes

When sites like Wikipedia and Reddit banded together for a major blackout January 18th, the impact was felt all the way to Washington D.C. The blackout had lawmakers running from the controversial anti-piracy legislation, SOPA and PIPA, which critics said threatened freedom of speech online.

Unfortunately for free-speech advocates, censorship is still a serious threat.

Few people have heard of ACTA, or the Anti-Counterfeiting Trade Agreement, but the provisions in the agreement are just as pernicious as anything we saw in SOPA. Worse, the agreement spans virtually all of the countries in the developed world, including all of the EU, the United States, Switzerland and Japan.
If You Thought SOPA Was Bad, Just Wait Until You Meet ACTA - Forbes

via TiddlySpace [source]