When every layer of the stack somehow ends up being JavaScript
Description
Five vertically-stacked frames from a TV interview show a decorated official standing in front of a busy community-meeting room. His face is blurred, but his uniform features gold epaulettes and a multi-color sash; he gestures more emphatically in each successive panel. White overlay text changes per frame: “Backend? Javascript.”, “Frontend? Javascript.”, “Styles? Javascript!”, “CI? Javascript.”, and finally “Infrastructure? Believe it or not, also Javascript.”. The meme humorously points out the language’s ubiquity - Node .js on the server, React on the client, CSS-in-JS for styling, JavaScript-based CI pipelines, and even infrastructure-as-code tools like the AWS CDK - illustrating how modern engineering teams can unintentionally create a single-language monoculture
Comments
30Comment deleted
If every layer speaks JavaScript, congratulations - you’ve traded polyglot complexity for the existential thrill that a single compromised npm package can now deploy straight to prod, style the error page, and break the build in one push
We've successfully abstracted away all the complexity of polyglot architectures into a single point of failure: npm install
When your entire tech stack is JavaScript, you don't have polyglot problems - you have a monoglot monopoly. From Express handling your API routes to React rendering your UI, styled-components managing your CSS, GitHub Actions running your CI pipeline, and Pulumi provisioning your cloud infrastructure, it's JavaScript all the way down. The real question isn't 'Can we use JavaScript for this?' - it's 'What's left that we haven't JavaScripted yet?' Spoiler: your coffee machine is next, and yes, there's already an npm package for that
JavaScript: full-stack isomorphism achieved, from DOM to deployments - bundle sizes and type errors as the price of empire
When “npm run” becomes your control plane - from CSS‑in‑JS to CDK deploys - you’ve basically built an entire company on a package‑lock
JavaScript everywhere: consolidating every failure domain into a single package-lock.json
JPEG only! No thinking required! Comment deleted
JavaPEG Comment deleted
I never use jpg by choice. Either I am forced to or there is nothing better Comment deleted
What is your preference for photos when file size does matter? Comment deleted
Not taking photos then Comment deleted
Idc if a photo is 500MB if its a PNG Comment deleted
There are also people who download flacs and they are like 200MB Comment deleted
I try to use webm or even avif where possible Comment deleted
JPEG sucks Comment deleted
jpeg is pretty ok at what it does, people just keep misusing it Comment deleted
telegram be like Comment deleted
It's pronounced "PNJ" Comment deleted
What is the name for that feeling, when your eyes feel pain while reading text on jpeg? That's jpegging! Comment deleted
Jeff Atwood be like Comment deleted
I don’t understand the last one….infra in JS? JS container ? Comment deleted
yup js container. Comment deleted
it does take a good while to encode, aye… Comment deleted
You see? PNGs are not treated as "native" images by Telegram, but merely as "files with view capability" (sounds similar to "people with disabilities"). Comment deleted
Looooool no its a visual sign that its a lossless file Comment deleted
I see it as a pro Comment deleted
Telegram has a similar system to vk, send as file or send as photo Comment deleted
That I'm saying is that Telegram considers that only photographical images are eligible for embedding, and thus uses JPEG compression unconditionally. PNGs are only allowed as generic attachments. Comment deleted
girlfriend? JavaScript Comment deleted
pulumi really is a great tool tho its TS not JS Comment deleted