SynthWave ‘84: How a VS Code Theme Hacks Core Files for Neon Glow
Hook
What if I told you that over 5,000 developers willingly corrupted their VS Code installations just to make their code glow like a 1980s arcade machine?
Context
VS Code’s theming API is deliberately constrained. You can change colors, but you can’t add text shadows, glows, or any CSS effects beyond what the editor explicitly exposes. This makes sense from a stability perspective—Microsoft doesn’t want extensions breaking the core UI. But it also means that achieving certain aesthetics is technically impossible within the official boundaries.
SynthWave ‘84 emerged from a collision of nostalgia and technical rebellion. Created as a love letter to the synthwave music scene and the neon-soaked aesthetic of 1980s pop culture, Rob Owen wanted more than just pink and cyan syntax highlighting. He wanted the text itself to glow like the signage in a James White artwork or an FM-84 album cover. Since the VS Code API wouldn’t allow it, he found another way: directly modifying the editor’s internal files. What started as an experimental joke became one of the most popular VS Code themes, proving that sometimes developers will happily accept technical friction in exchange for pure aesthetic joy.
Technical Insight
The architecture of SynthWave ‘84 is split into two distinct layers. The base theme is a standard VS Code color scheme distributed through the marketplace—this part plays by all the rules, defining token colors for HTML, CSS, JavaScript, React, and Elixir through the conventional theme JSON format. You can use this layer without any modifications to VS Code itself.
The magic—and controversy—happens in the optional glow layer. When you run the “Enable Neon Dreams” command from the command palette, the extension modifies VS Code’s internal CSS files. The implementation appears to use pure CSS to create the characteristic neon glow effect—the README explicitly states “No Shader magic. No cloud-streamed WebGL render-farms. Just plain CSS.”
The glow brightness is configurable through your settings.json:
{
"synthwave84.brightness": 0.45,
"synthwave84.disableGlow": false
}The brightness value is a float from 0 to 1 that controls the opacity of the glow effect. According to the README, “the value should be a float value from 0 to 1, where 0.0 is fully transparent.” The default brightness is 0.45. The README notes that “Changing the brightness currently only affects the opacity of the glow, the text will remain white.” To avoid eye strain, the documentation recommends avoiding higher brightness values for extended periods of time.
As of version 0.1.0, the theme became self-contained. Earlier versions required users to manually install the “Custom CSS and JS” extension and point it to a custom CSS file. The new approach bundles the activation logic directly into the theme extension itself. When you trigger “Enable Neon Dreams,” the extension modifies the necessary files. This is why Windows users may need administrator privileges and why the installation path can’t be read-only, as stated in the README: “you may need to run VS Code with administrator privileges” and “Code must not be installed in a read-only location and you must have write permissions.”
The trade-off is immediately visible: VS Code’s integrity checks detect the file modifications and display both a corruption warning dialog and an “[Unsupported]” label in the title bar. This isn’t a bug—it’s VS Code correctly identifying that its core files have been altered. The README acknowledges this head-on and even recommends the “Fix VSCode Checksums” extension to suppress the warnings. Every VS Code update overwrites the modified files, so you need to re-run “Enable Neon Dreams” after each editor update, as explicitly noted: “Every time you update VS code, you will need to repeat this step to re-enable the glow.”
What’s fascinating is the cultural signal this sends: Owen designed a theme so visually distinctive that thousands of developers are willing to dismiss integrity warnings and accept an “unsupported” label in their title bar. The implementation prioritizes aesthetic impact over technical purity, and the community response suggests that sometimes, in the realm of developer tools, delight trumps best practices.
Gotcha
The most obvious limitation is the fragility of the installation. Every single VS Code update requires you to manually re-enable the glow effect. If you’re on a monthly update cadence, that’s 12 times per year you need to remember to open the command palette and run the activation command. Miss it, and your carefully tuned neon aesthetic reverts to standard syntax highlighting. For developers who treat their editor configuration as infrastructure-as-code, this manual intervention is antithetical to reproducible environments.
Permissions become a significant barrier in enterprise settings. Many corporate environments lock down application directories or run VS Code from network shares. If you don’t have write access to the installation directory, the glow simply won’t work. On Windows, you may need to launch VS Code as administrator every time you want to enable the effect, which introduces security concerns. IT departments tend to frown upon developers running development tools with elevated privileges, and for good reason. There’s also the eye strain caveat that the README doesn’t sugarcoat: the glow effect is “experimental” and “not intended for extended use.” The README explicitly warns: “If you do decide use the glow effect, you do so at your own risk.” This is an aesthetic theme designed for screenshots, live coding streams, conference presentations, or short coding sessions where the vibe matters more than long-term ergonomics.
Verdict
Use SynthWave ‘84 if you’re creating content—streaming on Twitch, recording coding tutorials, or presenting at conferences where visual flair enhances your message. Use it for side projects and weekend hacking sessions where the nostalgic vibe genuinely makes coding more enjoyable. Use it if you have full control over your development environment and don’t mind re-enabling the glow after updates. The base theme without the glow is legitimately solid for daily HTML/CSS/JS/React/Elixir work and requires zero file modifications. Skip it if you’re in a locked-down corporate environment, work primarily in languages beyond the core supported set (the README notes “there will likely be issues for other languages”), or need a theme that survives editor updates without manual intervention. Skip it entirely if you’re uncomfortable dismissing integrity warnings or modifying core application files. And definitely skip the glow effect for marathon coding sessions unless you enjoy eye strain. This theme is proof that developer tools can be art, but art doesn’t always scale to production.
