GitHub - microsoft/poml: Prompt Orchestration Markup Language
MS가 프롬프트 엔지니어링에 구조, 유지보수성을 제공하기 위해 고안한 마크업 언어입니다.
<role>
, <task>
같은 HTML 유사 문법으로 모듈화된 설계를 할 수 있고, <table>
, <image>
같은 요소들로 외부 데이터를 유연하게 통합할 수 있어요. VSCode Extension도 제공하고 있고요.
예전에 봤던 것 중 JSX를 가지고 비슷한 시도를 한 라이브러리가 떠오르는데요, 이렇게 마크업을 통해 프롬프트를 작성하는 것이 표준이 될까요?
pnpm 10.14 | pnpm
pnpm이 이제 devEngines.runtime
옵션에 Node.js, Deno, Bun 등을 선택하면 해당 런타임을 프로젝트 내에 설치해줍니다.
워크스페이스 내 각 프로젝트마다 다른 런타임을 쓸 수 있고, 나중엔 컴퓨터 내 공유 위치에 설치되도록 개선될 예정이라고 하네요.
A11y Fundamentals Playground
토스에서 frontend-fundamentals에 계속 내용을 붙여나가네요. 저번엔 번들링에 대한 내용이 추가됐었는데 이번엔 웹 접근성입니다.
위 링크에는 스크린 리더를 직접 체험할 수 있게 해놨는데, 모바일에서 어떤식으로 사용되는지 볼 수 있어서 좋아요.
Accessibility Support
사용하려는 웹 접근성 기술이 얼마나 다양한 스크린리더, 브라우저에서 동작하는지 정리한 서비스입니다.
아직 데이터가 많지 않아 보이지만, Can I Use 같은 느낌으로 참고할 수 있을 것 같아요.
Remote functions • Docs • Svelte
Svelte도 React의 Server Component 비슷한 개념을 가지고 왔네요.
이쪽은 query
, form
, command
, prerender
네가지로 구분지어 다루도록 더 세분화 돼있어요.
GitHub - codpro2005/ts-regexp: A strictly typed & minimal RegExp wrapper.
typesafe RegExp 래퍼!
GitHub - typescript-eslint/tsgolint: ✨ Experimental proof-of-concept typescript-go powered JS/TS linter written in Go
typescript-eslint에서 Go로 포팅된 TypeScript Parser를 활용해 내놓은 POC 프로젝트입니다.
기존 대비 20 ~ 40배의 속도 향상을 목표로 하고 있다고 해요.
GitHub - tc39/proposal-composites
중첩된 객체를 불변으로 생성할 수 있도록 하자는 records / tuples proposal이 있었는데요, (사용례를 잘 설명한 글 참고) 이게 stage 2까지 올라갔다가 거절됐어요.
대신 Composite라는게 논의되고 있네요.
Composite는 두 객체가 동일한 key value 쌍을 갖고 있는지를 보고 비교가 가능하도록 도와줘요.
5 things I learned from 5 years at Vercel | Lee Robinson
Vercel이 30명이던 시절부터 650명이 있는 지금까지 5년동안 일하신 분의 퇴사 기념 회고 글입니다.
좋은 인사이트가 많아요. 원문으로 읽어보시길 추천드려요!
Next.js 15.4
Next.js 15.4 나오면서 16에 대한 얘기를 시작하네요.
next/image
API 변경 있을 예정React Router and React Server Components: The Path Forward
React Router RSC 프리뷰 관련 후속 글입니다.
Framework Mode를 사용하지 않아도 Data/Declarative Mode 상태로 RSC 사용이 가능하게 될 거라고 해요.
Framework Mode를 사용할 이유가 줄어들었네요.
GitHub - microsoft/markitdown: Python tool for converting files and office documents to Markdown.
모든 문서를 마크다운으로 변환해줘요. MCP도 제공하네요.
컨텍스트 변질: 입력 토큰이 많아질수록 LLM 성능이 어떻게 변하는가 | GeekNews
LLM이랑 대화할 때 솔직히 아무렇게나 막 넣고 잘 대답해주길 바란 적이 많았는데, 제대로 질문하는게 정말로 중요하긴 한가보네요.
JavaScript scope hoisting is broken
번들러들은 코드를 하나로 합칠 때 'scope hoisting' 과정을 거치는데요, 쉽게 말해서 모든 모듈을 전역 스코프로 모으는 겁니다.
원래는 합칠 때 전역 스코프에 싹다 긁어오는게 아니라 각 모듈을 함수 래퍼에 담아서 별도의 스코프로 격리했는데요.
이런 함수 래퍼가 불필요한 런타임 오버헤드를 만드니, 그걸 줄이겠다는 이유로 scope hoisting이라는 방법을 쓴거죠. (거기 더해 변수, 함수가 같은 스코프에 모여있어서 minify, 트리셰이킹도 잘 된다는 장점도 있고요.)
문제는 dynamic import 등의 방법으로 모듈을 여러개로 분리하면서 생기는데요, 이 글에서는 정확히 어떤 문제가 있는지 짚어줍니다. (사이드 이펙트의 실행 순서를 보장할 수 없다, this가 이상하게 들어간다 등)
How does Facebook serve React pages? : r/reactjs
페이스북은 리액트를 어떻게 서빙하고 있는가?
정적 파일: 바벨로 컴파일, 사내용으로 만든 MakeHaste라는 자체 번들러 사용, i18n / AB 테스트 값들은 빌드 시점에 집어넣음. 즉, 한국어 빌드, Case별 빌드가 따로 나온다는 얘기고, 런타임에 서버에서 해당 플래그 조합을 반영한 번들을 생성, 캐싱하여 제공함. CDN으로 서브.
동적 HTML/JS: Hack이라는 PHP 파생 언어 사용(자기들이 만든듯), 웹 어플리케이션 프레임워크는 사내용으로 만들어서 씀, SSR은 Hermes라는 JS 엔진 사용(이것도 자기들이 만듦)