Timothy Miller

Timothy Miller / Published

NEJSConf — 2019!

I attended the final NEJSConf in 2019, "The Good Life Aquatic". There were a lot of good talks there that day, and I learned a lot. Below are my notes from the event.

Pika: Reimagining the Registry #

Fred K Schott - @pikapkg #

https://www.pika.dev

Fred works on Pika, which is kind of a webpack replacement.

Pika has a whole suite of useful tools associated with it: a super efficient CDN, an in-browser REPL to test modules, and it's generally a more efficient package installer than NPM.

Fred says any project that uses NPM should have a bundle analysis run at some point, many times there are small wins that will drastically speed a project up (or you might end up wanting to switch to Pika)

@pika/web — a tool to run npm packages in the browser.

No recompilation step with @pika/web, it compiles once and then the files exist.

You can still have a build step with pika/web, but you don't need it.

CSZ is a CSS package that looks very odd, but interesting.

How I Ended up Automating My Curtains and Shouting at My Laptop #

Luke Bonaccorsi — @codefoodpixels #

https://lukeb.co.uk

A talk about automation for homes.

Luke built a bot named Woodhouse. He would have gone with Jarvis, but he knew this bot wouldn't be quite that cool, so he went with a more lame waiter.

Smart homes are fun because it's real life, not digital things.

Luke used a servo to automate his curtains, and a "smart outlet" for lamps.

MongooseOS running on something like an ESP8266 (like an arduino) is the brains for the curtains (moddable, espruino, tessel).

Woodhouse has voice control, which uses "Snowboy" and Google Speech Control for voice.

Storytelling and Tech #

Ash Banaszek – @ashbzak #

linkedin.com/in/ashmb

Everyone Has a Story #

Aspects of a good story:

  • Characters (Human or tech, real or fictional)
  • Setting (Where, constraints, background)
  • Problem (what went wrong?)
  • Complication (what makes it worse?)
  • Resolution (What happened, how are things fixed?)
  • Moral (Point of the story, the larger picture)

We crave and understand stories. They hijack our brains and force us to remember.

How to tell a story: write out the story. Cut the fluff. Emphasize your tie-ins. Reinforce with images. (any child will tell you a story is better with pictures)

Metaphors and Similes #

  • Metaphors translate for you.
  • "You can use an eraser on the drafting table or a sledge hammer on the construction site." - Frank Lloyd Wright

Ash often uses construction as a metaphor for software development, because it's easier for people to understand, and picture. E.g. "If you take the wrong piece of code out, the building could collapse."

Zoom out. Make metaphors relatable. Use common, every day knowledge.

For example:

  • “Firefighters are more exciting than fire marshals.” Many software catastrophes happen because people prefer the "action" of fighting fires, rather than less exciting fire prevention.

  • The problem and moral: you can't be the hero if you started the fire.

  • This story uses relatable characters, and striking visuals (firefighter, fire marshal, burning house)

  • Imagine that you're driving down the road.

  • Vehicle in front of you stops. What does ignoring mean? An accident. What does perceiving mean? Swerving around them. What does listening mean? Stopping to see if they need help, or if there are deer, or something like that.

  • You always suffer when ignoring. Perceiving is a start, but doesn't help as much as it could. Perceiving is taking charge.

Sometimes we focus on what's wrong with a legacy system, to the point where we ignore all the good points. People tend to hate redesigns because you take away your user's mastery of a clunky system.

Humor's purpose: to deflect. To relate. To keep attention. To make it memorable. To delight.

Humor needs to be infrequent. Timely. Short. To be humorous:

  • Timing and delivery is important: allow for pauses, for reactions.
  • Enunciate.
  • Vary your speed.
  • Choose your tone carefully.
  • Work on callbacks.
  • Watch your beats.

Stories, punchlines, puns, acronyms, memes, images, callbacks.

"Oops" moments can help push a point home.

"I didn't have time to write a short letter, so I wrote a long one instead." - Mark Twain

  • Start on time
  • Don't apologize, roll with the punches
  • Don't merely read your slides
  • Vary your tone
  • Use supportive movement
  • Slides support, not define (you can use props, or a single image)

At the end of your talk, tell them what you told them. Say "this is what I told you". Leave them with a call to action.

Everyone has a story. Write it out, then refine it. Use humor wisely. Call to action.

Read Nancy Duarty, slide:ology, and resonate.

Delicious JavaScript: Delectable Explanations of the Power of JS #

Adrienne Tacke — @adriennetacke #

Short and sweet talk about three functional JavaScript methods: filter, map, reduce.

Responsible JavaScript #

Jeremy Wagner – @malchata #

Based on articles he wrote for A List Apart.

"Sphexishness" - deterministic, preprogrammed (of animal behavior). "Sphex" is a species of wasps. These wasps are like robots, if you move their food away from their hole, they will endlessly retrieve without eating that food.

Web developers are also sphexish, in that we have tools that we automatically reach for whenever we start a new project (React is the current fan-favorite. Babel is also a big one).

10% of websites send over 1meg of JavaScript (compressed, maybe 3x that once uncompressed), based on data from Web Archiver. On Macs and iPhones that may not be a problem, but on cheaper devices it can take forever. Using the web can be incredibly tiresome for some—specifically less wealthy—people.

Many of the best video games are less than 1meg. Their constraints were fixed to the hardware, so they had to figure out how to make it work. Our constraints are far from fixed.

How to We Create Anti-spexishness? #

"Paint the Picture, Not the Frame: How Browsers Provide Everything Users Need"

Many frameworks make it too easy to make egregious mistakes, like creating a form in React using divs and spans, rather than forms and labels.

Side note: Jeremy recommends allowing browsers to validate your forms, and then check them on the server side. No more heavy libraries to validate forms.

SPAs (single page applications) break all sorts of built in browser functionality. Not recommended unless you want to do a TON of work.

Server side rendering loses some snappiness vs. SPAs, but it's expected, and doesn't break browser functionality.

Prefetching can help regain some of that snappiness, without the downsides of SPAs. Example:

<link rel="prefetch" href="/products/snes-console">

This does have issues though, Quicklink is a tiny framework by Google to fix some of the issues with prefetching. Prefetching allows you to make your website snappier by preloading things like navigation.

Babel is valuable, but can add a lot of bloat. We would all benefit if we transpiled less.

Default parameters are transpiled badly in babel. Using them adds a lot of bloat to your code. Classes are also complicated to transpile, not a great idea to do those yet, unless you can drop support for older browsers.

Babel "loose transforms" can also be useful for making builds smaller. Also, useBuiltIns: "usage" is the way to go when configuring Babel.

Those two things alone can remove more than 50% of your bundle size.

“Differential Serving”: Serving One or Two Bundles to the User Depending on the Power of Their Browser. #

<script type="module" src="/js/app.mjs"></script>
<script nomodule defer src="/js/app.js"></script>

The "nomodule" script won't be downloaded by modern browsers. This can reduce scripts for modern browsers by 75%. More info on jeremy.codes.

Be Accommodating: #

One third of Americans still have dial-up speeds when it comes to internet.

Client Hints can help bridge this divide. There are at least ten client hints that we can use. The most useful according to J:

  • RTT: Round Trip Time
  • Downlink: the approximate downstream speed of the user's connection
  • Etc: Effective connection type ("4g", "3g", "2g")

"Accept-CH" and "Accept-CH-Lifetime" is a header value we can set, and then we can get this info through server data ($_SERVER["HTTP_ECT"])

We should embrace Adaptive Performance. For example, we can show a single image instead of a carousel if someone is on a slower network.

"Adapting to Users with Client Hints" by Jeremy is an article with more details.

Our first job should be to figure out what people want. Then we need to work backward from there, don't get in people's way, allow them the information they need. This is how we help people, rather than capitalizing on them.

Our tools have a direct impact on our users. Unlike a mechanic, where we don't see and we aren't effected by their tools, end users are very effected by our tools.

Our experience as developers is important, but it's never more important than the user's experience. And if our tools are undermining our users, it's time to reevaluate.

History of Video on the Web #

Sebastian Golasch – @asciidisco #

Apple invented Quicktime in 1990. Not used on the web until ’93, but that's where all web video started. Quicktime even supported live streaming way back in ’95, at a very low resolution.

Video always used to be an embedded media player, not supported by the browser.

In ’97, shockwave player was released. It wasn't made for video originally: video was added in 2002. It was a very efficient, and low quality videos were very small, a 2 minute video could fit on a floppy disk.

2007: Opera proposed a video tag for the browser, and that is what turned into the video tag we use today.

From the beginning people have wanted to prevent people from downloading videos if the browser doesn't support streaming. This is not possible with HTML5 video, it is an innately open box.

This is where DRM comes in. DRM is what protects Netflix and other video streaming vendors. It can be:

  • User specific encryption
  • Content specific encryption
  • Rights definition and restriction enforcement
  • Revocation and renewal
  • They can track stolen videos down to the very account that downloaded it
  • MacOS also has DRM baked into the system, to make it easier for these companies

Many people have their fingers in DRM. There is a ton of money behind its development.

TVs are treated much more freely than laptops. TVs get 4k video more easily than laptops, because laptops require a lot more DRM in order to make the streaming company happy. The TV is inherently a black box, so streaming platforms trust it more.

"Hardware assisted" DRM is baked into the operating system, and if your system supports it you're much more likely to get HD video with less data transmitted.

"Widevine" is Chrome/Firefox's CDM system. Safari uses "FairPlay", which is their own CD< system. IE uses "PlayReady", developed by Microsoft. All of these systems are similar.

CDM is a Content Decryption Module. It can decrypt, it can decrypt and decode, it can decrypt, decode, and render on hardware (GPU).

How is this applicable?

On Netflix, only three requests are essential: the manifest, the license, and video chunks (huge guid)

How would we code a Netflix player that uses DRM?

We have to use the EME "Encrypted Media Extensions"—the JavaScript API that interfaces with the CDM, Key System, License Manager, etc.

First we have to create and apply keys to our video player. Then we need to create a session, using our media keys. Then we have to generate a request, ("cenc" request) which generates our giant guid. Then we need to request a license from our server, which uses an HTTP request.

MSE: "Media Source Extensions". A browser api that allows us to access the interface of the video element. This is how we can stream in chunks.

Manifest: our manifest pieces everything together. It specifies the DRM system, and spells out the session ID, and what resolution and other settings that the video needs.

The manifest also enables "Adaptive Bitrate Switching".

This is not secure enough for Netflix though. Netflix uses a "Message Security Layer" that they invited, to add even more DRM on top of DRM.

Netflix Plugin for Kodi 18 (plugin.video.netflix) is a plugin developed by this speaker that enables Netflix streaming on whatever you want, even a Raspberry PI.

"So in summary, it is important to support EME as providing a relatively safe online environment in which to watch a movie, as well as the most convenient, and one which makes it a part of the interconnected discourse of humanity." - Tim Berners Lee

EFF is not happy about DRM on the open web, and they want to continue fighting the US government about it, but they haven't made any progress in recent history.

Web Assembly: The Future of JS and a Multi-Language Web #

Kas Perch – @nodebotanist #

Slides

Kas is a developer at CloudFlare. Robotics Author/Addict.

What is WebAssembly? #

WebAssembly is not: a programming language. The death of JS. Or something you can ignore cause it's going to go away.

WebAssembly is:

  • a compilation target for other languages to compile to, as well as a language itself
  • An augmentation of the abilities of JS by allowing other languages to operate in the browser (compiling C# to JS?)
  • It's magic.

You write code in other languages (Rust, C/C++, Go, C#, PHP!), and they compile to WebAssembly.

Why:

  • NEW ERA for the web
  • WebAssembly is comparable to bringing the power of JVM into the browser, creating an evolution of the web as we know it.

Pre ajax: The browsers did html, css, and autoplaying mp3s. That was it.

Post ajax: We could actually build web apps, with data flowing in and out of the browser.

Post web assembly: Service workers, serverless servers running functions, ajax, a coherent application running in the browser with no loading or reloading.

Why does this matter?

  • Augmenting JS at its not-so-strong points (Kas says JS is the cockroach of languages. It's constantly evolving to prevent its own death!)
  • We don't have to rewrite entire codebases to use them on the web
  • Fewer calls to the server, because we have more compute power in the browser

How Do We Augment JS? #

If you're running anything that relies on mathematical numerical accuracy or speed that meant, until now, another AJAX call to have another language do all the math. With WebAssembly, we can do this in the browser, using Rust or whatever else we want. Dealing with numbers in JS is not so fun, so WebAssembly allows you to use more suitable languages for that.

WebAssembly is all about using the right tool for the right job. JS is really good at DOM manipulation and stuff like that, other languages are better at math and stuff like that.

WebAssembly makes JS better by allowing you to polyfill for JS's weaknesses.

Some people are trying to kill JS, and replace it with WASM. Speaker doesn't think that's likely to happen, but it wouldn't necessarily be a bad thing.

ImageMagik works with WASM. WASM would allow you to build an image editor in browser that works with no server!

The fact that you can use ImageMagik is amazing. You don't have to port it to JS, you use it in the browser.

WASM works on Node >= 8.0.0.

WASM are precompiled binaries, so they're portable to any platform that runs node.js. No compilation required. WASM will work.

"Everyone wants to [deprecate] node-gyp and WebAssembly would [eventually] allow us to do this." -Laurie Voss

Cloudflare Workers are wasm modules.

If you want to learn Rust, you can read the Rust Book and the Rust-wasm Book.

Try WebAssembly. Try some Rust. Both future forward languages that will probably last a long time.

Generate Art Everywhere (with Web components) and Fast (with Web workers) #

Trent Willis — @TrentMWillis #

What if we embedded art in existing user experiences?

Maybe with web components? <generate-art></generate-art>

What if we used Service Workers and an offscreen canvas so it doesn't impact performance?

What type of art should we create with JS? Generative Art. Generative art is created by a "non-human system".

This talk is focused on "Algorithmic Computer Art". JavaScript is well suited for this type of art.

There are two ways to do this. The manual approach, using <canvas/> and web apis, which is the lowest level method of creating computer art.

Or we can use libraries built on top of those apis, like p5.js, d3.js, chromata. You get less flexibility, but you write less code.

Most art on the web uses both approaches, as do the demos in this talk.

Demo #1 #

First demo starts with a canvas, as well as a script tag.

Lots of artistic principles help us create pleasing art:

  • Balance
  • Contrast
  • Emphasis
  • Movement (rhythm)
  • Proportion
  • Repetition
  • Variety (unity)
  • Also: Response, since this is an interactive system.

Demo #2 #

He used p5 and p5.sound for this, because it's easier than using the native methods. Processing is based on making programming more accessible to artists, so it is the perfect language for this.

Web Components are a perfect fit for this kind of thing, because then reusing this artwork is a simple as typing one element.

class GenerateArt extends HTMLElement {
    constructor() {
        super();

        const shadowDOM = this.attachShadow({mode: 'closed'});
        shadowDOM.innerHTML = markupForGenerateArtComponent;

        this.setDimensions(
            shadowDOM,
            this.getAttribute('width'),
            this.getAttribute('height')
        );
        this.setupGenerateArtButton(shadowDOM);
    }
}

customElements.define('generate-art', GenerateArt);

Demo #3 #

This much interactive code can cause problems though. Can cause a lot of jank, and slow down the user experience.

We should remember "primum non nocere": first do no harm.

Jank happens when your code prevents a user's action from being processed, which is no good.

Web Workers are the way to fix this. They give us a different execution context for code, so the user won't feel that code running.

The OffscreenCanvas allows us to transfer canvas work to a WebWorker, so that we don't block the main thread.

const offscreenCanvas = canvas.transferControlToOffscreen();

Demo #4 #

ez-offscreen-canvas is a package created by the speaker to help with this step.

The web is a great and practical creative outlet. We are now able to create our own expressions in ways we've never been able to before on the web.

Call to action: remix this!

glitch.com/~offscreen-canvas-kit

Are You Being Servered? Exploring a Serverless Web. #

Phil Hawksworth — @philhawksworth #

Slides

Wireless things have wires, but they're obscured. In the same way, serverless things have servers, but they're obscured.

Serverless allows you to focus on things you care about, rather than managing a server.

The problem with doing big projects: there are constraints, complexity, and infrastructure. They're complicated.

"Understanding constraints is critical to making good software." - Jeremy Wagner

Chris Coyier's talk: http://full-stack.netlify.com

Chris says that he's liberated from having to manage servers, and enjoys the ability to focus on what he's good at and cares about.

Phil works at Netlify.

Phil's (free!) book on serverless.

Serverless URL shortener.

Serverless is really "functions as a service".

Jamstack. A modern architecture, create fast and secure sites and dynamic apps with JS, APIs, and pre-rendered Markup, in an infrastructure without servers.

Aaron Swartz has been doing serverless since 2002. It's not a new concept.

Serverless can be more dynamic than you expect. SmashingMag is static, despite having e-commerce and logins and stuff like that.

hawksworx.com rebuilds on Netlify based on an IFTTT trigger whenever he tweets.

webtask.io allows you to run a serverless function as often as you like

Two Principles: #

Pre-rendering:

Doing the work now, so servers don't have to later.

Putting distance between the complexity and the user.

Jamstack stops at the CDN. No other servers required, except a CDN. The traditional model potentially requires a CDN, load balancer, web server, database server, the whole ball of wax.

Static sites are much more secure, because they're so much simpler. Less infrastructure means less security needed.

Traditional sites use static layers (caching) on each server, which slows things down. Serverless is faster.

Tranditional stacks add infrastructure to create scale. More requests mean more servers, which means more managing and more risk.

Serverless on-demand:

These are functions that allow you to add dynamic content to a serverless site.

The temptation is to recreate everything in serverless functions, but it's best to pre-render as much as possible. Functions are enhancements, they're not supposed to be core things. Static sites should be built static first.

vlolly.net - static site that retains user generated data. Goals:

  • Pre-generated pages with real URLs - 11ty
  • Data stored in a database - FaunaDB
  • Instant access to new content - Netlify functions

11ty generates lolly pages from data in the DB, and then Netlify rebuilds 11ty based on data received from users. But you can create a hook that builds the new lolly and ignores the rest for the moment, so people can instantly see their new lolly.

If the lolly page 404s, then we can render the lolly page with a serverless function that uses a template and the DB.

Custom 404 routing enables this functionality, allows us to give people a page that tells them their page is building.

We're also using events, triggers, and automation.

Database as a service is also an important concept.

Serverless brings a whole new paradaigm to web development. No longer do we need to add more servers to scale, now we can start static first, and make it much easier for our servers to scale dynamically to fit the load.

How Privilege Affects Performance #

Tatiana Mac — @tatianatmac #

Author's note: much of Tatiana's talk seemed political, targeting a lot of talking points from our current political climate. She seemed biased in one direction, and for that reason I've tried to record the facts as I heard them, with as little bias or commentary as I can manage.

Tatiana's background is in journalism. She wanted to be a journalist, but it didn't pan out.

So she started doing design and development work. She did that for a while, then got burnt out. She quit everything and went to Europe, and it taught her that she didn't like selling stuff for other people.

Now she considers herself an activist. Her life work: to seek solutions for justice.

She says the discomfort the privileged feel when challenged is the same discomfort the less privileged feel all the time.

Privilege: a special right, advantage, or immunity granted to only a particular person or group.

Tatiana says that capitalism is causing the lack of diversity in our country. She's also saying our founders were explicitly trying to make their lives easier, and the lives of people who didn't look like them harder.

"Privilege doesn't define how far we can go, only from where we start."

"Capitalism scares us with scarcity."

The speaker said capitalism is based on meritocracy. Her proof is that top level tech CEOs do not work so much harder than their employees to justify their profits. She seems to think that profits should be based wholly on effort, not value.

The speaker says accessibility issues come because we don't use screenreaders everyday, which is a mark of our privilege.

The speaker also says empathy is a scam, and selfish. By telling our stories we're "erasing other people's stories".

← Home

Changelog
  • Obsidian Linter at work
  • Add inclusive lang checker, remove non-inclusive language from blog posts
  • Adds new post about NEJSConf 2019