Text.js

Stato

Tutti i sistemi operativiAggiornato 31 ottobre 2026
console.logOperativo
90 giorni faUna chiamata per ogni frame modificato, nessuna in inattività.Oggi
console.clearUsato raramente
90 giorni faAl primo frame, dopo invalidate(), in inattività quando si accumulano 100 frame e a 300.Oggi
YogaOperativo
90 giorni faLayout flexbox in WebAssembly, pointScaleFactor 1.Oggi
Turbolog encoderOperativo
90 giorni faFiltro tramite hash di riga e codifica run-length %c.Oggi
DevTools ThrottlerRispettato
90 giorni faLimitazione del viewport a 50 ms. I frame sono distanziati di almeno 66 ms.Oggi
textjs.orgOperativo
90 giorni faDocumentazione, Impara, Playground, blog e negozio.Oggi

Benchmark in tempo reale

La pipeline di @textjs/core gira in questa scheda su una dashboard 100×32 e scrive i frame in una console in memoria.

Frame completo
—
layout + disegno + codifica
Digitazione
—
modifica di una riga
Frame inattivo
—
nessuna modifica
span %c
—
3200 celle

Si avvia automaticamente quando la pagina è inattiva.

Cronologia delle prestazioni

packages/core/test/perf.test.ts a ogni traguardo, stessa macchina (Apple M5 Pro · Bun 1.4.4). Media di 1000 frame.

ReleaseFrame completoDigitazioneInattivitàspan %c
0.1.0mar 2025 · @textjs/core · 7c91cea0.194ms0.065ms0.043ms205
0.2.0lug 2025 · textjs.org · 92437cc0.192ms0.067ms0.042ms205
0.3.0nov 2025 · 10× input · 8c2d1b10.205ms0.065ms0.043ms146
0.3.0nov 2025 · Mobile pass · e2e6e460.212ms0.067ms0.045ms146
0.4.0mag 2026 · Zero-flash frames · f007ade0.184ms0.046ms0.028ms146
1.0.0ott 2026 · Text.js 1.0 · 57968b60.163ms0.011ms0.000ms149

Frontend di DevTools

bench/devtools in Chrome for Testing: rendering vuoti, frame consegnati e ritardo di visualizzazione, 5 s per esecuzione. Come misuriamo.

DriverFPSRendering vuotiDisegnati / emessiRitardo p50
Accodamento (in uso)151.0%74 / 7510.4ms
Pulizia a ogni frame1570.6%70 / 7560.4ms
Accodamento, senza pause600.8%67 / 29531.2ms
Pulizia a ogni frame6081.1%45 / 3009.8ms

Incidenti passati

Dal più recente. Gli orari sono in UTC.

ottobre 2026

  • Pagine bloccate sotto l’intestazione in Safari su iOS27 ott – 28 ott 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto.

    2. In monitoraggio

      La correzione è in produzione. L’ancoraggio dello scorrimento è disattivato (overflow-anchor: none). Stiamo monitorando.

    3. Identificato

      Il titolo principale può ancora restare bloccato sotto l’intestazione fissa dopo aver scorso verso il basso e poi verso l’alto. L’ancoraggio dello scorrimento di Safari sta modificando la posizione di scorrimento.

    4. In monitoraggio

      La correzione è in produzione. Questi elementi ora scorrono solo in orizzontale e scrollbar-gutter: stable si applica solo ai dispositivi con mouse.

    5. Identificato

      Le schede dei file, i blocchi di codice e le tabelle nel testo hanno un overflow verticale di 1 px dovuto alla sottolineatura della scheda attiva, quindi scorrono su entrambi gli assi e iOS assegna loro i gesti verticali destinati alla pagina. Anche scrollbar-gutter: stable fa saltare il primo scorrimento su iOS.

    6. In analisi

      Stiamo esaminando le segnalazioni che indicano l’impossibilità di tornare in cima alle pagine di textjs.org in Safari su iOS.

    Questo incidente ha interessato: textjs.org.

    Postmortem

    Le pagine di textjs.org non si spostano durante il caricamento, quindi l’ancoraggio dello scorrimento non aveva nulla da correggere. In Safari su iOS bloccava la sezione principale sotto l’intestazione fissa e impediva di tornare in cima. ?debug=scroll su textjs.org ora mostra in tempo reale gli eventi di scorrimento, tocco e ridimensionamento e identifica il chiamante di ogni chiamata programmatica di focus o scorrimento.

    Correzioni: 297c5d7, 55da525, 8424fcd · Registro modifiche: 1.0.0

  • Test delle regole di lint non riusciti in CI23 ott 2026 · Risolto
    1. Risolto

      Il tester ora legge it.only solo quando un test chiama RuleTester.itOnly. La CI passa.

    2. Identificato

      Bun genera un’eccezione alla lettura di it.only quando la variabile d’ambiente CI è impostata. Il tester delle regole assegna RuleTester.itOnly = it.only all’importazione, quindi il caricamento fallisce.

    3. In analisi

      La suite di test di eslint-plugin-textjs fallisce in CI prima di eseguire qualsiasi test delle regole. Le esecuzioni locali riescono.

    Postmortem

    @typescript-eslint/rule-tester riceve le funzioni di test come proprietà statiche di RuleTester. La correzione racchiude it.only in una funzione. Nessun pacchetto o pagina ha subito conseguenze.

    Correzione: eca3f78

  • Spostamento del layout su /playground e /opencode21 ott – 22 ott 2026 · Risolto
    1. Risolto

      Lo spostamento cumulativo del layout è 0 su ogni route.

    2. In monitoraggio

      È stata distribuita una correzione. Entrambe le pagine condividono un layout del pad e la dimensione viene accodata senza spostare «Adatta alla console». Stiamo monitorando.

    3. Identificato

      Il controllo delle dimensioni della console accoda le dimensioni misurate alla propria etichetta dopo l’idratazione (Fit console · 120×36), spostando il nodo di testo «Adatta alla console». Anche le righe superiore e inferiore del pannello hanno altezze diverse nelle due pagine, quindi il pannello si ricentra durante la navigazione.

    4. In analisi

      La nostra verifica degli spostamenti del layout riporta uno spostamento cumulativo di 0,0001 su /playground e /opencode. Ogni altra route verificata riporta 0. Anche il pannello del focus si sposta quando si passa da una pagina all’altra.

    Questo incidente ha interessato: textjs.org.

    Postmortem

    Il pad ora ha spazi superiori e inferiori ad altezza fissa e ogni demo riserva le stesse righe, quindi cambiare pagina o demo non sposta nulla. Il pannello di connessione di OpenCode mostra una riga di stato in ogni stato, con uno scheletro fino all’idratazione. apps/web/scripts/e2e-layout.mjs verifica che i riquadri siano identici tra route, demo, dimensioni del viewport e stati di connessione.

    Correzione: 8f22b9b · Registro modifiche: 1.0.0

  • La barra laterale della documentazione scompare scorrendo in fondo alle pagine lunghe16 ott – 17 ott 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto.

    2. In monitoraggio

      È stata distribuita una correzione. Anche i capitoli di Impara renderizzano il footer nella colonna dei contenuti. Stiamo monitorando.

    3. Identificato

      La barra laterale dei capitoli di Impara ha lo stesso problema.

    4. In monitoraggio

      È stata distribuita una correzione. Le pagine della documentazione renderizzano il footer nella colonna dei contenuti, così il layout raggiunge il fondo della pagina.

    5. Identificato

      La barra laterale è position: sticky nel layout della documentazione e il footer del sito viene renderizzato dopo quel layout. Un elemento sticky resta ancorato solo mentre il blocco che lo contiene è sullo schermo, quindi quando il footer entra nello schermo, porta con sé la barra laterale.

    6. In analisi

      Stiamo esaminando le segnalazioni della barra laterale della documentazione che scompare scorrendo in fondo alle pagine lunghe.

    Questo incidente ha interessato: textjs.org.

    Postmortem

    Le pagine con una barra laterale sticky (documentazione e capitoli di Impara) renderizzano il footer nella colonna dei contenuti. Le altre pagine mantengono il footer condiviso.

    Correzione: 131ac96 · Registro modifiche: 1.0.0

  • Nome del pacchetto textjs non disponibile su npm14 ott – 15 ott 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto.

    2. In monitoraggio

      Il pacchetto del framework e della CLI ora è @textjs/next, nello stesso scope di @textjs/core e @textjs/react. Gli import passano da textjs a @textjs/next.

    3. Identificato

      Il nome textjs appartiene a un altro pacchetto npm dal 25 marzo 2016.

    4. In analisi

      La pubblicazione del pacchetto del framework textjs su npm fallisce con 403 Forbidden.

    Postmortem

    Da Text.js 1.0, le app importano da @textjs/next anziché da textjs e il bridge di OpenCode è bunx @textjs/app proxy, eseguibile da qualsiasi directory.

    Text.js 1.0: un nuovo nome · Registro modifiche: 1.0.0

settembre 2026

  • Livelli di disegno vuoti alle interruzioni di riga15 set – 16 set 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto.

    2. In monitoraggio

      È stata distribuita una correzione. Le interruzioni di riga che non proseguono una sequenza ora reimpostano prima %c su uno stile vuoto, così DevTools emette un normale ritorno a capo. Ogni frame contiene una copertura.

    3. Identificato

      Quando una sequenza con stile termina a un’interruzione di riga, \n viene scritto nello span %c della sequenza. DevTools divide lo span all’interruzione di riga e la parte vuota rimanente diventa uno span display: inline-block con contain: paint, che riceve un proprio livello di disegno.

    4. In analisi

      Stiamo esaminando elementi <span> vuoti alla maggior parte delle interruzioni di riga nei frame di DevTools e uno span di copertura duplicato in alcuni frame.

    Questo incidente ha interessato: Turbolog encoder.

    Postmortem

    Gli span con lo stesso stile continuano a unirsi attraverso le interruzioni di riga. Anche la copertura è stata spostata su una riga propria: DevTools posiziona il link al sorgente (VM12:1) a destra della prima riga di un messaggio e una copertura inline lasciava quel link accanto alla riga 0, restringendola.

    Registro modifiche: 1.0.0

agosto 2026

  • Latenza di visualizzazione aumentata dopo console.clear27 ago – 31 ago 2026 · Risolto
    1. Risolto

      Il ritardo mediano di visualizzazione in bench/devtools è 10,4 ms. La correzione è inclusa in Text.js 1.0.

    2. In monitoraggio

      È stata distribuita una correzione. Dopo ogni frame che svuota la console, il renderer attende 110 ms una sola volta, così i frame successivi arrivano oltre 50 ms dopo il precedente aggiornamento di DevTools e seguono il percorso immediato.

    3. Identificato

      Dopo uno svuotamento, DevTools inserisce una riga «La console è stata svuotata». Questa occupa lo slot immediato del limitatore e sposta il frame successivo sul timer da 50 ms. Con frame distanziati di 66 ms, ogni frame successivo resta su quel timer.

    4. In analisi

      bench/devtools riporta un ritardo mediano di visualizzazione di 63 ms dopo lo svuotamento della console. Il ritardo resta a quel livello per ogni frame successivo.

    Questo incidente ha interessato: DevTools Throttler, console.clear.

    Postmortem

    L’input discreto continua a essere renderizzato in modo sincrono quando l’intervallo tra i frame lo consente.

    Interrompere il blocco di fase · Registro modifiche: 1.0.0

  • Lo spinner disallinea le righe nella console di DevTools11 ago – 12 ago 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto. La correzione è inclusa in Text.js 1.0.

    2. In monitoraggio

      È stata distribuita una correzione. Lo spinner dots predefinito ora disegna blocchi a quadranti (▘ ▝ ▗ ▖), ciascuno di una cella in Menlo. I frame braille sono disponibili come variant="braille" per i terminali.

    3. Identificato

      Lo spinner predefinito disegna simboli braille (da U+2800 a U+28FF). Text.js misura ciascuno come una cella, ma Menlo, il font della console di DevTools su macOS, non ha glifi braille. Il glifo di ripiego è più largo di una cella e sposta a destra il resto della riga.

    4. In analisi

      Su macOS, le righe che contengono uno <Spinner> sono disallineate in DevTools. Le celle a destra dello spinner sono fuori griglia.

    Questo incidente ha interessato: console.log.

    Postmortem

    LineChart disegna punti a quadranti per impostazione predefinita per lo stesso motivo. Il braille è disponibile con marker="braille".

    Registro modifiche: 1.0.0

maggio 2026

  • Disegni vuoti frequenti nella console di DevTools5 mag – 19 mag 2026 · Risolto
    1. Risolto

      La correzione è stata rilasciata in Text.js 0.4.0. I disegni vuoti sono all’1,0%, tutti sul primo frame.

    2. In monitoraggio

      textjs.org ora accoda i frame anziché svuotare la console. Uno span di copertura a larghezza zero nasconde i frame precedenti e i frame sono distanziati di almeno 66 ms.

    3. Identificato

      DevTools applica console.clear() in modo sincrono ma disegna i nuovi messaggi con un intervallo minimo di 50 ms. Ogni frame rimuove subito il precedente e viene disegnato fino a 50 ms dopo. In bench/devtools, una dashboard 100×32 era vuota nel 70,6% dei disegni di DevTools a 15 fps e nell’81,1% a 60 fps.

    4. In analisi

      Stiamo esaminando le segnalazioni della console di DevTools che appare vuota tra i frame sotto carico.

    Questo incidente ha interessato: console.clear, DevTools Throttler.

    Postmortem

    Dalla versione 0.1.0, Turbolog inviava un console.clear() e un console.log() per ogni frame modificato. bench/devtools, che controlla il vero frontend di DevTools in Chrome for Testing, è stato creato per misurare questo incidente e ha prodotto i numeri nella tabella del frontend di DevTools qui sopra.

    Correzione: f007ade · Turbolog: eliminare il lampeggiamento · Registro delle modifiche: 0.4.0

aprile 2026

  • Percorsi dei file nei frame della console riformattati come link14 apr – 15 apr 2026 · Risolto
    1. Risolto

      Questo incidente è stato risolto.

    2. In monitoraggio

      È stata distribuita una correzione. Il codificatore inserisce un word joiner (U+2060) nel testo path:line, //host:port e data:, a meno che la cella non consenta i link.

    3. Identificato

      DevTools trasforma URL, path:line e testo //host:port nei messaggi della console in link e impone loro i colori del proprio tema. Il codificatore interrompeva già :// e www., ma path:line e //host:port dopo uno schema continuano a corrispondere.

    4. In analisi

      Testi come src/app.tsx:12 e http://localhost:3000 appaiono nel colore dei link di DevTools anziché con il proprio stile %c.

    Questo incidente ha interessato: Turbolog encoder.

    Postmortem

    :// e www. contengono un word joiner dalla versione 0.1.0. Le celle che devono restare cliccabili impostano l’attributo allow-link e vengono scritte senza modifiche.

    Registro delle modifiche: 0.4.0

novembre 2025

  • Pressioni dei tasti in ritardo nelle app della console4 nov – 18 nov 2025 · Risolto
    1. Risolto

      La correzione è disponibile in Text.js 0.3.0.

    2. In monitoraggio

      È stata distribuita una correzione. L’input discreto, come la pressione di un tasto o un’operazione di incolla, ora viene renderizzato in modo sincrono nello stesso task. Gli altri aggiornamenti continuano a eseguire il commit su requestAnimationFrame.

    3. Identificato

      Ogni aggiornamento, inclusa la pressione di un tasto, attende il successivo requestAnimationFrame prima che React esegua il commit e il frame venga scritto nella console.

    4. In analisi

      La digitazione nelle app della console è in ritardo rispetto alla tastiera, soprattutto in OpenCode su textjs.org.

    Questo incidente ha interessato: textjs.org.

    Postmortem

    Le pressioni dei tasti non attendono più il frame di animazione successivo. I commit che non derivano dall’input, come quelli di timer e dati in streaming, sono ancora raggruppati per frame di animazione.

    Correzione: 8c2d1b1 · Registro delle modifiche: 0.3.0