Impressions from 2017 - Day One

Here are the bits and pieces I learned from the talks I attended at the first day of JSConf 2017 in Berlin:

What’s new in Netscape Navigator 2.0

Marcin Szczepanski tried to build the TodoMVC app with the first JavaScript implementation that was available - in Netscape Navigator 2.0. There was no DOM to manipulate, you could only call document.write during the render call. What he came up with, was an application architecture based on HTML framesets with a “parent frame” that holds the application state and child frames that are re-loaded and thus re-rendered with the current state whenever an event occurs. A separation of state and rendering, with a unidirectional flow … wait a minute that’s Flux/Redux! What makes that feat even more awesome was that the only debugging and HTML code inspection tool at his disposal was alert().

I left this talk with the question if he ended up with a Flux architecture because that’s what’s state of the art (at least in 20152016) or because the Flux architecture is so easy to understand and implement and is so adaptable.

Immutable data structures for functional JS

This was a talk about the inner workings of immutable data structures: How can you change a single element in an immutable list, without having to copy the rest of the list, which is slow and consumes memory. The answer is to encapsulate your list in a Trie, which enables efficient replacement of single elements. Objects can also be represented, by hashing their object keys and treating the numeric hashes as list indices.

Two libraries that implement the data structures were presented, mori and immutable.js. Mori looked more attractive to me because the syntax is functional. Only some function names like conj turned me off, because they have a weird Lisp-y feel to them (mori is a port of a clojure library). immutable.js looked more JavaScript-like and object-oriented, but on a second look the object syntax feels misplaced: mylist.push('newelement') will not push the element to the list stored in the variable mylist, but rather return a new list with the new element. If you forget the assignment, your change is lost.

Unfortunately the talk was only 30 minutes, there was no time to actually demonstrate the benefits and examples of immutable data structures in real JavaScript code.

YES, your site too can (and should) be accessible. Lessons learned from building

The talk began with an explicit reminder that people with disabilities are not a small minority, but that 15% or more have some form of disability. In case of the Financial Times web site, that has a slightly older clientele, that percentage was even higher.

The good news is, that there are good accessibility checkers like pa11y that can even be integrated into your continuous integration system. They can be tuned to thresholds when you’re starting out, so you’re not overwhelmed by the hundreds of errors your site produces because you’ve have never paid attention to it.

The bad news is that the a11y checkers can only catch technical details, which only make up 20-30% of accessibility. But if you’re really determined to make your site accessible, it can be tested by real humans with various disabilities (seeing, hearing, motoric, cognitive) that can give you valuable feedback.

Pavlov’s Dog & Foucault’s Panopticon: Hacking My Anxiety With Open-Source Technology

Jessica Tran tried to cram three complex topics into one 30-minute presentation:

  • how she created a various JavaScript-based “self-surveillance and conditioning” tools that help her managing her anxiety:
    • A Biofeedback program that could measure her Heart Rate Variability and help her with her breathing exercises
    • “Anxiety triggers” (like sending offensive tweets to herself) as a form of confrontation therapy
    • regularly executed code that checks if she did her breathing exercises and threatens her with social embarrassment with she does not do them.
  • Mental health
  • Foucault’s theory of the Panopticon, power and conditioning. The important information I got from this part was a refresher of the idea that surveillance is not only bad because it can (and will) be abused but because the knowledge of being constantly surveilled affects our behavior and we start to self-censor and condition ourselves.

Building High-Quality JavaScript Tools

The topic of this talk was “We know you hate the Jest test framework but in the past two years we made it modular, faster and more feature-rich and have an automated tool that can convert all your tests to Jest syntax. Will you give Jest another try? Pretty please?” Although I like the minimalism and versatility of TAPE and my first encounter with Jest two years ago was rather painful, the talk was impressive enough that I might give Jest another chance. But I remain skeptical, especially until I know that my converted tests can be converted back to other test frameworks. Otherwise this smells of the 90’s Microsoft “embrace and extend” tactics.

The “jscodeshift” transpiling library that’s the basis for the “jest-codemods” test conversion tool looks interesting.

Keeping passwords safe in 2017

A roundup of the evolution of secure server-side password storage. From plaintext, to md5 hashes, salted hashes, password-based key derivation functions and hash functions especially designed for storing passwords. The gist is - you want to make cracking passwords literally “expensive”, i.e. needing lots of resources (CPU/GPU, memory, in the future maybe even storage or bandwidth). This left me with the question if expensive hashing functions could be used to launch denial of service attacks. After the talk I searched and found that other people had this question too.

At the end of the talk Emil Bay presented his secure-password package as the state of the art. While the Argon2 algorithm it uses might have won the password hashing competition, in my opinion it’s too new to use in a production system and there are some people who agree with me.

Sociolinguistics and the Javascript community: a love story

Some practical tips and examples for the question “How can we make our community more welcoming and friendly by looking at how we speak and present ourselves”. I’d love to link to this presentation, because it was so full of helpful content and I gave up on writing everything down because I wanted to focus my attention.

One thing that stuck with me was eliminating words like “simply”, “easy” and “just” from your instructions and description. Some days a go I saw a tweet with similar content, the idea stuck and I have caught myself writing those words already. Just because I know how to do something, other people might not, so don’t condescend by gloating how “easy” something is.

Another good idea was how to improve comments on positive code review messages: rather than writing “Ok” or “Looks fine to me”, try to find something you really like / would like to see more and comment on it, for example “Just the right level of abstraction”, “Thanks for adding all the type hints” or “I like how you encapsulated the file access, this will make adding different data sources easier in the future.”

While I was reflecting on the talk afterwards, I thought that when I’m not sure what to write, I could apply some nonviolent communication principles: How does the code make me feel? What basic needs does it fulfill? Order? Structure? Clarity? Security? Community? Support? How would you feel if someone commented “Wow, this looks exactly how I imagined it when I planned and postponed that feature. I’m so happy!”

A Brief History of Modularity

Every programmer knows modularity is important, few can explain rationally how to modularize and why. Separation of concerns - how do you know what the separate concerns are? Node has/had this obsession with “very small modules” that sometimes hurts the ecosystem - when things like the depublication of the left_pad module break the internet or when all the module boilerplate is bloating your compiled JavaScript file. Now there is the counter-tendency of writing every functionality yourself.

Modularity is about handling hierarchical levels of abstraction and because this method of thinking is like no other in the history of thinking, maybe there is not a rational, algorithmic way to do this, but a series of best practices, gut feeling, intuition and years of experience.

Making the Jump: How Desktop-Era Frameworks Can Thrive on Mobile

There are lots of different optimization profiles: Cheap smartphones with stable low-bandwidth connection, powerful smartphones with intermittent wifi connection, desktop computers with broadband connections and powerful CPUs. Too much focus on powerful smartphones (service workers, caching, lots of JavaScript for rendering) hurts performance for cheap smartphones. At the moment, the situation is a mess, but hopefully future frameworks can taylor the performance behavior closer to the hardware and act as a kind of compiler that adapts high-level JavaScript code to the hardware it finds.

Other talks I attended but have not much to say about

The Browser Hackers Guide To Instantly Loading Everything

The gist: Don’t load all your javascript at once, only load what’s needed and load the rest in the background. HTTP 2.0 is no panacea. Test all the loading times in dev tools and use real devices for mobile testing. Use the coverage reports in dev tools to see what parts of your JavaScript and CSS are really loaded.

This was about the storage of the private keys of server certificates. Is there only one place where they are stored or are there copies stored on different servers? By measuring the TLS handshake delay you can try to guess the distance to the server that holds the private keys. Some of the findings and the conclusion of the talk were not very convincing to me, but I’m not a security professional.

Can You Read Me? Creative JavaScript to Make Computer Science Fun

From the description I expected more of a “how to” of teaching computer science in a better way. Instead, the talk was about using Javascript to detect file types and their content. Which is a fun activity and I learned about how to handle input streams in Javascript and use headless Chrome as a command line utility to convert audio into graphics. But all those activities need some previous programming knowledge to be successful, so my expectation for the talk was not met.