제이쿼리 왜 까이는지 모르겟음

[익명(185.92)]

아직 쓸만한데;;

최소 4년은 더쓸듯

ajax, 몇몇 간단한 dom 조작쓰는걸 주로하면 괜찮은거같은데

[고양아(lastiii)]

하아 jQuery 할말많다...

[고양아(lastiii)]

분명한건 jQuery가 나쁜 건 아님. 오히려 굉장히 좋은 툴이라고 생각한다.

[고양아(lastiii)]

문제는 작은 문제를 해결하기에 적합한 이 툴을 마치 프레임워크인양 작지 않은 문제에서도 무작정 쓰는게 문제지.

[고양아(lastiii)]

제이쿼리의 문제점을 들여다보려면 웹의 태동기로 되돌아가야한다 - dc App

[고양아(lastiii)]

애초에 웹은 document를 표현하기 위해서 설계되었음. 거기에 js는 간단한 스크립팅을 위해서 만들어졌고. - dc App

[고양아(lastiii)]

document로서의 웹은 태동 이후 몇년정도는 목적 그대로 사용되면서 문제가 없었는데 문제는 document가 아닌 application 으로서의 웹이 생기면서 발생됨 - dc App

[고양아(lastiii)]

웹이 커버하는 영역이 커지고 사용자 클라이언트 성능이 좋아지면서 웹이 도큐먼트가 아닌 애플리케이션 형태를 지향해가고 그 과도기에 태어난게 제이쿼리임 - dc App

[고양아(lastiii)]

초창기야 애플리케이션화가 많이 진행되지 않았으니 스크립트로 해결해야 하는 문제들도 아주 작고 간단한 문제들이었음. 이런 영역의 문제는 제이쿼리로 해결하기 아주 적합함 - dc App

[고양아(lastiii)]

지금도 마찬가지임. 작은 문제들은 제이쿼리가 적합함. - dc App

[고양아(lastiii)]

근데 문제는 웹으로 점차 큰 문제들을 다루게 됨. 앞서 말한 애플리케이션화때문에. 그러면서 그에 걸맞는 프레임워크들이 등잠함. - dc App

[고양아(lastiii)]

여기서 말하는 프레임워크란 리액트, 앵귤러, 뷰 등을 말함. 물론 리액트는 엄밀히 말하면 라이브러리지만 보통 리액트쓰면서 리액트만 씨는 경우는 없으니 프레임워크로 퉁치겠음. - dc App

[고양아(lastiii)]

이런 프레임워크들은 웹 애플리케이션에서 해결해야하는 복잡한 문제들을 다루기에 적합하게 설계됨. 근데 일부 개발자들은 제이쿼리 이후의 것들을 학습하는데 있어서 거부감을 가지기 시작함 - dc App

[고양아(lastiii)]

그래서 복잡한 문제들도 제이쿼리로 죄 해결하려고 하기 시작함. 이게 제이쿼리가 욕먹기 시작한 시점임. - dc App

[Scala(scalaboom)]

뭔 댓글 달렸나 보러왔는데 요새꺼 거부감 가진다는데서 뼈맞고가네 부들부들;;

[하와와(223.62)]

그냥 존나 가만히 있어야겠다 - dc App

[고양아(lastiii)]

제이쿼리로 코딩을 할땐 구조를 어떻게 잡을지, 상태관리는 어떤 방식으로 할지 등등에 대한 표준 혹은 베스트 프랙티스가 없다보니까 개발자마자 전부 다른 방식으로 코딩을 함 - dc App

[고양아(lastiii)]

그래서 제이쿼리를 할줄 알아도 소스파악이나 유지보수가 힘들어지기 시작함. 게다가 dom을 직접 건드리니 성능도 나쁨. - dc App

[고양아(lastiii)]

결론은 간단한 문제에 한해서는 제이쿼리는 아직 현역이라고 생각함. 단 document로서의 웹이 아니라 application 으로서의 웹은 그에 걸맞는 도구들이 사방천지에 널렸음 - dc App