react.js, next.js, ssr, progressive hydration, 그리고 "Islands Architecture"와 fresh/deno

https://jasonformat.com/islands-architecture/

…이전에 몇번 언급한 hotwired 처럼. ㅎㅎ

지금의 reactjs, vuejs등은 다음과 같은 방식이 기본:

1. server: rest/gql등으로 요청을 받아서, json으로 응답.
2. browser(client): 응답으로 받은 json을 받아서, html을 생성하여 렌더링.

…이게 편하다고 생각해서 여기로 온거 같아. 나말고도 대부분의 사람들이 웹화면을 개발하던 시절에는 이렇게 만들고 싶었었던거 같아. ^{1 2}

그리고 당연히 ui개발이기 때문에 ‘컴포넌트모델’이나 값바인딩 같은 것들을 원했었고, 현재의 리액트와 같은 형태에 이르른 것 같아.

물론, vdom이 복잡도를 많이 낮춰줬지만, 희안하게도 예상하지 못하던 문제를 몇가지 더 만들어낸 것 같아. 그래서 요즘엔 ssr이니 seo을 생각해서 다른 방식의 프레임웍들을 사용하려고 하고 있고, 더 나아가서 progressive hydration 같은 쪽으로 더 세밀해지는 양상 같아.²

단순하게 생각하면, 그냥 필요에 따라서 그때 그때 필요한만큼만 js을 로딩하겠다는거겠지만, 생각보다 그렇게 쉽게 적용이 되는것은 아닌거 같아: Why Progressive Hydration is Harder than You Think

…발전해 나아가며, 점점 더 세밀하게 필요를 반영하는 것이겠지만, …그래도 한번 정도는 진지하게 정말로 이게 맞는걸까 생각해보는 것도 중요할 것 같아.

그리고, 지금의 next.js등을 중심으로 한 ssr쪽도 뭔가 이상한거 같다는 느낌. 굳이 저걸 react.js 컴포넌트으로 만들고, 꼭 그걸 서버측 렌더링을 해야만 했을까 싶기도 하고.

deno의 fresh framework 을 살펴봤다. 재밌었다. next.js ssr처럼 [name].tsx 같은 file system routing도 지원하고, preact component을 ssr도 기본적으로 지원. ㅎㅎ

어차피 deno이 기본적으로 node.js와 달리, typescript기본 지원, npm같은 패키징/실행 등도 모두 지원, eslint/prettier등등도 모두 golang처럼 아예 deno자체에서 지원하려고 하기 때문에 깔끔하고 좋았다.

하지만, 당분간은 여전히 그냥 다른 언어와 환경을 나는 더 개인적으로 선호할거 같아. deno이 가볍고 빠르고 좋겠지만 더 익숙하고 더 단순하고 더 가벼운 쪽이 나는 더 좋은거 같다.

그리고 프론트엔드 프레임웍도 마찬가지로 더 가볍고 그냥 잘 동작하는 것들을 선호하려고 한다. 위의 저런 이슈들과 접근법들에 당장 엮이고 싶지는 않고, 그리고 그런 가벼운 접근법들을 선택한다면 오히려 단순하게 풀리는 이슈들 같아서.