Forward 2 Notes - Part 1

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

• Building better communities is inseparably intertwined with building a better self
• Practice empathy and gratitude.
• Look around. You don’t need street credit or be famous to be able to help someone
• Communicate compassionately
• Life’s most persistent and urgent question is - What are you doing for others? This question is important.
• Community is a group responsibility. There isn’t one person owning and managing the community. Making a better community is about mutual work.

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

• How and why we engage with hardware, internet of things. We can make prototypes of lovable relatable objects
• If researchers figure out what technology can do, artists can reveal how and ask what its for
• Art gets recognized as art by people standing up and saying as many times as they have to, i.e I made this, and it matters.
• Sarah showed two gifs of kill bot and beach both. We have to make good decisions so that we make a world of beach bots (dancing) and not kill bots
• We need to think about our relationship with objects, how we can love them.

Cocerns of IoT

• IoT == distopia
• $1.4 biliion dollars in bio sensing, 60 million fitness trackers. Are we giving away our privacy? Are we giving too much power to the goverment?
• Internet of things raises substantial concerns about how we can keep control of our lives.

Sarah’s theory

• We can make things networked and controllable, and monitored, but what are we going to do it …. for?
• What we can make objects be loyal, have sentiment. What if objects were assistive technology (chairs that hug back)
• We might actually being saving the world by doing this

Relatables

• Allow objects to speak, have character, and be lovable
• Not only do objects that present information in a way that makes you act, but they talk to you. For example, a milk carton that speaks about the cows and how happy the cows are …
• Instead of creating monsters like Frankenstein, we should create relatables that we can love

Anxeities

• Technophobia - lack of understanding of technology. Deep concerns. By encouraging people to see objects as lovable, we can get them to understand technology
• Anthromorphism - Unfulfilling promises. We might be expecting a level of personal connection with robots, but they might not be able to deliver and so we feel like we are let down.
• Corporate overreach. Are we giving too much power away? We now have surveillance tools for everything. From pets, to kids, to even yourself. Pavlok shocks you if you are doing something you don’t like.

Examples

• Sarah showed examples of some relatables
• Neo-Neglect - Books that tell you when they feel lonely. If the book wasn’t opened and read for a while, it “dies”. Made by putting copper wires inside books that detect when a book gets closed / open.

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

• if a feature is sometimes usable and sometimes dangerous and if there is a better option then always use the better options….
• We are not paid to use every feature of the language, We are paid to write programs that work well and are free of error

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

• Proper tail calls - JS becomes a real functional programming language. DC’s most favorite feature
• Ellipsis …. aka… rest, aka… spread operator
• Modules. Much better than the crappy require stuff
• Let. let is the new var. A lot of people come from Java and the syntax between Java and JS are similar. BUT this causes confusion because the way JS works is different than Java. Using let removes the confusion.
• Weak maps. Its the way objects should always work. It was a mistake to make all keys a string. Now with weak maps, keys can be anything. They introduced weak maps because changing maps would break legacy code…
• DC does not think generators are not worth the effort

Bad Part in ES6

• CLASSES. Java people wanted classes, but what ES6 gives them is a “class” that is just syntactic sugar. The way to think in JS is to think in FP.
• (name) => {id: name}, for those people who hate to write ‘function’,… because its too much to type.

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

Good Parts Reconsidered

• I stopped using new years ago. Use Object.create instead.
• Now I stopped using Object.create.
• I have stopped using this. ADSafe.org. Removing this makes things much easier and safer. The problem with this is that it can be bound to the window object, which compromises security. DC’s solution is to make this illegal.
• I stopped using null. null and undefined are not the same. undefined is better because it’s the value that the language uses. Theres an error with typeof with null, which returns Object, which is wrong.
• I stopped using falsiness. To check if a value is undefined, I value === undefined

Loops Reconsidered

• I don’t use for. I now use array.forEach and its many sisters.
• I don’t use for in. I now use Object.keys(object).forEach.
• With ES6, I will stop using while because we’ll have proper tail recursion call. No longer a penalty for running recursion.

The Next Language

• If JS is the last language, that will be really sad.
• Programmers are as emotional and irrational as normal people. It took a generation to agree that high level languages were a good idea. I took a generation to agree that goto was a bad idea. It took a generation to agree that objects were a good idea. I took two generations to agree that landbas were a good idea.
• Once stuff gets in the brain wrong, it rarely gets fixed. So we need to wait a whole generation for it to die and then get a consensus on the good things.
• Things get discovered and only 20 years later, we move on.

Systems languages / Application languages

• System languages - low level stuff. C. Go.
• Application languages - Everything else. We need more innovation in both sectors.

Application languages

• Classical inheritance vs Prototypal inheritance. Most are class based Class. The Prototype has a lot of advantages over class.
• With classes, you need to build a classification taxonomy. It is built during the time when we have the least understanding of the system. So we invariably get it wrong. We then build the application with a broken hierarchy and taxonomy, which creates lots of friction. Now we have to rip things apart and get things right, and its scary. That doesn’t happen with prototypes.

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.
      method,
      other
      // 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

• Sarte: “Hell is other people.”
• Devs: “hell is other people’s code”
• Kyle: “Hell is not understanding my own code.”

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

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.

Warmups

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"

Coercion

• Kyle: Coercion… is awesome…! (He’s defending coercion here, not being sarcastic)
• If you read the spec, the above is rational because it follows the spec and makes sense.
• Javascript tries to do a best guess of what you were trying to do

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

Strings

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) {
  default:
    console.log("")
  case 10:
    console.log("10");
    break;
}

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

Finally

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.

“Class”es

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.

WTF!

TIL, __proto__ is pronounced dunderproto!