Babel transforms, helpers and polyfills

by Bran van der Meer

Configuring Babel 6 can be a little daunting for starters. Depending on what exact ES2015 features you are trying to transpile, you'll need transforms (plugins/presets), helpers, polyfills or a combination.

ES2015 consists of syntactic sugar, new internals and a revised standard library. In general you won't need to transform features that are standard library, but you will need to polyfill those. The syntactic sugar can mostly be transformed without the polyfill, but sometimes babel will need helpers for them.

Thoughts on SVG Graphics on the Web

by Bran van der Meer

So we all want HiDPI graphics on the web now, Apple started it all with Retina screens, and now most high-end Android and Windows devices have a 300+ PPI as well. With this, comes of course the problem of HiDPI graphics. Nobody wants 72 DPI graphics on their 300+ PPI screen.

And to make it interesting, I think most of you have to worry about IE 7 & 8 support, at least I do. It’s what makes our jobs interesting, right?

Translating this situation to the web, there are several ways to go. One of the easy ways is to create images that are twice as big, which generates 4 times the size. If you’ve got a photo, you might be forced into this solution. But we are talking about icons. For those kind of graphics, you could work with a library like Raphaël. Say your icon is suitable for it, this will get it on screen in all required browsers in no time. But, they do have performance drawback. Suddenly your visitors have to download an extra javascript library. And depending on whether you put it into head or body, either your page will load slower, or your page will become visible without the icons, which will appear later. I don’t want all that.

Let's not have a JavaScript library anymore!

by Bran van der Meer

JavaScript libraries bring a lot of features, and a lot of footprint. Most developers don't even use 10% of all the features most libraries have to offer. So maybe we should get rid of the library then?

When you never start using (or stop using) a JavaScript library, you'll save on bandwidth and performance by definition and you'll eliminate a lot of dead code in the process. You'll also lose an important dependency on code that's not "yours". But there are some trade-offs, like the steep learning curve for starting developers, most of them "know jQuery", but no real JavaScript. And you'll miss out on possible plugins and community support.

The moment you stop using a library and start developing something complex from a JavaScript perspective, you'll start running into problems you have to solve differently this time. The most common features used from libraries include the selector engine, event binding, DOM traversing/manipulation and http requests. And maybe animations, but I'm not going into that one in this article, it's already becoming a slight bit lengthy.

Why you need both a mobile app and a responsive website in 2012

by Bran van der Meer

A lot of people are struggling with the choice between a mobile app and a responsive website.

When you look at the discussion of responsive vs app, the answers have been given already. It basically all boiles down to whether your content is static or interactive. Static content (like posts on a blog) has more use on the web, where interactive content (like most webapps, Google Docs for example) fits better in an app at the moment.

Starting a relationship with your backender

by Bran van der Meer

I'm a frontender who works directly in the back-end template engines whenever possible. This makes me run into all the gray area in between front-end and back-end. This is the right place where quality and neat code should be made, but where often problems arise due to lack of inter-developer communication.

I work like this mostly because I've been a (evil) backender myself for a big part of my career, and I've worked with a lot of the template engines already. And maybe I like to get to know all the dirty little secrets of the back-end implementation as well.

The biggest advantage of being responsible for the code in the templates engine is being in complete control over how your code will end on the web. The backender doesn't have to translate your static code to a template engine language anymore, which most of them don't like anyway. And you won't forget about that one obscure use case your code will live in. Win-win.


Browser window resizer bookmarklet

by Bran van der Meer

I created a bookmarklet which can resize your browser window to any of the common resolutions. It currently has all the common desktop, Android (both tablet and phone) and iOS screen sizes.

pyinfo() A good looking phpinfo-like python script

by Bran van der Meer

Being a native php guy, I'm used to having phpinfo(), giving me easy access to php.ini settings and loaded modules etc. So ofcourse I wanted to call the not existing pyinfo() function, to no avail. So I used the code and cleaned up the layout to make it better.

Website just renewed, fully python and html5!

by Bran van der Meer

Just redone my entire website, in Python and HTML5! I have been planning to do the rebuild quite some time. But then again, It has to come out of my free time, which basically means for me that simple stuff like this can take a year. A year it didn't take, but long enough though.

World of Warcraft

by Bran van der Meer

A compilation of the stuff I did/accomplished in the game. It was a good time.

WM Mobile Armory available

by Bran van der Meer

I know there are several wm wow apps already, but I still wanted to make my own, because I think I can make a better one with lesser system requirements. Not finished yet, but released to receive some feedback, here it is.