Dwitter – Sammlung von JavaScript-Demos mit 140 Zeichen

 (beta.dwitter.net)
8 Punkte von GN⁺ 2026-01-11 | 2 Kommentare | Auf WhatsApp teilen
  • Dwitter ist eine Plattform, auf der man visuelle Demos mit JavaScript-Code von maximal 140 Zeichen erstellen und teilen kann
  • Jeder Beitrag wird als „dweet“ bezeichnet und zeigt zusammen mit dem Code sofort ausführbare grafische Animationen an
  • Nutzer interagieren über Kommentare, Remixes und Hashtags, wodurch Variationen und Neuschöpfungen von Code aktiv entstehen
  • Beliebte Inhalte lassen sich nach verschiedenen Sortierungen wie hot, new, top (Woche/Monat/Jahr/gesamt) erkunden
  • Ein Spielplatz für kreative Programmierexperimente, auf dem mit kurzem Code komplexe visuelle Effekte umgesetzt werden

Überblick über Dwitter.net

  • Dwitter.net ist eine Webplattform zur Erstellung visueller Demos mit auf 140 Zeichen begrenztem JavaScript-Code
    • Jede Demo wird als „dweet“ bezeichnet und erzeugt animierte Grafiken, die sofort im Browser ausgeführt werden
    • Nach dem Login können Nutzer neue dweets verfassen oder bestehende Werke remixen
  • Die Website bietet verschiedene Sortierungen wie hot, new, top (Woche/Monat/Jahr/gesamt), um populäre Inhalte zu entdecken
  • Jeder dweet enthält Funktionen zum Teilen, Vollbild, Melden und Kommentieren

Beispiele bekannter dweets

  • „Bubble universe colour expansion“ wird für seine vielfältigen Farben und klaren visuellen Effekte geschätzt
    • In den Kommentaren erscheinen Reaktionen wie „A whole universe!“
  • „Ants! 🐜“ zeigt mit kurzem Code einen Ameisenschwarm und erhielt Lob wie „god level dweetage!“
  • „Trees, shadows, hills.“ ist eine Animation mit Bäumen, Schatten und Hügeln und bekam Reaktionen wie „Amazing stuff!“
  • „Flight Over Destroyed City ✈️“ setzt eine Flugszene über einer zerstörten Stadt um
    • In den Kommentaren folgen humorvolle Reaktionen wie „i love the smell of sulfur and uranium in the morning“
    Anzeige
  • „Solar Orbit ☀️🌘“ setzt Planetenumlaufbahnen innerhalb von 140 Byte um und löste Staunen aus wie „How did you fit a whole planetary system in 140 BYTES OF JAVASCRIPT!?!?“

Community-Aktivität und Remix-Kultur

  • Jeder dweet kann auf Basis des Codes anderer Nutzer remixt werden, wobei ein Link zum Original angegeben wird
  • In den Kommentaren mischen sich technisches Feedback, Eindrücke und Humor, was eine lebendige Community-Atmosphäre schafft
  • Über Hashtags ist eine thematische Erkundung von #space, #galaxy, #lighting, #scene und mehr möglich

Technische Merkmale

  • Der Großteil des Codes ist in Formen wie eval(unescape(escape...)) komprimiert und setzt innerhalb des 140-Zeichen-Limits möglichst starke visuelle Effekte um
  • Im Code steht vor allem die Nutzung der Canvas-API für Formen, Farben und Bewegungen im Mittelpunkt
  • Bei jedem dweet wird die Codelänge angegeben (z. B. „// 136/140“), sodass Optimierungs- und Komprimierungstechniken eine wichtige Rolle spielen

Ein Raum für kreative Programmierexperimente

  • Dwitter verbindet Code Golf und visuelle Kunst und fördert damit einen kreativen Wettbewerb zwischen Entwicklern
  • Der Prozess, mit einfachem Code komplexe visuelle Ergebnisse zu erzeugen, wird als programmästhetisch wahrgenommen
  • Die Plattform dient als Experimentierraum, der die Grenze zwischen künstlerischem Ausdruck und technischer Komprimierung erforscht

Verwandte Beiträge

2 Kommentare

 
roxie 2026-02-27

Wirklich beeindruckend.
 
GN⁺ 2026-01-11
Hacker-News-Kommentare
  • Schön, das hier auf HN zu sehen :D
    Sorry, dass ich den Server kurz neu starten musste. Dank der Lektion vom letzten Mal habe ich die Größe des DigitalOcean-Droplets angepasst.
  • Ziemlich cool, aber wenn man nach Zeichenzahl begrenzt, entsteht ein Metagame, bei dem man multibyte Unicode-Zeichen nutzt, um ASCII-Zeichen zu komprimieren.
    Zum Beispiel kann man mit etwas wie eval(unescape(escape\<<97 wide characters>>`.replace(/u../g,'')))` 97 Unicode-Zeichen wieder in 194 ASCII-Zeichen umwandeln.
    Lieber wäre mir eine Übereinkunft wie im Dialog zwischen Ford Prefect und Mr Prosser: „Sagen wir einfach, ich habe 194 Zeichen in 140 untergebracht, und zeigen es einfach an.“
    Das ist eine ähnliche Logik wie beim 4096-Byte-Limit auf Demopartys, wo man tatsächlich mit Crinkler 12–20 KB passend komprimiert.
    • Im Beta-Frontend unter beta.dwitter.net/top gibt es einen „compressed“-Schalter, damit man es so ansehen kann, wie man möchte.
    • Man könnte das Limit auch einfach nach UTF-8-Bytes setzen, also z. B. 140 Byte.
    • 140 Byte entsprechen ungefähr 160 ASCII-Zeichen. Ohne Steuerzeichen wären sogar bis zu 170 Zeichen möglich.
    • Das ist, glaube ich, der Kommentar mit den meisten Antworten, den ich je auf HN gesehen habe :-)
    • Freut mich, jemanden zu sehen, der die HHG-Referenz (Hitchhiker’s Guide) erkannt hat.
  • Diesen Winter feiert Dwitter sein 10-jähriges Jubiläum.
    Ich habe ein altes Interview gefunden, das interessant ist: Medium-Interview
    Die eigentliche Magie steckt in der Community: Discord-Community
  • Ich habe eine Sammlung generativer Skizzen zusammengestellt, die auf Dwitter in 140 Zeichen entstanden sind.
  • Früher habe ich an einem kleinen Wettbewerb der Autohotkey-Edition von Dwitter teilgenommen und mit einer Zahnrad-Animation gewonnen.
    Animiertes GIF
    Details stehen in diesem Autohotkey-Forenbeitrag.
  • Wenn ich Seiten wie Dwitter sehe, schöpfe ich neue Zuversicht in die menschliche Kreativität.
    Mit Einschränkungen explodiert die Vielfalt eher noch: visuelle Täuschungen, kurze Sätze, Experimente in unerwartete Richtungen.
    Einschränkungen fördern Fokus und senken die Kosten des Scheiterns, wodurch sie zum Experimentieren ermutigen.
    Die meisten Plattformen versuchen, Kreativität durch zusätzliche Funktionen zu erweitern, machen sie dadurch aber oft nur komplexer.
    Ich denke oft an die Regel: Einschränkungen schaffen Spaß.
    Mich würde interessieren, wann Einschränkungen zu besseren Ergebnissen geführt haben und wann sie sich eher künstlich angefühlt haben.
  • In der Anfangszeit von Twitter war ich tief in 140-Byte-Codegolf drin.
    Diese Erfahrung hat meine Art zu denken über Code völlig verändert.
    In einer kleinen Community haben wir Byte-Spartechniken geteilt und alles Mögliche gebaut, vom Mandelbrot-Rendering bis zum Sudoku-Solver.
    Zehn Jahre später war ich völlig verblüfft, als ich in der Codebase meiner Firma eine UUID-Implementierung wiederfand, die ich damals geschrieben hatte.
    Relevante Links: YouTube-Video, Byte-saving techniques, UUID-Gist
  • Heute zum ersten Mal gelernt: 
    js_func`string`
    Das ist gültige JS-Syntax. js_func wird als tagged template literal aufgerufen.
    Ich werde jetzt wohl Dinge wie console.log\weeee`` ausprobieren.
    • Einige Bibliotheken unterstützen mit dieser Syntax JSX-ähnliche Syntax ohne Build-Prozess.
      Zum Beispiel: htm, lit.dev
    • Ich habe diese Funktion auch kürzlich in einem Bildgenerator im Code verwendet.
      Ich habe kleine SVG-Daten als Inline-Code gespeichert und so einen 13-KB-Sampler gebaut.
      Beispiellink
    • Jetzt verstehe ich endlich, warum diese Syntax bei SQL- und GraphQL-Templates verwendet wird.
      Zum Beispiel: 
      sql`SELECT * FROM users WHERE id = ${userId}`
gql`query GetUser { user(id: ${userId}) { name email } }`
  • Ich mag Dwitter, aber ich wünschte, die Nutzung von eval wäre unterbunden.
    Stattdessen hätte ich gern mehr Shortcuts. Zum Beispiel steht s für Math.sign, aber man hätte das noch weiter ausbauen können.
    • Solche Plattformen müssen erst einmal existieren, damit es überhaupt Wege gibt, die Regeln zu „brechen“.
      Wenn man es später ändert, verschwindet das feste Ziel, und damit geht ein Teil des Reizes verloren.
      beta.dwitter.net verbessert die Zugänglichkeit beim Encoding und behält trotzdem das feste Ziel bei.
      Ausnahmen wie Math.sin oder CSS-Farb-Encoder wurden aus praktischen Gründen ergänzt.
      Für Dwitter 2 gab es auch Diskussionen darüber, mehr vordefinierte Zeichen einzubauen, damit Nutzer selbst erweitern können.
      Am Ende geht es um Kreativität. Selbst das Verbiegen der Regeln ist an sich schon ein kreativer Akt.
    • Wenn man die Wertung auf UTF-8-Bytes umstellt, ließe sich das eval-Problem grundsätzlich lösen.
      Man könnte Daten zwar weiterhin in String-Literalen komprimieren, aber die Komprimierung des gesamten Codes würde abnehmen.
    • Ich nutze dwitter.net schon lange und bin zufrieden damit, dass eval erlaubt ist. Regeln sind Regeln – oder eben keine Regeln.
  • Als verwandte Beispiele: