whateverthing.com

☰

CascadiaJS 2015 was an amazing three-day Javascript and CSS conference hosted at Semiahmoo Resort in Blaine, Washington. It was also the first technology conference I've attended since 2011's Symfony Live in San Francisco.

I was anxious about driving across the border to the conference, but happily it was a perfectly smooth experience. Due to booking late, I stayed at a hotel in Bellingham instead of at the resort. It was pretty nice - plus, they put me in Room 404.

After a half-hour drive to the resort in the morning, I grabbed breakfast and then went to register. Had to wait in line a bit, but the swag bag and cool laser-cut wooden conference badge more than made up for the wait.

Once things got rolling, there were a bunch of great talks from a wide range of speakers. Some of them were presenting for the first time, but I wouldn't have noticed had it not been pointed out.

Day One was the first-ever "CascadiaCSS" part of the conference, Day Two was for front-end JS, and Day Three was dedicated to JS on the Server. I've tried to summarize my perception of each of the talks below. I hope I've managed to hit the high points.

Day One: CascadiaCSS

CSS is Dead, Long Live CSS

My takeaway: Several features from preprocessors are coming soon to CSS land, and it will make everyone's life easier. Additionally, when people are brought up only knowing preprocessors (such luxury!), they might not realize that some of the things they are doing (such as super deep nesting of selectors) will affect browser rendering speeds.

The Design of Developing

My takeaway: When designing tooling for your frontend, pay attention to how it gets cobbled together. You'll often find that parts of the toolchain grow too complex, and can be broken out into smaller programs that fit together in multiple ways. This is the UNIX way, and proper application of the principles can result in a powerful, flexible, and reusable ecosystem. This talk applied not only to CSS tech (such as preprocessors, asset management, and build processes), but also to any command-line programming.

Remote And Better For It

My takeaway: Remote is hard. So hard, in fact, that even people in the same physical office can basically be remote from each other. Making intentional choices to connect with people, including deeper peer-to-peer check-ins, can go a long way toward fostering a communicative and inclusive team - both in the office and remote. A team that can communicate effectively and inclusively with remote workers is a team that can communicate effectively, full stop.

Exploring Fractals in CSS

My takeaway: Whoa. What Gregor did with fractal animation was pretty crazy. From Mandel to Sierpinski to 3D fractal trees in CSS - it's amazing what a bit of math can do.

The Power of Emotion and Delight: Microinteractions

My takeaway: You often hear advice like "Don't sweat the details". That advice can be misleading - because the details are what humanize our software. Little things, like witty microcopy or visual charm, can make your site or product much more memorable to people. Establishing an emotional connection with the user helps them concentrate on the engagement, which will make it more memorable for them. Scour the web for the little things you enjoy (mascots, witty error messages, cute animations, etc) and find ways to apply those concepts in your own projects.

Spare the art, spoil the nth-child()

My takeaway: Creative coding is a great exercise for honing skills. Warping CSS fundamentals to produce artwork is a great way to become naturally connected to the rubik's cube that is CSS. You'll learn mad skills you can apply in your day to day work, because you'll be enthusiastically applying them in a fun way.

CSS as a Service: Maintaining Style (Rolodex)

My takeaway: If you have multiple applications and you want to share a common style between them, you can accomplish it, but you have to be prepared to approach CSS from a different perspective. Binding the style selectors to the structure can make it difficult to reuse CSS across all your projects, so shared CSS has to be completely independent of the structure of the HTML.

Efficient Web Type, circa 1556

My takeaway: In addition to utilizing new web font formats like WOFF2, you can use the existing font-family behaviour to provide a graceful solution for FOUT. Sometimes you might want to stop your site from spinning forever when loading webfonts, and you can use a WebFontLoader timeout to gracefully handle that situation. Also, be aware that some font compression approaches will use "subsetting" to strip out extended features of a font - this can negatively impact the experience of using the font. This talk also covered a lot of interesting history about typefaces.

Responsive Colour

My takeaway: Colour is an amazing way to enhance your experience, but you have to keep an eye out for gotchas - not all people see colours in the same way. (Blue/Black/White/Gold Dress, for example.) One good way to design for colour clarity is to set your system to greyscale rendering while loading your page - this will reveal things like shades that are too close together, which can cause visual confusion. Also, in addition to rgba(), there's also hsla(), which looks like a cool and intuitive way to work with colours using a colour wheel approach. (Maybe you've heard of CSS supporting hsla before, but it was new to me.)

CSS via NPM

My takeaway: This talk presented a way of using NPM to mix and match prefabricated CSS structures in a way that I found reminiscent of the Symfony Framework's component system for PHP libraries. I hope that CSS projects continue to make their internals modular so more of this mixing and matching can happen.

Open Source Design: A Call to Arms

My takeaway: Projects will appeal more to designers if they have a gentler and more approachable onboarding process. Designers might be afraid to contribute to projects for fear of breaking things (or because the version control system is scary and unfamiliar), and the best way to combat that is to be as helpful as possible. Having dedicated documentation, a project website, and/or a demo site are great ways to be helpful. More diverse participation in projects virtually guarantees fresh perspectives that will improve the overall project.

Day Two: CascadiaJS Browser Day

Power Tools for Powerful Visualization

My takeaway: D3 and SVG are pretty powerful, but there are potential performance problems. Exposing them can be complicated, but three strategies can help: Timers (especially console.timeEnd()), Framerate monitoring, and Timeline visualization (note that in timeline visualization, the width indicates the time spent - the height is just the call stack depth, which isn't an indicator of a performance issue). Go browser-native wherever possible. The fewer DOM changes, the faster the display. To optimize SVGs, use groups for organizing parts of the picture - browsers exploit this to improve rendering.

JavaScript and Prototypal Inheritance: Why Is It So Complicated?

My takeaway: Monkey-patching a prototype property/method will affect all related/inherited objects. If a property/method isn't found on an object, JS will move up the prototype chain until it finds something or returns null. ES6 will be getting Classes, but despite the syntactic sugar, they will still be based on prototypal inheritance, so ... they'll inherit state in a way that is completely different from what a C++ or Java dev would expect.

Making Waves with DSP on the 'Net

My takeaway: The Web Audio driver can be used for all kinds of analysis on audio data, although it doesn't yet enjoy full cross-browser support. Digital audio is pretty complicated, and sounds are made by overlaying different frequencies of audio together - tools like fourier transforms can assist in the analysis.

Death to Cookies, Long Live JSON Web Tokens

My takeaway: Our existing solution for session/state emulation in HTTP, using cookies, is not very friendly for single page web apps that rely on CORS. A better solution might be using JWT to sign each request, then storing the JWT token in local storage. HMAC is used to confirm payload is unmodified. This all sounded nice, but I had concerns about security while listening - however, it seems to me that most security concerns would be shared by the cookie model as well.

3D Everywhere with WebGL and Babylon.js

My takeaway: "It's like a sausage ... with some issues." (Describing the TorusKnot 3D shape). Babylon has lots of integrations and is a really powerful abstraction for working with WebGL. No need to speak ASM to GPU. It can accept models straight from 3D rendering utilities or online stores of shapes.

Fallability of Large Systems

My takeaway: Large systems are like a form of kinetic art. One little change can halt an entire system, like when symlinks stopped working in chokidar (a filesystem monitoring library). Investigating it revealed that symlinks should never have worked in the first place, and fixing something unrelated unintentionally broke the unsupported but functional and potentially-widely-used symlink behaviour.

Algorithms for Animation - Simple formulas to activate your UI

My takeaway: When adding motion to a website, you can't just use linear animation. Nature doesn't work like that, so it feels alien to us. Almost an uncanny valley effect. It can be remedied with elasticity and bounciness, via easing functions or actual physics libraries. Motion interactions (e.g., the way a button moves when it updates) can be part of the style guide for a project. The choice of CSS or JS for animations is flexible, but a good rule of thumb is that if the animation affects or relies on more than one element, it's probably time to get JS involved.

A JS Framework on Every Table: Todo Examples All the Way Down

My takeaway: While you were reading this blog post, someone released another JS framework. One reason this happens is that each framework specializes in solving a particular part of the global JS headache - for example, something that accelerates front-end development would not typically help on the back-end. TodoMVC is a good resource for seeing how the different frameworks might help solve your own problem. Microframeworks are basically just libraries, and eventually they might evolve into Web Components.

Hacking Culture with JS

My takeaway: Having a chatroom bot for your company can be powerful in ways you may not have imagined. From empowering everyone to deploy code to production, to automating things that you might not have realized deserved automation, to even improving the morale of the company by integrating with gift card APIs to send high five gift cards to coworkers. The first step, though, is to make the bot fun and amusing - before people will trust it with serious business, they have to trust it with silly business. From there, just make an effort to automate anything that takes more than a few steps, even if it seems so simple that it's not worth the effort to automate.

Components are the future of the web: it's going to be okay

My takeaway: We might be fooling ourselves in thinking that JS and CSS and HTML are actually independent of each other. Separation of Concerns can lead us down a path that results in complex, fragile code. You've probably seen it with brittle selector strings in your JavaScript and CSS - the HTML changes a teensy bit, and the site breaks. Maybe it's not as necessary as we first thought to strip stuff out of the HTML (such as onclick or angular's ng-click). In fact, since Angular promotes things like ng-click, maybe it's time to bring that broken-out stuff back into HTML. With Web Components, HTML itself can be expanded to enable new functionality.

Sidenote: Tessa recently released an absolutely amazing library for embedded comments on websites. Check it out.

A story of package managers, graphs, and one million vertices

My takeaway: RequestAnimationFrame calls have to take less than 16ms, otherwise they can cause performance issues. When dealing with a huge dataset, it is better to precompute the complex calcuations so they don't slow down the animation. Also, when visualizing data, care has to be taken that the "art" aspect doesn't overshadow the interesting details of the visualization. This was demonstrated with lines between points - when relationships were tangled together, it was impossible to see inside clusters. They would just be glowing, meaningless masses. By adding a limit to the number of lines being drawn (a filter), some artistic flair is preserved, but so is the detail in the data. The resulting demonstration was even able to run at high FPS on iPhones.

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

My takeaway: This talk was a great deep dive into concepts like abstraction, and how they can sometimes take away too much context, making it hard to learn a language or a system.

Day Three: CascadiaJS Server Day

I Think I Know What You're Talking About, But I'm Not Sure

My takeaway: We use a lot of words to describe the programming world around us. Sometimes we don't even agree on them. Sometimes the way we use the words doesn't have anything to do with what the dictionary says. Parameter vs Argument, for example. In "function (bar)", bar is the parameter, but calling "foo('test')", 'test' is the argument. This might be backwards to how other people describe it. Scope is a complicated topic, and its origin traces back to ALGOL 60. Basically, a code block's "scope" is the section of the program where its variables can still be referenced by the code. Once execution goes out of that scope, the variables can no longer be accessed by name. Recursion - a fancy programming technique where a block of code calls itself until a "terminating case" is reached, which can be a surprisingly powerful tool. Concatenation is a rare word that means the same thing as its originating inspiration (joining things together). We use too many acronyms: SaaS, Sass, DOM (Vin Diesel's character in the Fast and the Furious is also named Dom), GUI vs CLI, AJAX (and Synchronous JavaScript and JSON - SJAJ).

We have to be cognizant of the language we're using, especially when we're interacting with people who might have no idea what we're talking about. Because of our bizarre added meanings to many words, other people might not even be able to guess what we're talking about.

Scanning the internet with Node.js

My takeaway: The Internet's backbone is governed by the BGP routing table. It clocks in at 1.8GB in raw form, and it contains the rules that govern where data should travel and who owns the network the data is traveling on. The presenter demonstrated a few ways to trim that down to a manageable dataset in order to try and find every open DNS resolver on the Internet (about 8 million), and tie them to the specific country they live in. The goal was to be able to cross-reference with every open HTTP server (100 million) and determine which countries various websites "belonged" to. Of course, the data being crunched was too big to fit into memory, so streaming libraries had to be used to keep the memory footprint manageable.

Adding intelligence to your JS applications

My takeaway: Many resources exist for applying machine learning in JavaScript applications. Libraries such as "natural" and "brain" can enhance your applications by enabling natural language processing and neural networks. One example shown involved a simple neural network that was fed four examples of background-color with a properly-contrasted foreground colour, and it would attempt to deduce an appropriate foreground colour (white or black) based on provided background colours. Even with minimal training, it was fairly effective at creating readable combinations.

Kids, JS, and Minecraft: A 'Dynamite' Combo

My takeaway: Learning to code can be fun when you enable the JavaScript console in MineCraft. It lets you execute JS in the game using an embedded JavaScript engine called Project Rhino, which ships with some (all?) Java SDKs. Also, if you command a sheep to ride itself in MineCraft, the sheep will freeze in place. This allows you to stack sheep in pyramids.

The Art of Identifying Vulnerabilities

My takeaway: Vulnerabilities hide in the many areas of nuance in code. Complexity breeds vulnerability, because it greatly magnifies the unexpected interactions of nuanced assumptions, but even simple code can fall victim to unanticipated behaviour. Also, many vendors fail to consider the impact of threats to "availability". The example given was a regular expression that seemed completely fair and straightforward, but it was revealed that the way it was defined was vulnerable to an availability attack - by passing in a certain input (a long string of integers followed by the characters "minutea"), the regex could be fooled into taking tens of seconds to execute. Tens of seconds might not seem like much, but dozens of incoming requests taking tens of seconds to complete could bring some applications to their knees. To think like an attacker, you have to explore inputs in a way that catches these sorts of assumptions in action. To defend against these kinds of flaws, you need to ensure that you're actively combating your own assumptions. Avoid making blanket statements, or statements that start with "A user would never ..." - you should rather highlight it as a question. "Would a user ..." - if the answer is "only if they're an a-hole", then you probably have to rethink your approach.

Additionally, you should research common types of vulnerabilities by studying the OWASP Top 10.

Automating Web Performance Measurement

My takeaway: This talk showed some great ways to measure the rendering performance of websites. This metric often gets overlooked as people tend to concentrate on easier-to-measure things like page load times. However, once a page loads, it can still have performance issues (particularly if it does fancy things will scrolling). The presenter walked us through using Selenium to simulate loading a page and scrolling to the bottom, and then extracting the performance data from the web driver to get actual Frames-Per-Second rendering information. On an individual basis, these numbers aren't entirely meaningful, but if you incorporate this sort of measurement into your automated testing, you can build a performance graph over time that will allow you to pinpoint when code changes negatively or positively impacted the performance of the site.

Deploying Client-Side Apps, 1,000 at a Time

My takeaway: When deploying a SPA (Single Page App) into OPP (Other People's Pages), similar to Disqus, there are certain steps that need to be taken in a certain order. This is the workflow, and there are tools and concepts that can help with this. The first step is key: for your deployment process, you need to make each step small & independent. Once that's done, you can offload to a workflow service such as SWF (What? Flash? No - Amazon Simple WorkFlow). Essentially it boils down to two feedback loops that constantly check in on a job's status & advance things to the next step until the workflow has finished executing. One benefit of the route this company took was that their workflow could be defined in a simple JSON format - it even allowed them to pull things like retry/timeout logic up out of the individual steps and into the overall workflow definition.

Scratch That Itch - Node on the command line for fun and profit

My takeaway: With a library called nomnom, it's brutally easy to build command line utilities in Node. You can even use 'npm link' to expose them locally on your system without having to publish them to NPM to use them. Command line all the things! You can also tie in API requests using a library called 'request'. I was inspired by this talk to experiment, and that led to the creation of "deref-cli", a command line interface to my Deref.Link AngularJS project. Oh, also, ANSI colours are crazy - but you can use the Chalk library to make them easy.

These Bots are Made for Walkin'

My takeaway: Robots are cool. You can use javascript to interface with them using Johnny Five, Go Johnny Go, and Animation. Also, you can wire in an inverse kinematics library called Vektor which will make your robot's movements seem far more natural. The presenter created a wrapper for Vektor called Tharp that makes this even easier to work with. The presenter gave an amazing "dancing spider robot" demonstration using hand controls over a Leap motion controller.

Containing the Chaos: Building and Scaling IoT Node Services on Azure Using Paas and Containerization

My takeaway: Designing architecture to handle the data needs of the "Internet of Things" can challenge your preconceptions about clean, scalable architecture. The presenter walked us through an architecture based on Nitrogen.io and MS Azure that could handle constant data requests from a fleet of 30,000 cars, and how it evolved from having multiple external routers that determined where the information went to having a single all-powerful router that sat in front of a fleet of CoreOS instances running different types of Docker instances. The new architecture had less maintenance overhead and was able to respond to the requests more efficiently.

A Matter of Time

My takeaway: Dates are hard. Human history is riddled with quirks and decisions that make it extremely hard to work with dates, right down to certain times of day simply not existing on certain days. This even applies to relative lengths of time (comparing two dates), because then you get into questions like "Is 1 Day 23 Hours 59 Minutes and 59 Seconds the same thing as Two Days?". All of this can wreak havoc on code, which can explode if a date is being used without care and attention to the details that might cause it to hit an edge case. As humans, we make assumptions about the world around us that ground us in our own personal context. The assumptions allow us to quickly gauge what we think is possible, but at the same time, they can get us in trouble if we haven't properly audited the reasoning that led us to make the assumption.

Conclusion

The conference was great! I learned a lot, and I had a lot of fun. The food was great, too: ribs, clams and mussels, salmon, burgers, tacos, butter chicken, M&Ms brownies, cake, macaroons, ice cream - it was all delicious. A+++, would attend again.