네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백
20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.
- 1
SwiftUI만으로 마크다운 문서 전체 선택 같은 기본 텍스트 상호작용을 처리하기 어렵다고 지적함
- 2
NSTextView와 TextKit 2로 내려가도 SwiftUI와의 통합, 스트리밍 성능, 현대적 UI 조합에서 문제가 생김
- 3
WebKit은 마크다운 렌더링, 타이포그래피, 제어권 면에서 훨씬 안정적으로 작동했다고 평가함
- 4
Electron은 텍스트 작업과 마크다운 렌더링, Git diff 같은 기능이 예상보다 쉽게 동작했다고 말함
- 5
채팅·장문 리치 텍스트 앱에서는 웹 기반 접근이 사실상 표준이 된 이유를 설명함
‘Electron 또 씀?’이라는 반응에 대한 꽤 날카로운 반박이다. 리치 텍스트가 제품의 핵심이면 네이티브라는 이름값보다 브라우저의 텍스트 모델이 더 실용적인 선택일 수 있다는 얘기다.
관련 기사
타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다
마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.
타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐
마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.
“98% 지원”이 생각보다 별로 안 넉넉한 이유
브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.
메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개
메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.
shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경
shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.
댓글
댓글
댓글을 불러오는 중...