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
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
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 2015⁄2016) 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
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.
YES, your site too can (and should) be accessible. Lessons learned from building FT.com
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:
- 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.
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.
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!”
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
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
Other talks I attended but have not much to say about
The Browser Hackers Guide To Instantly Loading Everything
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.