저도 저번에 보고 좀 의아 했는데..
크로스브라우징의 문제가 스크립트쪽도 있기는 하지만 극히 일부분이고.. 대부분은 css 쪽일듯 한데..
서버에서 브라우져를 체크해서 따로 뿌려주는 방식인건가요? ;;

보통 크로스브라우징에서 문제가 되는 부분이 css 가 아니라 스크립트쪽이라는 얘기인가요?
좀 이해가.. ;;

IE가 불여시나 크롬처럼 css 만 통일되게 해석해줘도 크로스브라우징 80%는 해결이 될 거 같아요. 요즘은 모바일 때문에 오레라도 필수로 맞춰주고 있는데 외국애들이 왜 오페라오페라 하는지 알거 같아요.
JS가 브라우저별로 엔진에 차이가 조금씩 있지만 css만이라도 어떻게 맞춰 줬으면 좋겠어요.
빌게이츠 그렇게 안 봤는데 사람 고집 있는거 같아요.

Server Side(이하 SS)에서 처리를 한다면 UA값으로 분기 처리하거나 클라이언트단에서 JS를 조건분기 처리하는것이나 별반 차이가 없는것으로 사료 됩니다.
그리고, 분기처리를 한다면 SS에서 Node.js나 V8이 왜 필요한지요?
그냥 일반 php, jsp, asp등의 SS 스크립트로 해도 되는것을요?

두 예제 사이트는 RESTFul and SOAP service, XML-RPC, JSON-RPC등 객체를 다루는 부분에서는 말씀하신것처럼 node.js 및 SS JS, CoffeeScript 같은 언어를 사용하는것이 이점이 될수 있지만,
제가 잘못 이해하는지는 모르겠지만, 본질은 DOM 이벤트 컨트롤 부분에서는 SS JS와 CS JS는 무관하지 않을까 생각됩니다.

http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/ 링크를 클릭해서 글을 읽어보았는데 이건 node.js와 전혀 상관없는 이야기입니다. 서버 사이드 렌더링이 클라이언트 렌더링보다 5배나 빠를 수도 없습니다. 글을 잘 읽어보면 어떤 상황인지를 알텐데요.

링크에서 말하고자 하는 것은 다음과 같습니다:

처음 client-side rendering을 했던 이유는 사용자가 웹을 콘트롤 할 수 있도록 관련 api들을 담은 javascript를 client로 보내어 사용자가 원하는만큼만 데이터를 받아오도록 했습니다. 이것은 사용자들에게는 큰 잇점이 되지만 문제는 그에 필요한 api를 담은 방대한 javascript 코드를 client에 보내야 합니다. 문제는 모바일이 중심이 되어가는 시대에 이것은 효율성이 떨어진다는데 있습니다. 일반 피씨에서 javascript코드를 처리하는 것은 빠르지 않아도 문제가 없지만 모바일에서는 javascript코드를 처리하는 속도는 더욱더 느리고 또 데이터를 받아처리하는 api및 관련 javascript 코드를 받아야 하므로 더많은 데이터를 브라우져는 받아야 합니다. 따라서 이것은 모바일 시대에 맞지 않으므로 트위터에서는 server-side rendering으로 방향을 전환하고자 하는 겁니다.

그렇다면 server-side rendering이란 무엇인가? 그건 이미 대부분의 웹사이트(여기 sir.co.kr포함)에서 하고 있는 방식입니다. 관련 api없이 화면에 뿌릴 데이터를 서버에서 결정해서 관련 html 코드및 css, javascript 코드를 내려보내므로 client-side rendering 때보다는 관련 api가 없으므로 더 효율적입니다. 물론 사용자는 자신이 원하는 데이터만 받을 수없고 서버가 보여주는 모든 것을 봐야하므로 사용자 컨트롤은 사라집니다. 이것이 링크에서 말하는 요지입니다.

따라서 이것은 node.js와 전혀 연관이 없습니다.

또한 서버가 V8 엔진으로 돌아가는 node.js를 쓰더라도 다른 언어와 마찬가지로 클라이언트에서 화면제어에 사용될 javascript 코드는 내려보내야 합니다. 이유는 모든 서버는 무조건 클라이언트에 html, css, javascript 코드를 내려보내고 클라이언트 브라우져에서 그걸 받아들여 해석하여 화면에 뿌리기 때문입니다. 따라서 HackYa님이 원하는 것이 되려면 모든 브라우져는 동일한 javascript 엔진을 쓰지 않는 이상은 불가능합니다. 그런데 MS에서 혹은 Apple이 구글에서 만든 V8엔진을 사용할까요? 다행히 각 브라우져들은 업데이트 과정을 거치면서 어느정도 표준을 맞추어가고 있다는데 위안을 삼을 뿐이지요.

서버사이드에서 처리해서 렌더링 되는걸 강제한다는 말이 무슨 뜻인지는 잘 모르겠지만
사용자 user agent 값을 체크해서 다르게 보여준다는 건가요?
그건 별로 좋은 방식이 아닐듯 한데 ;;

옛날에 자바를 실행해서 클라가 결과를 받기 위해서는 핫자바를 써야 했는데 서버사이드가 클라에 종속 된다면 다시 과거처럼 플랫폼 독립적인 웹프로그램이 어려워 질 것입니다. 미오님 말이 맞을 거 같아요. 서버 플랫폼은 독립적이여야 하고 클라가 환경을 맞춰줘야 되는 게 맞을 거 같아요. 비용측면에서도 user agent를 구분해서 프로세스를 별도로 작성한다는 건 효율적이지 못할 거 같아요.

크롬 frame은 플래시나 실버라이트처럼 클라이언트에 설치형입니다.
말씀하신것처럼 강제시키기위해서는 플러그인을 내려받아서 설치형으로 해야되거나
JVM 기반으로 in IE로 프로그래밍 한다면 가능할지 모르지만, 효율성 면에서는 IE일 경우 크롬 frame을 내려받게하는게 더 쉬울것 같습니다.

제가 이해을 제대로 한건지 모르겠지만

응용 프로그램 사례로 비교해 볼께요..

웹이 뜨기전에는 2 Tiger ( Client - Server ) 였는데
매번 Upgrade 해야 되니, 번거스럽고 OS Lib 에 너무 의존하게 되는데다 용량이 커져서
나온것이 3 Tiger 방식 ( Client - Middle Ware - Server ) 가 생겼습니다.

여기서 Middle Ware 가 본글의 node.js 가 될것 같구요..

그런데, 응용프로그램 시절엔 접속자가 대중이 아니라
각 부서별 지역별 지점등이 연결된 구조라 동시 접속자수가 전국 대상은 아니기에
하드웨어만 빵방하면 그리 큰문제가 되지 않았습니다.

아주 큰 대기업은 접속자수 포화로 인해
볼랜드에서 나온 기능별 분리
( 단어을 잊어 먹었습니다..ㅠㅠ..M$ 가 라이센스 구매했고, Java 도 이와 비슷한 framework 을 가지고 있던데 )
을 이용 했었습니다.

하지만, 웹이 떴고 node.js 가 말씀 하신것처럼
전 세계의 대중을 대상으로 써비스한다면
부하를 서버에 두게됩니다.

웹은 분산화...
즉, 각 접속 Client 단에 부하을 넘겨 주고, 서버는 최대한 부하을 줄여주면서
퍼포먼스쪽에 효율성을 주는것이 대세가 아닌가 싶어요.

써비스 차원에서는 좋은 방식이기는 하지만
고급 사양의 서버라 하더라도 버티지 못할것 같은....ㅠㅠ

저의 사견이예요..^-^

상황이 그렇다면 얘기는 달라질것 같아요...^-^

그리고, 제가 하나 관과한게 있었습니다...크로스 브라우징....

응용 프로그램은
원도우로 딱 고정이 되어 있었는데,
웹은 그게 아니니...

딜레마에 저도 빠져 버리네요...ㅠㅠ

node.js 을 해 본적이 없고 모르는데, 주절 거린것 같아요..죄송합니다..
HackYa 님 따라가기 바쁘네요....ㅋ으

이건 예전에 JS, CSS가 디자이너 영역이냐 개발자 영역이냐 뭐 그런 거 같아요. 이건 남북통일보다 해결이 어려울 거 같아요. ㅠㅠ
저도 웬만한건 클라에서 해결 보는게 낫다는 생각을 갖고 있는데 각자 의견이 분분하니 그건 프로젝트 팀마다 월급 많이 받는 사람이 일 조금 더 하는 걸로... ㅡㅡ;

설명해주셔서 고맙습니다.
저도 미오님 처럼 html/css 크로스 브라우징 으로 이해했습니다.
브라우져별 js 처리문제라면, HackYa님 말씀처럼 node.js 같은 서버사이드 js 엔진을 이용한 방법이 좋은 해법이 될수 있겠네요.

제 컴이 얼마전에 JVM을 계속 업데이트 하던데 혹시 IE11을 위한 사전 조치일까요? ㅡㅡ; IE9 이제 겨우 적응했는데 걱정이네요.