프론트엔드

https://dev.blog.sellmate.co.kr/post/prototype-feedback-system-1/ 해당 글에서 이어지는 내용입니다. 5. 왜 HTML의 성능을 따라잡을 수 없었나 React는 애초에 “한 번에 다 그리지 않으려고” 만들어졌다 4장에서 나는 하나의 기능을 찾고 있었다. 링크를 열자마자 React가 모든 화면의 DOM을 한 번에 다 지어놓고 멈춰주는 방법. 그게 왜 없는지는 React가 왜 만들어졌는지를 보면 답이 나온다. React 이전의 방식을 떠올려보자. JS로 DOM을 직접 조작하는 방식이다. 함수를 실행하면 HTML에 DOM 객체가 추가되고 지워지고 값이 바뀐다. 데이터가 바뀔 때마다 개발자가 직접 이번엔 어느 DOM을 어떻게 고칠지를 계산해서 하나하나 손댄다. 화면이 단순할 때는 이게 문제가 안 된다. 그런데 화면이 복잡해지면 데이터와 화면이 어긋나기 시작한다. 데이터는 바뀌었는데 고치는 걸 빼먹은 화면 한 구석에만 옛날 값이 남아 있거나 갱신 순서가 꼬여서 앞뒤가 안 맞는 상태가 된다. 이렇듯 고칠 곳을 사람이 추적하는 한 화면이 커질수록 빼먹는 곳도 늘어난다. ...

사내 프로토타입 피드백 도구를 만들면서 겪은 시행착오와, 그 과정에서 깨달은 것에 대한 기록 1. 시작은 Slack에 흩어진 HTML 파일들이었다 현재 제가 진행하고 있는 프로젝트와 팀의 프로토타입 공유 방식은 단순했다. 기획자나 개발자가 HTML로 프로토타입을 만들어 Slack에 파일로 올리고 확인한다. 끝. flowchart LR A["기획자HTML 프로토타입 제작"] --> B["Slack에 파일 업로드"] B --> C["며칠 뒤'그 프로토타입 말인데요'"] C --> D["Slack 검색파일 재탐색"] D --> E["수정할 위치를말로 특정해야 함"] E --> F1["장문의 Slack 메시지"] E --> F2["결국 대면 미팅"] F1 --> G["피드백은 시간순으로만 존재버전 개념 없음"] F2 --> G 이 구조가 만든 불편은 크게 세 가지였다. ...