Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It occurs to me that "WebScript" actually solves another tricky problem: describing the thing people mean when they say JavaScript, vs. the thing JavaScript actually, technically, is. You see, technically, JS doesn't have half the functionality you're used to, like WebSockets, TextEncoder, fetch, or even something as simple as the URL class. In fact, JS does not technically even "fully" support ESM modules, as major portions of that standard are delegated to other Web Platform APIs.

There's good reasons for all of this of course, but from an end user perspective, it's pretty confusing that URL is not part of JS but encodeURIComponent is. And Uint8Array is part of JS but TextEncoder isn't. But the cool thing is that increasingly no one needs to worry about that because the non-browser JS runtimes have settled on the idea that they should implement the Web Platform APIs. So as a developer, you can just act as if WebSockets is part of JavaScript.

But there's no good name for this “collection" of standards that are together commonly accepted to be "JavaScript". No one says "JavaScript with browser-compliant modules and WebWorker additions…”, and even saying “ECMAScript with the Web Platform Additions” is a mouthful. But you know what does convey “ECMAScript, the way you're used to it in browsers”? WebScript.

This very much makes the case for not using ECMAScript, since ECMAScript still has a separate meaning. It is the pure language spec. Useful as a term for spec writers, pedantic everywhere else. Meanwhile, "WebScript" formalizes what people were sometimes (but not always) bending "JavaScript" to do before, and thus actually does add "new utility" to the terminology, vs. just being a replacement synonym that avoid legal issues.






Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: