Stickers

  • Aug 18 Screencast from chapter `Debugging and Profiling` of my book `JavaScript Unlocked` Follow the link
  • Aug 02 Do you want simply import/include HTML blocks on a page? Here is the directive Follow the link
  • 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
Building Real-Life Applications with Functional Elements of HTML 5.2

What's common among UI components like expandable, collapse, dropdown menu, tree navigation, popover? You can achieve all of them by using HTML elements details and summary. Moreover, you can leverage dialog element to build modals, overlays and dialog windows. You can utilize input types such as week, month, datetime, datetime-local instead of plugging in 3rd-party datepickers. You can make img element load images from different sources depending on viewport, DPI, mobile device orientation or browser support for new graphical types. Not all of these features are fully supported by popular user-agents. Yet we can enable them already with polyfills. So why struggle with outdated libraries for common repeating tasks? Why not embrace the power of standardized built-in browser elements? This article describes the new elements of HTML and shows usage examples natively and with polyfills.


State of JavaScript Modules 2017

When talking about modules in terms of JavaScript what come on the mind first are CommonJS and AMD. Yet, it's 2017 and we have the native module system in JavaScript. We have already Google Chrome, bundlers and loaders that resolve ES2015 modules. Besides by using Webpack we can combine dynamic and compiled modules to improve user response time. This blog post introduces the reader into JavaScript modules in general and into ES2015 module system in particular. It also explains how one can split the application into modules where some are bundled and some loaded on demand.


Bringing Angular 2+ Development Experience into 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 (https://babeljs.io/) 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: Missing chapter of my book `Unlocked JavaScript`

My book “Unlocked JavaScript” (www.packtpub.com/web-development/javascript-unlocked) 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.