You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
Luke Childs 921eb22f9a Integrate with Travis 8 years ago
controllers Follow xo style 8 years ago
lib Follow xo style 8 years ago
public Follow xo style 8 years ago
views Tor Explorer => Onionite 8 years ago
.gitignore Add .gitignore 8 years ago
.travis.yml Integrate with Travis 8 years ago
LICENSE Add LICENSE file 8 years ago
README.md Update demo link 8 years ago
icomoon.json Some size optimisations on the font 8 years ago
index.js Follow xo style 8 years ago
package.json Add xo 8 years ago

README.md

Onionite

Explore the Tor network in under 10k

An entry for the 10k Apart contest. Onionite allows you to view information on the individual nodes that make up the Tor network. It is essentially my own spin on the existing Atlas web app by The Tor Project, Inc.

It runs node on the server side and requires only HTML on the client for full functionality. It's a bit prettier with CSS support and you'll get some additional enhancements if you have JavaScript enabled.

I've implemented some additional features I've always wanted from Atlas such as search pagination, the ability to save nodes to your favourites, increased performance, better accessibility/mobile support and offline functionality (PWA).

Demo | Vote

Screenshot

Size

An average Onionite page weighs in at just over 7k. If the browser has JavaScript enabled additional requests will be made for ~1.5k of JavaScript enhancements and a ~500 byte SVG. These are requested asynchronously and so do not block the page load. They are purely for progressive enhancements and the site is fully usable without JavaScript.

Including the asynchronously loaded enhancements the page is still under 10k (~9.5k). The equivalent Atlas pages tend to be around 480k.

I have kept the size down by not using any 3rd party libraries. Everything has been implemented in vanilla HTML, CSS and JavaScript. I've also done as much heavy lifting on the server as possible to keep the amount of information that needs to travel down the wire to a minimum.

Emerging standards have been favoured over proprietary APIs to try and reduce unnecessary code duplication. For example I've intentionally not used Apple/Google/Microsoft link/meta tags for icon and home screen functionality. Instead I've chosen to use the less well supported web app manifest. Support for this should improve over time and it's not crucial for the site to function. I have used vendor specific fallbacks in places where the experience was completely broken without them.

Browser Support

Onionite works in all modern browsers and I've taken care to not completely break the experience in older browsers that don't support the modern features used. I've also used media queries to give a good experience on devices of all different screen sizes.

Making sure to use well structured semantic markup throughout the application also means that it works well with text based browsers such as lynx.

Accessibility

I've tested the site with various tools such as a11y and also done my own real world testing with screen readers. I've added ARIA landmarks to make navigation easier and made sure to hide certain elements from the screen reader (such as ascii graphs) that can't reasonably be understood by them. Testing using a11y is still returning some warnings but from my own personal tests I think these can be safely ignored.

Making sure all information was accessible without JavaScript was also really important. The target audience for this application are people who are running Tor relays or are interested in the Tor network. These people are more likely to be more concerned with privacy than the average user and are therefore much more likely to have JavaScript disabled.

One thing I really wanted to be able to show without JavaScript was bandwidth graphs. Atlas uses the D3 JavaScript library to generate graphs which is about 124k on it's own. It seemed a bit excessive to add a 124k dependency to a 7k page for one feature so I tried to figure out a way to render the graphs server side. In the end I settled on rendering the graphs in ascii art. This meant the graphs were basically just text which is highly compressible by gzip and works well on text based browsers.

Progressive Enhancement

With JavaScript enabled some feature detection code is ran and if the browser is capable, the ability to "favourite" nodes is enabled. This is something I find really useful as I regularly check the status of my node on Atlas and have to search for it every time.

Browsers/operating systems that support web app manifests will allow the web app to be installed to your home screen and act like a native application. Support for this isn't great yet but should improve over time. It currently works very well with Chrome on Android.

If the browser supports service workers a service worker will silently cache all static assets in the background. It will also keep a copy of the latest data each time you visit the top 10 nodes or an individual node page. If you lose your internet connection in the future the service worker will pull relevant data out of it's cache if it's available and show a nice error page if not.

These three enhancements really compliment each other and allow for a very native app like experience that even works offline for modern devices.

Performance

The fact that all assets beyond HTML and CSS are loaded asynchronously means that the browser can crack on with rendering the page without waiting for anything it doesn't need right away to load. All HTML, CSS and JavaScript is also aggressively minified and then compressed with gzip to squeeze every last byte out.

In the enhancement JavaScript, as much work as possible is done outside of the DOM ready event handler. This means even if the DOM isn't ready yet, we get as much work as possible out of the way so that when the DOM is ready we can inject the enhancement elements as soon as possible. This helps to reduce jitter as the elements are added after load making the website appear less laggy.

All information is provided by the Onionoo API. I've written a simple node API client as a separate reusable module (onionoo-node-client). It caches the API responses in memory (respecting Onionoo's Cache-Control headers) meaning that once the cache has warmed up the server responds very quickly. It also takes a bit of load off the Oninoo API server. Atlas makes all API requests clientside, meaning a large number of users will result in heavy traffic to Onionoo.

Credit

Onionite is heavily inspired by Atlas and Globe.

"Tor" and the "Onion Logo" are registered trademarks of The Tor Project, Inc.

License

MIT © Luke Childs