Pith. sign in

REVIEW 3 major objections 4 minor 49 references

Typed server-side DSL replaces JavaScript for reactive web controls

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 09:03 UTC pith:OC2KTCWO

load-bearing objection A solid, scoped Kotlin DSL for Datastar-style reactive hypermedia: real engineering, honest limitations, with two caveats — the 'no string literals' claim is overstated and the Datastar runtime dependency is untested. the 3 major comments →

arxiv 2607.29338 v1 pith:OC2KTCWO submitted 2026-07-31 cs.SE

BRHC: Backend-driven Reactive Hypermedia Controls with a Statically Typed Kotlin DSL

Fernando Miguel Carvalho , Paulo Carvalho , Leonel Correia , Ricardo Gomes , Juho Veps\"al\"ainen This is my paper
classification cs.SE
keywords Hypermedia-driven applicationsReactive signalsType-safe HTML templatingServer-Sent EventsHypermedia controlsBackend-driven UIDomain-specific languagesHATEOAS
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper claims that the interaction layer of a web application can be moved into the backend's type system: instead of writing JavaScript or string-typed HTML attributes, developers express reactive controls and signal bindings as statically typed expressions in a server-side DSL. The DSL compiles to attributes understood by an existing browser runtime, so no application-specific client scripting is needed for five catalogued interaction patterns. A realistic veterinary-practice demo application shows the approach applies beyond toy examples, and single-user benchmarks report lower average latency than both a full-page server-rendered baseline and a single-page-app baseline, with comparable initial load. The significance, if true, is that backend teams get compiler-checked wiring between UI, state, and endpoints while preserving server authority over application state.

Core claim

The paper's central claim is that the five backend-driven reactive hypermedia control patterns—signal update, action-triggered patch, signal-based patch, incremental patch, and formless submission—can be expressed entirely in a statically typed server-side DSL, with signal names, HTTP verbs, and handler references compiled from typed constructs rather than string literals. The paper states that this eliminates application-specific JavaScript expressions in the view layer, although the browser must still run a general-purpose runtime that interprets the generated data attributes and applies Server-Sent Event patches. A formal model extends hypermedia control semantics with a client signal sto

What carries the argument

The central object is a typed signal—a small abstraction carrying a unique name and a type parameter—together with typed builders for data attributes (signal declaration, two-way binding, text projection, event-triggered actions with debounce modifiers, and intersection-observer triggers). These compile to the attribute syntax of an external browser runtime; the typed representation carries the argument because it lets the compiler check signal names, route references, and expressions that in other hypermedia systems are strings. The formalization's five primitive phases (stream initialization, client action, server signal push, signal patch disposition, structural transclusion) and a compos

Load-bearing premise

The paper's guarantees hold only if the external browser runtime interprets the generated data attributes, maintains signal state, and applies Server-Sent Event patches exactly as documented; the paper neither pins a runtime version nor tests this dependency.

What would settle it

Compile a template that binds an element to a signal, inspect the emitted HTML, and load it in a browser runtime that does not implement the documented attribute semantics; if the UI silently fails while compilation succeeds, the central type-safety claim is shown to depend entirely on the external runtime. A simpler static check: search generated HTML for any data-signals, data-text, or data-bind value containing a name absent from the template's declared signals; if found, the DSL does not fully prevent string-based escape hatches.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Reactive interactions that previously required a separate client codebase can be authored and refactored in the backend language, with the compiler catching mismatched signal names and endpoint references.
  • The formal phase model gives implementers a recipe: any system providing stream initialization, action dispatch, server push, signal patching, and fragment transclusion can reproduce the five patterns.
  • Single-user interactive latency can be lower than full-page reloads and SPA round-trips because only affected fragments travel over the wire; in the reported measurements the reactive implementation was 3.6× and 4.2× faster than the two baselines in one workflow.
  • Initial page load retains server-rendered performance, since adding the small browser runtime adds little; measured first paint was approximately 3.2× faster than the SPA baseline and within about 100 ms of the full-page baseline.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same typed signal store could be used to generate server-side validation of incoming signal payloads, closing the gap where a client could otherwise submit undeclared signal names.
  • Compiler-checked endpoint references open a path to whole-app link checking: a build step could verify every hypermedia action points at a real route, something string-based attributes cannot offer.
  • The reported single-thread benchmark does not establish multi-user behavior; a natural next experiment is a concurrent-load comparison, since SSE fan-out and server push often change latency profiles under contention.
  • If AI coding assistants generate these typed constructs instead of free-form JavaScript, their output inherits compiler verification—an extension the paper's future-work section gestures toward.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper presents BRHC, an extension of the HtmlFlow Kotlin HTML DSL that generates Datastar-compatible data-* attributes, signal declarations, and SSE patch operations. It defines five backend-driven reactive hypermedia control patterns, provides a formal phase-based model of them, migrates Spring PetClinic to the DSL, and compares performance against Thymeleaf and React with Lighthouse and JMeter/Selenium/WebDriver. The main claims are that the DSL can express the five patterns and PetClinic workflows without application-specific JavaScript, improves type safety by moving hypermedia control definitions from stringly typed HTML attributes into Kotlin constructs, and achieves lower latency than Thymeleaf and React in single-user benchmarks.

Significance. If correct, this is a useful pragmatic contribution to hypermedia-driven development: it shows a concrete route from string-based htmx/Datastar attributes to compiler-checked Kotlin, and it ships working listings, a migrated PetClinic, a public benchmark repository, and a documented single-thread measurement procedure. The five-phase formalization is a helpful taxonomy. However, the contribution is a compile-time encoder for Datastar's documented semantics, not a derivation or independent verification of those semantics; every runtime guarantee inherits Datastar's browser behavior. The type-safety narrative is weakened by admitted string literals, and the headline speed advantage is partly due to differences in the compared workflows. These issues are addressable with conformance tests, precise claims, and benchmark controls.

major comments (3)
  1. [§9, §3.3–§5] The central RQ1 claim—'without requiring application-specific JavaScript in the view layer'—depends entirely on Datastar's client-side interpretation of generated attributes and SSE events. The paper explicitly concedes in §9 that 'the runtime still depends on Datastar in the browser,' yet no Datastar version is pinned and no browser-level conformance test checks that Listings 10–25 produce payloads Datastar actually accepts (e.g., datastar-patch-elements framing, datastar query parameter serialization, morph/append/remove modes, debounce modifiers). If any of these semantics differ, the DSL compiles to a runtime that misbehaves. Add a version pin and a small end-to-end conformance suite that exercises each pattern against the real Datastar runtime.
  2. [§3.3, Listings 12, 27–29] The paragraph claims 'No string literals are used for signal binding or endpoint routing,' but Listing 12 issues delete("/delete-row/$index"), Listing 27 uses get("/owners/find"), and Listings 28–29 use get("/pets/new") and post("/pets/new"). Signal names also remain string literals in Listings 10, 15, and 18. This contradicts a stated contribution and is directly relevant to RQ2. Either restrict the claim to 'no application-specific JavaScript expressions' and acknowledge string URLs/signal names, or introduce typed route and signal-name mechanisms and show them in the listings.
  3. [§7, Tables 4–5] The headline speed comparisons ('1.28×/2.14×' and '3.6×/4.2×') compare different workflows across implementations, not the same user-visible operation. In find owners, the React implementation first fetches all owners and filters client-side, while HtmlFlow sends a server-side search; in create pet, Thymeleaf performs three full page loads and React performs several API round-trips. The lower latency may reflect workflow size or interaction design rather than the DSL or Datastar itself. The paper should either implement equivalent workflows (e.g., React also performing a server-side search) or present the numbers as workflow-level comparisons without claiming the DSL is 3.6–4.2× faster.
minor comments (4)
  1. [§3.3, Listing 7] Listing 7 contains `data -signals` and `data -init` with a space after `data`, which would not parse as Datastar attributes. Fix the listing formatting.
  2. [§4.5, Figure 9] Typo 'pacthes' in the figure caption ('HTML pacthes'); also 'data acess layer' and 'received the Edit request' grammatical issues in §4.5 and §6.
  3. [§5] The formal model is a taxonomy mapping patterns to phases rather than a semantic model that proves correctness. That is acceptable, but the notation is confusing because `S` denotes both the system tuple and the set of signals; use distinct symbols.
  4. [§7, Table 5] HtmlFlow shows Std Dev 184 ms vs React 19 ms. The paper explains this, but should state explicitly that the HtmlFlow latency distribution is much wider, softening the practical advantage.

Circularity Check

0 steps flagged

No significant circularity: the DSL is implemented and benchmarked against external baselines; self-citations are background motivation only.

full rationale

The paper's central claims are (a) that the Kotlin/HtmlFlow DSL can express selected reactive hypermedia patterns without application-specific view-layer JavaScript, and (b) that the resulting implementation performs competitively against Thymeleaf and React. Neither claim is derived from the paper's own definitions in a way that reduces to its inputs. The DSL is a compile-time encoder for Datastar's existing data-* attributes and SSE protocol; the paper does not claim to derive Datastar's semantics. The expressiveness demonstration (Listings 10, 12, 15, 18, 22, 24 and the Petclinic migration) is an implementation-level existence proof, not a fitted prediction. Section 5 formalizes the already-implemented BRHC patterns as compositions of operational phases; this is descriptive modeling, not a derivation that presupposes its conclusion. The performance evaluation compares measured latencies against independently implemented SSR and SPA baselines, with acknowledged single-thread limitations; no parameter was fitted and then renamed as a prediction. The self-citations ([11], [17], [21], [30]) support background framing (e.g., 'templates are stringly typed', 'disappearing frameworks') and are not load-bearing for the central result; [17] merely identifies the HtmlFlow library being extended. The paper's own §9 concession that the runtime depends on Datastar in the browser is an external correctness dependency, not a circularity: the DSL's output is defined relative to Datastar's documented semantics, and the paper does not attempt to derive those semantics from its own model. No circular step meeting the required evidence standard was found.

Axiom & Free-Parameter Ledger

1 free parameters · 3 axioms · 1 invented entities

The central claims rest on two inherited bodies of semantics: Gross's hypermedia model (the formalization anchor) and Datastar's runtime (the behavioral anchor). The paper introduces one software abstraction, Signal<T>, which is implemented in shipped code rather than postulated without evidence. No numbers are fitted to data: the only hand-chosen constant is the 200 ms debounce interval, which does not affect the central claim. Benchmark protocol choices (25 warm-up / 250 runs, single thread) are experimental settings, not fitted parameters.

free parameters (1)
  • debounce interval = 200 ms
    Hand-chosen interval for the input-triggered search pattern (§4.3, Listing 15). A configuration constant for the demo, not fitted to data and not load-bearing for the central claim.
axioms (3)
  • domain assumption Gross et al.'s formal hypermedia control model S = (F, P, C, SER) is a valid foundation for describing BRHC patterns.
    Section 5 builds the formalization directly on reference [13] without justifying the model's completeness; the added value of the formalization inherits from that choice.
  • domain assumption Datastar's browser runtime interprets the generated data-* attributes and SSE patch/signal events exactly as documented (selector modes, morphing, signal serialization in the 'datastar' query parameter, debounce).
    Every pattern in §4–§6 delegates behavior to Datastar, and §9 concedes 'the runtime still depends on Datastar'. The DSL's correctness and claimed type safety are contingent on these semantics being true and version-stable; the paper neither pins a version nor tests the runtime.
  • domain assumption Kotlin's compile-time checking (function references ::, typed builders, name resolution) is sufficient to deliver the claimed type-safety guarantees.
    The paper demonstrates by examples that errors are caught at compile time, but gives no formal or systematic argument; §5's model is descriptive, not a proof system.
invented entities (1)
  • Signal<T> typed signal abstraction (with dataSignal / dataBind / dataText / dataOn builders) independent evidence
    purpose: Statically typed symbolic references for reactive state, translated into Datastar data-* attributes and SSE patch payloads; replaces string signal names and inline JS expressions.
    This is a software abstraction, not a postulated physical entity. It is fully implemented and exercised in the shipped Petclinic migration and benchmark repository, so its behavior is checkable outside this paper; the 'graviton problem' does not apply.

pith-pipeline@v1.3.0-daily-deepseek · 21889 in / 17422 out tokens · 159659 ms · 2026-08-03T09:03:40.171378+00:00 · methodology

0 comments
read the original abstract

AI-assisted coding tools (e.g., Copilot, Cursor, Claude) are increasingly ubiquitous and enable rapid generation of web applications. However, this raises concerns regarding complexity, longevity and the long-term maintainability of generated systems. A key source of complexity is the heterogeneity between backend and frontend programming models, where multiple languages and paradigms are combined within a single application, often leading to duplicated logic and fragmented state management. To address this issue, recent approaches (e.g., HTMX, Turbo Hotwire, Datastar, etc.) follow the Hypermedia-Driven Application (HDA) model, positioning HTML as the primary communication medium between client and server. Unlike SPA-centric architectures, HDA systems shift the application state and interaction logic to the server, where backend-driven reactive signals synchronize with the client user interface. However, these approaches still introduce complexity through custom attributes and do not fully eliminate JavaScript, particularly in computed expressions. In this work, we propose a statically typed approach using a Kotlin-based HTML DSL (Domain-Specific Language) for backend-driven reactive web applications. We extend the HtmlFlow Kotlin DSL with typed custom HTML attributes (i.e., Datastar data-* attributes) and signal-based bindings using statically typed builders. We demonstrate the approach through a catalog of reactive interaction patterns and a Petclinic Spring MVC case study. The results indicate that the proposed approach can nearly eliminate the need for JavaScript while improving type safety and preserving a homogeneous programming model across frontend and backend, bridged through a backend-driven reactive, signal-centric architecture.

Figures

Figures reproduced from arXiv: 2607.29338 by Fernando Miguel Carvalho, Juho Veps\"al\"ainen, Leonel Correia, Paulo Carvalho, Ricardo Gomes.

Figure 4
Figure 4. Figure 4: It establishes a baseline in which a Hypermedia Control supports interactive behavior through a [PITH_FULL_IMAGE:figures/full_fig_p012_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

49 extracted references · 1 canonical work pages

  1. [1]

    Facts and Figures 2025

    International Telecommunication Union . Facts and Figures 2025. Online report; 2025

    2025

  2. [2]

    Usage Statistics of Client-Side Programming Languages for Websites

    W3Techs . Usage Statistics of Client-Side Programming Languages for Websites. Online statistics; 2026

    2026

  3. [3]

    The 2025 Web Almanac

    HTTP Archive . The 2025 Web Almanac. Online report; 2025

    2025

  4. [4]

    The web as a software platform: Ten years later

    Taivalsaari A, Mikkonen T. The web as a software platform: Ten years later. In: . 2. SCITEPRESS. 2017:41–50

    2017

  5. [5]

    OpenJS Foundation . jQuery. https://jquery.com; 2026. Accessed: 2026-06-12

    2026

  6. [6]

    The heart of connection: hypermedia unified by transclusion

    Nelson TH. The heart of connection: hypermedia unified by transclusion. Communications of the ACM. 1995;38(8):31–33

    1995

  7. [7]

    Transclusions in the 21st Century

    Krottmaier H, Maurer HA. Transclusions in the 21st Century.. J. Univers. Comput. Sci.. 2001;7(12):1125–1136

    2001

  8. [8]

    Transclusions in an html-based environment

    Maurer H, Kolbitsch J. Transclusions in an html-based environment. Journal of Computing and Information Technology.2006;14(2):161–173

    2006

  9. [9]

    A component- and push-based architectural style for ajax applications

    Mesbah A, Deursen vA. A component- and push-based architectural style for ajax applications. J. Syst. Softw.. 2008;81(12):2194–2209. doi: 10.1016/j.jss.2008.04.005

    work page doi:10.1016/j.jss.2008.04.005 2008

  10. [10]

    Self-published, 2023

    Gross C, Stepinski A, Ak¸ sim¸ sek D.Hypermedia Systems. Self-published, 2023. Available free online. Accessed: 2026-04-07

    2023

  11. [11]

    Revisiting Hypermedia, The Forgotten Web Application Development Paradigm.TechRxiv.2026

    Vepsäläinen J. Revisiting Hypermedia, The Forgotten Web Application Development Paradigm.TechRxiv.2026

    2026

  12. [12]

    Architectural styles and the design of network-based software architectures

    Fielding RT. Architectural styles and the design of network-based software architectures. University of California, Irvine, 2000

    2000

  13. [13]

    Hypermedia controls: Feral to formal

    Gross C, Shaffer D, Revelle M. Hypermedia controls: Feral to formal. In: ACM. 2024:52–64

    2024

  14. [14]

    htmx: High Power Tools for HTML

    Gross C. htmx: High Power Tools for HTML. tech. rep., Big Sky Software; https://htmx.org: 2020. Accessed 2026-07-09

    2020

  15. [15]

    Hotwire: The Fast Way to Build Web Applications

    Basecamp . Hotwire: The Fast Way to Build Web Applications. tech. rep., Basecamp; https://hotwire.dev: 2020. Accessed 2026-07-09

    2020

  16. [16]

    Datastar: The Hypermedia Framework

    StarFederation . Datastar: The Hypermedia Framework. tech. rep., Star Federation; https://data-star.dev/: 2024. Accessed 2026-07-09

    2024

  17. [17]

    HtmlFlow: Java DSL for Typesafe HTML

    Gamboa M. HtmlFlow: Java DSL for Typesafe HTML. tech. rep., HtmlFlow; https://htmlflow.org: 2017. Accessed 2026-07-09

    2017

  18. [18]

    Kotlin Language Documentation

    Breslav A. Kotlin Language Documentation. tech. rep., JetBrains; https://kotlinlang.org/docs/kotlin-docs.pdf: 2024. Accessed 2026-07-09

    2024

  19. [19]

    Front-end Frameworks for Development of SPA and MPA Web Applications.Available at SSRN 3987838

    Sireteanu NA, Homocianu D. Front-end Frameworks for Development of SPA and MPA Web Applications.Available at SSRN 3987838. 2021

    2021

  20. [20]

    Web applications–spaghetti code for the 21st century

    Mikkonen T, Taivalsaari A. Web applications–spaghetti code for the 21st century. In: IEEE. 2008:319–328

    2008

  21. [21]

    Vepsäläinen J, Hellas A, Vuorimaa P.The Rise of Disappearing Frameworks in Web Development:319-326; Springer . 2023

    2023

  22. [22]

    Islands Architecture

    Hallie L, Osmani A. Islands Architecture. https://www.patterns.dev/posts/islands-architecture/; 2022

    2022

  23. [23]

    Islands Architecture

    Miller J. Islands Architecture. https://jasonformat.com/islands-architecture/; 2020

    2020

  24. [24]

    How to implement Incremental Static Regeneration (ISR)

    Vercel . How to implement Incremental Static Regeneration (ISR). Documentation page; 2026. Last Update: 2026-03-25. Accessed: 2026-06-05

    2026

  25. [25]

    Vercel . Next.js. tech. rep., Vercel; https://nextjs.org: 2016. Accessed 2026-07-09

    2016

  26. [26]

    Micro frontends in action

    Geers M. Micro frontends in action. Simon and Schuster, 2020

    2020

  27. [27]

    htmx Documentation

    Big Sky Software . htmx Documentation. https://htmx.org/docs/; 2026. Accessed: 2026-06-17

    2026

  28. [28]

    Datastar Guide

    Star Federation . Datastar Guide. https://data-star.dev/guide/getting_started; 2026. Accessed: 2026-06-17

    2026

  29. [29]

    Patterns of Enterprise Application Architecture

    Fowler M. Patterns of Enterprise Application Architecture. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002

    2002

  30. [30]

    Text Web Templates Considered Harmful

    Carvalho FM, Duarte L, Gouesse J. Text Web Templates Considered Harmful. Lecture Notes in Business Information Processing. 2020:69–95

    2020

  31. [31]

    Functional Reactive Animation

    Elliott C, Hudak P. Functional Reactive Animation. International Conference on Functional Programming (ICFP). 1997

    1997

  32. [32]

    A Survey on Reactive Programming

    Bainomugisha E, others . A Survey on Reactive Programming. ACM Computing Surveys. 2013;45(4)

    2013

  33. [33]

    SolidJS: Reactive UI Library with Fine-Grained Reactivity

    Carpenter R. SolidJS: Reactive UI Library with Fine-Grained Reactivity. Technical Report / Project Documentation.2021

    2021

  34. [34]

    Signals Proposal

    ECMAScript Technical Committee (TC39) . Signals Proposal. https://github.com/tc39/proposal-signals; 2025. Stage 1 Proposal, accessed 2026-06-11

    2025

  35. [35]

    Server-sent events

    MDN Web Docs . Server-sent events. tech. rep., MDN; https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events: 2015. Accessed 2026-07-09

    2015

  36. [36]

    Kotlin StateFlow Documentation

    JetBrains . Kotlin StateFlow Documentation. tech. rep., JetBrains; https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx. coroutines.flow/-state-flow/: 2024. Accessed 2026-07-09

    2024

  37. [37]

    Designing Data-Intensive Applications

    Kleppmann M. Designing Data-Intensive Applications. O’Reilly Media, 2017. Discusses stream processing and continuously updated state in reactive systems

    2017

  38. [38]

    Spring PetClinic Sample Application

    Spring Team . Spring PetClinic Sample Application. https://spring-petclinic.github.io; 2025. Open-source reference application demonstrating Spring-based web application development

    2025

  39. [39]

    Designing enterprise applications with the J2EE platform

    Singh I. Designing enterprise applications with the J2EE platform. Addison-Wesley Professional, 2002

    2002

  40. [40]

    Lighthouse: Automated Auditing, Performance Metrics, and Best Practices for the Web

    Google . Lighthouse: Automated Auditing, Performance Metrics, and Best Practices for the Web. tech. rep., Google; https://developer.chrome.com/ docs/lighthouse/: 2016. Accessed 2026-07-09

    2016

  41. [41]

    Using jmeter to performance test web services

    Nevedrov D. Using jmeter to performance test web services. tech. rep., Oracle; https://www.oracle.com/technical-resources/articles/ enterprise-architecture/jmeter-performance-testing-part1.html: 2006. Accessed 2026-07-09

    2006

  42. [42]

    Selenium WebDriver

    Software Freedom Conservancy . Selenium WebDriver. tech. rep., Software Freedom Conservancy; https://www.selenium.dev/: 2004. Accessed 2026-07-09

    2004

  43. [43]

    Playwright: Fast and Reliable End-to-End Testing for Modern Web Apps

    Microsoft . Playwright: Fast and Reliable End-to-End Testing for Modern Web Apps. tech. rep., Microsoft; https://playwright.dev/: 2020. Accessed 2026-07-09

    2020

  44. [44]

    Thymeleaf

    Fernández D. Thymeleaf. tech. rep., Thymeleaf Project; https://www.thymeleaf.org/: 2011. Accessed 2026-07-09

    2011

  45. [45]

    React JavaScript library for building user interfaces

    Walke J. React JavaScript library for building user interfaces. tech. rep., Meta; https://reactjs.org/: 2013. Accessed 2026-07-09. 32 CARV ALHOET AL

    2013

  46. [46]

    Docker: Accelerated Container Application Development

    Docker Inc. . Docker: Accelerated Container Application Development. tech. rep., Docker Inc.; https://www.docker.com/: 2013. Accessed 2026-07-09

    2013

  47. [47]

    Eclipse Temurin: Open Source Java SE Builds

    Eclipse Foundation . Eclipse Temurin: Open Source Java SE Builds. tech. rep., Eclipse Foundation; https://adoptium.net/: 2021. Accessed 2026-07-09

    2021

  48. [48]

    OpenJS Foundation . Node.js. tech. rep., OpenJS Foundation; https://nodejs.org/: 2009. Accessed 2026-07-09

    2009

  49. [49]

    Service Worker

    MDN Web Docs . Service Worker. tech. rep., MDN; https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API: 2015. Accessed 2026-07-09

    2015