Software Development & Management

UMD, how to break third parties

1 min min read - October 14, 2015

I do enjoy good practices in coding. I love the direction that many environments take to organise code and make it maintainable. But very often we think about our code and forget about whole world around it.

It's ok, when you have small page just for yourself. But when you have site that works, implement zillions of third parties to earn money, squeeze every penny out - you have to be careful.

I would like to highlight one good practice that ends in pain - UMD. Imagine you build cool new site, and decided to use Require.js to organise your code. It is quite good choice in the end. But then some third party you use loads some open library, like EventEmitter2 (again good choice) to not reinvent the wheel. All should be fine, but third party team decided that they don't do AMD, but depend on library registering their code in the window (worse, but still popular choice). What happens then? Their lib is being hijacked by your code.

Consider snippet below. It is from EventEmitter project. It expects that, if you use RequireJS nothing will be populated to the window. Your code delivers RequireJS and third party library can't asses it anymore. It crashes.

Lesson from this one? If your code lands on unknown environment - don't trust UMD. Maybe you would have to patch all libraries you use. Be as close to VanillaJS - so understand language. You never know what version of jQuery, Angular, React, Dojo, YUI or Prototype (sic!) your host will use.

Hope it helps.


if (typeof define === 'function' && define.amd) {
// AMD. Register as an anonymous module.
define(function() {
return EventEmitter;
} else if (typeof exports === 'object') {
// CommonJS
exports.EventEmitter2 = EventEmitter;
} else {
// Browser global.
window.EventEmitter2 = EventEmitter;

Next article

Software Development & Management

Times when many recruiters mistaken JavaScript for Java are long passed (except some rare awkward situations). Anyhow there is still very low understanding of specific technologies on JavaScript scene. It's nothing surprising as the market is very fast, tools change and new methods emerge almost every day.

read more…

4 min min read - October 1, 2017

Previous article

Software Development & Management
  1. First of all, you can get criticised. You may learn something from it, so you can improve. It's dangerous.
  2. Code shows your skills. They improve over time. Future employer can see you grow. That can end up with too big salaries.
  3. By resolving your problem you can become contributor of huge project. Like posting pull request to some framework. Then recruiter would think, you are a super star... you don't want that.
  4. Your code won't be hidden, ever... Imagine you do something cool, even for yourself. Great new business idea. And then you create snippet that is cool to. Only think is that this snippet has own value even outside the project. On the other hand it isn't something that affect value of the project. Say you build website for estate agencies and you have built nice CSS effect making buttons blink like Kardashians. If you don't publish that snippet as open source it will be forever safe. If you sale your project no one will use that snippet except new owners. If you publish it, you will keep all rights and it will be used by others... what a lose.
  5. Your code won't produce any direct money. No. Worse. You can build business model on top of it that you may not like. Like Symfony or Making money on service, training and support. Do you don't want that mess and scaling business. You just want to code for food...

In the end...

read more…

2 min min read - September 26, 2015