CLIEN

본문 바로가기 메뉴 바로가기 보기설정 테마설정
톺아보기 공감글
커뮤니티 커뮤니티전체 C 모두의광장 F 모두의공원 I 사진게시판 Q 아무거나질문 D 정보와자료 N 새로운소식 T 유용한사이트 P 자료실 E 강좌/사용기 L 팁과강좌 U 사용기 · 체험단사용기 W 사고팔고 J 알뜰구매 S 회원중고장터 B 직접홍보 · 보험상담실 H 클리앙홈
소모임 소모임전체 ·굴러간당 ·방탄소년당 ·아이포니앙 ·주식한당 ·MaClien ·일본산당 ·자전거당 ·개발한당 ·이륜차당 ·바다건너당 ·클다방 ·안드로메당 ·노젓는당 ·AI당 ·가상화폐당 ·소시당 ·물고기당 ·찰칵찍당 ·여행을떠난당 ·소셜게임한당 ·걸그룹당 ·콘솔한당 ·갖고다닌당 ·VR당 ·골프당 ·캠핑간당 ·개판이당 ·전기자전거당 ·e북본당 ·나스당 ·키보드당 ·3D메이킹 ·X세대당 ·ADHD당 ·AI그림당 ·날아간당 ·사과시계당 ·육아당 ·배드민턴당 ·야구당 ·농구당 ·블랙베리당 ·곰돌이당 ·비어있당 ·FM당구당 ·블록체인당 ·보드게임당 ·활자중독당 ·볼링친당 ·냐옹이당 ·문명하셨당 ·클래시앙 ·요리한당 ·쿠키런당 ·대구당 ·DANGER당 ·뚝딱뚝당 ·디아블로당 ·동숲한당 ·날아올랑 ·이브한당 ·패셔니앙 ·도시어부당 ·FM한당 ·맛있겠당 ·포뮬러당 ·젬워한당 ·안경쓴당 ·차턴당 ·총쏜당 ·땀흘린당 ·하스스톤한당 ·히어로즈한당 ·인스타한당 ·IoT당 ·KARA당 ·꼬들한당 ·덕질한당 ·어학당 ·가죽당 ·레고당 ·리눅서당 ·LOLien ·Mabinogien ·임시소모임 ·미드당 ·밀리터리당 ·땅판당 ·헌팅한당 ·오른당 ·영화본당 ·MTG한당 ·소리당 ·노키앙 ·적는당 ·방송한당 ·PC튜닝한당 ·그림그린당 ·소풍간당 ·심는당 ·패스오브엑자일당 ·라즈베리파이당 ·품앱이당 ·리듬탄당 ·달린당 ·Sea마당 ·SimSim하당 ·심야식당 ·윈태블릿당 ·미끄러진당 ·축구당 ·나혼자산당 ·스타한당 ·스팀한당 ·파도탄당 ·퐁당퐁당 ·테니스친당 ·테스트당 ·빨콩이당 ·공대시계당 ·터치패드당 ·트윗당 ·창업한당 ·시계찬당 ·WebOs당 ·위스키당 ·와인마신당 ·WOW당 ·윈폰이당
임시소모임
고객지원
  • 게시물 삭제 요청
  • 불법촬영물등 신고
  • 쪽지 신고
  • 닉네임 신고
  • 제보 및 기타 제안
© CLIEN.NET
공지[점검] 잠시후 서비스 점검을 위해 약 30분간 접속이 차단됩니다. (금일 18:15 ~ 18:45)

개발한당

자유 React VS Vue 와 회의론 33

2021-02-01 10:52:55 수정일 : 2021-02-01 12:00:55 121.♡.144.178
김더워

두개가 방식은 비슷하면서도 좀 다르지만


이렇게 js라이브러리가 양강구도로 가는것도 처음 보는거 같네요. 아시아권은 vue가 강세이고 (특히 중국)


미국은 리액트가 강세긴 한데 회의론자들도 많더군요. 


인터프리터인 php에 날개를 달아주고 아직도 소규모 비지니스나 초보자들도 쉽게 만드는 워드프레스의 높은 점유율과


여기서 파생되는 수많은 템플릿들이 있고 이것들의 대부분이 부트스트랩기반으로 만들어져 스프링부트용 템플릿으로도


공유되서 높게 활용되고 있는데 이것을 리액트로 한다면 이미 그려진 마크업을 다시 콤포넌트로 작업해야 하는 이중성이 생겨버리죠.


물론 뷰나 리액트 템플릿들도 나오고는 있지만 그 양이 한참 못미치죠. 아니 미미한 수준이라고 할까요.


무엇보다 대부분은 소규모 웹페이지가 압도적으로 많기 때문에 워드프레스와 php시장이 죽기 전에는 과연 어찌 될려나요.


그리고 무엇보다 지금까지 마크업을 해오던 사람들이 과연 dom방식의 콤포넌트 구현을 배워서 할것인가.


결국 기존의 html마크업을 받아서 개발자가 다시 콤포넌트화 노가다를 다시 해야 하는건가라는 의문점도


드는군요.  

김더워 님의 게시글 댓글
  • 주소복사
  • Facebook
  • X(Twitter)
댓글 • [33]
음성사서함
IP 223.♡.8.185
02-01 2021-02-01 10:56:44
·
사용 용도가 완전히 다르다고 생각합니다. jQuery, Wordpress, Bootstrap 등은 전통적인 웹사이트 용, React, Vue는 웹어플리케이션 용....
김더워
IP 39.♡.28.128
02-01 2021-02-01 11:03:42
·
@음성사서함님 뷰 리액트는 pc웹사이트에서도 씁니다.. 동일한 html5 컨트롤 라이브러리죠.
arstarst
IP 1.♡.143.147
02-01 2021-02-01 11:52:26
·
@김더워님 음성사서함님은 React나 Vue가 DOM 조작이 잦은 웹앱들을 위한 것이라고 이야기하시는 것 같습니다. 정적웹에는 과하다는 거고 PC 웹에 못 쓴다는 게 아니신 듯한
김더워
IP 121.♡.144.178
02-01 2021-02-01 11:56:48
·
@arstarst님 글쎄요. dom조작이 과해서 쓴다기 보단 기존의 특정부분에만 dom구조로 페이지를 그리던걸 전체로 확장한 새로운 패러다임이 아닐까 하네요. pc웹과 하이브리드로 쓰는게 웹앱이라 어차피 동일한 경우가 대부분이고 오히려 기능이 제약되죠.
arstarst
IP 223.♡.218.88
02-01 2021-02-01 12:51:36 / 수정일: 2021-02-01 12:52:08
·
@김더워님 일단 지금 저랑 윗분이 사용하시는 웹앱이라는 용어는 모바일 앱을 지칭하는 것이 아니라 페이스북이나 트위터, 지메일 같이 말 그대로 웹애서 동작하는 어플리케이션을 말하는 것으로 보이는데요, 글쓴이께서는 모바일 앱으로 한정해서 읽고 계신 것 같네요.

애초에 React는 페이스북에서 자사 프론트엔드의 수많은 DOM 업데이트들을 묶어서 관리함으로써 성능과 효율성 측면에서의 개선을 얻기 위해 개발한 라이브러리이고, 따라서 DOM 조작이 잦은 웹앱에 사용되는 것이 주 목적인 것은 전혀 틀린 설명이 아닙니다. 물론 이걸로 정적웹을 만드는 게 불가능하다는 말은 전혀 아니며, 그저 쓸데없이 클라이언트 디바이스 성능만 잡아먹는 일이 될 수 있다는 게 초점입니다.
음성사서함
IP 223.♡.8.185
02-01 2021-02-01 14:43:52
·
@김더워님 arstarst 님이 잘 말씀해주셨네요. 웹어플리케이션 != 모바일 입니다.

React, Vue 등의 웹어플리케이션 프레임워크는 페이스북, 트위터, 넷플릭스, 구글 Docs 같은 동적이고 규모가 큰 SPA 개발용으로 나온거죠.

전통적인 웹사이트도 React Vue로 못만들 이유는 당연히 없습니다만, 닭 잡는데 소 잡는 칼 쓰는 격이라 생각합니다.
김더워
IP 121.♡.144.178
02-01 2021-02-01 15:36:06 / 수정일: 2021-02-01 15:46:59
·
@음성사서함님 규모가 큰 SPA개발용이라기보단 js라이브러리가 아닐까 싶습니다.
오히려 더 가볍게 구현할 수 있어서 소잡는칼이라고 의미하기는 거창하지 않을까 싶네요.
콤포넌트형식으로 재사용성도 좋고 반복도 생략할 수 있으니까요. 쓰기 편하기 위해서 만들어진 jquery처럼 개선된 스크립트 라이브러리라고 볼 수 있겠죠.
arstarst
IP 223.♡.4.162
02-01 2021-02-01 17:30:47
·
@김더워님 내부에 VDOM이 박혀 있는데 소 잡는 칼이 맞죠. VDOM이 섞이면 DOM 조작 시에 레이어가 하나가 더 생기는 건데, 이 레이어를 버퍼 역할로 쓸 때나 성능 개선이 있는 거지 아니라면 그냥 낭비입니다.
류화
IP 223.♡.28.103
02-01 2021-02-01 11:35:18
·
혹시 장기적 관점으로 리액트 가 망할 수도 있을까요??
김더워
IP 121.♡.144.178
02-01 2021-02-01 11:54:45 / 수정일: 2021-02-01 12:03:11
·
@류화님 이미 과거에도 반짝했다가 사라진것들도 있어서 가능성은 있겠죠.
최근에만 봐도 angular가 먼저 나와서 인기가 좋았지만 지금은 식어서 완전히 죽어버렸습니다.
현재는 vue react가 각광을 받고 있지만 아직도 전 세계의 상위순위 사이트의 90%가 훨씬 넘는게 jquery라서요.
저야 뭐가 되던 별 상관은 없지만 하나로 통일되면 좋긴 하겠어요.
익숙해지는거야 뭐 일주일 정도 써보면 되겠죠.
하루ㄹ
IP 121.♡.101.155
02-01 2021-02-01 12:41:46
·
웹어플리케이션이 복잡해짐에 따라 data, dom 둘다 직접제어하는 방법과 react,vue의 data만 관리해주면 라이브러리에서 ui는 알아서 만들어주는 방법이 개발자가 받는 스트레스, 생산성, 유지보수면에서 비교가 안됩니다. 앞으로도 컴포넌트 기반 개발이 대세가 될꺼 같기도하고
김더워
IP 121.♡.144.178
02-01 2021-02-01 14:41:43
·
@하루ㄹ님 ui를 알아서 만들어 주는건 아니고 디자인 마크업된 html구조를 다시 콤포넌트형식으로 만들어 주는 작업을 해야 하는데 이를 피하려면 애초에 마크업담당자가 뷰/리액트로 만들거나 개발자가 아예 마크업 콤포넌트까지 해줘야 한다는 딜레마가 생기죠. 후자라면 기존에 마크업만 하시던분들은 단지 css밖에 못만드는데 도태되어 버리겠죠.
퓨리넬
IP 106.♡.213.239
02-01 2021-02-01 12:45:14
·
vue.js 는 회사 업무에 사용했었고, react.js 는 샘플정도로 만들어봤는데
접근은 vue.js 가 확실히 쉬웠고
react.js 는 영역이 넓고 일단 지금은 1위이죠.
저는 신규 프로젝트에서 뭘로 할래? 라고 물으면 vue.js 이지만 react.js 로 가야해! 하면 못할것도 없습니다. 결국 이것도 좋고 저것도 좋아요.
그러나 jQuery 로 하는 예전 방식으로는 하기가 너무 싫어요.
지금 회사에서 다시 jQuery 사용하고 있거든요. 하...

단순히 이건 옛날것이니까 나쁜거 저건 요즘것이니까 좋은거
이런 이유는 아닌 것 같습니다.
김더워
IP 121.♡.144.178
02-01 2021-02-01 14:44:37
·
@퓨리넬님 리액트가 1위는 아니고 angular vue react 셋중에 1위인거 같습니다.
제가 지적하는 점은 디자인,마크업,개발로 되어 있는 우리나라 분업 현황에 맞추어 볼때 콤포넌트 구조가 참 애매 하다는 점이죠.
퓨리넬
IP 106.♡.213.239
02-01 2021-02-01 17:07:50 / 수정일: 2021-02-01 17:08:33
·
@김더워님 아, 참 그렇죠. 그 셋 중에 1위이긴 하죠. ㅎㅎㅎ
그래도 angular, vue 는 퍼블리셔가 작업하고 개발자가 이어받아서 작업하기에 나쁘지 않았습니다.
예전에 jQuery 로 웹화면 만들 때 퍼블리셔와 같이 일했던것과 특별히 다르지 않더라구요.

하지만 react 스터디 하면서 느낀 건 이거 퍼블리셔가 jsx/tsx 로 작업해 주지 않으면 협업하기 어렵겠다는 생각이 들었습니다. 아직 본격적으로 업무에 쓰질 않아서 모르겠네요.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 13:41:37
·
jsp로 java코드랑 섞어서도 해보고...
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번형태의 사이트의 경우 전환하려면 많은 시간이 드는건 맞지만....

반짝하고 사라지기에는 명확한 장점이 너무 많습니다.
김더워
IP 121.♡.144.178
02-01 2021-02-01 14:37:24 / 수정일: 2021-02-01 14:53:31
·
@ruinnel님 2번도 3번처럼 그냥 써도 동일하겠죠. 부트스트랩같은 하이브리드 구조로 만들면 되거든요. 그리고 3번의 경우 api역시도 별개로 만드는게 현실이죠. restful이건 소켓이건 타사와의 통신은 별도의 보안이 필요해서 한곳에 따로 모아서 가둬두는게 관리하기 편하고 나중에 문제 대응이 되거든요. 정해진 포트로 인증토큰을 주고받고 통신을 해야하니까요.
그리고 웹앱이 아닌 앱용으로도 결국 따로 갈 수 밖에 없습니다. 서비스 자체가 대부분 다르고 축약되거나 제거된사항이 많아 쓸데 없는 비지니스는 제거해야 하거든요.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 14:56:23 / 수정일: 2021-02-01 15:00:02
·
@김더워님
부트스트랩은 CSS 프리셋 이랄까 UI 프레임워크인데..
vue / react에서도 부트스트랩 쓸수 있고 많이들 씁니다...
'부트스트랩 같은 하이브리드 구조'의 의미를 잘 모르겠네요.

앱용 API를 결국 따로 갈 수 밖에 없다는 이유도 모르겠구요..
(제 경우는 앱용으로 만들어둔 API를 프로모션용 웹페이지에서 일부 같이 사용 하는 케이스가 많았거든요)

타사 제공 API는 따로 두는 경우도 많지만...
보통 API별 접근권한 관리 문제 때문에 그렇게들 많이하지만.
각 API 별 권한관리를 타이트하게 할 수 있는 시스템이 구축되어 있으면 권한을 조정해서 열어 주면 됩니다.
애초에 인증을 OIDC 같은 걸로 구축하고 권한관리 적절히 하면 됩니다.
이런 인증구조를 만드는게 부담스럽거나 미리 준비되어 있지 않아서 타사제공 API를 따로 때는거겠지요.
여기서 말하는 논지와는 무관한... 이유로요.

위 2가지는 API에서 view관련된 렌더링 코드가 빠지고 데이터만 반환하는 형태가 되면 자연스럽게 생기는 이점이구요... 권한관리 문제로 따로 만들어야 한다거나 앱용은 결국 따로(왜죠?)만들어야 된다는 이유로 구조적인 장점이 장점이 아니라고 말씀하시는건 .... 좀 이유가 황당스럽네요.
김더워
IP 121.♡.144.178
02-01 2021-02-01 15:21:28 / 수정일: 2021-02-01 15:46:30
·
@ruinnel님2번이던 3번이던 차이가 없다는 겁니다. 비지니스데이터 json이던 bean으로 가져오던 구조적인 차이가 없다는 것이구요. 부트스트랩이 버튼이미지만 제공하는 ui가 아닌 col 하이브리드나 애트리뷰트같은걸 따로 제어해주는 js라이브러리를 말하는 겁니다.그리고 애초에 1,2,3번이 나눠진것도 별 의미가 없어요. REACT나 VUE나 js라이브러리이고 DOM구성에 대한 편의성이 좋은것 뿐이죠.
그리고 권한 관리라.. 타사가 api를 콜하는데 토큰정보 말고 별도의 권한이 무엇인가요? 님이 언급하신 OIDC도 토큰 방식인데요. 동일한 경로를 일반 사용자와 타사 API가 동시에 사용한다는건가요.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 15:58:38 / 수정일: 2021-02-01 15:59:03
·
@김더워님
음..
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를 사용할 권한이 있는지만 확인하면 될 문제입니다만...?
김더워
IP 121.♡.144.178
02-01 2021-02-01 16:34:54 / 수정일: 2021-02-01 17:05:55
·
@ruinnel님 1,2,3번이 구분되어지는것처럼 기본 구조가 변하는게 아니라는 의미겠죠.
구조적인장점이라는게 전 더 이해가 안되는군요. 애초에 ui를 편하게 구성하기 위한 라이브러리일 뿐이지
말씀 하신
2. jsp / asp나 thymeleaf 같은 서버사이트 템플릿을 사용하는 사이트.
3. vue.js / react.js로 화면을 그리는 사이트.
이런 경우 3번의 이점은 명확하죠.
서버는 비지니스로직을 가지고 데이터만 반환(보통 json)하는 구조가 되는데..
이 경우 앱에서 동일한 API를 사용 할 수 있고, 타사에 API를 열여 주어야 할 경우에도 그대로 활용 가능하다
라고 하셨는데 2번이나 3번이나 동일하다는 의미 입니다. 왜 구분 했는지가 이해가 안갈뿐입니다.
그냥 라이브러리를 뭘 썼느냐 차이죠. 리액트를 썼기 때문에 그대로 활용가능하다는게 아니라는 겁니다.

그리고 두번째인 api통신 역시도 일반 사용자가 접근하는 정보에 인증 토큰을 생성해서 계속 통신하고 계십니까?
일반 사용자는 세션값을, 타사 api는 로그인대신 토크나이저를 사용하는게 일반적이지 않나요?
같은 경로를 쓴다는거 자체가 이해가 안됩니다.

애초에 이런걸로 토론하고자 글쓴 의미가 아닌데 말이죠. ㅎㅎ
다들 너무 거창하시게 생각하신거라 생각됩니다. 단순히 ui용 스크립트 라이브러리일뿐 이것을 하나의 프레임워크라고 크게 생각을 하시는게 아닌가 싶네요.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 17:06:42
·
@김더워님
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니 하는 기술적인 차이를 논 할 필요 조차 없었을거 같습니다만...
김더워
IP 121.♡.144.178
02-01 2021-02-01 17:48:47 / 수정일: 2021-02-01 17:56:41
·
@ruinnel님 네 차이가 없다는 점 자체가 어차피 서버에서 요청에 의한 데이터를 주는 것은 마찬가지이며 프론트에서 jsx하던 html이나 jsp로 하던 마찬가지라는 것이죠. 서버에서 json을 주던 bean을 담아주던 프론트에서는 그냥 프론트 구조가 달라지는 것이지 프레임워크가 바뀐다는 의미가 아니라는 것이죠.
애초에 제 본문 글이 웹 프론트를 그리는 방법론에 대한 라이브러리 딜레마 였습니다.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 19:46:32 / 수정일: 2021-02-01 19:53:40
·
@김더워님
말씀하시는 차이가 없다는 의견의 의미는 알것도 같습니다만..

프론트의 극적인 변혁을 다 제쳐두고...
어짜피 http 서비스 본질은 거기서 거기다라거나..
서버 소스에 view 렌더링 소스가 빠지는게 프레임워크가 바뀌는게 아니라니....
엄연히 프론트엔드 프레임워크 인데요..
vue나 react는. 프론트엔드 "프레임워크" 라고 불립니다.
실제로 IoC가 있냐 없느냐가 라이브러리냐... 프레임워크냐의 차이라는게 정설인데... 그런의미로도 프레임워크입니다.

서버사이트 프레임워크만 존재하던 웹개발 세계에 프론트엔드에도 프레임워크가 생긴 큰 변화인데 말이죠...

다들 프레임워크 라는데 아니라고.. 라이브러리 라고 하시니...
김더워
IP 121.♡.144.178
02-01 2021-02-01 21:41:22
·
@ruinnel님 https://ko.reactjs.org/
리액트 공식 타이틀이 ui스크립트 라이브러리라고 나와 있습니다.
ruinnel
IP 116.♡.200.14
02-01 2021-02-01 22:07:24 / 수정일: 2021-02-01 22:11:38
·
@김더워님
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는 라이브러리 라고 한다고 아무런 의견없이... 한쪽만.. 딱 가져오는 건 좀 적당하지 않은거 같네요
삭제 되었습니다.
가디
IP 121.♡.152.97
02-01 2021-02-01 18:52:41
·
https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/
화사한하루
IP 223.♡.201.243
02-01 2021-02-01 21:38:20
·
라인, 카카오, 네이버 마크업 개발자들은 이미 react 컴퍼넌트에 jsx 를 직접 작업합니다
뭐 개인 프로젝트야 뭘로 해도 상관없죠
삭제 되었습니다.
ifmkl
IP 59.♡.46.4
02-03 2021-02-03 14:48:03
·
꼭 다른 한쪽 영역을 완전히 대체해야 하는건 아니니까요.
삭제 되었습니다.
kalook
IP 121.♡.212.46
02-05 2021-02-05 18:24:36
·
사용처에 따라 다르지요.
닭잡는데 소잡는칼 쓸 이유없듯이 다 상황에 맞춰서 쓰면 됩니다. 도구는 도구일뿐.
다만 도구에 자존감과 쓸대없는 보상심리 부여해서 멱살잡는 개발자들보면 이사람들이 엔지니어인지 무당인지 했갈리더라구요. 결국 모든건 도구일뿐 잘 가져다 쓰기면 하면됩니다.
망고덮밥
IP 61.♡.216.182
02-09 2021-02-09 20:45:28
·
일정 정도 이상의 복잡도와 규모를 가진 웹 어플리케이션을 리액트 같은 프레임웍 없이 만든다라 .. 음 ..
것도 팀 단위로 ..
앵귤러 1 도 나오기 이전에 웹개발 할 때 생각이 나서 잠깐 눈물 좀 닦고 갑니다 ..
양철북
IP 221.♡.68.166
02-12 2021-02-12 14:14:52 / 수정일: 2021-02-12 14:15:32
·
커리어/연봉만 따지면 답은 명확합니다. FE개발자 구인할 때도 JSP/JSTL/jQuery 로 개발하라고 하면 커리어 꼬인다고 안와요.
바람처럼스쳐가는
IP 203.♡.212.22
03-04 2021-03-04 11:29:54 / 수정일: 2021-03-04 13:16:17
·
일정이상의 복잡도를 가지는 애플리케이션은 react + redux든 vue든 뭐든 필요합니다.
생 html에 jquery, 부트스트랩은 state 관리가 안돼요
요구사항이 조금만 많아지면 코드 관리도 안되고, dom 관리도 안되고...
새로운 댓글이 없습니다.
이미지 최대 업로드 용량 15 MB / 업로드 가능 확장자 jpg,gif,png,jpeg,webp
지나치게 큰 이미지의 크기는 조정될 수 있습니다.
목록으로
글쓰기
글쓰기
목록으로 댓글보기 이전글 다음글
아이디  ·  비밀번호 찾기 회원가입
이용규칙 운영알림판 운영소통 재검토요청 도움말 버그신고
개인정보처리방침 이용약관 책임의 한계와 법적고지 청소년 보호정책
©   •  CLIEN.NET
보안 강화를 위한 이메일 인증
안전한 서비스 이용을 위해 이메일 인증을 완료해 주세요. 현재 회원님은 이메일 인증이 완료되지 않은 상태입니다.
최근 급증하는 해킹 및 도용 시도로부터 계정을 보호하기 위해 인증 절차가 강화되었습니다.

  • 이메일 미인증 시 글쓰기, 댓글 작성 등 게시판 활동이 제한됩니다.
  • 이후 새로운 기기에서 로그인할 때마다 반드시 이메일 인증을 거쳐야 합니다.
  • 2단계 인증 사용 회원도 최초 1회는 반드시 인증하여야 합니다.
  • 개인정보에서도 이메일 인증을 할 수 있습니다.
지금 이메일 인증하기
등록된 이메일 주소를 확인하고 인증번호를 입력하여
인증을 완료해 주세요.