읽은 글들 (~22.12.3)
JavaScript
자바스크립트에서 안전하게 난수 생성하는 방법
Math.random()
은 진짜 난수가 아닌 의사 난수를 생성하고, 이는 보안적으로 안전하지 않다. 따라서 안전한 난수를 생성하기 위해서는 Web Crypto API 를 사용해야 한다.
(번역) 자바스크립트에서 영역(realm)이란 무엇인가요?
자바스크립의 영역(Realm)에 대해 설명한 글.
영역은 별도의 전역 실행 환경과 전역 객체, 고유 객체, 그리고 자바스크립트 코드를 갖는 영역을 말한다. 글에서는 "생태계"라고 표현하고 있다.
브라우저는 기본적으로 하나의 고유한 영역을 갖지만 두 개 이상의 영역을 가질 때도 있다. iframe 을 사용했을 때가 대표적인 예로, 부모와 iframe 은 서로 다른 영역을 갖게 된다.
이 말은 각자 별도의 전역 실행 환경과 전역 객체, 고유 객체, 자바스크립트 코드를 갖는다는 말로, 그냥 봤을 때는 같아보이는 것이 다르게 판단될 수도 있다는 것이다.
글에 나온 인상적인 예 하나를 첨부한다.
<html>
<iframe id="blue_buttons_iframe">
<script>
window.top.createBlueButton = function (text) {
const button = document.createElement("button");
button.style.color = "blue";
button.value = text;
return button;
};
</script>
</iframe>
<body>
<script>
const blueButton = window.createBlueButton("my blue button");
if (!blueButton instanceof HTMLButtonElement) {
// <- 이 조건문의 결과는 true 다!
throw new Error(
"blue button created does not seem to actually be a button element!"
);
}
document.body.appendChild(blueButton);
</script>
</body>
</html>
Why We're Breaking Up with CSS-in-JS
CSS-in-JS (styled-components, emotionjs 같이 js 코드로 작성하는 CSS) 의 장단점을 소개하고, 글쓴이의 팀에서 왜 CSS-in-JS 를 버리고 CSS 로 갈아탔는지 설명하는 글.
글에 나온 장단점을 요약하자면 아래와 같다.
장점 (The Good)
- Locally-scoped 스타일
- 컴포넌트와 스타일을 한 파일에 묶어서 관리 (Colocation)
- CSS 에 자바스크립트 변수 사용 가능
단점 (The Bad)
- 런타임 오버헤드 - CSS-in-JS 를 CSS 로 변환해 document 에 삽입하는 과정 필요
- 번들 사이즈를 늘림 - emotionjs, styled-components 등이 포함되어야 하니까
- css() 를 사용하면 dev-tools 에서 확인할 때 컴포넌트 계층 구조가 지저분해짐
나쁜점 (The Ugly)
- 빈번한 CSS 삽입으로 인해 브라우저가 할 일이 늘어남
- SSR 에 완벽한 대응이 안 됨 (상황에 따라 초기화가 제대로 안 되는 이슈가 있을 수 있음)
결과적으로 글쓴이의 팀에서는 성능 때문에 CSS 로 갈아탔다고 하는데, 성능을 분석한 내용도 있으니 궁금하다면 본문을 참고하자.
HTML
Should I put input elements inside a label element?
<input />
과 <label />
을 조합할 때 어떤 형식을 많이 쓰는지 궁금해서 검색하다가 본글.
<!-- 1 -->
<label for="myinput"
>My Text
<input type="text" id="myinput" />
</label>
<!-- 2 -->
<label for="myinput">My Text</label>
<input type="text" id="myinput" />
대부분은 2번을 선호하지만 id 를 생략할 수 있다는 이유로 1번을 쓰는 사람도 있는 모양이다.
Etc
How we lost our slick new npm package name (and then got it back)
npm 의 비슷한 이름의 패키지는 등록할 수 없는 보안 정책 때문에, 양도받은 패키지를 날려버릴 뻔한 경험을 공유한 글이다. 이미 등록된 패키지는 해당 보안 정책의 영향을 받지 않는데, 글쓴이 가 양도받은 패키지를 unpublish 하는 바람에 패키지가 내려갔고, 그래서 이미 있는 다른 비슷한 이름의 패키지 때문에 보안 정책에 걸려서 재등록이 불가능해진 것이다. (결국에는 npm 쪽과 이야기해서 잘 해결했다고 한다.)
개발자 경험(Dex)이 주목받는 시대
다른 글을 읽다가 자꾸 "DX"라는 말을 쓰길래, "DX"가 대체 뭐지 하고 찾아본 글. 개발자 경험 (Developer Experience) 을 의미하며 개발자가 일하며 마주하는 여러가지 환경요소로 인해 얻게 되는 경험을 말한다. 사용자 경험 (UX) 의 개발자 버전으로, 좋은 개발자들의 이직을 막기 위해 좋은 경험을 제공해야 한다는 맥락에서 시작된 말 같다.
그냥 개발 문화에 대해 이야기한다고 봐도 될 것 같다.
글에 좀 더 자세한 설명이 쓰여있다.
Introducing the Overflow Offline project
네트워크 접속 환경이 열악한 지역을 위해 스택오버플로우가 비영리단체와 손잡고 오프라인 버전을 만들었다고 한다.