Matt E. Patterson writing for A List Apart:

The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.

What’s old is new again (with a twist):

a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place.

I won’t spoil the ending where Matt places his bet on the best toolkit to accomplish this, but let’s just say you’ve probably heard of it. Whoops!

Eve Martin:

Sometimes we need information from our servers instantaneously. For this sort of use case our usual AJAX request/response doesn’t cut it. Instead, we need a push-based method like WebSockets, Long Polling, Server-Sent Events (SSE) and - more recently - HTTP2 push. In this article, we compare two methods for implementing realtime - WebSockets and Server-Sent Events, with information on which to use and when.

This is a nice, reasoned comparison of the two technologies: advantages, stumbling blocks, open source resources, etc.

The WebSocket Inspector is part of the existing Network panel UI in DevTools. It’s already possible to filter the content for opened WS connections in this panel, but till now there was no chance to see the actual data transferred through WS frames.

This is rad. It’ll ship to all Firefox users in version 71, but it’s available in Firefox Developer Edition today.

A nice tut on the nitty gritty of using Action Cable to build a chat app. See also the follow-up post in which Lazarus dockerizes it as well.

inlets combines a reverse proxy and websocket tunnels to expose your internal and development endpoints to the public Internet via an exit-node. An exit-node may be a 5-10 USD VPS or any other computer with an IPv4 IP address.

You may be wondering why this project needs to exist, since many like it have come before. The author addresses that right up front:

Similar tools such as ngrok or Argo Tunnel from Cloudflare are closed-source, have limits built-in, can work out expensive and have limited support for arm/arm64. Ngrok is also often banned by corporate firewall policies meaning it can be unusable. Other open-source tunnel tools are designed to only set up a static tunnel. inlets aims to dynamically bind and discover your local services to DNS entries with automated TLS certificates to a public IP address over its websocket tunnel.

Drop-in Pusher replacement, SSL support, Laravel Echo support and a debug dashboard are just some of its features.

This looks really well done. The Laravel community is en fuego as of late. 🔥

This is a nice, deep primer on WebSockets. It includes some web history, describes WebSockets in detail, and catalogs available libraries you can use to get started with them. Here’s the intro to the topic:

In a nutshell, WebSockets are a thin transport layer built on top of a device’s TCP/IP stack. The intent is to provide what is essentially an as-close-to-raw-as-possible TCP communication layer to web application developers while adding a few abstractions to eliminate certain friction that would otherwise exist concerting the way the web works.

a tiny (319 bytes) wrapper around WebSocket that will automatically reconnect if the connection is lost

“Little” is the operative word, here. It doesn’t do all that much. I’m not ashamed to admit it, I’m logging this one because the name and logo scores a 💯. So cute!

Berlin based Rubyist Sven Fuchs asks if Java-based Jenkins is the best CI tool for open source Ruby projects.

Sven writes:

Instead, imagine a simple and slim build server tool that is maintained by the Ruby community itself (just like Gemcutter is, or many other infrastructure/tool-level projects are) in order to support all the open-source Ruby projects/gems we’re using every day.

Instead of just imagining, Sven and others have been working toward that vision with Travis, an extremely alpha Rails project. Travis is a single-page application built in Rails and uses Backbone.js as a client-side MVC frontend.

How it works

By configuring a post-receive URL in your GitHub project settings, GitHub will ping Travis when new git commits are received. Travis will then schedule a build in Resque, a Redis queue. Travis then uses Websockets courtesy of PusherApp to update registered browsers on build status as it runs in the background.

Take a look at some of the projects getting built over at travis-ci.org, the project’s new home page or checkout Sven’s quick tour of Travis in this screencast:

Usage

Currently, the hosted edition of Travis is open to anyone with a GitHub account. Just sign in with GitHub. Once you’re in, grab your Travis build token and configure a post-receive URL in your GitHub project’s Service Hooks page:

http://[YOUR_GITHUB_USERNAME]:[YOUR_TRAVIS_TOKEN]@travis-ci.org/builds

Host Travis yourself

If you want to run your own instance, you’ll need to set up configuration settings:

$ cp config/travis.example.yml config/travis.yml

If you want to run on Heroku, you’ll need to set some ENV variables

$ rake heroku:config

IF you’re running locally, you can start a worker with

$ RAILS_ENV=production VERBOSE=true QUEUE=builds rake resque:work

… or if you’re using God:

$ cp config/resque.god.example config/resque.god
  $ god -c config/resque.god

How you can help

Travis is in EARLY ALPHA. Sven and gang are looking for folks to help test, log issues, and submit patches. If you want to join the community, join the Google Group or hang out in #travis on IRC.

Special thanks

Sven and team would like to offer a special thanks to Pusher App for donating a Big Boy account for the project. If you’d like to pitch in with the compute side of the project, (we’re looking at you Heroku or Linode), please ping Sven.

[Source on GitHub] [Blog post] [Discuss on HN]

As new technologies are delivering on the promise of the Real Time Web, it’s becoming apparent that the revolution will be streamed. Malte Ubl seems to agree, creating Streamie, your very own real-time Twitter stream powered by Node.js and Websockets.

We talked about how crazy fast Node.js can be in episode #20. In episode #31, we talked about the possibilities of pushing updates to the browser with Websockets. In Streamie, the new Twitter User Stream API provides the payload to stream your tweets to you in real time.

Websockets are implemented in Streamie using Socket.io, which falls back to traditional polling in older browsers.

Features

Although it’s still in early, active development, Streamie does offer some nice features you’d expect in a Twitter client including:

• Scroll state memory - Streamie remembers your scroll position between visits. New tweets appear scrolled offscreen to the top.
• Google Chrome notifications - Growl-like notifications for new updates.

Instructions on setting up Streamie to run locally can be found in the README

[Source on GitHub] [Live version]