React 16에서 18버전으로 옮겨오면서 느낀 트렌드 3가지

  이전의 사랑하던 Arc 패턴을 정리했다. Component와 Container를 나누어서 관리하겠다는 발상은 이제 고인이 되었다. 삼고빔을 하기도 전에 이번 React 십팔 버전의 감정으로는...

메이저버전에서 느껴지는 버전의 이름대로 바꿔야하니까 욕이 나ㅇ

빠른 변화 감사합니다...

 

 Server 사이드에 친숙한 느낌을 받는 과정이 생겼다. 덕분에 귀찮은 여러가지 설정 부분이 단순화 되기 시작했고, 점점 PHP화 되어가는 느낌도 받았다. 원래 백엔드 프론트 엔드를 나누기 전에 웹개발이였다.

 

   웹API를 활용한 웹사이트 구축은 사용자에게 편리함을 제공하기 위한 예술적인 과정이라고 할까... (예술의 혼을 불어 넣기 위해서는 수 많은 난관을 스스로 해쳐나가야하는데 요즘은 GPT가 어시스트를 해주는 덕분에 좀더 아니 많이 삽질을 피할 수 있는 과정이 생겼다.)

 

몇가지 경험을 남겨두어 되새김질 하려한다.

 

1. Server Side Render를 지향... "멋지고 속도 빠른 서버 오빠가 다 해줘, 알겠지?"

 

   과거의 리엑트는 어떻게 하면 프론트에서 다 처리하지 라고 했던 발상에서 본래로 돌아왔다. 서버로. 따라서 express에 찰싹 붙은 리엑트를 살펴볼 수 있는데, fastly, Koa 등 여러 웹데몬 미들웨어도 있지만 소스 변화없이 잘쓰이는 express.js의 미들웨어적 성격, compress 등과 같은 역할들을 최대한 활용하여 민첩하게 개발하는 과정이 더 담기게 되었다.

 

  필자는 이걸 더 선호한다. 피자를 받는 사람이 피자를 만드는 것보다는 서버 즉 서비스를 해주는 쪽에서 다 처리하고 먹으라하는 것이 일단 맞다. 주기전에 좀 원가(불필요한 것들 정리하고)

 

  보는 사람과 쓰는 사람의 쓰는 Resoucre 차이를 이해하는 것이 더 중요해졌다.

 

 

2. Express + React "사실혼 관계... 부정 할 순 없어"

 

   그래서 돌고 돌아 유행은 서버에서 템플레이팅 하는 과정이 있는데, PHP나 라라벨의 경우 "내가 그랬잖아 결국 돌아온대도" 유행도 돌아오듯 개발의 TPO는 결국 서버.

 

  여러 Express Templates 에 대한 부분을 살펴보면, https://expressjs.com/en/resources/template-engines.html 명시되어있는 것 중 사장된 비인기도 많지만 https://mustache.github.io/ 와 같은 비교적 꾸준히 개발자 팬층이 많은 템플레이트도 있고 Pug야 입문을 하는 과정이 있지만....

 

  React도 서버 사이드의 템플레이트적 성격 ✅(https://github.com/redexp/express-engine-jsx)을 유지하면서 클라이언트 퍼포먼스를 최대한 끌어내려는 과정이 있는데 자꾸 강제 결혼 하려하는 과정이 보이는게 요즘 트랜드.

 

  요사이에 치고 들어온 스벨트가 가볍고 빠르기에. Vue보다 손쉬운 입장을 견지하다보니 퍼포먼스격에서도 React 입문보다 쉬운 https://svelte.dev/ 의 등장도 살펴볼만 하다는 점. 라이브러리 들끼리의 생존 경쟁에 대해서 보면 재밌다. 콘텐츠 전달속도, 유지보수 용이성 등등 있지만 최고는 입문한 개발자들이 포기하지 않고, 언어 숙지한 것이 망각되지 않게 해줄 수 있는 언어까지 서비스를 해줘야 살아남는다. 이렇게 볼 수 있다는 점. (웹팩은 이번 hot, liveReloading 등 그런거보면 좀더 더 미들웨어화 하는 과정이 생존을 위한 다이어트 아닌가 싶다.)

 

 

 

 

3. Hook, Currying, Middleware 핫키워드...
"프론트는 훅으로 뼈를 때리고, 백은 미들웨어로 매끈하고 매끄럽게"

 

   리엑트 훅의 관점이 늘어났다. React 입장에서는 훅이라지만, 사실 이전부터 있던 여러가지 프로그래밍 관점으로 필요한 정보를 언제든지 필요한 위치에서 쓰는 관점이 생겨났다. 그리고 더 필요하다면 준비는 서버의 미들웨어에서 해결해주는 관점이 늘어나다보니 Webpack5에서는 다른 번들팩 프로젝트 견제(Parcel 등) 에 대응한 여러 미들웨어 전환작업이 주를 잇는 모습이 보인다.

 

  이는 AWS의 영업이익과 상관관계가 있지 않을까 싶다. 서버의 사용량이 극대화되면 될 수록 부담이 되긴하지만 더 빠른 속도로 대용량 또는 고연산을 해줄 수 있는 것에 대한 비용 지불 액수 자체가 늘어나기 때문.

 

   디자인패턴으로는 눈에 띄는 것은 Hook(https://github.com/rehooks/awesome-react-hooks)과 Currying(https://ko.javascript.info/currying-partials) 기법으로 가볍게 개발을 마감질 수 있게 해주는 부분이 커졌고, 잘 처리하고 잘 압축해서 보내는데 더 신경이 쓰이는 것이 보였다.

 

???

"CPU의 역할이 많이 바뻐진 만큼 돈도 두둑하게 내라구! 😊"

 

 

 

경험의 결론 🙋‍♂️

   18버전으로 전환되면서 프론트만 단지 변화된게 아니라, 서버에서 처리하는 여러 부차적인 기술(Brolit Compress)등 과 같은 프로젝트들이 활발해지다보니 보다 더 최적화한 깔끔한 맛의 서비스를 제공하려는 모습들이 보이기 시작했고, 다채로운 미들웨어와 훅 그리고 커링이 보다 많이 어썸하게 태어나는 시기가 될 것으로 보인다. 끝-