CascadiaFest: Browser JS Morning Part 1 Notes

Our second day at CascadiaFest is Browser side JS.

Jana Beck: Data Visualization on the Web

Talk today about all the things I wish somebody had told me before embarking on the project of writing a large data visualization library.

Most common toolset: D3: Data-Driven Documents + SVG

Basics & Best Practices

Why D3 + SVG? D3 binds data to DOM elements.

Basically three sections: enter, updates, and selections = core functionality

To become proficient at data viz, need to become very familiar with SVG

Using the group element: organization, hooks for interaction, performance implications.

Orders matter a lot, so you have to inspect the console a lot.

Groups provide hooks for interactions, and in lots of different ways. Also affects performance.

Profiling Performance Problems

3 ways:

  1. timers (around main render method using console.time and console.timeEnd)
  2. framerate meter (in Chrome)
  3. record a timeline

Can use a FPS meter open (Chrome developer tools) to profile a certain interaction, which can significantly drop when plotting more things. Good for ballparking but will not good to precision. Anything above 40 is pretty good, where users won’t generally notice. 30-40 is meh, notice some lag. Under 30, people will really notice.

Timeline Tool is good for finding the code responsible for your performance problem. If your code base is complex, these different modules have different expectations. Can set up frames and colour coded. Always zoom into the yllow bars to find potential JavaScript bottlenecks. Width represents time, look for things that don’t make sense. Note: Divisions into separate horizontal blocks often not significant.

Example: Data generations is taking 3-4 times longer than the drawing, which is really slow. Want to look into the cal stack for the functions that are being called.

Improving and Solving Performance Problems

Two general strategies:

  1. Render browser native whenever possible.
  2. Try to change the DOM as little as possible.

Why browser-native?

  • better performance now
  • and better performance in the future

Wise Words

“The browser was not designed to be constantly creating and throwing out DOM nodes.” – Pete Hunt

How to avoid changing the DOM

  • data aggregation or smoothing
  • reusing DOM nodes


  • crossfilter: first choice for filtering helper, provides a wider variety of fucntionality including numerical querying
  • PourOver: client-side faceted search, works well for categorical data

Take Aways

  • learn SVG
  • strategize


Helen V. Holmes: JavaScript and Prototypal Inheritance: Why Is It So Complicated?

Story about grandfather to learn everything about photography after getting a camera. That’s how he learned, but grandmother just wanted enough information to take pictures i.e. how the buttons work.

This can be really overwhelming and frustrating.

Everyone learns differently.

Inheritance is one of the most complicated features. Want to cover the topic in both ways.

The name and the syntax in order to drive adoption, because looked and felt familiar.

Unfortunately, one of the biggest assumptions is that inheritance will work the same way that it does in Java or C++ but it doesn’t.

What is prototypal inheritance?

It’s important to know that everything in JavaScript is an object, the object have links together and the relationships, which are called prototypes, and this is true until you reach null.

Example: 3 users: user, admin, power user (can delete everything). Code example in which create user, admin, and create power user based on user and admin and additional variables (abilities).

Some argue that classical inheritance is just a subset of prototypal inheritance.

Classes are an analogy with our work week, they have a routine where instances act the same way, we know they’re properties at any point and we know what they’re going to doing when. Prototypal inheritance can be all over the place.

Check out the MDN article, and Eric Elliot.

Take Away

Which approach to use is really about what’s most appropriate.

Expertise comes in different shapes and sizes.

Dave Justice: Making Waves: Digital Signal Processing in the Browser

DSP definition

the use of mathematics to modify an information signal.

Get Data:

  • get data about the signal (e.g. get amplitude)
  • get data about the environment (e.g. sonar)

Modify Signal
* output a modified version of the signal (reverb effect pedal)
* produce a new signal *synthesize speech from the text signal)

More terms
* Sinusoid (just a sine wave): peaks: top points, troughs: lower point
* Amplitude (loudness over time)
* Magnitude (amplitude minus the negative values)
* Frequency: rate of repetition of vents over time. Sounds like the pitch is changing.
* Fourier Series: any waveform is just a sum of sine waves.

With digital, trying to keep adding to it or take it apart.

  • Time domain – a graph of samples over time. A bunch of sine waves mixed together.
  • Frequency domain – graph of magnitude of frequencies.
  • Discrete Fourier transform – converts time-domain samples into frequency domain data.
    > f = ancos(nx) + bnsin(nx)
  • Web Audio API – native browser API for synthesizing modifying, and scheduling sounds.
  • Audio Graph – chain of nodes by which your audio signal passes through.

Firefox released Web Audio Inspector

Analyser Node – runs a FFT over our signal aloowing us to get data in the time or frequency domain. Goes in and samples the signal in real time. Connect it to the processor node.

Script Processor Node allows us to process audio in real time.

Visualizing our Signal in 2D: real-time time domain, real-time frequency domain, waveform time domain.

Audio Worker node: WebWorker with an audioContext: similar to webworker, runs own process, replaces scriptProcessorNode, create custom nodes, runs your JS, more possibilities for DSP.

Using Bitcrusher webworker, can load local variables and on audio processes in a separate file. The shim allows for reusable effects and visualization.

Community Effort
* web-audio-modules
* audio-graph-editor
* #webaudio, #boringengineering on freenode

Break Time

There is no snow here, so you’re unlikely to see any least weasels, but maybe you’ll see something else cute.
least weasel

Author: Cynthia

Technologist, Librarian, Metadata and Technical Services expert, Educator, Mentor, Web Developer, UXer, Accessibility Advocate, Documentarian

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 )

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: