Hello there!

I am Bran van der Meer, internet geek and builder of the web, living in Rotterdam, Netherlands. I tend to make use of the nicknames branneman and branmovic all around the web, if you come across them, that's probably me.

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.

» Read full article

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.

» Read full article

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.

» Read full article