HN 공개: 놀라운 실험을 목격하여 간단한 버전을 만들었습니다
(github.com/Momciloo)- 이 저장소는 Björn Staal의 작업에서 영감을 받아 만든 간단한 코드 실험이며, 원본 아이디어에 대한 추가 정보 링크를 함께 제공함
- 로컬 실행은
npm i후 터미널 2개를 열어 하나는 서버, 다른 하나는 클라이언트 정적 서버를 실행하는 방식임 - 서버는
node server/server.js로 실행하고, 클라이언트는cd client && http-server로 실행함 - 실험 확인은 브라우저 탭 2개에서
localhost:8080?b=1과localhost:8080?b=2를 각각 여는 방식임 - 향후 계획에는 localStorage 전용 모드, 무한 개수 창 지원과 URL 쿼리 제거, WebRTC 전환이 포함됨
프로젝트 개요
Momciloo/fun-with-sockets는 Björn Staal의 작업에서 영감을 받은 간단한 코드 탐색 프로젝트임- 원본 아이디어에 대한 추가 정보는 LinkedIn 게시물로 연결됨
- README에는 실험 화면 녹화 이미지가 포함되어 있음
로컬 실행 방법
- 먼저 의존성을 설치함
npm i
- 터미널을 하나 더 열어 총 2개의 터미널을 사용함
- 첫 번째 터미널에서 서버를 실행함
node server/server.js
- 두 번째 터미널에서 클라이언트 디렉터리로 이동한 뒤 정적 서버를 실행함
cd client && http-server
- 브라우저에서 두 개의 탭을 열어 각각 다른 쿼리 값을 사용함
localhost:8080?b=1localhost:8080?b=2
향후 아이디어
- localStorage 모드만 실행할 수 있는 플래그 추가를 계획함
- 무한 개수의 창을 지원하고 URL의 쿼리 필요성을 제거하는 옵션을 계획함
- 구현 방향을 WebRTC로 옮기는 계획이 있음
댓글과 토론
Hacker News 의견들
-
멋진 데모임. 다중 모니터에서는 어떻게 동작할지 궁금함
또 다른 사람에게서 직접 영감을 받았다고 자발적으로 밝히고 출처를 인정한 점이 좋음. 소프트웨어 업계에 이런 사람이 더 많아졌으면 함- 원 제작자가 다중 모니터에서 동작을 시연한 영상이 있음: https://twitter.com/nonfigurativ/status/172798055677504755...
-
Krita, Inkscape, Gimp 같은 페인트 프로그램에서 레이어 관리에 이런 방식이나 비슷한 방식이 유용할 듯함
전체 애플리케이션 창 안에 탭 패널로 간단히 구현하고, 선택된 탭의 레이어가 편집 작업의 활성 레이어가 되게 만들 수 있음 -
예전에도 창의 위치와 크기를 활용한 데모가 꽤 있었던 게 기억남. 물리 시뮬레이션 데모도 있었는데, 액체였는지 여러 고체였는지는 기억나지 않지만 한 창에서 다른 창으로 물체를 떨어뜨릴 수 있었음
소켓까지 필요하지 않고 창 사이의 메시지 채널만으로도 가능할 것 같음. 창이 자식 창을 열면 보통 서로 격리되는 탭/창과 달리 특별한 접근 권한이 있어서, 로컬 전용 버전도 쉽게 만들 수 있어 보임- Browser Ball일 수도 있음: https://experiments.withgoogle.com/browser-ball
-
이런 걸 좋아한다면 WindowKill도 재미있을 수 있음. Asteroids와 비슷한 비디오 게임인데, 서로 겹치고 상호작용하는 여러 창을 영리하게 사용함
창 경계도 쏴야 하고, 그러지 않으면 창이 줄어듦. 게임 후반에는 보스 적이 들어 있는 추가 창도 나타남
플레이 영상: https://youtu.be/7iP68FZWVxM -
원작 Bjorn Staal의 트윗 링크가 사라졌는데, 이게 무엇이었는지 볼 수 있는 링크가 있는지 궁금함
- 끝자리 숫자가 하나 빠져 있음. 원래 트윗은 여기임: https://twitter.com/nonfigurativ/status/172732259457002734... / https://nitter.net/nonfigurativ/status/1727322594570027343
- GitHub에도 링크가 있지만 영상은 여기 있음: https://www.linkedin.com/feed/update/urn:li:activity:7133171...
-
브라우저 창으로 Pong을 하는 멋진 데모가 떠오름: http://stewd.io/pong/
-
이게 무슨 뜻인지 설명해줄 수 있는지 궁금함. GitHub 페이지의 GIF도 제대로 이해했는지 모르겠고, 그냥 창들이 데이터를 공유하는 것처럼 보임
- 핵심은 창끼리 통신한다는 점보다, 브라우저 API로 창 좌표를 드러내서 쓴다는 데 있음
- 여러 클라이언트와 단일 서버 구조처럼 보임. 각 창이 개별 클라이언트이고, 화면 기하 정보를 서버에 보내면 서버가 클라이언트별로 다른 배치를 내려서 콘텐츠가 여러 창에 걸친 하나의 객체처럼 보이게 만드는 방식 같음
-
멋짐. 포커스된 창의 사각형이 맨 위에 그려지는 편이 자연스러워 보임
- 단순히 투명도를 쓴 게 아니라는 걸 보여주려고 그렇게 한 것 아닌가 싶음
-
그런데 왜 지연이 생기는지 모르겠음. 이 정도면 즉시 처리될 만큼 단순해야 하지 않나?
- 브라우저 안에서 돌아가기 때문임. 단순한 마우스 이동과 단순한 객체 좌표 변경 사이에도, 이벤트를 해석 또는 컴파일된 코드로 전달하고 상태 변화를 화면까지 보내는 시스템·애플리케이션 계층이 많이 끼어 있음
네이티브로 가도 서로 다른 두 창을 즉시 똑같이 움직이게 하는 건 항상 사소하지 않음. 예를 들어 일부 GUI 툴킷은 부드러운 창 크기 조정을 불가능하게 만든다는 글도 있었음. 모든 것을 직접 만들더라도 시스템이 창에 빠르게 알리고 화면에 비트맵을 밀어 넣을 만큼 성능이 충분하길 기대해야 함. 더 나은 방법은 시스템 전체 소프트웨어/하드웨어 합성기를 쓰고, 객체별 레이어를 추가한 뒤 좌표만 바꾸는 것인데, 이때도 합성기가 필요할 때 초당 60/120/144회 이상의 갱신을 감당할 만큼 좋아야 함 - 창 위치 조회가 안타깝게도 느림. 브라우저 기능의 특성임
- 네트워크를 거치지 않고 postMessage API를 쓰면 더 즉각적일지 궁금함
- 백그라운드 창이나 탭의 우선순위가 낮아지는 것도 한 요인일 수 있음
- 아마 WebSocket 네트워크 지연 때문이고, 개인적으로도 창 위치 갱신이 가끔 이상하게 덜컥거리는 경우가 있었음
- 브라우저 안에서 돌아가기 때문임. 단순한 마우스 이동과 단순한 객체 좌표 변경 사이에도, 이벤트를 해석 또는 컴파일된 코드로 전달하고 상태 변화를 화면까지 보내는 시스템·애플리케이션 계층이 많이 끼어 있음
-
LocalStorage를 재미있게 쓴 예임
별도 브라우저 창에서 설정이 바뀌었을 때 대상 창을 갱신하려고 같은 LocalStorage 공유 기법을 써본 적이 있음. 갱신을 위해storage.onChanged이벤트만 들으면 됨- 이건 로컬 저장소를 쓰는 것 같지 않음. WebSocket 기반 서버가 클라이언트들에게 다른 박스들의 위치를 움직일 때마다 보내는 구조임