10 things I learned at Nordic.js 2017

#7 will shock you!

Rohan Dang
Open House
8 min readSep 18, 2017

--

“Hey, I have a ticket to Nordic.js in Stockholm next week, wanna pop over?”

… asked my friend last week. My immediate response?

“Hell yes!”

Next thing I know, I was on a plane to Stockholm. ✈️

I’d never been to Nordic.js (or Sweden) and had no idea what to expect. All I knew was it was a conference about JS, and it was in Stockholm where I would get to see my friend.

Little did I know that it’d turn out to be one of the best experiences I’ve had at a conference in a long time! So, I’d like to share some of my learnings.

If you’re interested in Javascripty things and like learning about what’s current and happening in the JS community, here’s what I found to be cool and eye-opening.

Quickly, a little bit about me — I’m an engineer at Opendoor in San Francisco. Opendoor is revolutionizing the way people think about buying and selling homes, making it incredibly simple and easy through technology. I never took JS seriously until recently when I got involved with it and started to see how sophisticated and amazing it really is. I have been loving every bit of it since then. Attending this conference was an opportunity for me to get to meet the community, expand my vocabulary and get a feel for how to think in JS.

Here are the highlights of what I learned, in no particular order.

1. State of JS in 2017 — React, Redux, TypeScript FTW

State of Javascript — by Sacha Greif

My TL;DR highlight: React, Redux, TypeScript, ES6 are the clear winners of where the community seems to be headed!

The State of JS in 2017

Sacha gave us a sneak peek at the 2017 results from the survey taken by over 20K developers. In addition to the very useful insights, I loved the selected comments he shared towards the end —

“The state of JavaScript is there is too little attention to keeping things simple.”

And this little gem —

“Every time I write something in JavaScript I’m surprised that it works.”

2. Don’t use Aria (use native controls)

You’re only supposed to blow the bloody doors off! — by Léonie Watson, W3C Advisory Board

My TL;DR highlight: Aria is an escape hatch — you shouldn’t need it in the first place — use as much of native controls as possible!

If you use custom controls and start adding Aria tags, you’ll inevitably miss something and break the screen readers. Seeing a live demo of how painful it can get when it doesn’t work was really enlightening. It really shouldn’t take that much more effort to make a native <button> work for your use case, instead of using something like <a href="#" role="button">.

3. Write async code in a sync manner

5 architectures of asynchronous JavaScript —by Tomasz Ducin

My TL;DR highlight: Promises + Generators = Async Await

I loved how Tomasz gradually walked us through the evolution of async await and really got into the details of how it all works. Highly recommend going through his deck if you’re interested in deeply learning the async programming concepts in JS.

His summary towards the end captured it best —

  • For a single async operation, a promise is enough.
  • For a combination of different operations — use async await.
  • But if something is repetitive — make it an observable stream.

4. Build reusable react components

Best Practices for reusable UI components — by Mars Jullian, Netflix

My TL;DR highlight: Make sure to not leave any “backdoors” in your UI components!

There’s a skill to building your react UI components in a reusable manner, and Mars really highlighted the difference. They core message was that reusable components need to be self-sufficient and easy to integrate with.

5. CSS Grid is a thing!

Solving layout problems with CSS Grid and friends — by Rachel Andrew, CSS Working Group Expert

My TL;DR highlight: Start using display: grid. It’s awesome and works (if you can ditch IE10).

CSS Grid Layout is a useful tool for 2D layouts (when you want to control both rows AND columns), and really complements the use of Flexbox.

Biggest difference is in a grid layout, you’re defining the grid first and placing items inside it, versus in flexbox, your layout is defined mostly by the items inside it.

Another interesting highlight was learning about the new fr unit (fr stands for fractional), which essentially replaces the % unit for width and height properties.

Asking too much here

CSS Grid is available in most modern browsers, with only partial support in IE.

Here’s the best place to learn all about it: gridbyexample.com.

More resources on her Nordic.js page over here.

6. Anyone can contribute to ECMAScript

The hilarious misadventures of being a platform downstream from your language — by Myles Borins, Google

My TL;DR highlight: Contributing to the future of the JS language can start with a simple pull request to the ecma262 repo!

TC39 is a committee that implements the ECMA-262 specification which eventually JS is an implementation of. If you’re unhappy about something or have ideas on how to improve the language (!), you can have your voice heard too (start by testing it).

It was really cool to walk through the process of how changes in the ECMAScript specification comes to be and how transparent it all really is!

7. [!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]+[]

Down the Rabbit Hole: JS in Wonderland — by Claudia Hernández

My TL;DR highlight: These six letters are enough to do anything in JS: !()+[]

I’d heard the baNaNa joke above, but what was new was actually learning about a whole vocabulary that can be created by exploiting all the quirks of JS (like the truthiness of []), then putting it together to pretty much do anything (like write the entire jQuery library 😱).

On a more practical note, Claudia showed how this way of programming led to the discovery of a serious hack when eBay’s security checks to prevent inclusion of scripts or iFrames were bypassed by the JSF*ck style of programming!

I also liked this parting quote from her talk —

That’s the point about the science. We should keep on discovering by pushing the limits even though there is no practical use in short run.

8. Performance matters

Beyond the bubble — by Ben Schwarz, Calibre

My TL;DR highlight: The Web in 2017: Making people wait for text to render. 🙈
Some very interesting, easy to follow checklists for quick perf wins (learned that font-display: swap is a thing!)

Putting performance into perspective

Ben definitely put the cost of performance into perspective then gave some pretty good, easy to follow hints on how to avoid common pitfalls and improve performance of your web apps.

Multiple highlights:

  • Moto G4 is the best phone to capture the “average” mobile device in 2017
  • Throttle CPU in Chrome dev tools to see how your site performs
  • Lie-fi 🙃 — the wifi that your device says you have but you know you don’t
  • Custom fonts have perf gotchas, keep these things in mind:
    → Fonts are not requested until there is text to render
    → Should use preload to load critical resources (like fonts) early
    → Use font-display: swap to use a system font while a custom one loads
    → Prefer woff2 and woff formats wherever possible (better compression)
  • Code splitting is good 👍

9. Use RxJS to make interactive animations!

Reactive Web Animations with RxJS — by David Khourshid, Microsoft

My TL;DR highlight: Just check out this interaction built using RxJS

When you think about animations as a function of state and time, you start to get the power of combining something like RxJS into a visual animation and UI feedback tool.

I found it really interesting and fresh to think about animations this way. RxViz.com has some beautiful ways to visualize this concept even further.

10. Next.js is my new favorite thing

TBA.js — by Guillermo Rauch, ZEIT

My TL;DR highlight: Next.js is a lightweight framework to quickly build server-rendered React apps, code-split by routes that mimic simple file structure. Definitely worth trying it for the next thing I build!

Guillermo introduced me to the amazing world of Next.js. In my own words, it looks like a wrapper framework that makes it incredibly easy to build and deploy React apps with all the sensible configurations figured out for you by default.

Another interesting way I read it being described as is it’s just like PHP (file based routing, server rendered by default, etc.), but using JS and React.

Let me just list their amazing set of features from the official docs:

  • Server-rendered by default
  • Automatic code splitting for faster page loads
  • Simple client-side routing (page based)
  • Webpack-based dev environment which supports Hot Module Replacement(HMR)
  • Able to implement with Express or any other Node.js HTTP server
  • Customizable with your own Babel and Webpack configurations

The demo simply blew me away. With almost no configuration, we were able to get a React app with all these features listed above, up and running in no time.

Very impressed, can’t wait to try it out for my next project!

Bonus: He also talked about another pretty awesome tool called Now.js (also from Zeit folks). With a single line command it takes your code and deploys it to a publicly accessible Node.js app within seconds. Works with static, node (package.json) or dockerfile deployments.

Many thanks!

That was just a glimpse into the Nordic.js 2017 conference. I called out the things that stood out to me, but there were incredible other talks given by some really talented folks. Be sure to check them all out!

Also, goes without saying but what an excellent job by the conference organizers —

Jonny Strömberg,
Martina Elm, and
Johannes Edelstam!

👏

Thanks for welcoming me in this community and showing me a good time!

Until next year!

Opendoor is looking for engineers of all backgrounds to build products and technologies that empower everyone with the freedom to move.

Find out more about our jobs on StackShare or on our careers site.

--

--