웹 소프트웨어의 미래는 HTML-over-WebSocket 이다

- SPA + API + JSON 은 개발과 릴리즈 사이클을 느리게함
- 양방향 웹소켓을 이용해서 서버 렌더링, 빠른 프로토타이핑, 직관적인 SEO, 신속한 기능 개발이 가능하다는 주장
ㅤ→ 변경되는 HTML 또는 간단한 텍스트를 소켓으로 전달
ㅤ→ 클라이언트의 복잡한 값 검증 및 에러객체들 대신 서버가 검증하게
ㅤ→ 사용자의 접속여부는 소켓 연결이 활성화 되었는지로 체크
ㅤ→ 다중 사용자 채팅이나, 문서 협업들도 모두 쉽게 지원
- Rails의 귀환 : Turbolinks, Stimulus, StimulusReflex, CableReady, and GitHub’s ViewComponent
- Basecamp 의 Hotwire 도 같은 기술

[chanhee]

dotnet의 serverside blazor가 비슷하게 동작하는거 같은데요. 이걸 프로덕션에서 실제로 사용해보면 좀 피곤한경우를 많이 겪게되서...
Electron에 서버와 클라이언트를 다 붙여서 배포하는거 빼고는 딱히 장점을 모르겠더라구요.

[kunggom]

혹시 구체적인 사용 경험에 대해 들려주실 수 있나요?

[andrewchaa]

그런데 API endpoint는 만들어 놓으면 모바일, 웹, 데스크톱 다 쓸 수 있어서 범용성이 좋은데, 웹소켓을 미래라고 할 수 있을지 모르겠네요.

[colus001]

Elixir Phoenix LiveView, 나 RoR Stimulus Reflex 도 비슷한 개념인데,
Chris McCord 가 Rails 로 만들다가 구조적인 문제로 Elixir 로 넘어갔다고 하는 얘기도 있죠.

- If not SPAs, what? https://macwright.com/2020/10/28/if-not-spas.html

[iolothebard]

뺑뺑이 돌리는 소리...

[xguru]

이런 주장도 있구나 라고 보시면 좋을듯
Javascript 가 어디에나 쓰이면서 SPA, SSR 등 뭔가 용어가 많아 졌고, 과도하게 복잡해졌다는 것에는 동의합니다.
양방향 처리가 되는 것이 웹소켓이 더 많이 활용될 것 같긴 한데, 전 Hotwire 보다 더 편한 무언가가 나오길 기대해봐야 할 것 같아요.

- Hotwire : HTML Over The Wire Hotwire : HTML Over The Wire

[galadbran]

(제가 잘 몰라서일수도 있지만) 최근 좀 웃기다고 느낀 부분이 있는데 리액트+라라벨 웹앱에서 서버측만 변경된 경우에는 배포 내용이 버전 표식과 바뀐 코드 몇줄인데, 프론트가 변경되면 프론트앱 빌드하고 배포 사이즈가 상대적으로 많이 커서 웃음이 나더라고요. 일시적으로 급한 커스터마이징 적용도 어렵고요. 이전의 개발 경험이랑 비교가 되어서 그런 것 같기도 하지만요