Hot topic last couple of years is state management. Especially in the front-end apps. There are lots of problems and lots of solutions. One thing thought is totally ignored in this context - the JavaScript module system. I'm very often reaching out to this approach and decided to share it here.

You probably heard about Kik, NPM and left-pad saga this week. Shortly, a company Kik asked a developer Azer Koçulu to give the ownership on a NPM module. The module name matches the name of the company. The developer refuses and the company reaches the registry (NPM). The module was transfered to the company based on a NPM policy. The developer then decided to remove all his modules from the registry. The bad thing is that one of these modules left-pad is a dependency of many other modules. As a result of the un-publishing all the packages that depend on left-pad can not be built. Some really popular tools like Babel and React started getting broken builds.

Two months ago I published a starter pack for React based on webpack. Today I found out that I need almost the same thing but without the React bit. This simplifies the setup but there are still some tricky parts. So, I made a brand new repository webpack-library-starter and placed all the stuff that we need for creating a JavaScript library.

When CommonJS was announced we all thought “Finally something that will organize our code”. However, there are some cons that we should be aware of. It’s not only unicorns and rainbows. In this article we will see how a simple require line makes our code difficult to test.

I like npm and the fact that I can install tons of stuff. It’s great piece of software and helps me solve problems everyday. Yesterday I had to use a postinstall script and hit a problem.

These days I spent some time working on Yez!. Chrome extension whose main role is to replace the annoying switching between the terminal and the browser. It uses Node.js module to run shell commands. So, I had to deal with child processes, and I decided to document my experience.

I'm writing a lot of JavaScript these days. Sometimes it's really crazy what you can do with that language. I have bunch of tools in my arsenal and I wanted to document them somehow. Writing an article is a good option. By tools I mean patterns, piece of logic or just syntax shortcuts. However, this article is not exactly about design patterns, but it uses some of them. It's just about few ideas, which I came into during my daily scripting.

AssetsPack is a NodeJS module which helps in organization, compilation and minification of assets. It's meant to be used in local environment during the development process. It was made generally for HTML/CSS/JavaScript based applications.

PHP is one of the most popular back-end solutions available. However, I think that there is something wrong with the way we are using it. It is really popular to use some giant framework, with a lot of features. Generally, I'm not a big fan of this approach. Even if the framework is well documented and has big community it still adds some restrictions and complexity. Many people are trying to build the perfect framework, which covers as many cases as possible, but the true is that it is not possible. In this article I'll present you my vision about PHP programming and I will be very happy if you share yours.

The Dependency Inversion Principle relates to the stability and reusability of higher-level components within an application. The principle states:_A. High-level modules should not depend on low-level modules. Both should depend on abstractions.B. Abstractions should not depend upon details. Details should depend upon abstractions._Read more here.

That's a great article by Robert C. Martin. It's one of those articles that really may change something in your programming. The principle is called Open-Closed and it says:_SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION._More about that here.