Naman Goel

talk about code

Page 2

Is Safari the new IE?

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


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.


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...

Continue reading →

Ideas on Improving Error Handling in Javascript

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...

Continue reading →

CSS in JS in CSS

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...

Continue reading →

Browserify VS Webpack - JS Drama

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 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...

Continue reading →

An Intro to Practical Functional Programming in Javascript

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...

Continue reading →

Going semi-colon-less. OR why I’m considering the NPM Style Guide.

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...

Continue reading →

The Next Step in the Life of Grunge.js

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...

Continue reading →

A Javascript developer’s guide to Swift

This year’s WWDC was a big surprise for anyone following Apple. But the biggest surprise was the new language called Swift. Apple has managed to create a whole new language that borrows heavily from many other languages but eventually is something unlike anything out there. The syntax may be similar but there unique characteristics to the language that are not out there in any other language. One of these is the fact that Swift is completely compatible with Objective-C. It uses the same APIs and in fact you can use both languages in the same project. It is then but natural for lots of people to directly compare Swift with Objective-C. Others have also compared Swift to Go, Scala, F, C etc.

I’m here to compare it to Javascript. Going over the language, I see the many similarities. And even in places where the languages are very different, there are ways where Swift can be written in a...

Continue reading →

Delivering a State-Machine with CSS / Another approach to Angular SEO

CSS is the language developers love to hate. This is mostly because of the inconsistent syntax. But many fail to recognize the power of modern CSS. I’m here to give an example of CSS power that may very well blow your mind. As an additional bonus, this technique can be used to provide a better first load experience for Angular apps and can be a fix for its SEO problems that are often hard to fix without some sort of server setup.

Ladies and gentlemen, introducing :target

:target is a special pseudo selector in CSS that helps you change the style of something that is currently the target — the hash address in the URL matches its id. It sounds harder than it is so let me jump straight into an example, but first, a little recap about the hash address in browsers.

Consider, a static website, say, an FAQ page. All the questions are at top, followed by all the answers. You want users who...

Continue reading →

Replacing Eval with a Web Worker

Eval is Evil. Douglas Crockford has made that so popular that any competent Javascript developer thinks twice before actually using eval. But when do we even need to use eval?

Sometime we need to actually affect the webpage by evaluating a string. Those are cases when there is no way around eval. However, in most cases, eval is usually used for testing, and providing an interactive coding experience in the browser for tutorials, demos and the like.

I recently ran into the problem while developing Imprezzive. Imprezzive is a modern web-based presentation framework that has been tailored especially for real-time editing and collaboration and sharing code samples.

Screen Shot 2014-05-16 at 4.40.48 PM.png

One of the things I wanted to accomplish with Imprezzive was to provide a text editor within the slides where you could actually run the code and see the results. This is very useful for presenting code samples and showing...

Continue reading →