PaperTrends

A high-performance, client-side visualizer for research trends in papers from the ACL Anthology. See the evolution of topics and keywords over time.

Features

• Trend Visualization: Real-time line charts showing keyword frequency across ACL venues.
• Comparison Mode: Compare trends across venues or phrases (topics).
• Multi-Topic: Compare multiple comma-separated topics simultaneously across selected venues.
• Diversity Interleaving: Results table interleaves matches across both keywords and conferences for a balanced view.

UX Decisions

• Press-enter-to-search instead of search-as-you-type for performance reasons.
• Comparison Mode toggle between venues and phrases is live-updating since it doesn't require re-fetching data.
• Other filters (venues, years) are not live-updating (press Update Trends button) since they may require re-fetching data.
• Consistent color-per-keyword and color-per-venue across entire UI.

Technical Design Choices

The architecture of PaperTrends has evolved through several versions before finalizing the current client-side, browser-native approach.

1. Server-Side vs. Serverless (Client-Side In-Memory)

• Considered: A traditional Django/FastAPI backend with a PostgreSQL/PostGIS database.
• Decision: Client-Side In-Memory Processing.
• Rationale: The ACL Anthology dataset fits within browser memory limits (~25MB per decade). By fetching raw data directly from the GitHub, we eliminate backend infrastructure costs, reduce latency to zero once cached, and enable a fully "serverless" deployment on GitHub Pages.

2. Client-Side SQL or DuckDB vs. Client-Side In-Memory

• Considered: sql.js (using HTTP Range Requests to fetch database chunks) or DuckDB-Wasm.
• Decision: Custom In-Memory Aggregation.
• Rationale:
  • sql.js / Range Requests: While memory-efficient and enables SQL queries, it requires complex SQLite schema and file generation and incurs latency for multiple network round-trips during range requests.
  • DuckDB-Wasm: Provides elite analytical performance but carries a heavy WASM binary overhead (~20-30MB) that slows down the initial "Time to Interact". Good for large datasets with million rows and complex aggregations and filtering.
  • Current Approach: By using a lightweight, year-sharded JSON strategy, we achieve zero WASM overhead, instant "warm" restarts via in-memory caching, and a trivial update path directly from the ACL Anthology's GitHub source. Also, this enables faster always-on search or search-as-you-type (currently removed in-favor of press-enter-to-search for performance reasons).

3. Data Ingestion: Pre-processed and stored JSON files vs. on-the-fly JSON parsing

• Considered: Storing pre-processed JSON files for each year in the repo.
• Decision: On-the-fly JSON parsing.
• Rationale: Files are small enough to be fetched on-the-fly. This keeps the data up-to-date with the ACL Anthology's GitHub source. Opted for a normalized JSON structure that pre-calculates venue keys and years, allowing for O(1) lookups during filtering. XML is processed and cached in-memory as javascript objects in papersCache for future use.

4. Visualization: Canvas-based Chart.js

• Considered: D3.js (SVG) or WebGL (GPU-accelerated).
• Decision: Canvas-based Chart.js.
• Rationale:
  • SVG: While flexible, it becomes a performance bottleneck when handling thousands of line segments.
  • WebGL: Provides unbeatable frame rates for millions of points by offloading to the GPU, but adds significant complexity.
  • Canvas: The ideal middle-ground for trend data, providing significantly better performance than SVG for high-density line charts with 20+ years of data across multiple keywords, ensuring smooth interaction and resizing.

5. Concurrency

• Considered: Web Workers for true multi-threaded parsing.
• Decision: Asynchronous Batch Processing.
• Rationale: While Web Workers offload work to separate threads, they add significant overhead and complexity. Asynchronous fetching of chunks keeps the UI responsive for our current data scale (~100k papers) while preserving a simple, zero-dependency architecture.

Project structure

• index.html: The main entry point and UI skeleton.
• script.js: Core logic including XML fetching, parsing, trend calculation, and Chart.js integration.
• style.css: To center divs.

Future Work

• Support for more conferences (NeurIPS, ICML, ICLR, etc.) and/or data sources (e.g. arXiv, S2, etc.) including pre-prints (helps keep up with the latest trends).
• Some way to visualize in graph view like connected papers.
• Add More Venues button coming soon.
• Support for more granular time axis (e.g. quarterly, monthly, etc.)
• Add dimension for tracks (e.g. main, short, demo, industry, etc.).
• Word breaks is a subtle but important detail. May be support for user-input regex or advanced search. Semantic search?
• Aggregated view of all conferences.
• More data points per topic.
• localStorage for caching data for even faster loading.