Skip to content
Online Rocket League Replay Parser
TypeScript JavaScript CSS HTML Rust Dockerfile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
assets
crate
cypress
src
tests/core
.dockerignore
.gitignore
Dockerfile
LICENSE.txt
README.md
azure-pipelines.yml
cypress.json
package-lock.json
package.json
tsconfig.json

README.md

Rocket League Replay Parser (rl-web)

Build Status

The Rocket League Replay Parser (rl-web) allows one to select a local Rocket League replay and view statistics all from the comfort of their browser without any data being uploaded. This repo is meant to demonstrate the versatility of the underlying Rust based parser, boxcars which compiled to web assembly for parsing performance. A similar, but offline tool is rrrocket. For a more feature rich analysis of replays, see calculated.gg

Screenshot

Screenshot of web page

Goals

  • Lightweight: Javascript bundle weighs < 10kb gzipped to facilitate quick loading. No HTTP extraneous requests. No tracking. No ads. Even though the web assembly modules weighs ~250kb, the website scores a perfect 100 in lighthouse.
  • WebAssembly: Boxcars is used behind the scenes due to how efficient it is at parsing replays. Boxcars is in Rust, but through WebAssembly we can see the same efficiency in the browser. Even though the web assembly module is heftiest component on the page, this is a postive trade to demonstrate compiling Rust to web assembly, the speed that it brings, and that it saves developer time and bugs by not needing to rewrite the parsing logic in javascript.
  • Minimal dependencies: This web app only relies on a single js and css dependency: (preact and sanitize.css). Minimal dependencies help keep the app lightweight and results in easier maintenance as it reduces the possibility of breaking changes and funky interactions between libraries. To a lesser extent, dev dependencies should be minimized to mitigate the possibility of the build breaking. Fewer dev dependencies are worth it even if this means sacrificing trendy features like css modules.
  • Easy Maintenance: rl-web is not destined for greatness, but it can expect to see sporadic updates. These updates should not be bogged down trying to re-grok the codebase or fixing dependencies. They should, as much as possible, be spent adding features / bugfixes.
  • Static Typing: Typescript removes the cognitive burden of null checks, type definitions, and eliminates silly mistsakes which in turns allows for easier maintenance where one can focus on bugfixes and features.
  • Minimal Config: Parcel allows a zero config setup for both development and production builds. Zero config makes the project easier to maintain. When a build dependency receives an update, the fewer times I have to look at a config and ask "is this relevant" the better. Parcel may not be as flexible, but it's a worthwhile tradeoff.
  • Integration Testing: Cypress is used for end to end tests against the actual site. These tests confirm ability of the WebAssembly and js to function against real world input. Integration tests allows rl-web to skip component testing in favor of . With no component tests, rl-web is free to swap out the internals (ie: move to a different framework or eschew all of them) and not invalidate any tests (easy maintenance). There are still unit tests, but only those that don't use the DOM.

Non-Goals

  • Increase browser support: 85% of users have access to WebAssembly. It's futile to chase that last 15%.
  • Server: While it would be cool to allow users to upload replays to allow others to view the statistics, having a server to store replays increases costs and complexity. Not practical at this time.
  • Competition: You want actual statistics and value? calculated.gg. In light of calculated.gg, rl-web should be viewed as an experiment.
You can’t perform that action at this time.