Every once in a while, I see or hear someone complaining that a basic React application ran through Webpack ends up being 700 kB or more. I think it’s important to take a look at why this is happening – cause it’s usually all about the environment.

When you’re in development, what you want is:

• Quick builds
• Being able to trace an error back to the correct line number
• Warnings if you’re doing something wrong

When you’re in production, what you want is:

• Smallest bundle size
• Fastest execution

Code is read much more often than it is written. Having a consistent and defined coding style helps developers read the code, and it also helps to make a code base feel like one unit, instead of individual pieces written by different authors with their own way of doing things.

Having a coding standards is beneficial, but making people follow it is usually a bit harder. Let me introduce two awesome tools to help you: JSHint and JSCS.

So you want to write reusable, maintainable and modular Javascript, huh? Good.

Here’s a rather extensive “getting started”-guide by yours truly – which means it’s my own preferred way of doing things. It’s written with open-source in mind, but most points can be applied to “private” modules as well.

The web platform is maturing faster and faster, and we’re seeing the work normally done by native desktop applications now often shifting towards web-based applications instead. Features that may appear to have little importance can be really powerful when combined together.

A good example of this is URL.createObjectURL(). On it’s own, it really doesn’t do much. Paired with the HTML5 video and audio element, or even the good old image element, it gets to be really powerful.

If you have a node.js project that you want to have tested using Travis-CI, you may run in to a problem if you want to support node <= 0.8. The reason for this is the new caret operator, which was introduced in node-semver.

This module is used by npm to figure out how to resolve versions for your dependencies, and while it’s a great idea, it fails to work on older node versions without upgrading npm first. It’s actually fairly trivial to fix this, however.

D3. Behind this name is a pretty neat concept, called Data-Driven Documents. I took a look at the framework last year after seeing a lot of cool demos using it. It’s really flexible, and is not tied to a specific form of presentation – you can use D3 to generate an HTML table from an array of numbers, or use the same data to create an interactive SVG bar chart with smooth transitions and interaction.

After looking through different layout algorithms available in D3, I found the treemap algorithm particularly interesting. I’ve seen it used before in both profiling tools and disk usage analyzers and found them to be very efficient for visualizing the difference between numbers. An idea popped into my head: “Maybe this can be used to visualize which articles are being read the most?”. I decided to give it a try.

OpenVPN has feature that exports client configuration files. While it is definitely possible to run OpenVPN from the command line, I prefer to have a GUI that allows me to easily connect/disconnect from VPN. Ubuntu’s network manager and the .ovpn configuration files exported from OpenVPN does not play well together, however.

There is a workaround which involves cutting and pasting parts of the configuration file into separate files and adding some references to them in the configuration. After having done this a couple of times and helped other people with the same issue, I decided I’d write a simple tool to do the job instead.

HTTP 1.1 introduced the concept of chunked transfer encoding. This (among other things) enables us to send a request without knowing how large the content is going to be at the time we start the request.

An example usage would be where you generate content on-the-fly. You could potentially send chunks of a video-stream while you are recording or dynamically alter (compress, parse or similar) content from one source and incrementally send chunks to the server.

The developers here at VG have been talking about wanting to arrange a meetup for quite some time. At some point we sat down and tried to nail down the details of how we would arrange it. We created a group on Meetup and about a month later, on September 25th, we held our very first meetup event. It was a big success. A month later, we did our second event – focusing on the mobile application discussion around native/hybrid and web solutions. On Wednesday, December 4th, we’re arranging our third event. Title: Modern PHP.

If you’ve worked on more than one project in your coding career, you’ll probably have come across different coding styles. While some projects prefer an indentation of four spaces, others might prefer to only use two. Some may even use tabs. Then there’s line-endings, charsets and trailing whitespace.

When you are contributing to a project, it’s a good idea to try and follow the coding style already in place. This makes it more likely that your contributions will get accepted, and is in general a Nice Thing™ to do. So how can we simplify the task of setting up our editor to use a project coding style? Enter: EditorConfig.