두개가 방식은 비슷하면서도 좀 다르지만
이렇게 js라이브러리가 양강구도로 가는것도 처음 보는거 같네요. 아시아권은 vue가 강세이고 (특히 중국)
미국은 리액트가 강세긴 한데 회의론자들도 많더군요.
인터프리터인 php에 날개를 달아주고 아직도 소규모 비지니스나 초보자들도 쉽게 만드는 워드프레스의 높은 점유율과
여기서 파생되는 수많은 템플릿들이 있고 이것들의 대부분이 부트스트랩기반으로 만들어져 스프링부트용 템플릿으로도
공유되서 높게 활용되고 있는데 이것을 리액트로 한다면 이미 그려진 마크업을 다시 콤포넌트로 작업해야 하는 이중성이 생겨버리죠.
물론 뷰나 리액트 템플릿들도 나오고는 있지만 그 양이 한참 못미치죠. 아니 미미한 수준이라고 할까요.
무엇보다 대부분은 소규모 웹페이지가 압도적으로 많기 때문에 워드프레스와 php시장이 죽기 전에는 과연 어찌 될려나요.
그리고 무엇보다 지금까지 마크업을 해오던 사람들이 과연 dom방식의 콤포넌트 구현을 배워서 할것인가.
결국 기존의 html마크업을 받아서 개발자가 다시 콤포넌트화 노가다를 다시 해야 하는건가라는 의문점도
드는군요.
애초에 React는 페이스북에서 자사 프론트엔드의 수많은 DOM 업데이트들을 묶어서 관리함으로써 성능과 효율성 측면에서의 개선을 얻기 위해 개발한 라이브러리이고, 따라서 DOM 조작이 잦은 웹앱에 사용되는 것이 주 목적인 것은 전혀 틀린 설명이 아닙니다. 물론 이걸로 정적웹을 만드는 게 불가능하다는 말은 전혀 아니며, 그저 쓸데없이 클라이언트 디바이스 성능만 잡아먹는 일이 될 수 있다는 게 초점입니다.
React, Vue 등의 웹어플리케이션 프레임워크는 페이스북, 트위터, 넷플릭스, 구글 Docs 같은 동적이고 규모가 큰 SPA 개발용으로 나온거죠.
전통적인 웹사이트도 React Vue로 못만들 이유는 당연히 없습니다만, 닭 잡는데 소 잡는 칼 쓰는 격이라 생각합니다.
오히려 더 가볍게 구현할 수 있어서 소잡는칼이라고 의미하기는 거창하지 않을까 싶네요.
콤포넌트형식으로 재사용성도 좋고 반복도 생략할 수 있으니까요. 쓰기 편하기 위해서 만들어진 jquery처럼 개선된 스크립트 라이브러리라고 볼 수 있겠죠.
최근에만 봐도 angular가 먼저 나와서 인기가 좋았지만 지금은 식어서 완전히 죽어버렸습니다.
현재는 vue react가 각광을 받고 있지만 아직도 전 세계의 상위순위 사이트의 90%가 훨씬 넘는게 jquery라서요.
저야 뭐가 되던 별 상관은 없지만 하나로 통일되면 좋긴 하겠어요.
익숙해지는거야 뭐 일주일 정도 써보면 되겠죠.
접근은 vue.js 가 확실히 쉬웠고
react.js 는 영역이 넓고 일단 지금은 1위이죠.
저는 신규 프로젝트에서 뭘로 할래? 라고 물으면 vue.js 이지만 react.js 로 가야해! 하면 못할것도 없습니다. 결국 이것도 좋고 저것도 좋아요.
그러나 jQuery 로 하는 예전 방식으로는 하기가 너무 싫어요.
지금 회사에서 다시 jQuery 사용하고 있거든요. 하...
단순히 이건 옛날것이니까 나쁜거 저건 요즘것이니까 좋은거
이런 이유는 아닌 것 같습니다.
제가 지적하는 점은 디자인,마크업,개발로 되어 있는 우리나라 분업 현황에 맞추어 볼때 콤포넌트 구조가 참 애매 하다는 점이죠.
그래도 angular, vue 는 퍼블리셔가 작업하고 개발자가 이어받아서 작업하기에 나쁘지 않았습니다.
예전에 jQuery 로 웹화면 만들 때 퍼블리셔와 같이 일했던것과 특별히 다르지 않더라구요.
하지만 react 스터디 하면서 느낀 건 이거 퍼블리셔가 jsx/tsx 로 작업해 주지 않으면 협업하기 어렵겠다는 생각이 들었습니다. 아직 본격적으로 업무에 쓰질 않아서 모르겠네요.
thymeleaf 같은 템플릿엔진도 써보고..
과도기로 jsp / thymeleaf로 그려진 html 페이지에서 jQuery로 Ajax 써서 서버에서 내려 주는 데이터로 dom 업데이트 해서 화면 갱신하는 형태도 써봤습니다.
결국 웹사이트가 구현에 따라 크게 3가지 정도 유형으로 분류 될거 같은데요.
1. 완전 정적인 html로만 이러우진 사이트.
2. jsp / asp나 thymeleaf 같은 서버사이트 템플릿을 사용하는 사이트.
3. vue.js / react.js로 화면을 그리는 사이트.
3가지가 유형이 복합적으로 섞인 사이트 들도 있죠.
일단 1번은 번외로 두고...
요즘은 client가 다양해져서 앱도 많이들 만들죠.
아니면 타사 연동을 위해서 API를 제공해 줘야 하는 경우라던가요.
이런 경우 3번의 이점은 명확하죠.
서버는 비지니스로직을 가지고 데이터만 반환(보통 json)하는 구조가 되는데..
이 경우 앱에서 동일한 API를 사용 할 수 있고, 타사에 API를 열여 주어야 할 경우에도 그대로 활용 가능하죠.
그런데 2번의 경우면... 앱용으로 API를 따로 만들거나, 타사제공용으로 API를 따로 만들어야 하게 됩니다.
추가로 코드관리 측면에서도 비지니스로직과 화면렌더링 코드의 분리도 이루어져서 유지보수 측면에서도 장점이 많구요.
vue.js 나 react.js가 러닝커브도 있고 기존에 만들어져있던 2번형태의 사이트의 경우 전환하려면 많은 시간이 드는건 맞지만....
반짝하고 사라지기에는 명확한 장점이 너무 많습니다.
그리고 웹앱이 아닌 앱용으로도 결국 따로 갈 수 밖에 없습니다. 서비스 자체가 대부분 다르고 축약되거나 제거된사항이 많아 쓸데 없는 비지니스는 제거해야 하거든요.
부트스트랩은 CSS 프리셋 이랄까 UI 프레임워크인데..
vue / react에서도 부트스트랩 쓸수 있고 많이들 씁니다...
'부트스트랩 같은 하이브리드 구조'의 의미를 잘 모르겠네요.
앱용 API를 결국 따로 갈 수 밖에 없다는 이유도 모르겠구요..
(제 경우는 앱용으로 만들어둔 API를 프로모션용 웹페이지에서 일부 같이 사용 하는 케이스가 많았거든요)
타사 제공 API는 따로 두는 경우도 많지만...
보통 API별 접근권한 관리 문제 때문에 그렇게들 많이하지만.
각 API 별 권한관리를 타이트하게 할 수 있는 시스템이 구축되어 있으면 권한을 조정해서 열어 주면 됩니다.
애초에 인증을 OIDC 같은 걸로 구축하고 권한관리 적절히 하면 됩니다.
이런 인증구조를 만드는게 부담스럽거나 미리 준비되어 있지 않아서 타사제공 API를 따로 때는거겠지요.
여기서 말하는 논지와는 무관한... 이유로요.
위 2가지는 API에서 view관련된 렌더링 코드가 빠지고 데이터만 반환하는 형태가 되면 자연스럽게 생기는 이점이구요... 권한관리 문제로 따로 만들어야 한다거나 앱용은 결국 따로(왜죠?)만들어야 된다는 이유로 구조적인 장점이 장점이 아니라고 말씀하시는건 .... 좀 이유가 황당스럽네요.
그리고 권한 관리라.. 타사가 api를 콜하는데 토큰정보 말고 별도의 권한이 무엇인가요? 님이 언급하신 OIDC도 토큰 방식인데요. 동일한 경로를 일반 사용자와 타사 API가 동시에 사용한다는건가요.
음..
bean은 데이터를 담은 객체(뭐 로직도 담길 수 있지만..)이고 그걸 표현하는 방식이 json 인데..
비지니스 데이터를 json 이던 bean으로 가져오던 구조적인 차이가 없다.... 라는 말의 의미를 잘 모르겠네요.
죄송합니다만..
이런 저런 용어의 레이어가 섞이는 거 같아서 문맥이 이해가 잘 안되는 부분들이 있어서 논지를 파악하기가 조금 어럽네요.
그리고 http 요청으로 받아오는게 순수데이터 인지(json), 아니면 서버에서 렌더링한 html 인지..
그 구조적인 차이에 따라서 파상되는 장점(비지니스로직, 렌더링 코드 분리, API 재사용성)에 대해서 이야기하고 있는데..
1,2,3에 구조적인 차이가 없다는건.... 어떤 이유에서 인지 이해가 안되네요.
그리고 부트스트랩은 js 포함된거 알고 있구요. 특히 jQuery 의존성을 가진것도 알고있고..
요즘 jQuery도 npm으로 배포되고 있어서 vue / react에서도 어렵지 않게 jQuery도 가져다 쓸수 있고..
실제로 부트스트랩 기반으로 vue / react로 랩핑해서 만들어진 테마들도 많습니다.
말씀하신 그리드(col?)나 attribute까지 당연히 제어해가면서 사용하도록 컴포넌트 구성 가능하구요..
예를들어 어드민 템플린계에 유명한.. Metronic 같은거라던지..
https://themeforest.net/item/metronic-responsive-admin-dashboard-template/4021469
실제로 제 스스로도 html + css(bootstrap) + js로 구성된 오픈소스 템플릿을 vue로 랩핑해서 컴포넌트로 만들어서 사이트도 만들어 봤구요.
부트스트랩을 마치 vue / react에서 못쓰는 뉘앙스로 받아 들여져서 조금 당혹 스럽습니다.
권한 관리쪽으로 이야기가 퍼지는건 논지랑 맞지 않는거 같지만...
뭐가 되었든 권한 관리를 잘하면 동일한 API를 타사 제공용으로 못쓸 이유는건 사실이구요.
권한관리를 세세하게 관리 할 수 있게 구축하는게 API를 분리하는 것보다 코스트가 크다/적다에 대해서는 이야기 할 만한 거리가 될거 같습니다.
그리고 토큰정보.... 에 토큰 소유자가 누구인지 확인해서 접근가능/불가능 처리하는게 권한처리지 뭐가 별거인가요?..
토큰정보 말고 다른 별도의 권한?........ oidc 방식으로 인정된 토큰 서버에서 받아서 그 토큰 소유자가 누군지 권한이 요청한 API에 적합한지 체크하는게 권한 처리죠.... 동일한 경로를 일반사용자와 타사에서 동시에 사용 못할 이유는 뭔가요?
API요청시 따라온 토큰이 그 API를 사용할 권한이 있는지만 확인하면 될 문제입니다만...?
구조적인장점이라는게 전 더 이해가 안되는군요. 애초에 ui를 편하게 구성하기 위한 라이브러리일 뿐이지
말씀 하신
2. jsp / asp나 thymeleaf 같은 서버사이트 템플릿을 사용하는 사이트.
3. vue.js / react.js로 화면을 그리는 사이트.
이런 경우 3번의 이점은 명확하죠.
서버는 비지니스로직을 가지고 데이터만 반환(보통 json)하는 구조가 되는데..
이 경우 앱에서 동일한 API를 사용 할 수 있고, 타사에 API를 열여 주어야 할 경우에도 그대로 활용 가능하다
라고 하셨는데 2번이나 3번이나 동일하다는 의미 입니다. 왜 구분 했는지가 이해가 안갈뿐입니다.
그냥 라이브러리를 뭘 썼느냐 차이죠. 리액트를 썼기 때문에 그대로 활용가능하다는게 아니라는 겁니다.
그리고 두번째인 api통신 역시도 일반 사용자가 접근하는 정보에 인증 토큰을 생성해서 계속 통신하고 계십니까?
일반 사용자는 세션값을, 타사 api는 로그인대신 토크나이저를 사용하는게 일반적이지 않나요?
같은 경로를 쓴다는거 자체가 이해가 안됩니다.
애초에 이런걸로 토론하고자 글쓴 의미가 아닌데 말이죠. ㅎㅎ
다들 너무 거창하시게 생각하신거라 생각됩니다. 단순히 ui용 스크립트 라이브러리일뿐 이것을 하나의 프레임워크라고 크게 생각을 하시는게 아닌가 싶네요.
2. jsp / asp나 thymeleaf 같은 서버사이트 템플릿을 사용하는 사이트
=> 이건 http request에 대한 응답이 html 이 됩니다.
3. vue.js / react.js로 화면을 그리는 사이트.
=> 이건 http request에 대한 응답이 data(json 또는 다른 인코딩도 가능) 이 됩니다.
음.. 3번은 좀더 명확하게 몇글자 설명을 더 추가하면..
"서버에서는 data(json)만 반환하는 API만 제공하고 브라우져에 화면은 vue.js / react.js로 화면을 그리는 사이트." 라고 생략된 설명을 덧 붙이죠.
2번의 서버에서 렌더링하는 (vue.js나 react.js 기반은 서버사이드 렌더링은... vue.js / react.js 계열이니 번외로 두고..) 사이트의 경우 http 요청(API 요청)의 결과로 순수한 data(json 또는 ...)를 받기 위해서는 순수한 data를 반환하는 API를 새롭게 만들어서 제공할 수 밖에 없습니다.
2번 3번이..계속 동일하다고 하고 기본구조가 변하는게 아니라고 하시는데...
서버에서 html을 반환하느냐 json을 반환하느냐.. 라는 차이가 생기고
(spring 쓴다 라고 하면) 그에 따라 html을 java 소스와 섞인 혹은 다른 template 언어(ex: thymeleaf)와 섞인 채로 관리 해야 하느냐 아니냐의 차이가 발생합니다.
이런 거 다 덮어 놓고 결국 1,2,3번 모두 구조적으로 같은 웹서비스(http) 서비스다.. 같은 해탈한 관점의 이야기를 하고 싶으신거면... 굳이 react / vue니 ... jQuery니 하는 기술적인 차이를 논 할 필요 조차 없었을거 같습니다만...
애초에 제 본문 글이 웹 프론트를 그리는 방법론에 대한 라이브러리 딜레마 였습니다.
말씀하시는 차이가 없다는 의견의 의미는 알것도 같습니다만..
프론트의 극적인 변혁을 다 제쳐두고...
어짜피 http 서비스 본질은 거기서 거기다라거나..
서버 소스에 view 렌더링 소스가 빠지는게 프레임워크가 바뀌는게 아니라니....
엄연히 프론트엔드 프레임워크 인데요..
vue나 react는. 프론트엔드 "프레임워크" 라고 불립니다.
실제로 IoC가 있냐 없느냐가 라이브러리냐... 프레임워크냐의 차이라는게 정설인데... 그런의미로도 프레임워크입니다.
서버사이트 프레임워크만 존재하던 웹개발 세계에 프론트엔드에도 프레임워크가 생긴 큰 변화인데 말이죠...
다들 프레임워크 라는데 아니라고.. 라이브러리 라고 하시니...
리액트 공식 타이틀이 ui스크립트 라이브러리라고 나와 있습니다.
https://vuejs.org/
Vue.js
The Progressive
JavaScript Framework
vuejs는 타이틀이 프레임워크죠.ㅡ 거의 비슷한 용도로 쓰이는데 react.js 라이브러리를 표방하죠.
react.js의 태생이 MVC의 view 레이어를 위한 라이브러리로 탄생했죠.
원래 다른 웹프레임워크의 view레이어로 쓸수 있었죠.. 저도 backbone.js의 view레이어로 쓸려고 처음 알게 되기도 했구요.
지금도 react.js 자체는 라이브러리라고 할 수 있습니다.
하지만 react.js로 웹어플리케이션... SPA를 만든다고 하면 보통.. react + redux + react-router 조합을 말하죠. 그렇게 조합해서 쓰면 사실상 프레임워크죠...
내가 만든 코드에서 react 코드를 부르는게 아니라.. react + redux + react-router 조합의 라이프사이클 위에 맞춰서 코드를 짜는거니까요.
IoC 걔념이 들어가고.. 프레임워크로 보는게 맞다고 봅니다.
react js is framework or library라고 검색해보시면 다양한 의견들이 많습니다...
vue는 대놓고 framework 라는데....
대등하게 옆에 놓이는 react는 라이브러리 라고 한다고 아무런 의견없이... 한쪽만.. 딱 가져오는 건 좀 적당하지 않은거 같네요
뭐 개인 프로젝트야 뭘로 해도 상관없죠
닭잡는데 소잡는칼 쓸 이유없듯이 다 상황에 맞춰서 쓰면 됩니다. 도구는 도구일뿐.
다만 도구에 자존감과 쓸대없는 보상심리 부여해서 멱살잡는 개발자들보면 이사람들이 엔지니어인지 무당인지 했갈리더라구요. 결국 모든건 도구일뿐 잘 가져다 쓰기면 하면됩니다.
것도 팀 단위로 ..
앵귤러 1 도 나오기 이전에 웹개발 할 때 생각이 나서 잠깐 눈물 좀 닦고 갑니다 ..
생 html에 jquery, 부트스트랩은 state 관리가 안돼요
요구사항이 조금만 많아지면 코드 관리도 안되고, dom 관리도 안되고...