Disclaimers:

• I’m not trying to start a flame-war. Both Typescript and Flow are great.
• I’m not a Typescript expert so feel free to correct me on Twitter (@naman34)
• I’m assuming Typescript >2.0 which includes non-nullable types (because nullbale-types === ?)

If you haven’t noticed, there are two popular ways of adding types to your Javascript code — Microsoft’s Typescript and Facebook’s Flow.

Both are extremely powerful, gradual, structural, type-systems. They also, look very similar, with almost the same syntax. Almost.

Often developers jumping from one system to the other get frustrated that all the things they learnt no longer work in the same way. And they assume that the features aren’t supported. And so, they do what any modern JS developer would do and vent on Twitter.

But wait, didn’t I just tell you that both type-systems are powerful. Everything you did in one type-systems...

Forget everything you know about Gulp. Welcome to Gulp 4.

If you’re a front-end developer you surely have a build process in place. You maybe using Grunt, Gulp, Broccoli, NPM scripts etc. If everything works for you and you understand everything in your build process, you should stop reading now and focus your energy elsewhere.

If, however, you’re confused or just want to learn a little more about Gulp hang around.

Using Multiple Files to Organize Tasks.

If you currently break your gulpfile into multiple files, you probably make a folder called gulp and using something like require-dir to import it all.

While this works for now, it has the effect of making your build process harder to read.

Instead, keep things more explicit. This happens in two steps.

Firstly, start writing you gulp tasks as simple functions and attach them to gulp.task separately.

So, instead of writing this:

It’s been a few months since Microsoft announced the demise of Internet Explorer. Imagine a world, where this picture fill you with nostalgia instead of hate:

(Too soon. I know!)

But is Safari picking up where Internet Explorer left off? The answer is a little complicated — Yes and No

No

Safari isn’t remotely like IE 5-8. Safari is fast, efficient, and it’s been getting more stable. It mostly follows web standards and doesn’t shove in too many proprietary features into. We’re far from the ActiveX monster that was Internet Explorer.

Yes

If you look at Internet Explorer 9 - 11, Safari seems to be following in it’s footsteps. It’s standards compliant, but it’s way behind the competition. Features that have been implemented in all other browsers is nowhere on the horizon for Safari — WebRTC, getUserMedia, Web Components, Shadow DOM, the list goes on.

At the same time, Safari does...

I like Javascript. I like it a lot. But of late, I’m really annoyed by the state of Error Handling in the language. There are some tools that improve the situation some of the times. Promises and Reactive Extensions both give you a simple way to handle all your errors in one place. This is pretty good of course, no one wants to keep checking for errors everywhere, but there are deeper problems. What is an error after all?

Usually when we speak of Errors we are talking about exceptions. Javascript is pretty good at handling exceptions. You can throw an exception from anywhere. You can use try-catch to catch exceptions from anywhere as well.

So what’s the problem? The problem is that you that while you can throw values, you don’t really want to. While you can use try-catch to catch non-Error values and use it as a way to do control flow, it’s really not the best way to do thing. And it...

Once upon a time, HTML was the only language on the web. Styling was done with tables and color tags. Then CSS came along, and changed how we though about design. CSS selectors grew to let you target almost any element on your page in many many ways. Inline styles were shunned, to improve maintainability, and keeping you HTML free from junk.

A little down the road, we are told not to use the power of CSS selectors. We are now told to only use classes, and nothing else. And we’re now left to painfully go through our markup and styles and create a set of classnames that are unique but general.

At the same time CSS is still missing many features. In 2015, we can’t rely on CSS to have variables. Vjeux from the React time detailed these problems a few months ago in this talk.

Vjeux concludes that we should write our CSS in javascript for all the benefits that come from using a real...

A simple Gist by Substack, the author of Browserify has caused much drama in the javascript community. A lot has been said about modularity vs the kitchen-sink approach.

While on the one hand, Substack talks about how bundling features into a single project hurts Semver and hurts competition, Pete Hunt is sick of this ‘modularity shaming’ and points out that the Webpack codebase is extremely modular.

I see some good points on either side of the story, but I think the major difference between the two projects is something else entirely:

Compatibility with node.js

Browserify

Browserify was born to make your Node code in the browser. Till date it only supports the node flavour of commons (including JSON support) and provides in-built shims for many node core modules. Everything else is a different package. Need to watch files for incremental compilation? Use Watchify. Need Bundle...

There are the often simple explanations, Pure functions, no side effects, etc. All these sounds like huge limitations to most programmers who are used to using for loops etc. I’m going to talk about it in a different way.

Functional programming is different way to program. It’s not always a better, but it can often be more resilient to bugs. Also, it doesn’t just have limitations, but also it’s own set of features or powers. Let’s look into those:

First Class Functions

If you have a background in C/C++, this concept may seem a little foreign to you. (C++ has add function pointers now) But this perhaps one of the most powerful features that enables functional programming. First class functions means nothing other than the fact that functions are just another type of value that can be passed around, stored in variables, accepted as arguments in other functions and returned. Without...

The semi-colons in Javascript debate is probably decades old. (Which is quite a lot considering that the language itself is less that 2 decades old)
Most javascript developers are taught to always use semi-colons. The ASI in javascript is strange and inconsistent, and can surprise in weird ways.

So, let’s just not rely on stupid ASI and always write semi-colons. It sounds good enough. It sounds logical. Also, Douglas Crockford said it, so it’s probably the right thing to do.

But, the more time I spend writing semi-colons, the more I realize that you can’t really avoid the ASI by putting semi-colons. I agree that the JS ASI is weird and strange. But it is not inconsistent. It has a certain set of rules that work in every browser.

To use a saying made famous by Nokia, using semi-colons to avoid the ASI is like pissing in your pants to keep yourself warm. You see using semi-colons makes...

Grunge.js is what I can call my first major Open Source project. It launched without much fanfare. And it’s been stagnant ever since. It has seen little activity on Github, and almost no one has actually used it on a real project. Hell, even I’ve never actually used it on a project.

Grunge.js was my way to put generators to use and make something interesting. Turns out, Lazy.js does most of the things it does, and the few things that it does that other libraries don’t are edge-cases that people usually don’t care about.

Grunge.js, I thought, was going to turn into just a library for academic interest, but then I saw transducers and js-channels. At first, I didn’t really get it, but then I saw how amazing transducers could be.

They are fast, and extremely flexible. They make it possible to treat channels and observables as just another collection you can map over.

However amazing...