• Oct 06 ByContract 0.0.5 released. ByContract is a small library that implements Design by Contract -like validation in JavaScript code, using JSDoc expression for contracts. From now it supports custom types (union/complex) declared in the fashion of @typedef JSDoc tag. Follow the link
  • Sep 14 The Flavor of TypeScript: a hands-on guide full of ready-to-use recipes and code examples Follow the link
  • Apr 13 "A few things you need to know about CSS" slides from an internal master-class Follow the link
Second Wind for Backbone

I've been working with Backbone for years and it suited me pretty well. I do love its conciseness. It gives the desired abstraction and yet leaves you at the full control of your app. When you need to know what exactly is happening in your app behind your code, it's matter of minutes to go though the Backbone annotated sources and figure out the flow. That's something you hardly can afford with other frameworks such as Angular, React, Vue or Amber. Besides it's ridiculously small - it's less than 8Kb without dependencies where the dependencies can be dropped if you go with Exoskeleton and Backbone.NativeView. I know that few today care about download size, but I do as it still affects the user response time.

Guarding functions in JavaScript

As developers we spend a lot of our time on debugging and particularly on spotting the source of a problem. DevTools guides us though the call stack, but the tracing process can be still pretty time consuming, especially on a cascade of asynchronous calls. The remedy here is early problem reporting.

Nightmare of End-to-End Testing

Modern application get complex, we cannot go without automated testing. The canonical agile testing quadrants are split to technology-facing and business-facing tests. As for technology-facing testing I believe nowadays everybody has dealt with unit-tests. Thus we make sure that the smallest parts of the system act as intended in isolation. Also we use component tests to verify the behavior of large parts of the system and integration tests to check if communication between object isn't broken. The entire quadrant is all about programmer low-level tests proving that the code meets all the design requirements. These tests are meant to control internal quality, to minimizes technical debt, and to inform dev-team members of a problem of early stages.

Business-facing (or acceptance) tests describe the system in non-programming terms and they ignore the component architecture of the system. Here we know testing techniques such as functional, story-based, prototypes, simulations. Apparently in web-development the most demanded approach is end-to-end testing. This one is performed on the application level and tests whether the business requirements are met regardless of app internal architecture, dependencies, data integrity and such. Actually we make the test runner to follow the end-user flows and assert they get the intended experience.

Writing Backbone Applications in TypeScript

Nowadays JavaScript evolves fast. We have ECMAScript 6th and 7th editions released over just 2 years. the current support of ES6 specification in major browsers is close to 100%. So the language changed, and changed for better. It has become more expressive, much more concise and readable. It is tempting to jump into, but what about older browsers? Transpilers can translate ES.Next into the old-good JavaScript of ECMAScript 5th edition.

Then the question is which transpiler to pick up? Babel ( is still on the rise, but look what is happening to TypeScript. Since it was chosen for Angular2 it is gaining its momentum. Why have they decided for TypeScript? Because it's much more than transpiler. TypeScript enhances JavaScript with optional features such as static typing, interfaces, abstract classes, member visibility and more. That's a completely new level, not available in plain JavaScript.

Enhancing user experience

My book “Unlocked JavaScript” ( has been released on December 7, 2015.

This book is for developers already familiar with JavaScript who want to level up to get the most out of the language. The book is practice–oriented and would be most helpful for those who is used to `learn by doing` as the topics are thoroughly covered with real-life examples and tutorials. This is an extract of a chapter not included in the book.

As you likely know, in addition to new syntax, HTML5 introduces powerful features and APIS that can be used with JavaScript. Some of them such as Web Storage, IndexDB, FileSystem, Workers, Custom Elements, HTML Imports, Shadow DOM and Templates we examine in the book. Here I want to share with you a few HTML5 API that you may not be even aware of. Nonetheless they may help you to improve UX in your web application significantly.

Responsive Web Design: Best Practices for Improving Performance

User are impatient. Majority would leave a resource if it failed delivering the core user experience in 1-3 seconds. Today when mobile overtakes fixed Internet access you need to think of how the app loads on a low bandwidth, what images must requested on what devices, how stylesheets and JavaScript are cached e.t.c. Fortunately there a number of amazing tools such as PageSpeed Insights, WEBPAGETEST, Pingdom Website Speed Test. So you can find out what's wrong with your app in terms of web-performance. Chore DevTools emulator gives an idea how you app renders with different connection speeds. As you see there are many ways to discover if you have performance issues and what they are. But that brings to the question “how to solve them?”. Here I am to share my experience.

Automated CSS regressive testing in practice

We write unit-tests tests for server-side source code and for JavaScript. Even when putting aside benefits of TDD approach it gives us a priceless thing – early problem reporting during refactoring. So you make change, you run tests and you will know at once if anything broke. What about CSS? You encapsulate a declaration set into a separate rule, look through the site pages where dependent classes used and satisfied proceed with refactoring. After finishing your work you test the site thoroughly, opening every page, every modal, drop-down and expandable. Now you find out that on the very first change you broke the styles of a component that shows only by user action so missed it back then. It turns out that refactoring decision wasn't quite good. But it's late to change.

If only we could go with automated testing... In fact we can.

Modularizing and Packaging JavaScript for Scalable, High Performance Web Apps

JavaScript applications have been growing in size and complexity increasingly over the past years. That brings new requirements for code maintainability where encapsulation gets crucial. While AMD implementation of modular design in JavaScript is wide-spread, CommonJS Modules/1.1 is are mostly used for server-side JavaScript only. Nonetheless this standard can be applied beneficially in-browser a well. Precompiled CJS has its advantages. Besides cleaner syntax comparing to AMD approach it may boost the performance of one's application by reducing the number of HTTP requests while the code stays well-grained. Here we are going to talk on how to achieve an efficient JavaScript code design by using CommonJS compiler.

10 things to need to know about CSS

CSS may look as a simple language. In fact it can be simple only to use, but definitely not simple to maintain.Everybody who used to work on a large-scale projects knows how hard it can be to keep constantly growing CSS sources readable and consistent, styles reusable and loosely coupled. Moreover while going responsive web design (RWD) we also deal with increasing cyclomatic complexity. Learning from own experience I collected 10 vital principles that help turning your styles into efficient and highly maintainable code.

Creating a web-component: VanillaJS vs X-Tag vs Polymer

It seems like these days the most trending concept in the HTML5 world is web components. But what the fuss is all about? In order to make such a simple thing as a container expanding on click in past we needed to write CSS and JavaScript. Today thanks to checkbox-hack and :focus or :target pseudo-selector we go on with CSS-only. In fact by using `summary`/`details` elements we do not need any tricks with CSS to make it working, considering that browser already supports this feature. Thus by placing this elements in the DOM we declare specific functionality, CSS is used for styling and JavaScript if still used only for extending the element basic behavior. That is how it is meant initially. However HTML brings just a few new elements what is hardly enough to replace all the custom plugins, libraries and snippets we use. But what if customs elements could be created by anybody? If source code, styles and markup could be kept encapsulated in a package? If the package could be included into HTML document by a link? It sounds almost like an industrial revolution. Just imagine that you need a slideshow on your page. So you add a link to a corresponding component and simply wrap your image slides with custom `img-slider` element. That's it, you have a running slideshow. You want something else? Just search in the web-components repository. In the other hand you can switch to a UI library based on web components, e.g. Mozilla Brick and build the entire application with web components Exciting, isn't it?

That is in theory. I never have a grip on a new thing until I try it in practice. So I invite you to learn web components with me in practice.