In software engineering we try to discover and eliminate bugs as soon as possible. One of most important heuristics here is validation of input/output on functions and methods. If you are going with TypeScript or Flow, you are fine. But if not? Then we have to manually validate at least input (arguments). But what would be the best way doing it?
When talking about modules in terms of JavaScript what come on the mind first are CommonJS and AMD. Yet, its 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.
Ive 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, its matter of minutes to go though the Backbone annotated sources and figure out the flow. Thats something you hardly can afford with other frameworks such as Angular, React, Vue or Amber. Besides its ridiculously small - its 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.
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 its much more than transpiler. TypeScript enhances JavaScript with optional features such as static typing, interfaces, abstract classes, member visibility and more. Thats a completely new level, not available in plain JavaScript.
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 ones 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.
JavaScript frameworks have been proliferating recently with a frightening rate. Just take a look at TodoMVC that provides dozens of MV* framework-specific implementation for a single task. It gives a felling how must be confused a developer making a choice for a framework.
Some time ago I even ran into a manifesto (bitworking.org/news/2014/05/zero_framework_manifesto) against JavaScript frameworks. I do not completely agree with the author, yet he has a point – it’s too many of them, too many of meta-languages to study that you as a web-developer may not need at all. Most of the frameworks contain plenty of code (AngularJS - 22K LOC, Ember.js – 43K LOC) and if you hope to know what is really going on in your application you have to study every line of this code. Let’s assume 3-5 of the trending frameworks are thoroughly tested by the communities, but what about others? Are you ready to spare days and weeks digging in someone’s code looking for traps and leaks in there?
In spite of most server-side languages JavaScript was not designed for templates. Yet we have plenty of template engines for client-side JavaScript now. They allow us processing templates, but what about declaring a template?
JavaScript was designed as a script language that is easy to embed in a larger host system and meant to manipulate the objects of the host system. With the advance of HTML5 formerly mostly static web-pages are turning into sophisticated web-applications. Now we expect JavaScript code to be scalable and modular. But how when JavaScript has no built-in facilities to combine distinct scripts?
As JavaScript application grows, navigation on the code becomes a hell. It comes on mind how useful would be to have ability including JavaScript files. For example, thanks to include/require statements we can build an expressive file structure in PHP. Let’s say following PSR-0 standard we have one class per file (or one prototype object per file in JavaScript) and class name (namespace) reflects the location of the file where it belongs. Well, on server side (e.g. with NodeJS) that is achievable with CommonJS. Of course you have to export every object of a single file as a module, which is often not a module in fact. As for the client side, modular JavaScript implies that all the dependent modules load asynchronously and separately. If every object makes a module to load that sounds nothing like a good idea.
A substantial web application doesn't need to wait until all the required JavaScript libraries loaded. Usually most of them can load asynchronously and start acting whenever they are ready. Most commonly used approach here would be AMD. That's a sophisticated and time-proved solution. However to use it with libraries, you must have them converted to modules. I don't appreciate the idea to interfere with 3-rd party library code. At the same time I still need non-blocking loading and dependency being resolved in my code. Thus, I worked out a very simple, but yet working solution.
JavaScript seems so simple that many people dont even bother to learn the language while using it. And yet it works! However, it turned out to be one of the reasons why JavaScript was dramatically misunderstood . Yes, it looks like a language of the C-family and, when starting with JavaScript, programers are just writing in C, Java, PHP or other language style. But JavaScript is no subset of any of these languages. You may find JavaScript even a superior language, but you have to know how to do things in JavaScript way. You cannot learn this from the documentation. References and, even more so, the specs are not meant to cover programming patterns, but the language itself. Of course, there is plenty of books and you may find some (e.g. Secrets of the JavaScript Ninja by John Resig, Learning JavaScript Design Patterns by Addy Osmani ) pretty useful. Besides, you can learn straight from the code, since we are lucky to have tons of substantial JavaScript applications available in open-source (jquery.com, yuilibrary.com/projects/yui3/, backbonejs.org, modernizr.com, raphaeljs.com and so on). In either case you may stumble over programming techniques unknown to you. Ive collected here some commonly used practices which may help you.
Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. On the other hand, JavaScript is an incredible impressive language. I wonder if JavaScript was originally designed as a foundation on which you build your own language.
About 2 years ago I had worked out a solution which developed by now into a light-weight library which brings into JavaScript everything I miss in the language as a follower of class-based OOP
The classical design of object in JavaScript may look pretty clumsy. So I prefer the module design propagated so indefatigably by Addy Osmani (addyosmani.com/largescalejavascript/). We keep all the declarations within the function body. Public members placed in the object, which the constructor function returns. It looks much nicer. But, here shows up a problem. Common implementation for inheritance doesnt work on such objects. Lets study how exactly JavaScript instantiates objects and come up with a solution for our requirements.
Few years ago only lazy didn’t say about bringing desktop application experience to the web ones. However in reality, it just meant that user actions didn’t always required page reload, but could change page UI dynamically. As for other application events, as a rule they were not handled dynamically.
Well, now you can find more and more web applications acting really like desktop ones. For example, Facebook and G+ have widgets which update automatically. You can keep the page untouched, but you will see anyway new status updates appear as your friends submitting. The same for notifications. Whenever a new one arrives, the counter changes and the notification list extends.
That seems to me as a trend worth to follow. I’ve been thinking of a solution to vivify widgets on my sites. Now I’m coming up with the following pattern.
Since YUI 3.1 version, the framework includes internationalizing utility. That’s pretty huge from the prospective of application maintenance and deserves a little review.
Everybody time to time comes to the dilemma which JS library to choose for further development. I used to work with prototype coupled with script.aculo.us and now use YUI3 in the office and jQuery at home. I like both of them, though finding each as the best one sui generis. YUI3 is a classical framework that provides design patterns and development philosophy as well as tool. jQuery is meant as a rapid, lightweight, flexible and pretty easy to start library. Its like Ruby on Rails and Python. Ruby and Python as languages are comparable (conceptual elegance against explicit consistency) and you will find APIs of both YUI3 and jQuery are quite similar.
First I decided rewrite my old BlogSlideShow JS-class. In fact I have a plan to rewrite all of my old works gaining to update functionally and appearance regarding to nowadays fashion and make better their code. So, after I finished with implementation on fluent JS, without use of any external library I ported it on jQuery. After that I wrote also implementation on YUI3. I’m fond of both those frameworks and found that is a good practice top have the same task solved thrice in different ways. So here is my observations experienced the task.
RIA is considered one of the most distinctive features of the modern Web, reflecting a trend where web applications grow to resemble desktop applications. The overwhelming majority of rich web applications are still built on the request-response model. Events on the client side can reach the server, but not vice versa. To build something as simple as a chat, you have to use tricks. These techniques for emulating bi-directional connections are collectively called Comet, a term coined by Alex Russell of Dojo.
Users coming from desktop apps tend to find web application interfaces frustrating. With AJAX, there is no good reason for that. This article walks through building an interactive data grid with sorting, filtering, and pagination, all without reloading the page.