Forward 2 Notes - Part 1

Forward 2 at Hyatt Regency San Francisco

I had the opportunity to attend Forward 2, a conference dedicated to forward-looking, experimental JS and front-end technologies.

Overall, I thought it was a well organized conference with awesome speakers. I’m quite exhausted from trying to distill all the information, but there was a ton of useful and practical tidbits that I look forward to putting into practice.

Some of my highlights were:

  1. The Better Parts, by Douglas Crockford - Got me re-thinking about JavaScript best practices
  2. Love & Node, by Sarah Groff-Palermo - Inspirational talk that got me excited about hardware hacking again.
  3. We Will All Be Game Developers, by Hunter Loftis - Was completely blown away by Hunter Loftis’s crazy 3 week endeavor. Also learned why we should steal best practices from the game dev community.

What I also have here are the raw notes I took at the conference. Some of it might not make sense much, but I think I got the gist of most of the talks.

Here are my notes in order of talks I attended:

  1. Keynote by Karolina Szczur and Sarah Groff-Paermo
  2. The Better Parts, Douglas Crockford
  3. What the… JavaScript?, Kyle Simpson
  4. We Will All Be Game Programmers, Hunter Loftis
  5. No More Tools, Karolina Szczur
  6. Developing High Performance Websites and Modern Apps with JavaScript and HTML5, Doris Chen
  7. Love & Node, Sarah Groff-Palermo
  8. Developer Led Innovation, James Sacra
  9. Choosing a JavaScript Framework, Pam Selle
  10. Test-driven client-side apps, Pete Hodgson

This post will have notes on the first three. I will post the rest soon in Part 2. Enjoy!

Key Note Speaker 1: Karolina Szczur

How to build better communities

Key Take Away

Let’s make the community better by taking responsibility and owning it.

Key Note Speaker 2: Sarah Groff-Palermo

Love + Node @supersgp

Sarah is a designer and artist that loves tech. Her talk was about IoT and the imminent dooms day, e.g. forfeiting power and control.

Our Relationship with Hardware

Cocerns of IoT

Sarah’s theory




Key Take Away

If we make objects to be relatable, lovable and caring, maybe we won’t end up with dooms day.

The Better Parts, Douglas Crockford

Author of Javascript: The Good Parts

The Good Parts

Using programming languages more effectively, and using that experience to create and select better programming languages

“It seems that perfection is attained not when there is no more to add, but when there is nothing more to subtract” - This applies to programming languages. Removing the bad parts.

Principles of Good Parts

Arguments Against Good Parts

  1. “Just a matter of opinion.”” DC - No, its not if it makes you write better code
  2. “Every feature is an essential tool.””
  3. “I have a right to use every feature.”” DC - “I have the right to write crap” (lol). We have the responsibility to write good code
  4. “I need the freedom to express myself.”
  5. “I need to reduce my key strokes.” DC - We don’t spend the majority of time writing code, but rather in times where we felt like this: “Oh what have I done… why does this not work”. If we can make a program error free, we’ll have less to type because there’s less to fix.
  6. “There was a good reason why there is that feature”
  7. “I would ever make a mistake with a dangerous feature.””

The origin of triple equal - The guy who built double equal with coercion realized that double equal was bad, and so proposed a better solution, but it was turned down by committee due to legacy issues and instead was introduced as ===.

Danger Driven Development

Software development is difficult because of scheduling -

  1. The time it takes to write the code..
  2. The time it takes to make the code work right.

We want to make 2 small as possible. We should take the time to write correct code.

New Good Parts in ES6

Bad Part in ES6

Languages are better by making them smaller. Removing the imperfections.

Good Parts Reconsidered

Loops Reconsidered

The Next Language

Systems languages / Application languages

Application languages

Prototype Inheritance - memory conservation - Object.create (shallow copy) vs Object.copy - Confusion: own vs inhertied. - Retroactive heredity. Using __proto__. - Performance inhibiting.

JS is class free OOP, the best thing JS gave to the world.

How DC will make objects

function constructor (spec)  {
  let {member} = spec,
      {other}  = other_constructor (spec), // For inhertiance
      method = function () {
        // member, other, mehtod, spec

  return Object.freeze({ //Freezing so that the object is immutable.
      // All the other public methods

Ken’s Thoughts

Seems like FP and immutability is a big theme across this conference and the JS community. Are we seeing the next paradigm shift?

What The… Javascript, Kyle Simpson

Pulled out a lot of crazy and WTFs from Javascript - WAT video. WAT is nothing compared to what he found in the dark corners of the JS world.

Definition of WTF: not just funny, not a bug, not just ugly, not cross browser quirks, but inconsistent, incoherent, and unreasonable code that is part of the spec. Most WTFs come from the lack of understanding and the reasoning behind the WTF.

Kyle is not bashing TC39, and usually is in the unconventional camp of defending JS. but today he will defect and hate on the language.

Yes, there was a lot of swearing in this talk.


Number.MAX_VALUE > 0; // true;
Number.MIN_VALUE < 0; // false;
1 < 2 < 3 // true
3 > 2 > 1 // false due to coercion
42.toFixed(2); // error
42. toFixed(2); // error
42 .toFixed(2); // "42.00"
42 . toFixed(2); // "42.00"
42..toFixed(2); // "42.00"


// Not WTF because of coercion
[] == ![] // true
[] + {}; // "[object Object]"
{} + []; // 0
// Not WTF, but strageness due to historical reasons
Number("") // 0
Number(" ") // 0
Number("0"); // 0
Number("-0"); // -0

- 0; // -0
Number("- 0"); // error because its not a valid sytax.

Again, this is according to spec.

Now for crazy coercion - WTFs

Number("0.") // 0
Number(".0") // 0
Number(".") // NaN - WTF!

Number("0O0") // 0 - WTF

Different rules for undefined and null

Number(undefined) // NaN
Number(null)  // 0


String(null); // "null"
String([null]); // "" - the null just goes away... Wtf!

Symbols in ES6

s = Symbol("that's cool");

s; // Symbol (that's cool)

String(s); // Symbol (that's cool)

s + ""; // TypeError!  Wasn't JS all about guessing what you wanted to do?

The WTF is that Javascript is inconsistent in how it treats WTFs. In most cases, it tries to guess, but in other cases it just throws an error.

Switch default break

Specs say that default can be anywhere, but depending on where you put it, it can be WTF.

switch(42) {
  case 10:

In the above case, it goes to the default case, but because it has no break;, it loops through all options again.


try {
  return 2;
} finally {
  return 3;

The finally return overrides the return in the try. We lost 2!

Temporal Dead Zone. TDZ

TDZ: A variable can be in a special state.

  typeof a; // undefined
  typeof b; // TDZ error

  let b;

WTF because typeof should work with any kind of variable. Again, inconsistencies.


super is statically bound unlike this, which is dynamically bound. Using super doesn’t work with dynamicism which is what JS is all about. And so now we’re left in this weird state where we have both dynamic… and static… things and it’s a big WTF

Key Take Away

Javascript has its good parts, but there are bad WTFs that are inherent in the spec itself.


TIL, __proto__ is pronounced dunderproto!