CascadiaFest: Browser JS Afternoon Part 2 Notes

Here is the last part of CascadiaJS Browser Day.

Tessa Thornton: Components are the future of the web: it’s going to be okay

Web Apps started with just HTML, but then JavaScript grew up, AJAX was introduced. Separation of concerns: HTML for content, JavaScript for behaviour, CSS for presentation and called it best practices. Decided best practices were killing us because not feasible in a lot of situations.

HTML doesn’t always represent content e.g. select list options pulled using JS, range input field.

Declarative API: declarative specifies what the desired result is and leaves the implementation up to something else (e.g. SQL uses algorithm, but you don’t decide which algorithm) vs. imperative which specific the steps to achieve desired result

HTML has declarative APIs e.g. range input field.

We think our HTML should be dumb, but then we have to do all sorts of things in JS to make up for it.

Declarative are reusable, composable. Web components in combination with polymer.

JavaScript in the future: back and forth between wiring together components and tweaking implementations

Limits to declarative programming: need to tweak implementations. Up side, declarative API, meaningful HTML , encapsulation, reusability, composability, choose your components.

Coming whether you like it or not.

Andrei Kashcha: A story of graphs, package managers, and one million vertices

Every visualization starts with requesting an animation frame, which is just a browser API. It takes one unction and calls it again and again.

Using 3GS, which is built on top of WebGL, but will hide it behind an interface.

Code example with particles.

How do you render graphs on the screen?

If render nodes at random, you end up with a mess. Hard to understand because there’s no structure.

Several methods:

  • reduce amount of intersections
  • connection between two nodes have same strength, should have the same length
  • detect symmetry

How do you combine all of these? Nature has that answer.

If pretend every node is a charge particle, they will repel each other. Pretend every connection is a particle spring. These two competing forces pull them apart and on the other hand make sure they don’t fly too far away.

How to we make sure that it still renders quickly?

Put it on the server will calculate the forces for each particle. Save the results for each note with the coordinate.

You can render really, really large graphs.

Using Bower to map package dependencies. Only showed dots, didn’t draw the edges, because it will otherwise will be beautiful but useless.

What if only render the links who’s length is only smaller than 200px or 100 px?

Can begin to explore clusters of dependencies.


Try it:

Works even with 200,000 packages.

It is Fast

Runs at ~60 FPS.

Can deal with large sets

Visualizing GitHub users 1.1+ million nodes, about 20MB of data.

Ashley Williams: If you wish to learn ES6/2015 from scratch, you must first invent the universe


I like to think about thinking, especially the type of thinking that happens when people write code.


“The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programming.” Edsger W. Dijkstra

When programming, you’re abstracting.

“Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by abstracting ou the varying parts. ” – Benjamin C. Pierce

“… immaterial to the problem being solved.” – Wikipedia

What problem are we trying to solve with JavaScript?

For beginners, iteration is hard. Many say that programs should be written for people to read, and only for machines to execute. Taught iteration in a language that they did not understand. JavaScript version exposes the underlining concepts of iteration in its syntax (vs. Ruby where it was abstracted).

“The real problem in speech is not precise language. The problem is clear language… ”

Where Should We Begin?

There are things in our languages now that will go from “draw two circles, draw the rest of the owl.”

Abstraction can be more efficient, but being more explicit means more maintenance.

Human beings are amazing pattern recognizers. See the patterns, give them names. This is abstraction.

We need to be careful about the abstraction we makes, because it will cause big problems.

JavaScript has been a delightful beginner programming language because it lacked abstraction, but that’s all about to change.


“ECMAScript syntax is relaxed…”

What is JavaScript trying to solve?

Objects are not fundamentally class-based. You might not need class syntax.

“… The practical question is how wrong do they have to be to not be useful.”

strucutre, heaviour, and state are all inherited.

Classes are normally thought of as blueprints. JavaScript classes are model homes. You can leave them empty but someone can move in.

What even is a class? In JavaScript, we may be trying to do too much.

Teach Programming Concepts, not Language Features or Syntax

JavaScript is a teaching language, and will be the introductory language to a whole generation of programmers.

Programming languages are tools. There isn’t a bad language, just a good programming language for the job. Start with a simple language, and then extend the language gradually.

The Creative Extension Principle

Implement things only when we need to, not just because we foresee it.

Think About This

Are we programming yet? What do we mean by programming? If what we mean by programming is really this awesome feeling of abstraction, how much time do we spend doing that instead of typing into our terminal?

Need to think about what our paradigms our.

We have an awesome opportunity to think about how we extend JavaScript.

Let’s reconsider our ontology, do it often, and stay beginners.

End of the Day

Time for a quick nap perhaps before dinner.
baby bengals sleeping together
Thanks for joining today and come back tomorrow for CascadiaJS Server day!

Published by


A librarian learning the ways of technology, accessibility, metadata, and people

Leave a Comment

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s