잠깐 React를 살펴볼 기회가 있어서 처음으로 프로젝트를 만들어서 빌드해보고 돌려보고 좀 놀랐습니다. 특히 빌드한 결과물을 보니, 이게 정말 웹개발이 맞나 싶네요. 이게 뭔가 웹과는 잘 맞지 않는 뭔가 괴물 같다는 생각을 했습니다. 반대로 React Natvie가 원조이고, "네이티브 앱을 웹브라우저에서도 동작시켜봤어요" 이런 시도라면 이해는 갑니다.
그래서 좀 찾아보니, 역시 React에 관해 논란이 많네요.
일단, 성능이 느리기 때문에 쓰지 말자는 의견이 있습니다. 이러한 이유로 접근성이 떨어저 2G를 국가에서는 동작시키기도 어려운가 봅니다. 그리고 웹의 원래 방향과 다르다는 이유도 있습니다. 저도 동감입니다.
https://dev.to/ender_minyard/why-you-should-stop-using-react-g7c
React State관리하는데, 수 많은 히스토리가 있었나봅니다. 여전히 뭔가 해결이 안되나 봅니다.
"React는 단지 렌더링 엔진일 뿐이며 일반적인 웹 앱에서는 프로젝트용 프레임워크를 구축하려면 데이터 레이어, 상태 관리, 라우팅, 자산 번들러 등 많은 라이브러리가 필요합니다. React 뒤에 있는 생태계는 이런 종류의 선택 사항을 너무 많이 제공하여 기술 스택을 조각화하고 악명 높은 "Javascript 피로"를 야기했습니다."
https://medium.com/building-productive/react-ruined-web-development-dd65342a833f
vue.js와 같은 JS 툴킷은 어떤가요? 웹 컴포넌트로 웹개발이 어려운가요?
개인적으로 조금 만져 봤을때 React 보다는 Vue.js 쪽이 좀 더 맘이 갔고 실제로 경험도 좋았습니다.
초반에 React 와 경쟁하던 Angular.js 는 저랑은 아주 안 맞았구요
이건 개발성향에 따른 개인 취향차이가 크다고 보고 써보고 판단하시면 좋을거 같습니다.
짧은 식견의 제 생각을 써보자면
웹 프론트 개발 사이즈를 볼때 사이즈가 커지고 한 프로젝트에 대한 개발인력이 많아 질수록 React 나 Vue.js 같은 프레임워크? 혹은 UI라이브러리를 쓰는게 맞다고 생각은 합니다만.
모든 프로젝트에 다 쓸필요는 없고 마이크로한 작은 사이트면 그냥 bootstrap 같은 CSS 셋에 자바스크립트 기본 기능만 써도 충분한것 같습니다. 요즘은 JS 도 ES2020 이후로는 편의 기능들이 많이 좋아진듯 합니다.
프론트엔드에서 성능을 논하려는 개발인력이 대규모로 넘어가는 꽤 큰 엔터프라이즈 서비스 정도 되지 않으면
그냥 개발 속도 빠르게 작업하는게 좋은듯 합니다.
소규모의 프로젝트 라면 React 외에 Svelte나 alpine.js 같은 다른 대안들을 시험해 보는것도 방법이 될 수 있을거 같습니다.
지난 10여년간 프론트엔드쪽은 너무 발전이 급격하고 많이 변해서 이게 최고다 이 방법이 옳다 이런건 몇달 지나면 다 지나가는것 같습니다. 인터넷의 여러의견은 참고만 하시고 시행착오를 직접 겪어 보는 수밖에 없더라구요.
성능에 관련해 링크한 글은 일단 너무 오래되서 현재와 맞지 않고 1, 2, 3은 사실상 같은 말 아닌가 싶고 오늘날 스트리밍을 지원하는 프론트엔드 프레임워크는 리액트 밖에 없으니 4번도 틀렸네요.
그리고 2G는 솔직히 억지 아닌가 싶네요. 국내 뿐 아니라 해외 어지간한 사이트도 3G 조차 간당간당한데 2G를 들고 와서 깐다고요? 리액트 번들의 용량이 크다한들 그래봐야 텍스트예요. 어지간한 사진 이미지나 동영상 하나에도 못 미칩니다. 2024년에 텍스트만 있는 웹사이트가 보고 싶은 게 아니라면 말도 안되는 얘기죠.
C# 이용해서 Blazor를 통해서 개발해도 되고요.
리액트가 만능은 아니고 장단점이 존재함에도 현 다른 라이브러리 대비 사용자가 많아 다양하게 사용될 확률이 높고 그러기에 이런 저런 논란이 많을 수 밖에 없다고 생각합니다.
크기의 문제는 2G 속도 정도의 네트워크에서 동작 시켜야 환경에 배포 하는 게 아니라면 신경 쓸 이유가 없다고 봅니다.
느리더라도 브라우저의 캐쉬도 있고요.
특수한 상황이긴 한데 제가 본 곳중에 코드 분할을 하지 않고 10MB에 육박하는 스크립트를 사용하는 곳도 있었습니다...
상태 관리는 리액트의 핵심이기 때문에 해결이 되지 않는 다기 보다 좀 더 편하거나 성능을 높일 수 있는 방향으로 제공되는 라이브러리들이 있습니다.
SPA 를 사용할려면 라우팅은 다른 라이브러리나 프레임워크도 동일한 문제를 가지고 있고
번들링은 legacy 스택이 아닌 이상 이제 필수적인 요소라 이건 vue, angular 등 다른 쪽에도 여전히 많은 라이브러리들이 필요합니다. 현재 자바스크립트 생태계 자체가 기술 스택이 조각화 되어 돌아가고 있습니다. 전 나름 계속 새로운 게 나와서 재미있습니다.
저는 리액트로 개발하는게 생산성이 기존 바닐라 대비 높아서 매우 좋습니다.
갠적으로는 이 붐이 일반적인 개발에도 점점 늘어나는 걸로 보입니다.
기존 SSR(서버 사이드 랜더링)으로 해도 되는데, CSR(클라이언트 사이드 랜더링)으로 새로이 구축해서 들어가는 것이 좀 이해가 되지 않는데.. 신기술이고, 좋다고 하니.. 점점 따라가는거 같습니다.
개발자 입장에서는 괜찮은거 같기는 한거 같습니다..
뭔가 체계가 잡혀 있는거 같고, 라이브러리나 패키지 설치하면 코드 몇줄에 서버단이 돌아가고..
이전처럼 서버단(리눅스계열이나 윈도우즈에) 별도 모듈이나 패키지 설치를 구지 설치하느라 뻘짓 안해도 되고..
docs나 api 구성이 나름 정리되어서 참조하기도 많이 편하고, 신규 구축 및 확장성은 뛰어난거 같습니다.
다만, 자바스크립트라고 생각해서 그런가.. 왠지 가벼움이 느껴지고, 버전 업이나 사라지거나 하는 것이 너무 빠릅니다.
1년만 지나도, 없어지는 패키지나 문법의 변화가 오는 경우가 많이 보이더군요.
그외에도 좀 더 있기는 한데...
아무튼 붐이라서 한동안은 지속될거라 봅니다.
그러다 파이썬쪽으로 이동하기 않을까 생각도 해 봅니다.. ㅎㅎ (장담 못함)
아.. 참고로 요새 느린 것은 하드웨어로 충당한다고 말들 많이 합니다.. ㅎ
개발비용이나 개발기간이 늘어난 비용보다 하드웨어로 보강해 커버치는게 비용이 더 싸게 나오는 말들이지만..
그냥 주저리 적어봅니다..
프론트, 브라우저 단에선 실행시킬 수 있는 언어가 제한적이고, 그 언어가 자바스크립트죠.
그리고 그 자바스크립트를 브라우저가 아닌 다른 환경에서도 v8엔진인 nodejs 런타임으로 쓸 수 있는 방향이 된거라,
자바스크립트가 아닌 다른 언어로 프론트를 사용하긴 어렵습니다.
아 그런데 요즘엔 웹어셈블리로 웹브라우저상에서 파이썬을 돌리기도 하더라구요....
dom제어가 가능한지 모르겠는데... 파이썬으로 프론트가 불가능한 일은 아닐 것 같기도 하네요.... ㅎㅎㅎ 당장은 가능하더라도 매우 비효율적입니다
현재는 node.js 쪽 생태계가 크고 방대해서 자바스립트 계열이 많이 나온다고 보면 되는 것이고요..
(호환성이 좋으니, 계속해서 비슷하거나 새로운 것을 탑재해서 나오는 것이죠..)
AI가 더 대중화 되면 파이썬 진형도 만만치 하게 백단에서 많이 사용이 될것이고..
그럼 당연 이쪽 생태계도 커지면서, 이에 맞게 호환성이 좋은 프론트단이 나오지 않을까 생각한 것이고요..
(위에서 언급한 것은 이런 의미였습니다.)
그게 파이썬 계열일지, 아니면 자바스트립 계열일지는 몰라도..
서로 상호 보완하면서 같이 나아갈수도 형국이 될 수도 있고요..
예전에는 그래도 몇년에 한번씩 패러다임이 바뀐거 같은데, 요새는 1년도 짧은거 같다는 생각이 들어가서 적어본겁니다.. ㅎㅎ
웹프레임워크(ex: spring)은 꼭 필요할까요?
가 있을거 같습니다.
무거워 지는건 사실 이지만 그걸 넘어서는 편리함, 생산성 등이 있으니까 쓰는거 아닐까요?
하지만 저도 react 별로 좋아하진 않습니다 ㅋㅋ
프론트라고는 react밖에 몰랐는데, 덕분에 더 넓은 시야를 배웁니다 :)
2. 리액트의 DX에 대한 부분은 논란의 여지가 있지만, 소위 많이들 사용하느 기술스택으로 선정하면 레퍼런스 측면에서 매우 자료가 많다는 것을 고려하면 상당히 괜찮다고 여길 수 있습니다. (이것은 레퍼런스 많음 보정치 적용)
3. 리액트 외에 DX는 스벨트가 압도적으로 괜찮다는 개인적인 의견입니다. 하지만 레퍼런스는 ...
4. 현재 모던한 웹 개발이 단순한 레이어를 가지지 않은 것인지, 그것이 리액트 때문인지는 한번 살펴봐야할 문제입니다...
5. 취업을 위해서다 -> 두말 할 것 없이 리액트를 해야만 합니다. 하지만 본인이 어나더레벨이라면 아무거나 하셔도 문제 없습니다.
6. 구인을 위해서다 -> 특수한 요구사항이 있는 프로젝트가 아니라면, 리액트로도 차고넘칩니다. 인력수급에 가장 용이하고, 숙련된 개발인력 수급에 유리합니다. 역시, 본인이 숙련된 웹앱 개발자이면서, 리딩하시는데 문제가 없다면 아무거나 선택하셔도 좋습니다. 하지만 숙련된 인력을 빠르게 구인해야하는 상황이라면 리액트 외 프레임웍은 좋은 선택이 아닐 수 있습니다. 모던한 웹 개발 경험이 있는 숙련된 웹개발자라면 타 프래임웍에도 금방 적응 할 가능성이 높지만, 기대한만큼 못따라올 가능성도 여전히 있기 때문입니다. 그 재교육 및 훈련 비용은 생각보다 거대할 수 있습니다.
7. SPA특유에 번들 사이즈의 문제라면, 코드스플릿팅으로 처리가 가능합니다. (이는 매우 특별한 방법이 아니라, 일반론에 가깝습니다.)
8. 리액트의 미래, 앞으로 몇년은 리액트의 위상이 변함 없을 것 같습니다. 확실히 대한민국에서는 더 그럴 것입니다. 이미 숙련된 리액트 프론트엔드 개발자는 다른 프레임워크에 관심을 가질 이유가 충분하지 않으며 생산성이 그만큼 나오기 쉽지 않을 것이기 때문입니다.
9. 만약 글로벌을 기준으로 하며, 2g환경에 대한 서비스를 목적으로 한다면 리액트는 그다지 좋은 선택이 아닐 수 있습니다. 하지만 이는 대한민국에 대부분의 웹개발자들이 고려하지 않아야할 항목입니다.
2. 난 리액트보다 더 높은 품질의 코드를 더 빠른 시간에 만들수 없다. → 리액트 필요함.
문제는 3번 입니다.
난 1번인데, 같은팀에 50명 있고 나머지 49명은 2번이다.....
→ 나머지 49명을 1번으로 만들던지, 그냥 2번으로 통일하던지.....
전에 그렇게 정해졌다고 들은 것 같은데 말이죠.
그러면 vuejs나 다른 뭘 해도 상관은 없지만 국내에서 리액트는 필수과목 정도 되는 것 아닐까요?
하아... 이러자고 next쓴건 아닌데..
serverRendering: 이제 서버가 대신 처리해주는 것과 클라이언트 렌더링을 쪼개서 가벼워졌다
???: 그럼 백엔드 없어도 되지 않나?
nextJS14: 그래서 넣어드렸습니다
네, 그러니까 PHP가 선구자였던 거지요(?)