Impressive, but we should stop trying to fit a square peg into a round hole. If there's one thing the world doesn't need is JavaScript in more places.
this post was submitted on 24 Dec 2025
45 points (95.9% liked)
Programming
24030 readers
300 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Every time I consider learning more JS because it's widely used I find myself between a rock and a hard place. It's popular but it probably shouldn't be and I don't want to contribute to it being used even more for whatever mad shit is being attempted now.
Why?
The language itself is… fine. It has some bad decisions baked into it, but what language doesn’t? And it has a pretty mature security model, which is a big help for embedded devices.
And given that so many embedded devices these days are talking to cloud services — that are probably running JS, but are at least communicating via JSON — being able to share some cross-platform code or tooling can help things go quicker and/or safer.
Edit: This is probably not a route for teams that are chronically tight on memory and choose to solve that by spending hundreds of dev-hours on optimizing code rather than adding BOM cost. But for teams that could stand to increase BOM cost as long as the savings on dev-hours make up for it… it could be an option.
JavaScript doesn't have a few bad decisions baked into it, it's an absolute minefield. It was made for one thing and one thing only: making simple scripts for web pages. Anything beyond that and it becomes increasingly difficult to maintain. I honesty have no idea why devs are so hellbent on using it everywhere. Putting such an unreliable dynamic language, with absolutely no safety guards when it comes to type checking and serialization, on bare metal hardware is not something I'd ever consider in good conscience. Maybe it could be used for some IoT devices, but that's it, definitely not for something that interfaces with machinery or anything more than something like a display. TinyGo sounds like an infinitely better pick if someone wants to use a garbage collected language on an embedded device.
JavaScript for embedded, I've seen everything...
This seems similar to Espruino, wonder how it compares
I feel like people didn't make this much fuss about micro python lol