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 we talk about user input within a web app we often think first of HTML forms. Web forms have been available with the very first editions of HTML. Apparently the feature was introduced already in 1991 and standardized in 1995 as RFC 1866. We use them everywhere, with almost every library and framework. But what about React? Facebook gives a limited input on how to deal with forms . Mainly its about subscribing form and controls for interaction events and passing state with value property. So form validation and submission logic is up to you. Decent UI implies you cover such logic as on submit/on input field validation, inline error messaging, toggling elements depending on validity, pristine, submitting states and more. Cannot we abstract this logic and simply plug it in our forms? Definitely we can. The only question is what approach and solution to pick up.
I observe as some people still write ancient ES5 syntax of JavaScript and it’s disheartening. I wonder what keeps them from moving forward. Some must be driven by psychological inertia, but some likely just find it to complex to make their new syntax running in a wide range of browsers. In fact, nowadays we may not fear about it anymore. One can set up a dev environment where tools decide what transformations requires the code and what polyfills to load depending on selected target (list of user agents to support). The only thing one needs to start “a new life” is a proper setup. That’s what the article is about.
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.
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.
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?
We all are taught not to repeat ourselves while coding.. Nonetheless we keep repeating the same operation over and over – pressing F5/Ctrl-R for browser reload every time we have to examine the results of our last changes. After watching some of Paul Irish screencasts where he was showing the magic of live reload under Sublime Text 2 I wondered if I could employ something alike while keeping working with my beloved NetBeans IDE. However in my case it wouldn’t be enough just to reload the page when any of watched files change. I need to compile SASS sources, combine atomic JavaScript chunks into a single module and sometimes flush the application cache.
Eventually I found a tool meeting all requirements I have.
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.
Not so long ago Microsoft announced a new language, targeting on front-end developers. Everybodys first reaction was like Why on Earth?! Is it just Microsoft darting back to Google? Is that a trick to promote their Visual Studio?
But anyway, whats wrong with JavaScript? Why everybody is so keen to replace it? JavaScript for a language designed in only 2 weeks is freakishly powerful and flexible. But JavaScript still has its bad parts.
After Microsoft released TypeScript I took a look at their examples and found the idea pretty promising. I do love JavaScript. However, it has its bad parts. JavaScript doesn’t provide any built-in facilities to declare interfaces or object abstraction. There is no explicit way to have type annotations and type checking. Well, even class-based OOP is not a part of the language. Flexibility of JavaScript is incredible. So, there are tons of libraries meant to work-around these inconveniences. It hardly helps with code readability. At the same time TypeScript is a separate consistent language, which is, nonetheless, first and foremost a superset of JavaScript. You can use regular JavaScript within TypeScript and TypeScript is being transformed to JavaScript by TypeScript compiler.
I went through the specification and started writing design pattern examples on TypeScript to get a feel on the language.
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.
Standards are being always approved with a slow pace. Though, the features declared in drafts usually find their implementation long before the standard release. Let’s take for an instance Websockets, which were already implemented in Chrome/Safari and Firefox 4b when standard unexpectedly changed. Apparently YUI3 and jQuery have implemented for long time the features, which are only coming up with ECMAScript 5 (the implementations is called JavaScript 1.8.5) spread.
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.
Your site may contain a wealth of technical terms. The user while viewing it may have to wonder about their meaning. What can be done to provide site visitors with instant answers to the questions they have?
I am sure being accustomed to desktop applications GUI, users find interfaces of web-applications as extremely uncomfortable. Their notes, probably unexpressed, are timely within AJAX Age. Besides, it is not so difficult to make web-applications more user-friendly.