Skip to main content

JavaScript: ForwardJS

I went to ForwardJS. These are my notes:

The workshops are being recorded, Use the offer code "forward6".

JIBO is a robot built on NodeJS. It's a programmable platform. "The world's first social robotics platform on JavaScript."

It's really amazing how diverse the audience is.

Analytics, Automation, and Intelligent Agents

Microsoft Cognitive Services is pretty interesting and useful. It works very well.

There's modern etiquette: You can post some photos on Instagram, but ugly photos should be posted on Snapchat.

Hacking Web Performance

Max Firtman @firt

He's from Argentina, but he's done training in 55 countries so far.

He did a quick runthrough of a lot of stuff that he covered in his tutorial yesterday.

The average time to load a mobile landing page is 22 seconds.

He asked how many people in the room were happy with AMP. No one raised their hand.

We always underestimate mobile.

Responsive Web Design is not enough to address mobile.

ATF = above the fold

Finding your edge in a culture of feedback

Paulette Luftig @pyluftig

Here are the slides.

Growth mindset vs. a fixed mindset.

Persist in the face of setbacks instead of giving up easily.

Learn from criticism.

"Imperfections are not inadequacies; they are reminders that we are all in this together."

Most org cultures don't feel safe enough to explore our edges.

Feedback: ASK: Actionable, Specific, and Kind

Give more positive feedback than constructive feedback.

Avoid absolutes like "always" and "never".

Kindness is a terrible reason not to give important feedback.

You want to care about people, but also radically challenge them.

She said it's better to get good feedback from an @sshole than no feedback from an empathetic person. I'm not sure I agree ;)

Be careful when you are in a position of power.

Worry about how you can improve, not about what they will think about you.

Feedback is an opportunity to grow with help from other people.

Stop playing defense (passive or active).

Slow down and listen carefully.

Have compassion for yourself and others.

Take what works, and leave the rest. Sometimes the feedback that you're given doesn't resonate with us.

How to Perform a Library Autopsy

Zack Argyle @zackargyle from Pinterest.

He's working on their progressive web app strategy.

You really have to autopsy a project before you can successfully contribute to it. Keep this in mind when trying to contribute to open source.

How to do a real autopsy:

  • External examination
  • Blood sample
  • Y incision

Follow the code style, conventions, how tests work, etc.

Figure out how to run tests, run linters, run the developer server. Start by looking in package.json.

Clone the repo. Run the tests and setup your dev environment early.

Most of the audience has worked with React.

He's using Atom.

He walked the audience through figuring out how React's setState was implemented.

First, figure out where's implemented.

Find a test that's calling it. Put debugger; in it.

Run the tests in such a way that you can inspect the code. Do something like:

node --debug-brk ./node_modules/.bin/... whatever to run the tests

He showed that setState is actually asynchronous, which surprises a lot of people.

Using a debugger to walk through some code starting from a test is a great way to examine a library.

React has a ton of dev warnings.

You don't need to understand the whole architecture before being able to contribute something.

He submitted a PR to the AMP project. 650 lines of code. He got 34 comments on his PR. However, he managed to work through them, and get his PR merged.

He said that we all experience imposter syndrome. Remind yourself of the times when you shined. Don't think about the times when things didn't go well.

Remember, the people who wrote these libraries like React are humans too. They make silly mistakes too.

We all suck, and we're all awesome.

Only about 1/4 of the audience had contributed to a large open source library.

If you're going to contribute to an open source library, it's really helpful if you can find someone to help mentor you.

If you want to make a change to a library, and you need your change, fork the library and use your fork while you're waiting for them to merge your PR.

Right now, there's no good way to test Service Workers because they run in a weird, custom environment. He just wrote something to mock out or setup such an environment, and he plans on opensourcing it soon.

TypeScript in Action

Doris Chen @doristchen, Senior Developer Evangelist from Microsoft.

TypeScript and Angular 2 love each other.

She's going to cover new things in TypeScript 2.0.

TypeScript = a typed superset of JavaScript that compiles to plain JavaScript.

It's built more for large codebases.

Enables better tooling.

She plugged Visual Studio Code.

You can just rename a .js file to a .ts file, and you'll get warnings immediately that TypeScript can spot.

She showed some examples where the type inferencing can help you spot bugs.

You can mix and match TypeScript and JavaScript in the same project easily.

Interesting: TypeScript compiles to ES5 by default, but it can also compile to ES6.

Visual Studio Code can rename a function, and the refactor will work across files.

Anything in JavaScript is valid TypeScript. TypeScript is only a 10% addition on top of JavaScript. You don't have to use those things. The main thing being added is optional static type annotations. However, there are a ton of other little things.

They came up with a way of handling null and undefined. You can declare a parameter as having the type number|null|undefined. This is an optional feature. Just turn on strictNullChecks to true in your TypeScript configuration.

In JavaScript, null == undefined returns true.

TypeScript has flow analysis when you are inspecting the type in an if statement.

You can use TypeScript with React. They have .tsx.

It works with Webpack.

If you're going to use TypeScript, remember to stay current. Just don't update your type definitions the night before a talk ;)

React Exposed!

Ben Ilegbodu @benmvp from Eventbrite

He's the manager of the frontend team.


Eventbrite is converting from Backbone and Marionette to React. The two main benefits are that it's easier for developers to learn, and it's nice that they are able to build and use a component library.

Understanding a little about how React works under the hood can help you use it more effectively.

JSX is not HTML. It gets transpiled to JavaScript. To understand the idiosyncrasies in JSX, just see how it gets compiled to JavaScript.

Why can't you have a function return two adjacent elements without wrapping them in an enclosing tag? Because it's like having a function with two return statements in a row.

Why can't you use if in JSX markup? Because it's like trying to use if as an expression instead of as a statement. Just pull the if statement out of the JSX markup, and put it above it, or use a ternary operator. Although, he doesn't like the ternary operator approach.

Why can't you use HTML comments? You can comment out props on their own line using //. Or use:

{/*} stuff {*/}

However, he says the syntax is so ugly, he doesn't use it.

Why can't you use unexpected prop names? (Sorry, I didn't catch why.)

He mentioned class vs. className, and for vs. htmlFor. It's because in ES3, you couldn't write:

labelNode.class = 'something'

Later HTML versions allow this.

JSX follows the earlier JavaScript-based DOM API.

React is really good about providing useful error messages.

If you're outputting an array of elements in JSX, they must each have a key. Using the loop index for the key is an anti-pattern. Instead, use some value in the object that is unique. Otherwise you may end up with the following performance problem: if you insert something at the head of the array, it'll bump up the indexes of all the other things in the array. Hence, React will need to update everything in the list instead of just one thing.

Sophisticated form validation has always been a bit of a pain in the web.

If you use <input type="text" value="hi">, React will give you an error. The problem is that if the user tries to type into the input field, their value will be overriden with value="hi" every time the component re-renders.

If you just want to set an initial value, use defaultValue="hi". This is called an uncontrolled component.

If you want to track the value, add an onChange handler to capture changes to the value, and then use value={this.whateverTheCurrentValueIs} to update the value based on the new value. This is called a controlled component.

To learn more about this problem, see Controlled and uncontrolled form inputs in React don't have to be complicated.

Building Universal Web Apps with React

Elyse Kolker Gordon @sfdrummerjs from Vevo.

Here are the slides.

Here's the code.

She wrote Isomorphic Development with JavaScript.

They've been doing isomorphic apps at Vevo for about 2.5 years.

In this context, she thinks that "universal" and "isomorphic" are interchangeable terms.

Write code once, run it in Node or in the browser.

There are still some open challenges to building apps this way.

Isomorphic apps are good for perceived performance.

She also said that they're good for SEO (but she didn't say that Google runs your JavaScript, which it does).

It's nice to write in JavaScript for both the backend and the frontend. It's good for code reuse and to avoid mental context switching.

You need a bunch of things to build a Universal app architecture.

It's important to keep in mind whether the code is running on the server or the client.

Start with Node and Express. Most stuff is handled by Express middleware. She's not doing any routing on the server (this was confusing, because later she talks about how she's using React Router on the server).

Use Webpack. It can handle the differing module formats you're going to need to generate for the server and the browser.

react-dom/server has a renderToString method.

React Router has both a client and a server implementation. You can use the same router for both.

On the server, React Router has a function called match which calls a callback if the route matches.

She's using Redux. You don't have to use it.

She adds a static method called loadData to the component in order to load the data the component needs.

She's using isomorphic-fetch to fetch data.

You need to setup server middleware.

She sends down the HTML along with a stringified version of the state that was used to build that HTML so that React on the client side can "re-hydrate". She takes the state from the server, passes it to Redux, and lets React re-render.

She said that there are challenges and tradeoffs to using this approach.

These are two very different environments. You may need to build code that only works in one environment or the other. Configure Webpack to set process.env.BROWSER. Then, you can use if statements based on that.

renderToString is slow. Try to do one of the following:

  • Only use it to render above the fold content
  • Stream the response (although she's hasn't tried that approach)
  • Use caching

She talked about various approaches to caching.

For server-side isomorphic caching, Walmart Labs has something called Electrode.

Vevo does some trick where all user-specific stuff is done from the browser. Hence, they can take advantage of CDN-based caching.

There's a lot of complexity to isomorphic apps.

Walmart Labs has an out-of-the-box solution for building an isomorphic app.

Vevo is using GraphQL.

Take home message: Building Universal Apps requires you to think about your application flow in a new way.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p