1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
# 017 — 웹 레이아웃을 복제하지 않는 문서 작업
**범위 정정 — 2026-09-23:** 아래 결과는 브라우저 호스트에 한정한다. Pure의 목표는 앱 로직·
net·RPC·DB·UI를 다루는 독립 네이티브 애플리케이션 런타임이다. UI는 일부다.
웹 호환성을 브라우저에 레이아웃·편집을 맡기는 것으로 해석한 것은
Codex의 오류다. 이 실험의 기능 검증은 보존하지만, Pure 자체의 레이아웃·텍스트·입력 체계가
불필요하다는 근거로 사용하지 않는다. 현재 구현 방향은 [010 로드맵](010-roadmap.md)을 따른다.
2026-09-23. 일반 텍스트를 열고 편집·읽기·저장하는 화면에 Pure를 연결했다.
**이 작업에서는 레이아웃 트리·텍스트·스크롤 위치를 VM으로 옮길 필요가 없었다.**
크기 변경과 줄바꿈은 브라우저가 처리하고, Pure에는 사용자가 정한 패널 비율 하나만 둔다.
이것은 실제 UI 조건을 확인한 구현·기능 검증이다. 전체 메모리 절감, 새로운 압축 원리,
대규모 앱 성능 우위의 증거는 아니다. 화면 하나의 분할 비율을 위해 VM을 추가할 성능상의
근거도 얻지 않았다. 기존 실행 규칙을 표준 웹 호스트에 연결하는 경계를 확인한 단계다.
## 직접 확인하기
기존 작업 화면을 새로고침하고 **문서 편집 · 반응형 레이아웃 작업 화면** 링크를 연다.
직접 주소는 서버의 `/document.html`이다.
1. 일반 UTF-8 `.txt` 파일을 열거나 빈 문서에 작성한다. **예제 문서**도 있다.
2. 가운데 경계를 끌거나 방향키·슬라이더로 두 패널의 폭을 조절한다.
3. 조작 중 창 크기를 바꾸거나 Esc로 취소한다. 좁은 화면에서는 두 패널이 위아래로 놓인다.
4. 양쪽을 독립적으로 스크롤하고, 텍스트를 고치고 실행 취소한다.
5. `.txt 저장`으로 다른 편집기에서도 읽을 수 있는 파일을 내려받는다.
6. **분할 규칙 수정**에서 `clamp(event_value,20,80)`을 `clamp(event_value,30,70)`으로
바꾸어 적용한다. HTML 어댑터를 바꾸지 않아도 같은 컨트롤의 제한이 바뀐다.
파일은 텍스트만 저장한다. 패널 비율·Pure 규칙을 묶는 자체 문서 형식은 만들지 않았다.
임포트/익스포트는 파일당 2 MiB까지이고, UTF-8 오류는 현재 문서를 유지한 채 거절한다.
브라우저 textarea의 줄바꿈 정규화 때문에 저장은 LF·BOM 없음으로 이루어진다.
원본 파일의 모든 바이트를 그대로 보존하는 편집기라는 뜻은 아니다.
## 어디에서 무엇을 소유하는가
| 자료/작업 | 소유자 | 연결에서 하는 일 |
|---|---|---|
| 작성 중인 텍스트·선택·실행 취소 | 브라우저 기본 textarea | 입력 후 읽기 화면에 텍스트 전달 |
| 읽기 화면의 글자 배치·줄바꿈·스크롤 | DOM/CSS/브라우저 | 문서가 바뀔 때만 텍스트 갱신 |
| 패널의 실제 크기·좁은 화면 배치 | CSS Grid/media query | 비율 하나를 CSS 변수로 전달 |
| 사용자가 요청한 분할 비율의 정책 | Pure 숫자 상태·규칙 | range/포인터/키보드가 같은 숫자 입력을 사용 |
| 접촉 소유권·취소 시작값·기하 캐시 | 브라우저 어댑터 | 조작 시작과 무효화 뒤 필요한 좌표만 읽음 |
문서 크기나 줄 수가 늘어나도 이번 정책의 VM 상태는 비율 하나다. viewport width,
DOMRect 배열, 텍스트 AST, 스크롤 위치를 VM 상태로 복제하지 않는다. 레이아웃 연산이
없어진 것은 아니다. 브라우저가 그 연산과 관련 저장 공간을 담당한다.
읽기 화면은 textarea와 별도의 텍스트 표현을 갖는다. 따라서 **제로 카피 문서 모델은 아니다.**
별도 JS 문서 모델과 Wasm 문자열 사본은 만들지 않았지만, 브라우저 내부의 텍스트·undo·
레이아웃 저장 공간과 파일 읽기/인코딩의 임시 버퍼는 여전히 필요하다.
## 필요한 경계만 추가했다
기존 실행기는 키·포인터·프레임 입력은 받았지만 네이티브 숫자 컨트롤의 값을 직접 받을
경로가 없었다. 다음 입력을 추가했다.
```text
state ratio = 50
input split = value
on split.change { ratio = clamp(event_value,20,80) }
```
호스트는 `runtime.change('split',65,'range')`, CLI는 `change split 65`를 사용한다.
값은 유한한 숫자이고 사건 동안만 존재한다. 규칙이 저장한 값만 상태가 된다.
기존 원자적 이벤트 실행·실패 취소·공유 규칙·표시 캐시 무효화를 그대로 사용한다.
문서 호스트는 HTML로 출력하므로 가짜 도형 선언이나 SVG 장면을 만들지 않는다.
출력 도형이 없는 프로그램에서는 사용하지 않는 표시값 배열도 생성하지 않도록 했다.
[정의](../../prototypes/workbench/examples/document.pure)의 실제 표현은 상태 1개,
입력 2개, 반응 2개, 명령 7개다. 활성 상태는 8 B, 명령·연결은 144 B다.
하지만 코어는 여전히 **20,064 B를 예약하고 Wasm 선형 메모리는 64 KiB**다.
이 숫자는 브라우저 앱 전체 메모리가 아니며, 작은 상태만으로 전체 효율을 주장하지 않는다.
포인터 이동은 프레임당 마지막 좌표만 전달한다. 놓을 때 대기 중인 이동을 먼저 처리하고,
취소는 시작 비율로 복귀한다. 크기 변경·스크롤은 기하 캐시를 무효화하지만 그 콜백에서
레이아웃을 읽거나 쓰지 않는다. 다음 조작이 실제로 필요할 때 읽는다.
관찰된 0회는 애플리케이션의 해당 API 호출 수이며 브라우저 내부 레이아웃 비용 0을 뜻하지 않는다.
## 확인한 것과 한계
- 네이티브 37개, Node/CLI 87개 검사 통과. 새 숫자 사건의 컨텍스트, 잘못된 입력,
비유한 수, 여러 반응의 실패 원자성, 공유 규칙, 캐시, 저장·복원을 포함한다.
- 문서 브라우저 검사 32개: 창 크기 변경·독립 스크롤·네이티브 컨트롤·실제 마우스와
CDP 터치·조작 중 resize·취소·표준 파일 다운로드와 새 페이지 왕복·늦게 끝난 파일 읽기
거절·Unicode 편집·네이티브 undo·미완성 조합 중 출력 보류·규칙 수정·Wasm 실패 시 문서 기능 유지.
- 기존 작성 흐름 44개도 통과했다. 기본 화면의 숫자 입력 컨트롤 3개, 잘못된 출력·조작 중 교체·파일 크기 등의
추가 확인 6개도 통과했다.
- 창 크기 변경과 스크롤에서 Pure 이벤트·문서 재전달·앱 기하 읽기가 증가하지 않음을
확인했다. 비율 변경도 문서 재전달을 일으키지 않는다. 이는 소유권 검증이며 속도 비교가 아니다.
환경은 Linux Chromium이다. 한글 조합의 순서는 합성 composition 사건으로 확인했고,
실제 운영체제 IME·물리 모바일 기기·전체 접근성 적합성을 검증한 것은 아니다.
분할 조작은 [W3C의 separator 의미와 키보드 지침](https://www.w3.org/WAI/ARIA/apg/patterns/windowsplitter/)을
참고했다. 포인터 캡처·취소는 [Pointer Events](https://www.w3.org/TR/pointerevents3/),
크기 관찰 경계는 [Resize Observer](https://drafts.csswg.org/resize-observer/)를 참고했다.
표준을 재발명한 것으로 세지 않는다.
[검증 자료와 재현](../../prototypes/workbench/results/2026-09-23-web-layout/README.md),
[실행 계약](../../prototypes/workbench/CONTRACT.md),
[문서 호스트](../../prototypes/workbench/web/document.mjs),
[입력 어댑터](../../prototypes/workbench/web/split-input.mjs).
## 당시 결정의 정정과 남은 한계
당시 ‘기존 환경과의 경계가 이미 목적을 충족하므로 자체 레이아웃을 추가하지 않는다’는
결론은 철회한다. 브라우저를 필수 기반으로 삼은 이 구현은 독립 네이티브 UI 목표를 충족하지
않는다. 현재 HTML 화면은 직접 작성한 호스트이며 현재 DSL이 일반 UI 전체를 표현하지도 않는다.
Pure의 UI 체계가 배치·입력·출력을 소유하는 일은 애플리케이션 런타임 구현의 일부다.
다음 우선순위는 로드맵의 실행·수명 계약과 UI·RPC·DB를 연결하는 실제 작업을 따른다.
이는 모든 기능을 현재 VM에 넣거나 새 문서·미디어 포맷을 먼저 만들겠다는 뜻은 아니다.
남아 있는 구체적 비용은 **텍스트 한 부분을 편집해도 읽기 화면의 전체 문자열을 갱신하는 것**이다.
좁은 화면에서 읽기 패널이 보이지 않을 때도 지금은 갱신한다. 이 웹 호스트의 추가 최적화는
미룬다. 표준 파일 왕복·숫자 입력·취소 등의 동작은 네이티브 구현에서 참고하되, DOM/CSS에
맡긴 비용이 제거됐다고 계산하지 않는다. 표준 파일을 포기하거나 새 포맷의 우위를 가정하지 않는다.
|
