HTML 5가 등장해서 Web은 어떻게 변화할 것인가?  현재까지는 대부분이 하이퍼 링크를 통한 연결된 문서구조를 조회하는 수단으로 사용하였지만 웹의 발전과 더불어 HTML 5의 등장은 이런 구조를 넘어서 웹에서 응용 프로그램을 실행하는 플랫폼으로 발전한다고 볼 수 있습니다.


웹 애플리케이션 데스크탑 애플리케이션과 동일하게

이미 구글은 크롬 OS를 만들겠다는 발표를 하였고 그에 맞춰 데스크탑 애플리케이션을 웹과 동등하게 만드는 작업을 꾸준히 해왔습니다. (Gmail, Google Calendar, Google Docs 등) 데스크탑 애플리케이션에 비하면 기능과 사용 편의성 면에서 차이가 크기는 하지만 이러한 웹 애플리케이션을 “기본과 동등”하게 하는 것이 구글의 목표라는 것은 사실입니다.



만약 이것이 실현된다면 응용 프로그램은 운영체제(Windows, Macintosh, Linux)에 제약을 맞지 않고 개발할 필요가 없어지게 됩니다.  이렇게 된다면 클라이언트 플랫폼은 절대적으로 웹을 기반으로 할 것이고 IT 업계에는 엄청난 변화가 찾아올 것입니다.



이미 웹의 생태를 유지시켜주는 많은 벤더들 또한 그렇지 않았던 벤더들까지 모두 웹을 기반으로 하는 플랫폼으로 발전하기 위해 무척 노력들 하고 있고 이러한 노력은 방법만 다를 뿐 목표는 같다고 할 수 있겠습니다. 그러나 구굴의 이런 시나리오는 실현이 가능할지 의문이 듭니다. 물론 실현은 가능할 것입니다.  HTML5 뿐만 아니라 프로그래밍 언어라는 JavaScript의 진화가 뒷받침 되어야 한다는 것이지만, 현재 많은 모던 웹 브라우저는 JavaScript 실행 환경으로 JIT 컴파일러를 제공하려 노력하고 있기 때문에 실행 속도측면에서 보면 머지 않아 웹 응용 프로그램은 데스크탑 응용 프로그램과 거의 같은 지점까지 도달할 것입니다.

HTML5는 로컬 데이터베이스 기능이 갖춰져 있으며, 시각적 요소를 유연하게 표현할 수 있는 Canvas와 아직 표준화가 되지 않은 3D를 표현 가능한 O3D가 있습니다.  그리고 대규모 개발을 지원하는 JavaScript 개발 환경 및 라이브러리, 프레임 워크 등의 뒷받침은 데스크탑 애플리케이션과 거의 동등이 할 수 있는 기술적인 요소 대체로 볼 수 있습니다.

즉 구글은 웹 응용 프로그램을 데스크탑 애플리케이션과 동등하게 하려는 목적은 거의 주요 울토리안에 담아 둔 것입니다.  물론 실현과 시장에 내놓기까지에는 몇 년의 기간이 필요하겠지만 최근 구글의 움직임을 보면 이 처럼 뚜렷하게 목표를 세우고 그 시장을 주도하고 있다는 느낌을 받습니다.


각 장치의 기반 기술은 웹으로 일반화 된다.

또 하나는 모바일과 PC 및 기타 장치 응용 프로그램들이 모두 웹 표준으로 통일되어간 다는 이야기입니다.

지금은 스마트폰 전용의 웹 사이트가 많이 있고 어떤 사람들은 휴대 전화 전용 기능을 많이 사용도 하고 있습니다.  하지만 iPhone과 Android의 등장으로 장치가 발전하였고 PC용으로 만들어진 Web 사이트를 휴대폰에서도 동일하게 보려는 흐름으로 가고 있습니다. 이런 흐름은 휴대전화 전용의 웹은 없어져야 하고 웹 표준으로 단일화 되어가려는 것이라고 견해를 모으고 있습니다.

그리고 이 진화의 흐름은 모바일과 스마트폰뿐만 아니라, 예를 들어 차량용 디스플레이, 디지털 신호에 사용하는 디스플레이와 같은 많은 장치에서 실행되는 응용 프로그램이 HTML, CSS, JavaScript 웹 기술을 기반으로 통합되어가는 시나리오의 일부분이라고 생각합니다.  웹 응용 프로그램이 데스크탑과 똑 같게 되면 모바일에서도 기종에 의존하는 전용 응용 프로그램을 만드는 것보다, 표준 기술을 기반으로 휴대할 수 있는 응용 프로그램 만드는 것이 더욱 효율적일 것입니다.

물론 다양한 디바이스 별 차이로 인하여 사용자 정의를 따로 처리해야 할 일은 남을 것이고 디바이스 의존성이 강하거나, OS 의 내장 기능에 대한 차이가 많은 경우 그리고 디바이스마다의 고유한 사양 메모리 CPU 등이 여유가 없는 경우에는 한계 있다는 것입니다.


웹 기술의 발전은 메가 트랜드가 될 것이다.

이렇게 보면, 웹 기술의 발전이라는 것은 응용 프로그램이나 장치를 잠식해가는 메가 트랜드가 될 것입니다.

현재 Visual Basic 및 C++/C#과 같은 클라이언트 응용 프로그램을 작성하는 프로그래머, 장치에 대해 기본적인 응용 프로그램을 개발하는 프로그래머, 그리고 개발하고 있는 것이 비즈니스 애플리케이션, 엔터테인먼트 그리고 교육까지 모두가 웹 기술을 기반으로 하는 시대가 수년은 먼저 오는 것이 아닐까?

함께 읽으면
HTML 5를 개척하는 새로운 웹 ( 1 Google 편)

출처 : http://www.publickey.jp/blog/09/html5web_1.html
신고
Posted by Rhio.kim
TAG HTML5, Mobile, web

HTML 5를 개척하는 새로운 웹 ( 1 Google 편)


문서를 보기 위한 웹에서 응용 프로그램 플랫폼으로 HTML 5의 등장이 웹을 크게 바꾸려고 합니다.  해당 HTML 5에 대한 주요 웹 브라우저 벤더는 어떻게 생각하고 대응하려고 하고 있을까?


개방된 형태로 HTML 혁신을 추진하라

이번에는 구글 오이카와 타쿠야와 소프트웨어 엔지니어 타무라씨에게 Google Chrome 관련 HTML 5의 노력에 대한 이야기를 들었습니다.

그림 1 오이카와 타쿠야

그림 2 타무라



질문] 구글은 올해 샌프란 시스코에서 Google I/O, 일본에서 Google Developer Day 2009 에서 HTML 5에 대하여 크게 어필을 시작하고 있고 구글에서 HTML 5를 통해 일어나는 웹 세계는 어떤 것이라고 생각하고 있나요?

답변] 오이카와 올해 구글은 HTML 5에 대해 대대적으로 메시지를 보내고 있지만, 사실 작년부터 HTML 5는 시작하고 있었습니다.  지난해 Google I/O, 일본에서 Google Developer Day에서 클라우드, 연결성, 클라이언트 3개의 C가 중요하다는 이야기를 했습니다.  그 중 Connectivity와 관련된 상황에서 환경이 안정되어 있지 않거나 오프라인이 되거나 하는 상황에 대한 답변으로 Gears를 소개했습니다.

그 때의 Gears 방향으로 HTML 5의 표준화를 추진하고 있다는 것을 분명히 하고 있습니다.  그런 부분에서 HTML 5라는 키워드를 발표했습니다.

그 때부터 사실 메시지는 변경되지 않았고 웹 브라우저 크롬을 개발하고 있는 것도 똑같은 생각에서 앞으로의 웹은 정적 정보의 발신, 수신뿐만 아니라 응용 프로그램을 사용하는 장이 될 것입니다.

실제로, 많은 사람들이 PC에서 사용하는 것이라고 하면 웹 브라우저와 메일, 그리고 메일도 대부분의 웹 메일을 사용하도록 되고 있습니다.

이렇게 많은 사람들이 웹 쪽으로 사업과 생활을 나누게 될 때 네이티브 응용 프로그램이 웹에서도 얼마든지 할 수 있는 것이 당연한 모습이 아닐까요!

그때 필요한 것이, HTML의 혁신입니다. 그것도 개방된 형태로 혁신을 추진해야만 한다, 이것이 지난해부터 계속해 온 좋은 메시지 입니다.



HTML 5 스펙으로는 아직 네이티브 애플리케이션을 만들 수 없다.

질문]  당연히 웹에서도 네이티브 응용 프로그램과 동일한 수준이 가능할까요?

답변] 오이카와 그렇지 않습니다.



질문] 같을 수 있다는 점에서 많은 사람들이 회의적이라고 생각합니다.  네이티브 응용 프로그램과 웹 응용 프로그램의 자유도 및 실행 속도와 표현력에 차이가 있는 것은 아닐까. 하지만 그것들은 HTML 5를 기반으로 하므로 극복할 수 있다고 믿어도 될까요?

답변] 오이카와 네 그럴 것 같습니다.  HTML 5는 그것을 때로는 가능 여부의 검증을 위해 사용할 때도 있지만, 좁은 의미의 HTML 5는 둘러싼 기술과 개방형 웹 기술이라는 것을 사용한다면 극복할 수 있다고 생각합니다.  

현재 구굴 엔지니어링 부분 부사장인 Vic Gundotra는 이전 MS의 핵심 엔지니어로 있을 때 웹 애플리케이션과 데스크탑 애플리케이션에서 할 수 있는 것은 다르다고 생각했었다. 

그 떄 당시 그가 주목하던 소프트웨어 공급 업체 중 하나인 KeyHole 라는 회사의 입체적인 지구가 빙글 빙글 움직이는 이런 것이야 말로 웹 응용 프로그램이 없는 원시 응용 프로그램이다 라고 알고 있었다고 합니다. 

이것이 문득 생각이 나 KeyHole라는 회사를 구글에서 인수하였으며 또한 Gmail도 나오고, 점점 로컬에서 밖에 할 수 없다고 생각했던 응용 프로그램들을 웹에서도 가능하도록 시도 하고 있습니다.

비슷한 일이 앞으로 몇년 동안 일어날 것이고, 과연 웹에서 무리라고 생각했던 것이 HTML 5를 중심으로 한 개방형 기술을 웹 브라우저가 도입하고 그것을 응용 프로그램에서 사용한다면 가능하게 될 것입니다.



질문] 이렇게 HTML 5를 중심으로 한 새로운 표준과 기술과 함께 구글이 주력하고 있는 것은 무엇이 있습니까?

답변] 오이카와 먼저 기술이 개방되고 있는 것은 매우 중요하다고 생각합니다.  또한 예를 들면 Gears에서 하고 있는 것은 오프라인 기능, 프로세스, 스레드와 스케쥴링을 제공하는 Web Worker와 같은 것을 여러분의 동의를 얻어 구현과 표준화를 추진할 예정입니다.

O3D(웹 브라우저에서 3D 그래픽을 표시하기 위한 Google에서 제공하는 새로운 기술) 는 아직 연구 중인 HTML 5의 Canvas에 2D 그래픽스를 실현할 수 있게 되면 다음은 역시 3D가 아닌가 생각합니다. 이 부분 역시 구현을 진행해 가면서 표준화를 추진해 나가는 식이 될 것 같습니다.



질문] O3D 를 연구하는 것처럼 HTML 5에 아직 부족한 부분이 많이 있다고 생각합니다.  HTML 5에 부족한 부분이 있다면 어떤 것이라고 생각합니까?

답변] 타무라 개인적인 느낌은 지금의 HTML 5의 스펙은 네이티브 애플리케이션과 같은 것을 만드는데 매우 부족하다고 생각합니다.  여러 방면의 API와 기능이 필요하다고 생각합니다.


HTML 5에 부족한 것

답변] 오이카와 아직 HTML 5에 들어 있지 않은 스펙으로는 구글이 하려고 하는 것 중에 contentEditable 기능이 있습니다.

이 기능을 사용하여 웹 브라우저에서 쉽게 리치 텍스트 편집기를 제공할 수 있지만 현재는 표준이 충분하지 않기 때문에 웹 브라우저마다 구현이 상당히 다릅니다.  예를 들면  블로그에 편집기 같은 것들을 많이 구현되어 있고 편집기에서 텍스트를 선택하고 굵게 변경하고 다른 웹 브라우저에서 다시 편집기를 통해 원래대로 되돌리려고 해도 되돌아 가지 않는 경우가 있습니다.

이런 웹 브라우저마다 구현의 차이에 대응하기 위해 JavaScript를 사용하여 복잡한 프로그램을 써야 합니다.  그런데 이것의 표준화가 제대로 된다면 불과 몇 줄로 끝날 수 있습니다.

이 부분은 곧 HTML 5 스펙에 건의를 할 수 있는 상황에 와 있지 않나 생각합니다.

이 외에도 Notification 이라는 것을 검토하고 있습니다.  이것은 예를 들면, Google Calendar에 경고를 표시하기 위해서는 웹 브라우저 탭이나 어딘가에 열려 있지 않으면 안됩니다.  다른 탭에서 작동하는 경우에도 경고가 표시되면 강제로 탭에 포커스를 잃게 하는 것은 문제점이 있다고 생각합니다.

이러한 웹 응용 프로그램에서 알림 기능은 로컬 응용 프로그램처럼 응용 프로그램 화면에서 독립적인 모양이 좋지 않을까요?  이것은 표준화 작업 전에 구글에서 프로토타입을 만들고 그것을 보면서 표준화를 추진하려고 합니다.

그 이외에 아직 아이디어 단계에 있는 것들을 예로 들면, 역시 P2P의 일종, 웹 응용 프로그램이여 반드시 웹 서버와의 통신만 하는 것이 아닌 피어간의 통신을 하는 것들도 필요하지 않을까 생각합니다.  채팅 때는 일일이 서버를 경유하지 않아도 되니 괜찮을지 모릅니다.

또한 드래그앤 드롭 기능도 아직 한정되어 있으며 또는 파일 API에도 업로드 불가능한 파일을 제거하는 방법 등이 고려할 여지가 있을지 모릅니다.

예를 들면, 웹 브라우저 간에 여러 형태의 데이터 통신이 발생하는 것은 웹 개발팀에서 고민을 하고 있습니다.  실시간 채팅의 경우라면 짧은 데이터로 매우 빠르게 상호 작용하게 됩니다.  반면에, 많은 사진을 드래그 앤 드롭 하면 훨씬 많은 데이터를 전송하게 됩니다.  여러 파일 데이터 액세스 등이 필요하게 될 것입니다.

또는 웹 카메라와 마이크에 대한 액세스인데 이것은 Flash를 사용하고 있습니다.  Flash에 의존하지 않고 로컬 리소스에 액세스를 가능하게 하고 싶습니다.

답변] 타무라 Gmail은 첨부 파일을 업로드하는 기능은 올 3월 경부터 Flash를 사용하여 다중 파일 처리와 업로드 상태 진행률 바를 나타내도록 하고 있지만 특정 브라우저 버전과 플래시 버전에 따라 동작의 차이가 있어, 역시 플로그인에 의존하는 것은 어렵다는 느낌을 받습니다.  이래서 파일을 다룰 부분은 검토하고 싶습니다.

또 하나의 Gmail이나 Docs 풀다운 메뉴가 있지만 브라우저 호환성을 위한 처리 떄문에 수천 줄 같은 코드를 작성하게 됩니다.  이것은 HTML 5의 메뉴 기능이 쉽게 구현할 수 있게 될 것으로 기대하고 있습니다.

폼 입력의 유효성에 대한 것은 HTML 5는 쉽게 할 수 있습니다.  개인적으로 이메일 주소의 유효성은 웹 사이트마다 제 각각이여 곤란한 경우가 종종 있는데 HTML 5의 검증(Validation)을 사용하여 type = email 로 쓰면 됩니다.

답변] 오이카와 웹 포럼에서 반각 문자(영어와 같은)에 치우치지 말고 자동으로 IME를 설정해주면 좋을 텐데라고 생각합니다.  아직 일본이나 아시아의 언어로 부드럽게 설정하려는 곳이 있기 때문입니다. 사실 이 부분은 가까운 미래에 아마 제 멋대로 될 것이라 생각합니다.  IME 통합 등은 W3C 및 기타 브라우저 벤더들 하기 나름이기 때문에 대화로서 좋은 방법을 찾으려 하고 있습니다.

우리의 목표는 로컬 응용 프로그램과 유사한 다양한 웹 애플리케이션에 있습니다.  온라인과 오프라인에서 모두 사용 가능하게 되는 것입니다.  거기에 부족한 것은 구현하고 표준화를 진행하고자 합니다.



질문] 그런 기술을 보급하는데 얼마나 많은 시간이 걸릴 것으로 예상하고 있습니까?

답변] 오이카와 어떤 것을 기준으로 해야 할지 어렵습니다.



질문] 예를 들면 Gmail 또는 Google Wave에서 HTML 5의 기술을 사용하여 공개 출시하는 것이나 그와 비슷한 것들?

답변] 오이카와 HTML 5를 사용한 것은 꾀 빠르다고 생각합니다.  지금 Google Wave팀과 긴밀한 커뮤니케이션을 하고 있지만 HTML 5의 기술을 매우 이른 단계에서 사용하기 시작한 것이 아닐까 생각하고 있습니다.

왜냐하면, HTML 5를 말하는데 가장 중요한 것은 일부 스펙은 사용하기 시작한지 얼마 되지 않았고, Canvas의 경우에는 올해 반년 동안 매우 빠른 속도로 사용되어지고 있기 때문이 아닐까 생각합니다.

답변] 타무라 Gmail도 지금 각 브라우저에서 저장이나 응용 프로그램 캐시 기능을 구현하는 것을 시작하고 있기 때문에 조속히 구현하고 있습니다.  이런 식으로 무엇인가 구현을 시작한다는 느낌입니다.
(리오 : 결론은 아직 한참 멀었다는 이야긴가?)

답변] 오이카와 또 Canvas가 구현되지 않은 Internet Explorer는 ExplorerCanvas라는 JavaScript 라이브러리를 사용해서 기본적인 기능을 사용할 수 있습니다.  그리고 Flash에서 사용되고 있는 벡터 형식의 그래픽을 허용하는 SVGweb은 JavaScript 라이브러리를 Google에서 지원합니다.  사실 이외에도 있지만 비밀입니다.(웃음)



질문] 모바일에 관한 이야기는 없나요?  지금까지 모바일과 PC는 각각 기술적으로 나누어진 세계였습니다.  그러나 특히 iPhone과 Android의 등장으로 PC와 모바일에서 동일한 웹의 세계를 볼 수 있도록 되어있습니다.  앞으로는 모바일 및 PC 웹이라는 것이 기술적으로 동일하게 흘러간다고 생각합니다만 어떻게 생각하세요?

답변] 타무라 네 맞는 말이라고 생각합니다.  Android와 iPhone는 대중적이고 휴대전화 전용 웹이라는 것은 사라져 간다고 생각합니다.

답변] 오키카와 완전히 동감입니다.  인터넷이 장치에 의해 분리되었다는 것은 매우 이상하다고 생각합니다.  그 원인은 기술 문제와 비즈니스 모델의 문제가 겹쳐서 발생했던 것입니다.

사업 모델에 대해서는 각 이동 통신사들 및 컨텐츠 제공 업체가 별도라는 생각 떄문에 그런 것 같습니다. 기술에 의한 분단은 이제 확실하게 사라져 간다고 생각합니다.

그러나 몇 가지 제약이 있습니다.  메모리와 프로세서 파워 등은 PC와 같이 매년 증가해가는 것은 당분간 어렵다고 생각합니다. 그리고 넓은 대역폭과 지연시간에 대해서 좀더 개선해야 한다고 생각합니다.  그런 측면에서 모바일의 웹 브라우저와 PC용 프로그램을 모바일에서 사용하기 위한 준비도 빠르게 진행되기란 어려울 것입니다.

소감] 오늘 이야기를 들어 보았던 HTML 5의 스펙과 구현의 목적은 역시 응용 프로그램 플랫폼 표준화가 되어가는 것이군요.  마치 Window + .NET과 JavaVM + Java SE 처럼도 보입니다.

소감] 오이키와 그런 것 같네요.  구글은 그런 멋진 말은 없지만,  웹이 플랫폼이 되는 것은 맞습니다.  또 “웹 브라우저” 에서 묵묵히 “웹 클라이언트”으로 변해 갈 수도 있습니다.  그것이 플랫폼으로 인프라가 되려고 하고 있고 그것은 사실이라고 생각합니다.


요약(필자)
구글이 웹 브라우저 응용 프로그램 플랫폼 만들고 있다는 사실은 지금까지 누구라도 알고 있습니다.  그러나 그 목표가 “웹 브라우저에서 네이티브 응용 프로그램 같은 것을 제공한다”라고 명확하게 한 것에 대해 놀라지 않을 수가 없습니다.  게다가 그것을 플러그인 기술이 아닌 기본 스펙에서 실현하려는 수단까지 명확하게 하고 있습니다.  구글이 여기까지 영입하고 자원을 투입하고 있는 이상, 그것은 아마도 언젠가는 실현되는 것이 분명할 것입니다.  아니 “그것이 언제 실현 될지?” 라는 질문할 수 있는 시점까지 와 있는지 모릅니다.
요약(리오)
짧은 인터뷰 내용이지만 구글의 HTML 5 그리고 표준화에 대한 진행은 웹 이라는 것을 새로운 플랫폼으로 재 탄생 시키려는 혁신이고, 구글의 미래이자 다가올 웹의 미래가 아닐까 생각해봅니다.

최근 구글은 넷북 시장에 관심을 갖고 있으며 여기에 크롬 OS와 앱 스토어와 같은 마켓 플레이스를 향하고 있다는 생각을 해봅니다.  결과는 아래의 그림과 같은!?

 

그림 3 미래 구글의 마켓 예상



더 큰 그림이 있겠지만 HTML 5를 중심으로 한 개방된 기술의 형태 그리고 네이티브 애플리케이션들이 웹 애플리케이션으로 바뀐다는 것은 윈도우에 종속되었던 네이티브 애플리케이션 시장이 이제 웹에서도 똑같이 열릴 수 있다는 것입니다.

구굴이 생각하는 시나리오는 성공하리라 생각해봅니다.
지금부터 조금씩 준비해 나가면 새로운 시장에서 개발자 각 개인도 애플 앱 개발자들 처럼 작은 꿈을 꿀 수 있지 않을까? 


구굴이 주도 하는 HTML 5의 중심의 웹의 미래를 미리 짐작해 볼 수 있는 좋은 자료인 것 같습니다.  
하지만 오역이 있을 수 있습니다. : )
출처 : http://www.atmarkit.co.jp/fwcr/design/benkyo/html5_01/01.html
신고
Posted by Rhio.kim
TAG Google, HTML5
사용자 삽입 이미지
바로 오늘 HTML 5 가 W3C에 의해서 첫번째 표준안의 밑그림이 발표되었습니다.
W3C HTML WG 과 WHATWG 의 협력적 노력으로 W3C 기술 리포트에 두가지의 문서로 결실을 맺었습니다.

하나는 HTML 5  그리고 또 하나는 HTML 5 differences from HTML 4 입니다.
많은 변화가 있습니다. 자세한 사항은 살펴 보지 않았지만 이번 HTML 5의 표준안 발표로
웹의 판도가 어떻게 흘러갈지 기대됩니다.

Web2.0이 각광받기 시작하고 이미 발표한 ECMAScript 4 또한 HTML5의 발표에 발맞춰 웹의 판도는
어마 어마한 시장성을 확보하고 볼수 없는 상상조차 할 수 없는 무궁무진한 잠재력이
내포되어 있음을 뜻합니다.

앞으로 다가올 웹 2.0 혹은 그 이상의 시대는 어떻게 변할지 상상조차 가지 않습니다.
가슴이 두근 두근 거립니다.


변화 요약!
새로운 속성추가, 변경된 엘리먼트, 없어지는 엘리먼트와 속성

새로운 엘리먼트 추가
  + dialog

  + figure
  + audio, video
  + header, footer
  + nav

Input 엘리먼트의 type 추가
  + datetime
  + datetime-local
  + date
  + email
  + url

HTMLDocument 에 getElementsByClassName() 메서드가 추가되면서 className 으로 element collection
을 쉽게 컨트롤 할 수 있게 되었네요.

그리고 다양한 API까지 제공을 하게 되었네요.

자세한 내용은 Draft 를 통해서 참고하시기 바랍니다.
신고
Posted by Rhio.kim
TAG HTML, html4, HTML5, W3c
getElementsByClassNamenative 가 되었다.
여담 : 저는 이런 Webkit, Mozilla 의 새로운 이슈되는 기사를 볼때마다 MS와 비교가 됩니다.
         발빠른 HTML 5 스펙, ECMA Script 4의 적용, Gears 등등 새로운 웹 기반의 패러다임을 만들기 위해서
         불철주야 새로운 이슈를 내놓는데 도대체가 MS는 IE 차기 버젼의 이름은 IE8 이다 라는
         이슈를 봤는데 그게 뭐 어쨋따는 건지... 이그.. 윈도우만 아니였으면 벌써 IE는 쇠퇴해 갔을텐데...

사용자 삽입 이미지

위 그래프는 getElementsByClassName 를 10,000번 수행한 결과 입니다.
상당히 아니 너무나 대조적입니다.  이게 왠말인가.. native 의 수행속도가 이렇게 확연히 차이가 나는 이유는
무엇일까요?

그 속내가 더욱 궁금합니다. 저런 수행 능력이라면 대부분의 것들을 native로 등록해서 쓸 수 있도록 하면 더욱 좋을텐데 말이죠.

이 메서드는 HTML 5 스펙이 추가되었습니다.
또한 파이어폭스와 오페라의 최신의 새버젼에서 지원합니다.


Javascript native method 의 명확한 이점!!


1. 추가적인 javascript 라이브러리 파일을 필요로 하지 않는 다는 것!!
2. 명확한 명세와 일관된 속성을 제공한다는 것
3. 눈부신 속도


밴치마킹 테스트 페이지 : http://webkit.org/blog-files/gebcnspeedtest.html(사파리)
출처 : http://webkit.org/blog/153/webkit-gets-native-getelementsbyclassname/
신고
Posted by Rhio.kim
ECMAScript 4가 발표한지도 한달 정도 흘렀습니다.

대부분의 브라우저에서 이를 지원하기 위해서 각 기술 팀들이 불철주야 발빠르게 뛰고 있겠죠??

사용자 삽입 이미지



















ECMAScript 4 Reference Implementation (ES4 RI)
ECMA TG에서 ES4를 활용하기 위한 참조 도구를 계속해서 제공하고 있습니다.

Tamarin 은 모질라와 Adobe 공동으로 Open Source Adobe VM 에 적용하고 있습니다.
이는 FireFox3 와 Flash 10에서 지원되고 있습니다.

Spidermonkey 스파이더 멍키는 FireFox 의 새로운 자바스크립트 엔진입니다. 스파이더 멍키에
ES4 스펙과 매치되는 새로운 기능들이 계속해서 업데이트 되고 있습니다.
이 프로젝트는 기존의 ActionMonkey 를 대신하게 될 것입니다.

Rhino 는 Java 도구인데 최근에 ES4 스펙을 추가하여 업데이트 되고 있습니다.

Futhrk 는 opera에서 사용되는 javascript 엔진입니다. 조금씩 업데이트 되고 있네요..
가장 저조하지만 이것은 Opera 10에서도 그대로 사용될 계획입니다.

Mbedthis 는 임베디드형 웹 어플리케이션를 위한 스크립트 언어인데요.
최근에 모바일과 C나 Java VM으로 개발되어진 javascript 위젯 형식의 기능을 모바일 기기에서 수행하기 위해서 업데이트 되고 있습니다.

모질라와 Opera에서는 빠른 변화를 보여주고 있는데
IE는 도대체 IE8 을 개발하면서 계속에서 나오는 메모리 누수 문제며 W3C 업데이트된
CSS Griding Positioning 에 대한 언급만하고 이런 ES4에 대한 적용은 어떻게 되가고 있는지는
알려주 않네요.  제발 표준에 의거해서 추가하지 않고 기본에 충실했으면 좋겠는데..

사파리도 빨리 국내에 대응하는 브라우저로 거듭나도록 빠른 대응이 있었으면 좋겠네요..
신고
Posted by Rhio.kim
신고
Posted by Rhio.kim
ECMA Script 4 에 구굴 Waldemar Horwat 와 Pascal-Louis Perez 의  프리젠테이션 영상입니다.
이 영상을 보고 느낀점이 있습니다.  저 정도의 요약된 프리젠테이션이라면 국내에 내놓으라한 개발자들
1주일 정도 회사일 하면서 준비할 수 있는 분량의 프리젠테이션 내용입니다.

구굴을 개발자 커뮤니티가 정말 잘되어 있는것 같습니다.
국내 NHN, Yahoo korea 등 큰 기업에서는 내부적으로 이와 비슷한 스터디 프리젠테이션을 하는 것으로
알고 있습니다.

국내의 고급 소프트웨어 개발자의 인력은 쉽게 많들어 지지는 않습니다.
변화에 빠르게 적응할 수 있는 개발자들간의 커뮤니케이션이 정말 중요하다는 생각이 듭니다.



구글에서도 ECMAScript 4의 가장 큰 변화(기능)은 진정한 OOP 라는 점을 강조하고 있네요.
Class, Interfaces, namespaces, packages, program units 등등

영상속에 숨어있는 간혹 나오는 예제 소스도 관심있게 보세요..
비록 소스가 보이지는 않지만 -_-;;
신고
Posted by Rhio.kim
진화적인 프로그래밍 과 단계적인 타이핑 in ECMAScript 4

튜토리얼이 나왔네요.  완벽한 버젼은 아니구요.
간단한 예제 중심으로 설명을 잘 해놨네요..

가장 중요한  진보는 진화적인 프로그래밍은 타입시스템 그리고  네임스페이스(namespace) 와 패키지(package)
union type, generic functions, reflection

http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf

이건 도대체 Java 인가 JS 인가 ^-^*
신고
Posted by Rhio.kim
W3C에서 "Enabling Read Access for Web Resources" 로 크로스 도메인 처리가 가능한 XMLHTTP Request(XHR) 을 추가하였습니다.

정말 크로스 도메인에 대한 처리는 너무 기대됩니다.
그간 많은 사용자들이 크로스 도메인을 해결하기 위한 시도가 있었는데요..

HTTP header 에 설정을 통하여 가능하게 됩니다.
Access-Control: allow <*.example.org> exclude <*.public.example.org>

XML 방식의 처리
<?access-control allow="allow.example.org" deny="deny.example.org"?>

그래서 이제는 cross_dmain.xml 이 필요없게 되었습니다.


이번 크로스 도메인 정책에 의미는 엄청난 잠재력을 지닌, 보안 문제에 있어서도 안전한
 Mash Up 메커니즘을 제공할 것입니다.

아래 표는 위의 제안과 JSONRequest 의 차이점에 대한 표입니다.
사용자 삽입 이미지



신고
Posted by Rhio.kim
사용자 삽입 이미지
Safari(Webkit3) 의 10가지 변화

맥 OS X (10.5.1 과 10.4.11) 에 있는 사파리와 윈도우용 베타 버젼에서 사파리 브라우저에 내장된 Webkit의 위대함을 느낄 수 있답니다..

^-^;; 얼마나 대단한지 계속 보시죠... 텍스트 위주라 지겨울 수도 있지만 변화를 알고 싶다면 보셔요 ^^



1. Enhanced Rich Text Editing(향상된 리치 텍스트 에디팅)

쉽게 디자인 모드로 만들어진 textarea 말하는데요. 좀더 향상된 지원이 가능합니다.
사파리에서 데모 한번 보시면 아실꺼에요. 브라우저 자체 지원으로 좀더 심플하지만  가볍고 좋네요.
지금은 기본 기능에 충실했지만 차후에 계속적인 고급 기능들이 추가될 거라네요..


2. Faster JavaScript and DOM(더욱 빨라진 Javascript 와 DOM)

다양한 부분의 벤치마킹 툴을 이용하여 맥북에서 WebKit2 와 WebKit3 의 비교를 했습니다.
IE도 좀 이런데 신경 쓰면 더 좋을텐데 말이죠.. 그건 그렇고  아래 밴치마킹 결과를 보세요.

i-Bench JavaScript Processing (사용법도 간단하고 다운로드도 여기서 할 수 있습니다.)
WebKit 2 - 1.99 sec
WebKit 3 - 0.87 sec
WebKit 3 is 2.3 times as fast!

Celtic Kane Javascript Speed Test 2007
WebKit 2 - 1276 ms
WebKit 3 - 624 ms
WebKit 3 is 2 times as fast!
이 부분이 자바스크립트와 DOM 의 프로세싱 테스트 인거 같은데요. 기존 속도에 비해 2배나 빨라졌습니다. 랜더링 속도가 다른 브라우저에 비해 월등했는데 오페라와 맞먹겠는걸요!!

pentestmonkey MD5 test (테스트)
WebKit 2 - 8.352 sec
WebKit 3 - 3.794 sec
WebKit 3 is 2.2 times as fast!

이 부분은 현재 제 PC에 깔린 4개 브라우저에서 테스트한 결과입니다. webkit2 인점을 감안하고 보세요.
- IE
MD5 Benchmark took 3.844 seconds for 3000 hashes (780 hashes/second)
MD4 Benchmark took 6.828 seconds for 2700 hashes (395 hashes/second)
SHA1 Benchmark took 4.094 seconds for 1900 hashes (464 hashes/second)

-Webkit2 in Safri
MD5 Benchmark took 5.531 seconds for 3000 hashes (542 hashes/second)
MD4 Benchmark took 5.203 seconds for 2700 hashes (519 hashes/second)
SHA1 Benchmark took 6.641 seconds for 1900 hashes (286 hashes/second)

- opera
MD5 Benchmark took 2.875 seconds for 3000 hashes (1043 hashes/second)
MD4 Benchmark took 2 seconds for 2700 hashes (1350 hashes/second)
SHA1 Benchmark took 3.156 seconds for 1900 hashes (602 hashes/second)

-FireFox
MD5 Benchmark took 4.406 seconds for 3000 hashes (681 hashes/second)
MD4 Benchmark took 3.25 seconds for 2700 hashes (831 hashes/second)
SHA1 Benchmark took 6.297 seconds for 1900 hashes (302 hashes/second)

테스트 결과가 좀 웃기네요.  4개 브라우저에서 평균적으로 가장 느립니다. 거기에서 2배 정도 빨라진것입니다.
결론은 그동안 다른 브라우저에 비해 MD5등 알고리즘이 느렸는데 빨라져서 다른 브라우저와 비슷해졌다...
뭐 그런 뜻으로 봐야겠네요..

JavaScript Raytracer (테스트)
WebKit 2 - 853.594 sec
WebKit 3 - 48.48 sec
WebKit 3 is 17.6 times as fast!

전반적으로 Webkit3 가 2에 비해서 Javascript와 DOM 처리 속도가 2배 정도 빨라졌다는 점입니다. 짝짝짝!

3. Faster Page Loading (더욱 빨라진 페이지 로딩)

WebKit 2 - 2.95 sec
WebKit 3 - 2.06 sec
WebKit 3 is 1.4 times as fast!
추가적으로 IE, FF 보다 페이지 로딩속도가 빠릅니다.
이 부분은 몇몇 기사에서 소개도 되고 전문 연구 기관에서도 확인한 내용입니다.
하지만 국내에서는 잘 안쓴다는거.. ^^ 국내 지원이 된다면 아마 IE와 FF처럼 점점 느려질 수 밖에 ^^;
그래도 기대해 봅니다. 또. 빨라지면 뭐해 -_-;; 고만큼 무거운 Web 프로그램을 요구할텐데;;;


4. SVG(Scalable Vetor Graphics)
Webkit3의 메이저급 새로운 기능입니다. SVG는 XHTML 과 함께 쓰여 큰 그래픽적인 요소를 표현하기 위한 XML 랭귀지 입니다.
아래 간단한 데모 사이트 입니다.


5. XPath
또 다른 메이저급 기능 바로 XPath 는 W3C의 표준 쿼리 랭귀지 입니다. 이 XPath는 개발자들을 우히ㅏㄴ 언어입니다. HTML Document에서 특별한 엘리먼트를 효율적으로 찾을 수 있습니다.

예를 들어 document.getElementById('element id')  이것은 DOM Method 입니다. 이러한 방식처럼 XPath 랭귀지가 있습니다. Prototype.js 에서는 이 부분을 지원하고 있는데요 Selector 오브젝트에서 지원되는 브라우저에 따라 XPath를 이용하여 엘리먼트를 찾습니다.

이를 통해서 DOM 에서 지원되지 않는 메서드들이 사용자가 만들 수 있습니다. 거의 대부분 정규표현식을 통해서 찾는 방식이긴 합니다만...


6. New and Improved XML Technologies (새롭고 향산된 XML 기술들)
XPath와 XVG의 큰 기능이 추가되었습니다.
XSLT를 위한 XSLTProcessor Javascript API 와 많은 XSLT 문제점 수정과 확장지원, DOM 파서 API, XMLSerializer API, XML을 위한 추가적인 렌더링 지원, 좀더 정밀하고 완벽한 XMLHttpRequest, 이벤트 핸들러 추가지원, 지속적인 서버 커넥션을 위한 추가적 업데이트,  등등등... 아놔 하다보니 너무 많네요...


7. Styleable Form Controls
폼 컴포넌트들에게 좀더 비주얼한 느낌을 줄 수 있게 지원되네요.
점점 크로스 브라우징에 대한 대비가 절실해지는 느낌이 드네요.. 눈도 침침해지고 ㅠ.ㅠ


8. Advanced CSS Styling
그냥 봐도 알겠네요. 고급 CSS 스타일링 -_-; 무슨 헤어 스타일 왁스도 아니고 말이죠...
이런 비쥬얼한 부분은 크로스브라우징만 잘된다면야 아무런 할말없이 넙죽 받아먹고 싶습니다.
하지만 그렇지 않다면 이건 괘난일이라고 말하고 싶습니다.

기본적으로 CSS2.1, CSS3을 지원하구요. CSS Media queries 요것도 지원합니다.
많은 향상중에 하나의 이미지를 이용한 컨트롤 하여 다양한 영역에 표시할 수 있도록 지원됩니다.

Safari 에서 지원하는 CSS Reference document 입니다.


9. Reduced Memory Use
이 부분 원본출처에서의 기사에도 느낄 수 있지만 Webkit 엔진 개발자의 마음을 읽을 수 있습니다.  웹 브라우저의 내실을 아주 튼튼히 한다는 기초를 튼튼히 다진다는 마음이 참 마음에 듭니다.
이들은 10가지의 내용중에 가장 중요한 부분이라고 말하고 있습니다. 

많은 내용을 갖은 페이지는 좀더 효율적으로 저장되어야 합니다. Javascript 코드 자체는 작은 데이터 구조입니다.  뭐니뭐니 해도 메모리 캐시 핸들링이 가장 중요한데요.  이 캐쉬는 현재 아주 잘 데이터를 관리해줍니다. 페이지 로딩 속도를 빠르게 하기 위하여.. 꼭 그렇지 않은 경우도 있는데 생략 -_-;;

WebKit 2 - 26.7M RPRVT memory
WebKit 3 - 23M RPRVT memory
WebKit 3 uses 14% less memory!


10. Web Developer Tools
Firebug 같은 웹 개발을 위한 툴인데요. 요건 이미지로 설명을 대신 합니다.
사용자 삽입 이미지


언!!!

국내에서는 IE의 사용률이 매우 높지만 외국의 경우는 꼭 그렇지 않습니다. IE가 1위의 자리르 계속 차지하고 있지만 몇년 전에 비해 현재는 그 차이가 현저히 줄어들고 있습니다.

홈페이지 개발자(? 빌더), 웹 개발자, UI 개발자 모두 알아야 합니다.
단지 PHP 로 만들어진 게시판을 만들어 보는게 다가 아닙니다. Apache 웹 서버를 셋팅할 줄 알면 되는게 아닙니다. 웹서버를 구성하고 웹 사이트에서 PHP 코딩으로 홈페이지를 만드는게 진정한 개발자는 아닙니다.

구글이나 야후와 같은 세계 시장을 상대로 성공한 곳의 개발자들의 역량은 HTML 문서에 있는 image가 브라우저에 띄워지기까지 어떻게 하면 빠르게 띄워질것인지 모든것을 알고 있습니다. 또한 어떤 문제가 발생할 때 그 문제점의 원인과 해결책을 알고 있습니다.

기초부터 변화되는 기술, 정보들을 시시각간 알아야 합니다.
50세 개발자 60세 개발자 외국에는 많습니다. 한분야에 능통한다는 것은 결코 있을 수 없습니다.
늘 그 분야에 관련된 먹이 사슬처럼 하나씩 알아가야 합니다.

50세가 되어도 다 모를 것들이 태산입니다. 그래서 60세까지 개발을 해야합니다.
그런 야망을 가지고 일하고 싶습니다.
신고
Posted by Rhio.kim
이 내용은 webkit.org 계속 추가 되고 있답니다.

HTML5 에서는 멀티미디어 관련 지원이 강화됩니다.
이 중 Media tag가 추가가 되는데요. <video> 와 <audio> 태그가 추가됩니다.

간단하게 아래와 같이 사용할 수 있습니다.

● tags
<video src="sample.mov" autoplay></video>

이뿐만 아니라 기존에 embde나 object, javascript를 통해서 사용했던 방식도 그대로 지원합니다.

그리고 javascript를 통해서 직접 컨트롤도 가능합니다. 좀더 간단해지겠는데요.. ^^

● Javascript 제어
<script>
  function movPause() {
    var movPlayer = document.getElementsByTagName('video')[0];
    if (movPlayer.paused)  movPlayer.play();
    else  movPlayer.pause();
  }
</script>
<input type="" onclick="movPause()" value="play & pause" />


● 이벤트 추가
movPlayer.addEventListener('over', function() { alert("종료되었습니다."); } );


● 생성자
new Audio("song.mp3").play();

한가지 이슈거리라면...mpeg 코덱을 가지고 있어야 한다는것!!

언제 발표될지는 모르겠지만 기대됩니다. ECMA 4도 너무 많은 변화에 어리둥절 합니다.
javascript 2.0 으로 도대체 웹에서 무엇을 개발해야될지 난감합니다.

ECMA 4에 대한 글을 포스팅 해보려고 했었지만 생각이 조금씩 바뀝니다.  너무 많은 변화가 도려
기존 개발방법에 대한 페러다임을 새롭게 잡아버려서....

과연 높아지는 PC사양에 비해 더 높아지는 개발 언어들의 무거움....

HTML5 도 너무 많은 지원보다 내실이 더 튼튼해지길 바랍니다.
신고
Posted by Rhio.kim
사용자 삽입 이미지

ECMAScript edition 4가 발표 되었습니다.

ECMA-262 에 비하면 새로운 랭귀지에 더 가깝다고 보고 싶고 java like 라고 할 수도 있겠습니다.

ECMA Script : http://www.ecmascript.org/index.php
ECMA Script edition 4 download : http://www.ecmascript.org/download.php


core ES4 에서 Javascript 2.0 에 대한 새로운 자료를 기재해볼 계획입니다.
현재 오픈된 es 클래스에 대한 소스 분석과 사실 이부분이 가장 흥미롭습니다.
기존에 javascript native 소스와도 다를 바 없을 것 같습니다.

보면서 큰 도움이 될 것 같구요.

기대해주시고 저도 기대됩니다...
신고
Posted by Rhio.kim