We selected 4 best answers of September on Stack Overflow that are related to Web Development.

Should I inline all CSS files programmatically to optimize page load speed?

Asked by Shaun Luttin. The best answer (56 votes) supports our understanding that generally inlining is bad for the web page performance because it disables browser caching of the styles:

Inlining all your CSS means it cannot be cached, so every single page load will contain all of the CSS required, and when you are using large libraries that can really be a lot of wasted bandwidth. For example, Bootstrap is around 120k. Note the Google link you shared specifies the following (emphasis mine):

says [DavidG](http://stackoverflow.com/users/1663001/davidg)

However, for small CSS files it may make sense to inline them in html. But because amount of styles tends to grow inlining should really be the last resort.

The topic starter wanted to inline styles in order to reduce the number of network round trips. It’s worth mentioning that with the advancement of HTTP/2 the number of round trips will become less and less of an issue. So in the long-term serving your styles in a separate file is more beneficial.

Javascript return with colon?

Sean who is just learning Javascript encountered the following code structure:

var Test = (function () {

  function func1() {
      //do something.....
  }

  function func2() {
      //do something.....
  }

  function func3() {
      //do something.....
  }

  return {
      func1: func1,
      func2: func2,
      func3: func3
  };

})();

As the best answer(42 votes) points out, it’s a Revealing Module Pattern:

The main idea behind the pattern is avoiding evil global variables. This looks similar to IIFE except an object is returned instead of function. The variables/methods defined inside the IIFE are private to the function. To access any variable/method inside the IIFE, it needs to be added in the returned object and then it can be accessed from outside of IIFE. This pattern takes advantage of closures, so the variables/methods defined inside the IIFE are accessible even after the object is returned.

says [Tushar](http://stackoverflow.com/users/2025923/tushar)

Thus, what’s returned by the IIFE is what the module exposes to the outside. Other stuff inside the IIFE is private.

We hope that ES6 modules will soon be prevailing so one will not have to build structures like in the question. An ES6 equivalent for this is:

//es6-module.js

export function func1() {
    //do something.....
}

export function func2() {
    //do something.....
}

export function func3() {
    //do something.....
}

Getting NaN inconsistently mapping parseInt

ReferentiallySeethru came up with the following code:

var arr = new Array(32).join(0).split('').map(parseInt)
// prints [0, NaN, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
console.dir(arr)

That prints NaN without noticeable reasons. The best answer(26 votes) explains:

That's because the function passed to map will be called with three arguments:

<br>
1. The current array item <br>
2. The index of that item <br>
3. The whole array<br>

In this case, that function is parseInt, which only uses two arguments:

<br>
1. The string to be parsed<br>
2. The radix used to parse the string<br>
3. Additional arguments will be ignored.<br>
<br>

Therefore, for the 2nd item in the array (i.e. index 1), the call will be

```js
  parseInt("0", 1, ignoredArray)
```. When the radix is 1, NaN is returned.

says [Oriol](http://stackoverflow.com/users/1529630/oriol)

Well, let’s just check the API docs before raising a question :-) Nevertheless, the answer is full of insights about how the parseInt function works.

Two Date.now() in one object declaration

What should happen? - asks Randomblue:

var o = {a:Date.now(), b:Date.now()};

Will o.a === o.b?

The answer is No (21 votes). Well, it’s not just No. The answer refers to the corresponding specification:

When we look at the spec for Date.now (15.9.4.4), it simply says that it returns

the time value designating the UTC date and time of the occurrence of the call to now

which provides no guarantees to two calls ever returning the same value. From what I can tell, the spec specifies that Date objects will have millisecond precision (15.9.1.1) but makes no guarantees as to accuracy.

It is likely that two calls in the same line will probably return the same time, by virtue of the underlying timer being imprecise and the two occurring within the same tick, but the spec does not appear to specify that.

says [ssube](http://stackoverflow.com/users/129032/ssube)

The next answer actually provides a way to test how often two dates will be equal:

var test = new Array();
for(var i=0; i<40000; i++){
  test.push({a:Date.now(), b:Date.now()});
}
for(var i=0 ; i<test.length; i++){
  if(test[i].a != test[i].b){
     console.warn('a & b !=');
  }
}

On my machine, it’s approximately 10 / 40000. So let’s not rely on this :-)

We hope we all learned something new from these answers. Thanks for reading and till the next time!