Skip to main content

JavaScript: ForwardJS Day 2

Introduction

I went to ForwardJS. Here are my notes for day 2:

Create Electronic Dance Music with JavaScript

Walmik Deshpande

"When you go to a club or a party or a rave.. What is one of the most obvious things you notice about the music?

"It's repetitive!

"Since we are engineers, what comes first to mind when we see something repeating itself over and over again?

"Automate the damn thing \m/

"I've created a Node.js module called Scribbletune which has a very minimalistic API (only 3 methods). I'd like to showcase this module along with the options available to us today when it comes to creating music with JavaScript & Node.js right from the terminal. Using my module and regular JavaScript String and Array functions I will put together the structure of a Electronic Dance Music track and show how easy it is for you to start dabbling with EDM using JavaScript"

Unfortunately, I missed this talk. I heard the demos were pretty awesome.

One person told me the developer wrote code that would generate a MIDI file, and then would use software to play that MIDI file. He built up music one instrument at a time in realtime. His knowledge of how to turn music in his head into code and thus into audible music was quite impressive. It's the sort of thing Beethoven would have done.

When To Go Native Over Javascript with React Native

Harry Tormey @htormey

"React Native is great for writing cross platform apps. Certain use-cases, however, still require native code. Together we will look at how to evaluate when native code is the better choice. I’ll cover strategies for dealing with performance issues and how to handle background tasks like geolocation."

He's been doing native development for a long time. He was at Apple for two years working on core audio. He was also at Facebook where he worked on their iOS app. These days, he's running a consultancy.

Native code can impact how you write React Native code.

  • Tooling
  • Third-party code
  • Writing native code

A lot of people have done ReactNative. Almost everyone comes to ReactNative from JavaScript; almost no one comes to it from a native background.

He really likes Expo. It's like "Ruby on Rails for ReactNative". It has "Tools that enable developers to build and share truly native apps that work across both iOS and Android."

You can use whatever editor you want instead of the native platform's preferred IDE.

Expo makes a lot of things really easy.

"Standard Expo projects don't support custom native code, including third-party libraries which require custom native components. In an Expo project, you only write pure JS."

You would need to "eject from Expo" to have your own native code or even third-party native code.

You don't want to use Expo if you plan on using third-party native code, or if you plan on writing native code yourself.

If you want to work on the latest and greatest iOS features, you can't use Expo.

CodePush is a tool from Microsoft. It's "A cloud service that enables React Native developers to deploy mobile app udpates directly to their user's device."

However, it won't work for pushing native code.

He wants to talk about third-party libraries. One that is particularly difficult is navigation. There are a lot of third-party libraries to handle navigation.

A lot of these third-party libraries rely on native code, although some are entirely JavaScript. He talked about which used which approach. If you use one that's based on native code, they can make use of the platform's native approach to navigation.

(I'm thinking that if you have native developers, it may make sense to have some of the app in ReactNative so that non-native app developers can do feature work in JavaScript. Don't use Expo. Do let the native developers integrate other native stuff.)

(He's going really fast, so it's hard to keep up with everything he's saying.)

He talked about the rather large drawbacks of using a pure JavaScript navigation library. It's really nice to make use of what the OS provides instead of trying to emulate it.

Accessibility is another interesting problem for ReactNative, but there are ways to work around the problems.

Native library pros:

  • Performance
  • Native feeling

Cons:

  • Can require some native knowledge

    • Setup is tricky
    • Native linking/build errors
  • iOS/Android behave differently

There are some scenarios where you're going to have to write native code.

He had a long aside about medical marajuana. eaze is a medical marajuana supplier that is one of his clients.

(He's from Dublin. He's using Atom like several other people I know from Dublin. It seems like the ratio of Atom/Sublime is slightly higher in Dublin compared to San Francisco.)

The iOS simulator is very different than how the actual device works. You must test on a real device, especially if your code runs when the screen is locked or off. If the app is backgrounded for ~8 minutes on iOS, it behaves differently. On Android, it's more like 10-20 minutes. It's also different unplugged and not on WiFi.

Apple has a lot of stuff that has to do with background modes.

It's hard to do background stuff in ReactNative. It sounds like you're better off doing that part in native code.

He does use CodePush, but he has to be careful about when he does or does not touch the native code.

There are a bunch of special cases that they have to deal with between Android and iOS. However, the vast majority of the code can be shared.

Apple will reject your app for lots of different reasons.

You may also need to move your code to native in cases where performance is particularly critical.

Whether ReactNative is a good fit for your team really depends on your situation. For JavaScript developers, it's really helpful. For native developers, it takes 1-3 months to learn JavaScript, and they'll always be able to do things JavaScript developers can't. It's really nice to have a mix of different skillsets. It's really useful to have some stuff shared across the platforms.

You need to test each of the platforms. If you don't, you're going to piss off people.

If you're a Cordova developer, and you know React, moving to ReactNative is a no brainer.

It may annoy your native developers to ask them to learn JavaScript.

Mobile developers are expensive.

Full Stack Websocket Deep Dive

Brad Urani @BradUrani

He's a very passionate speaker.

I was a few minutes late.

They started by using Pusher. It's useful, but expensive.

ActionCable is a solution for Rails. There's also Faye.

There's socket.io in the JavaScript world.

NodeJS much better at handling socket connections than Ruby.

He showed how to open a WebSocket in JavaScript.

In real life, you should always use port 443 so you're less likely to run into firewall problems.

You should use wss:// (secure), not ws://.

Why WebSockets?

  • Full duplex
  • Performance

He showed the protocol. It starts with a normal HTTP/1.1 connection, but it has this header:


Upgrade: websocket

The server then switches protocols to "websocket".

Chrome DevTools has nice debugging support for WebSockets.

WebSockets uses TCP not UDP.

If the socket closes too early, you'll need to reconnect yourself. See "reconnecting-websocket".

There are "subprotocols" on top of WebSocket. For instance, you might want to send JSON objects with certain keys present everytime.

Faye is for pub/sub.

He also mentioned WAMP, Stomp, and socket.io.

WAMP has pub/sub, but it also has RPC.

socket.io is popular. It's the kitchen sink of web socket implementations. Whether or not you need something this heavy depends on your situation.

Once a WebSocket is open, any other JavaScript on the page could hijack it for its own use.

(He has a bunch of references to "Journey to the Center of the Earth".)

Pusher and PubNub both have pretty nice free tiers. It's as easy as pie.

(He had lots of fun pokes at JavaScript, but he said he's been using it since 1996.)

RFC 6455 is the RFC on the WebSocket protocol.

Chrome was the first browser to implement it. It's pretty much everywhere. It's even in IE 10.

He talked about how the protocol worked over TCP once the connection is established. He talked about the onion of protocols.

WebSockets run on top of OS-level sockets. To see which OS-level sockets are open, you can use:


lsof -Pn -4

There's an implementation of WebSockets written in Bash using nc :) It's easier than you might think.

He showed how to capture the protocol flow using tcpdump.

Advice:

  • Always use wss://
  • Always use port 443
  • Increase your file descriptor count
  • Look at available subprotocols and libraries
  • Use node.js [instead of Ruby]

He learned all this stuff but decided to stick with Pusher.

He's now also using Elixir.

He works at ProCore in Santa Barbara. The view from his office is beautiful ;)

How I'm Taking Notes

I'm writing my notes in Markdown using Typora. Then, I'm translating that Markdown into HTML to post them on Blogger. This is much faster and easier than all my previous approaches to taking notes during conferences!

I'm enjoying Typora more and more. It's a nice blend of a pure text editor and a WYSIWYG.

WebGL the Easy Way With Unity

Rocco Balsamo @TheRoccoB

http://unitywebgl.com contains all the links he has in the talk.

"Ever try creating an app from scratch with Three.js or pure WebGL? I know I did, and I got nowhere fast. These platforms can be intimidating and tedious for those without an intimate knowledge of computer graphics.

"But today, there's a way to build full-fledged WebGL applications and games with a mature editor that professional game developers have been using for about a decade. In 40 minutes, I'll show you how to create a simple physics demo, export it to WebGL and talk back and forth between the WebGL instance and your javascript application. I'll also show you how to customize your WebGL canvas, and how to access remote resources and API's directly from Unity scripting. Finally I'll share some of the advantages and limitations of this approach for production-level development."

He worked on Rock Band among numerous other games.

He's trying to freelance as an instructor on Udemy.

Game developers have been using Unity for over a decade to build AAA video games.

He mentioned SpriteKit and Swift.

Unity lets you span multiple platforms.

Unity lets you export to HTML5.

He showed nice tooking demos.

Building things from scratch in WebGL is not recommended.

Two main JS libraries for WebGL are three.js and babylon.JS.

He also mentioned Play Canvas, pixi.js, and Phaser.

Phaser is great for writing games with high school kids.

Another approach: C++ Game Engine + emscripten. Funky Karts is an example.

Then there's the Unreal Engine. They have a beautiful demo. Unreal has a pretty steep learning curve. The game he exported was 1G, and his game crashes in Chrome.

He had a demo of building a game from scratch.

Unity has an asset store where you can buy little assets for your game.

WebGL Memory Size is important.

They have an experimental WebASM build.

It takes 5 minutes to do the export.

It's converting C# code to C++, and then converting that to ASM.JS.

You can edit the HTML templates to get rid of weird Unity WebGL stuff in the template.

He made things responsive to screen size. That's not really documented.

Unity can be a bit overwhelming at first. Start with a 2D game.

He started with "Make a Unity 2D Physics Game - For Beginners" on Udemy.

He mentioned scenes, sprites, prefabs (prefabricated items), etc.

UnityScript is a typed JavaScript invented by Unity. Don't use JavaScript in Unity. It's actually deprecated. You should use C# instead.

Awesome Tuts has "Unity Game Development: Make Professional 3D Games" on Udemy.

Playmaker is part of the Unity ecosystem.

In video games, they use finite state machines a lot.

Pros of using Unity:

  • Extremely mature engine
  • Been around for 12 years
  • Over 100 commercial games developed with it, some of them AAA
  • Huge community
  • Easy to use
  • WebGL
  • Experimental WebAssembly

Cons:

  • Closed source

  • It costs money

    • But free for personal use
  • Poor debugging pipeline for HTML5

    • console.log debugging
  • WebGL mobile support lacking

    • It crashes on mobile

You can interface with the JavaScript on the page. It's a little bit of a kludge. You're passing strings back and forth.

(He's using Sublime and Unity's editor on a PC.)

Unity runs on a 3D canvas.

JSONObject is a library for Unity.

He built "Devtools 2017: Beginner to Expert w/ Chrome Developer Tools" on Udemy.

His sites: http://Simmer.io and http://simmerindustries.com

Squeezing PNG and JPEG Images *

The Lazy Person's Guide

Ariya Hidayat @ariyahidayat

We want image file sizes to be small, but we don't want a noticeable loss in visual quality.

MozJPEG vs. Guetzli: Guetzli is only slightly smaller, but takes a really long time. MozJPEG is often used inside of cameras.

PNG

  • Grayscale

  • Indexed color

  • Truecolor

    • RGB
    • RGB+A

DEFLATE = Lempel-Ziv + Huffman

It takes a lot of processing time to find more optimized compressions.

Zopfli: Exhaustive DEFLATE

http://github.com/google/zopfli

You might save 30% of the file size.

One approach to improving compression is to reduce the number of colors that are used in your image. If you reduce it to 256 colors, you can get away with only 8 bits per pixel instead of 24.

pngquant can do that. If you can do this, it's totally worth it.

JPEG is slightly different.

It uses YCbCr.

Our eyes are very sensitive to light intensity.

Block splitting: 8x8 pixels, 64 pixels in each block.

Something about discrete cosine transform (DCT).

He talked about the quality factor.

It's a lot like audio where you throw out the high frequencies in order to save on bitrate.

mozjpeg and cjpeg let you specify a lower quality.

Guetzli is a much more exhaustive jpeg encoder. It tries very hard to preserve the quality of the image. It is extremely slow.

Another approach is to blur the background. You can save another 10%.

Books:

  • High Performance Images
  • Designing for Performance
  • Understanding Compression

Real-Time React with Deepstream

Terence Pae @tpae

He loves real-time apps.

Deepstream is like Firebase but open source. It supports a wide variety of platforms. It's very scalable. It has authentication. It has data conflict resolution. It has a very simple interface.

http://deepstream.io

"A record is an arbitrary JSON data structure that can be created, retrieved, updated, deleted, and listened to." Any change to the record gets published to all the listeners of that record.

It has a pub/sub-based event system. It uses WebSockets.

It supports prescence out of the box.

It looks like Deepstream is a separate server that your clients and HTTP server can interact with.

He talked a lot about his approach to using React:

  • Use higher-order components

  • Use a functional pattern with Recompose

  • Avoid using redux:

    • He likes redux
    • But it has caused him a lot of problems while building real-time systems
  • Keep it simple!

Recompose is like lodash but for higher-order components.

It works well with stateless, functional components where the state is pulled out of the component.

He cited a blog post from Dan Abramov on why you might not need Redux.

He prefers his components to be purely visual.

He uses higher-order components to add logic to them.

He talked about swapping out React with Vue.js, etc. without losing his higher order logic.

He has higher-order components such as withList, withRecord, etc.

(He's using Atom on a Mac.)

Reflecting on the future of the Web after +20 years on it

Max Firtman

[Max is one of my favorite speakers.]

He built his first website using edit in DOS.

index.htm


<FONT SIZE="6"><BIG><BLINK>Hello ForwardJS</BLINK></BIG></FONT>

His first 4 websites fit on a 1.4MB floppy disk.

Getting your own web host was too expensive. He posted his stuff on GeoCities. GeoCities had URLs that looked a little like addresses.

There were no tutorials, no books, no videos, etc. (at least in Argentina).

There was no StackOverflow and no Google.

Today is very different.

On the other hand, unfortunately, lots of things haven't changed!

Here are some frustrations for the user which still happen even today:

Lack of accessibility.

Not supporting the user's browser, device, form factor, or lack of plugins.

The eternal spinner.

Sometimes we force the user to install an app instead of just showing them the web site.

Mobile underestimation.

The mobile web we have today is thanks to Apple and Safari on iOS.

He doesn't like the idea of trying to have one experience that works for desktop and mobile. He doesn't like just using CSS to tweak the layout. He thinks the experiences should be even more different.

He wrote multiple editions of "Programming the Mobile Web", and they were really different from each other.

48% of web browsing happening today happens in the Facebook app with a WebView. It's really different than the real browser on the device.

We have new publishing systems: AMP, Facebook Instant Articles, etc. This leads to a really weird web experience.

Performance is also a frustration for the user.

More than 50% of your users are coming to your website from a mobile device.

There are also frustrations for the developers:

Tools.

First we had layout with tables. Then, we moved to designing without tables--just divs and fighting with floats. Now, we're coming back to something like tables in CSS.

We had different JavaScript library eras: Prototype, Scriptaculous, jQuery, jQuery mobile, AngularJS, Angular 2 (so much frustration on so many levels), React, etc.

Everything is changing all the time.

Compatibility is changing all the time.

"I only know that I know nothing" — this is how you should feel as a web developer. And this doesn't seem like it's going to change.

Buzzwords! "Dynamic HTML", "Rich Internet Applications", "AJAX", "Single Page Applications (SPAs)", "HTML5", "Progressive Web Apps (PWAs)", "Responsive Web Design".

It's a frustration for the business that we pick a technology as a goal instead of as a tool.

"The web is dying". "Mobile apps are dying". "The web isn't dead". "Mobile apps aren't dead".

Steve Jobs did a "one last thing" 10 years ago where he promoted Web 2.0 + AJAX for iPhone development.

The web is "cyclothymic". A good idea is presented. We use it a little bit. We ignore it. It disappears. Years later…it comes back, enhanced, and with a new name.

AMP: We had WML (was somewhat similar) (18 years ago). XHTML MP (16 years ago).

Web Assembly: We had the Alchemy Project (9 years ago).

Apache Cordova: We had Microsoft HTA (18 years ago). Symbian WRT (10 years ago).

WebVR and a-frame: We had VRML (20 years ago).

Web components / Angular: We had Flex (13 years ago).

JSX: We had E4X (13 years ago).

We are going back to the same ideas, but with better implementations and new names.

The future is unknown.

There was real change in how our mobile devices changed over the years.

VR seems important. He doesn't want 100 apps for doing VR. He thinks the web may be the platform for it, or at least, that's what he wants.

IoT seems important. He doesn't want 100 apps for doing IoT.

Augmented Reality (AR) seems important. We've been playing with AR for a while. Remember Google Glass?

They used his picture without his permission all over the media related to Google Glass.

AR Kit is really cool. The demos are really amazing. It's like Google Glass, but really well done.

He thinks the web is going to deliver these services.

Resizing the window back and forth != responsive design.

Lessons:

  • Don't frustrate your users.
  • Not everything is a nail.
  • Never underestimate mobile.
  • Embrace good ideas; they'll be back.
  • Embrace the change.
  • Don't take buzzwords as goals.
  • Performance.
  • Accessibility.
  • Remember the user.

Giving it a REST: An intro to GraphQL

Brian Douglas @bdougieYO

"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. I will walk through how to approach adding it to your React and Angular projects and explore the relationship between it and your UI. I will also explore the architecture of Apollo Client, one of the leading GraphQL client implementations."

Slides: http://disco.netlify.com

He had a long tangent about Hip Hop, Grand Master Flash, etc.

The end of disco was July 1979. It only lasted two years.

Is jQuery done? He doesn't think it is. Disco is also not dead.

Does GraphQL kill REST? We'll find out...

In the room, something like 3 people are using GraphQL, but 5 of them are using it in production (WFT?!?) :-P

Hip Hop came out of remixing Disco beats. (This is an important metaphor in his talk.)

These days, everyone is sampling old school records.

Disco, give it a REST!

"My favorite thing to talk about is myself."

Netlify hosts web sites based around the JAM stack.

He likes having a client and having an API—i.e. a separation of concerns.

He uses so many puns. I can't possibly catch all the jokes and cross-references ;)

He said REST is "exposing data using lots of endpoints." For instance, /user/repositories. What fields do you get? Go see the docs. How do you know what endpoints are available to you? Go see the docs.

He likes Axios for making REST requests.

GraphQL is a schema-based language for how you structure your data and return it from an API.

You can have a proxy in between your client and your server.

You define the shape of your data. You fetch the data using JSON.

(No one admitted to fetching their data in XML anymore.)

Data (???) lets you sample data with GraphQL.

GraphQL client interactions:

  • Queries
  • Mutations
  • Subscriptions (new)

GraphQL came out as a spec.

How do I get GraphQL in my client? It is supported by lots of different languages.

GraphQL isn't just a React thing.

You can just use it with Axios, but you're missing a lot of the benefits of richer libraries.

Relay (from Facebook) and Apollo (from Meteor) make it much nicer.

(That's only the second time I've heard Meteor mentioned at the conference.)

GitHub's new API is GraphQL-based.

Apollo lets you take advantage of higher-order components.

He likes describing the shape of the data he's fetching.

Relay has two different versions: Relay Modern vs. Relay Classic. He doesn't use Relay.

How do I add GraphQL to my existing API?

He hasn't really convinced his team to use GraphQL yet.

GraphQL SDL - Schema Definition Language

You can put your GraphQL endpoint near your data, or you can use a gateway to your data.

Lots of languages support GraphQL. What's hard is the database part.

"I went to my backend guy and asked if he wanted to do this. He said, no." [I think this is a important statement.]

There's a gateway written for Node.

LaunchPad is some middleware server.

So he was able to "sample" REST using GraphQL, LaunchPad, etc.

He said he remixed his disco in order to make Hip Hop.

REST is not dead.

He doesn't know about these things yet:

  • Batching queries
  • Speed
  • Performance

Apollo and Redux get along well.

GraphCool is like Firebase, but with GraphQL.

He mentioned:

GraphQL is game changing by "sampling".

Comments