Soon We Can Banish JavaScript to the ShadowRealm
TC39에서 제안 중인 ShadowRealm API는 JavaScript 실행 환경인 realm의 새로운 형태로, 별도의 스레드를 사용하지 않고도 코드 격리를 가능하게 한다. ShadowRealm은 독립적인 전역 객체와 내장 객체를 가지며, 메인 스레드에서 실행되지만 외부 realm과 전역 상태를 공유하지 않아 전역 오염 문제를 해결할 수 있다. 이를 통해 테스트 격리, 서드파티 코드 분리 등 다양한 활용이 기대되며, 현재는 표준이나 브라우저에 구현되지 않은 이론적 개념이다.
https://css-tricks.com/soon-we-can-finally-banish-javascript-to-the-shadowrealm/
Why is ` not allowed in JS object property definitions.
const a = { `thing`: `value` } // OH NO ERROR!
Why???
const a = {};
a[`thing`] = `value // THIS IS COOL!
const a= `thing`;
const b = { [a]: `value` } // THIS IS ALSO COOL!!
... are strings just too hard, #tc39
JavaScript's Date object has been a source of bugs for three decades. Temporal, which just reached Stage 4, is a modern replacement with immutable types, first-class time zone and calendar support, and nanosecond precision. This is the story of how Bloomberg, Igalia, and the TC39 community spent nine years turning an idea into a shipping standard.
I feel like the currently-proposed TC39 Observables lacking some value that can be supplied upon "completion" is a mistake.
Am I the only one to think that it's good that cancellable promises never made it into any specs whatsoever?
Getting information about the status of #TC39 proposals is a horrible process: As a developer, I want to know how far along the "Pattern matching" feature is.
So I google "TC39 Pattern Matching". First result is this GitHub repo: https://github.com/tc39/proposal-pattern-matching. It says in the readme "Status: Stage 1" (I assume that's not true anymore). So I check the official "proposals" repo (https://github.com/tc39/proposals), and search for "pattern": Nothing, no results at all. I guess they only track Stage 2.
Every so often I get an email notification from some starred bug report about TC39 decorators, and I peek at what's going on, and it seems like the current situation is that it's fully standardized but all 3 browsers went "This is complicated and we don't feel like implementing it" 😞
Promise.try: единый вход для sync/async и единая обработка ошибок
Привет, Хабр! Не раз ловил себя на том, как в код-ревью всплывает одна и та же проблема: часть наших функций синхронные, часть асинхронные, а часть ведут себя как шрёдингеровские коты и делают вид, что синхронны, пока не дотронешься. В итоге в одном месте у нас try/catch, в другом .catch , где-то внезапно падает исключение, а в соседнем модуле молча утекает Promise. С появлением нативного Promise.try стало проще навести порядок и избавиться от разнобоя. Фича прошла процесс стандартизации в TC39 и включена в спецификацию ECMAScript 2026, при этом уже с января доступна в актуальных движках. Можно перестать спорить про обёртку из Promise.resolve().then и получить единый вход для sync/async с нормальной обработкой ошибок.
https://habr.com/ru/companies/otus/articles/940298/
#js #Promisetry #JavaScript #ECMAScript_2026 #TC39 #синхронный_код #асинхронный_код
sayzard
Pomax
N-gated Hacker News
GripNews
Sal Rahman
Moritz
斎藤ただし
Darryl Pogue
Habr