jQuery 쓰세요

angular 가 협업에 좋다라...

글쎄요. 일단 angular 쓰는 사람을 그리 본적이 없어서 ( ..)

일단 배우면 좋습니다. jquery 하고 호환성 100% 이구요. jquery 대체를 하기 위해서 구글에서 만든거니깐요.

angular의 진수는 restful 방식의 one page 를 지원한다는 점이죠. scope 개념도 재미있구요.

react의 경우 소스 가독성이 좋아지죠.

퍼블리싱하는 사람이 자바스크립트를 모르면 망한다는 단점이...

@닥

jquery는 이미 왠만큼 사용가능합니다. jquery로 짜게 될 경우 라이브러리기 때문에 구조를 만들어야 하는데, 구조를 안만들고 사용하면서 대충 대충 만들다 보면 어느새 소스코드가 지저분해지고 이벤트의 흐름이 직관적이지 않아서 위와같은 고민을 하고 있습니다.

@kaido

제가 말하는 협업은 디자이너와 개발자의 관계를 말합니다. 개발자끼리의 협업이라면 물론 고려대상이 아닙니다. 프론트 단을 나중에 다른 시스템과 어느정도 연계하기 위하여(가령 지마켓이나 앱같은..) restfulAPI를 구현했고, 활용하기 위해 angular와 react를 검토하게 되었습니다. 다만 spa기능은 ci기반이기 때문에 구지 필요한가라는 생각때문에 구지 저기능이 전부 필요하다라는 생각이 안들어서 새로운 뭔가를 만들어야 겠다는 생각입니다.

@박준영

제가 개발하고 퍼블할거라 그다지 문제가 되지는 않지만 나중에 유지보수시에 약간의 리스크가 있습니다.

그리고 또한가지 문제가 seo를 고려하면 서버사이드 렌더링을 해야하는데 php렌더링 셈플은 구하기 어렵네요 거의 node다 보니,

node로 갈아타기엔 러닝커브가 클거같고 하이브리드로 가기엔 개발비용이 늘거같고 심플한 구조로 플럭스의 패러다임을 받아들여

뭔가 만들어 ci에 적용하면 좋게다는 생각을 하고 있습니다. 그리고 거의 대부분 자바스크립트로 처리하는데 전부 자바스크립트로 구현할 필요가 있냐는 생각도 듭니다.

@닉

개인적으로 전 디자이너와의 협업을 고려하지 않습니다 OTL

어차피 안 될건데요 뭘. 

"난 몰랑. 난 내할일 함. 너님이 알아서 처리 하셈."

이런 디자이너 퍼블을 한두명 본게 아닌지라. 이미 체념했습니다 ㅋㅋㅋ

뭔 프레임워크를 사용하든 템플릿코드를 쓰든 어차피 자기 할일 만 하더라구요 OTL

@kaido

부럽네요 저도 제일만 했으면 합니다만, 일이 많아지면 분담하고 싶은게 사람 심정인지라 왠만한 간단한 건 디자이너나 퍼블이 맡아서 처리해 줬으면 하는바람이 있습니다. 제가 하고 있는 플젝은 정말 하드해서 인원이라곤 개발자 꼴랑 저혼자라 디자이너에게 마크업을 시켰습니다. 서버쪽 할일도 많고 공부할것도 많고 한대 간단한건 너 알아서 해라 하고 싶어서 협업을 고려하고 있습니다. 때문에 angular의 html에 곧바로 사용하는 코드는 나중에 디자이너가 수정하기도 편하겠다는 생각을 하게 된거죠. 허나 엥귤러의 전 기능은 필요치 않고 리엑트의 좋은점도 있으니 축소와 짬뽕으로 ci만의 새로운 무언가가 나왔으면 좋지 않냐는 생각을 하게 되었습니다.

react:, angular 이 둘의 장점은 타 분야로 진출하기 쉽다는 점입니다.(안드로이드 까지 확장 할 수 있습니다.) 다만, 유지 보수가 힘들다는게 단점인 것 같습니다.

저같은 경우는 https://github.com/WebReflection/document-register-element#document-register-element 를 연구 하고 있습니다.

연구중인 페이지: http://demo.foxrain.me/test/custom_element/

@닉

프로그램을 하다 보면, 너무 정해진 규격에 맞게 하기위해서 일부러 돌아가야 하는 경우도 발생합니다.

어떤게 더 효율 적일가요? 디자이너가 프로그래밍 정보가 부족하다 하여, 그걸 배려하기 위해서 개발자가 좀 더 고생하는게 맞는 걸까요?

저같은 경우는 작업 순서을 진행 할 때.

디자인 및 퍼블리싱 된 파일은 따로 보존 하고 별도로 작업합니다.

디자인과 퍼블리싱만 된 파일을 보존하고, 복사해서 제가 프로그래밍한 곳에 씌우는 방식을 사용합니다.

자바스크립트 라이브러리를 어떤걸 쓰던 관계는 없지만, 남을 너무 배려하다 보면 오히려 프로젝트 소스가 더 복잡해 지지 않을 가 하는 걱정이 드는건 사실 입니다.

@닥

저도 닥님 처럼 작업 합니다.

가령 이렇게 저렇게 하면 우리 둘다 편해질수 있어요! 친절히 가르켜 주어요. 그리곤 나는 기대를 했어요.

그런데 돌아온것은 반쪽짜리 결과물입니다.

"윙? 이게.... 뭥.미?"

라고 하면

"전 최선을 다했어요. 당신 때문에 전 하지도 않을 작업을 더 했다구요. "

이런 상황 많습니다.

그 이전에 '니가 알아서 해' 인 경우가 더 많구요.

아 물론 이건 같은 회사 사내에 있을 경우엔 그렇고,  하청으로 업무 배분하면 그런거 없다. 알아서 맞춰서 가져오기. 계약서 쓸때 이렇게 하라고 꼼꼼히 작성해서 보내줬고, 너님은 계약서 찍었다. ㅇㅇ

뭐 이게 일반적인 상황 아닌지.

@웅파 확인해봤는데 나중에 시간났을때 사용해 보면 좋겟네요 약간 부트스트랩이나 jqueryui같은 거네요...

@테러보이 자바의 커스텀태그 같은건가요??

@닥 네. 이부분 저도 공감하는 내용입니다. 가령 배려하려 컨트롤러에서 루프를 돌려 데이터를 가공하고 뷰부분에서 템플릿코드를 사용한다던지 하는 부분은 어지되었던지 리소스를 좀더 사용하는 거기때문에 성능상 좋지 않은 부분일 수 있습니다. 그부분 저도 충분히 공감하고 그럼에도 이전 프로젝트에서 템플릿 코드를 사용했을때에 디자이너가 수정할 수 있는 범위가 넓어지는건 사실입니다. 남을 배려했을때 제가 작업해야하는 비용과 배려하지 않았을시에 디자인 수정 비용의 차이가 전자는 디자이너 혼자 처리가능, 후자는 디자이너와 개발자가 같이 처리해야 함 이럴경우 좀 더 고생하는게 나중에 유지보수 할 시에 좀 더 편해지는 이점이 있을거라 판단하였습니다.

@닉

참 난해한 부분이네요. 

디자이너가 단순히 php 변수가 들어간 구문때문에 수정을 못한다면, 디자이너 혹은 퍼블리셔의 역량을 키우는 방향이 바람직 하다고 봅니다.

기술의 부족을 서버사이드에서 보완하는 방법은 프로젝트도 복잡해지고, 일만 많아지는 꼴이 됩니다.

왜 디자이너는 html만 만져야 한다는 생각을 해야 할까요?

우리가 중점을 줘야 하는건 성능이 좋은 웹사이트를 만들어야 하는 것이지요.

디자이너가 수정하기 편한 웹사이트를 빌드 하는 목적이 아닙니다.

유지보수도 디자이너가 조금만 코드를 이해하려 하는 의지가 있다면 개발자가 수정하지 않고 디자이너 혹은 퍼블리싱 단에서 해결 된 문제 들이라고 판단 됩니다.

업무효율적인 측면에서도 자기분야에서 부족한 부분은 기술자가 습득해서 채워야 하는 부분이지, 다른 이에게 의지하여, 코드의 복잡성을 가중시킨다면 잘못 된 방법같아 보입니다.

즉 개발자들도 일찍 집에 가야 한다는 소리지요!

이상입니다.!!