프론트엔드에게 setTimeout 함수는 단순한 함수가 아니다!!!

일단, 지금 내가 좆같이 외부망 막힌 프론트엔드 개발짓거리 하고 있는 관계로 블로그질을 잘 못하겠지만,
이런 일을 자주 겪어 존나 머리가 쌓이기만 하기에 내 메모리 릴리즈 하는 개념으로 글 씨지르겠다.

프론트엔드 개발하다 보면 이런 경우를 겪는다. 특히 화면 변경할때 말이지.
화면을 변경하다 보면 갑자기 스크립트 오류가 나거나, 원하는 화면이 안나올 때가 있다.
이것으로 머리 싸매다가, 안되겠다. 지연시켜서 뿌려야겠다는 생각으로 setTimeout 함수를 쓰면
원하는 화면변경이 이루어진다. 이상할 정도로.
더 웃긴 현싱은, 타임아웃 주기를 0으로 해도 잘된다는 것이다. 이게 대체 어떻게 된 거지?

먼저, 자바스크립트는 싱글 쓰레드라는 것. 아주 질리도록 들었을 것이다. 비동기도.

하지만 잊지 말아야 할 점은 이 싱글 쓰레드가 하필 화면을 표현하는 렌더링 시점에도 블로킹 현상이 일어나는 점을 간과해서는 안된다.
즉, 스크립트 실행중인 시점에 DOM에 어떤 변화가 찾아올 지 우린 예상할 수 없다는 것이다. 왜냐? 싱글 쓰레드로 하나씩만 진행하기 때문에.
그럼 왜 setTimeout 함수는 회피할 수 있을까? 간단하다.
위 그림을 보면 setTimeout 블록으로 등록된 timer 스레드는 그저 다음 실행 시점으로 예약만 하고 이 스레드에 도달해야 실행되기 때문이다.
그렇다면 왜 setTimeout은 분명 1초인데 1초 빨리 실행하거나 1초보다 늦게 실행하기도 하는가?
먼저, node.js 개발해본 시람은 알겠지만 거기는 setTimeout 함수는 없고 process.nextTick 함수를 사용한다. 그렇다.
원리는 비슷하다. 빠르게 tick 하면서 스크립트가 실행된다. 게임이나 영상으로 치자면 프레임 단위에 무슨 이벤트가 일어난다는 것이다.
보통 1 tick 하면 1/1백만 초다. 백만분의 1초. 하지만 setTimeout은 아무리 최소값이라도 4/1000초.
클라이언트 스크립트에서 tick 단위를 허용기엔 가뜩이나 렌더링이 스레드 예약하고 블록거는데 무슨 일이 일어날 지 검증이 안 된 상황.
자, 일단 여김가지 갔으면 이제 setTimeout 함수로 예약한 함수 루틴은 나머지 구문을 실행한 후 실행하는 것을 알 수 있다.
즉, 렌더링에 시간을 벌어주어 렌더링 후 화면 변경에 대한 정보를 불러오고 쓰는 데 정확도를 높일 수 있는 그런 트릭인 것이다.
그런 고로 화면을 변경할 때, 특히 DOM 데이터를 주고받거나 다룰 때 setTimeout 함수는 DOM 렌더링 시간을 벌어주어 원하는 사용자 처리를 도와주는 프론트엔드에게 고마운 함수인 것이다. 감사하며 쓰도록 하자.

참고: Why is setTimeout(fn, 0) sometimes useful?

composite / 2017년 1월 9일 / Piss Development / 1 Comment

From node-webkit to Electron 1.0

이 글은 Github 소속 Electron의 메인 개발자인 Cheng Zhao(@zcbenz)의 기고글을 번역한 글이다.
원문: From node-webkit to Electron 1.0
시간에 쫓기고 작성하다 보니 오역이 있을 수 있다. 오역 교정 환영한다.

아니 프리랜서가 시간관리도 못하고 왜 시간에 쫓겨다녀?

한국 프리랜서는 용병이 아니라 그냥 사업자를 빙자한 근로자거든요 ㅋ


이 글을 통해 내가 node-webkit를 재구성하다가 Electron 프로젝트를 시작하게 된 내역을 기고한다. 내역을 좋아하는 애들을 위해 커밋 내역과 관련 링크를 달아주었다.

DOM에서 node.js 모듈 불러오기

모든 것의 시작은 2011년 @rogerwang 이 만든 마법의 모듈 node-webkit이었다.
이 node.js 모듈은 웹킷으로 하나의 브라우저 창을 띄워주는 것도 모자라, node.js 모듈까지 사용하는 마술까지 부렸다.

Node.js 코드 단은 이랬고,

var nwebkit = require('nwebkit')
nwebkit.init({'url' : 'index.html'}, function () {
  nwebkit.context.runScript('')
})

그리고 index.html 내용은 이랬다.

<html><body>
<p id="output"></p>
<script>
require('fs').readdir('.', function (err, files) {
  var result = ''
  files.forEach(function (filename) { result += filename + '<br/>' } )
  document.getElementById('output').innerHTML = result
});
</script>
</body></html>

이 데모로는 아직 시판하기엔 부족한 점이 많았지만, 충분히 성공 가능성이 있었다.

크롬 임베디드 엔진을 사용하다.

그 당시 node-webkit 에서 가장 큰 문제였던 게 있는데, 웹킷 라이브러리 기능을 리눅스 외에 사용하기엔 너무나 버거웠다.
그래서 @rogerwang 은 이 모듈을 웹킷에서 크로미움을 애플리케이션에 넣는 인터페이스를 제공하는 크롬 임베디드 프레임워크로 바꿔 해결했다.

당신은 그 CEF를 사용하여 개발한 node-webkit 코드를 볼 수 있다. node.js 비동기 기능을 수행하도록 만들기 위해, 거기에는 크로미움 메시지를 node.js 입출력 라이브러리인 libuv로 대체하는 패치가 있었다. 그러나 이제 그 패치는 더이상 찾을 수 없었다. 왜냐하면 NW.js 의 Chromium fork 저장소가 이미 오래전에 rebase 해버렸기 때문에. 이제 그 당시 커밋 내역으로 돌아갈 수 없게 됐다.

인턴으로 취직

당신은 @rogerwang 오랫동안 오픈 소스를 지원했던 인텔에 일하고 있다는 사실을 알고 있는가? 놀랍게도 인텔이 오픈소스를 위한 인턴을 구했다. 이보다 더 좋은 인턴쉽이 있었던가?

Intel OTC

2012년 여름, 나는 한참 졸업을 앞둔 대학생이었을 때 여름 인턴쉽을 찾으러 다녔다. 그 때 바로 인텔의 구인란이 눈에 보였는데, 인텔은 node.js의 오픈소스 프로젝트 node-webkit 개발자가 필요하다고 했다. 나는 이때다 싶어서 지원했고 운좋게 붙었다.

그리하여 나는 그 node-webkit 를 개발하기 시작했다.

컨텐트 쉘

첫번째로 내가 했던 업무는 node-webkit의 CEF 브랜치 개선이었다. 그리고 개발하면서 정말 어렵게 해냈다.
node.js가 V8 API를 직접 호출하면서 CEF는 크로미움의 컨텐트 모듈을 입히는 자체 API를 연동한다.
당신이 크로미움과 node.js를 연동하고 싶다면 중간에 CEF를 엮이지 않게 달아야 할 것이다.

그래서 기존 코드를 향상시키는 대신 아예 컨텐트 쉘을 재구성하는 쪽을 택했다. 크로미움을 최소한으로 사용한 가벼운 브라우저를 구현하기 위해.

결과는 꽤 좋았고 node.js 통합이 가능한 작은 브라우저를 획득했다. 그리고 난 그 node-webkit 0.2.1 버전으로 릴리스를 배포했다.

node-webkit를 프레임워크로

node-webkit는 node.js 모듈이기 이전 독립적인 브라우저였었다. 왜 여태까지 이 프레임워크로 HTML과 자바스크립트로 데스크탑 앱을 만들지 않았지? 나는 그 때 몇 개월간 그 아이디어를 행동에 옮겼다.

먼저 나는 node-webkit의 패키징 시스템을 추가했다. 아이디어는 게임 프레임워크인 LÖVE framework 를 슬쩍했다. 그 아이디어는 앱을 ZIP 아카이브로 만들고 node-webkit 실행 파일을 합치면, node-webkit 실행 시 그 아카이브를 풀고 아카이브에 포함된 앱을 실행하는 식이었다.

Packaging node-webkit

몇가지 구현 항목이 있다면, package.json 에 윈도우 속성을 넣거나, DOM 요소 확장, 브라우저 보안 모델 삭제, DOM 요소에 네이티브 파일시스템 도입, 그리고 끝없는 버그 수정 등이다.

한가지 재밌는게 가장 어려운 도전이 있다면 아무래도 node.js 네이티브 모듈 도입이었다. 나는 V8에 OpenSSL을 도입하기 위해 따로 기호(Symbols)를 추가해 크로미움에 패치하고, NSS와 OpenSSL 사이에 충돌이 일어나는 node.js 기호도 수정해 패치했다. 이렇게 윈도우용 원시 코드 node.lib 커스텀 패치를 제공하여 node-webkit에 네이티브 모듈이 돌아가도록 했다.

이리하여 node-webkit v0.2.5 배포 후, 왠지 안정된 느낌을 받았다.

자체 API 추가

이번엔 API 제공하는 데 DOM을 여전히 격리되고 있고, DOM 제공이 너무 제한적인 부분인 현실에 내 생각을 말해본다.
예를 들면 네이티브 메뉴와 여타 텍스트가 들어간 메시지박스 등.

그때 나는 자체 API를 제공하는 제공할 수 있는 걸 생각해 냈다. 바로 require('nw.gui') 같은 빌트인 모듈. NW.js 써봤다면 알 것이다. 그때 나는 메뉴를 생성하거나, 트레이, 메시지 창 등을 API에 넣었다. 지금 NW.js의 원형인 셈이다.

내가 새 릴리스를 배포할 때마다 이런 아이디어를 유지했고, node-webkit v0.3.6 버전으로 피날레를 장식했다.

다른 GUI 프레임워크와는 달리 크로미움의 특별한 점 하나가 있는데, 바로 멀티 프로세스 아키텍쳐라는 점이다. 크로미움 브라우저는 웹 페이지를 실행하고 GUI를 띄우면서 응답해야 하기에 웹 페이지에 GUI 모듈 제공은 너무나 힘들었다.

이렇게 해서 웹 페이지 내에 브라우저 처리를 하기 위한 내 첫번째 시도는 이랬다.
먼저 크로미움을 싱글 프로세스로 돌린다. 허나 이건 너무나도 불안정하게 돌아간다.
이번엔 그냥 네이티브 GUI API를 렌더러 프로세스에 호출하도록 해봤다.
하지만 몇몇 플랫폼에서 GUI 요소와 프로세스를 직접 핸들링할 수가 없었다.
그래서 찾은 마지막 방법은 IPC 메시지를 통해 GUI 모듈을 node-webkit에 입혔다.
이렇게 해서 렌더러 프로세스 중에도 상시 행동이 가능했고,
브라우저 프로세스 간이나 주어진 일을 완료하면 메시지를 보낼 수 있게 됐다.

node-webkit 홍보

node-webkit 같은 프레임워크는 사용자가 가장 중요하다. 많은 사용자를 가지고 만드는 데 있어서 가장 중요한 것들도.

그래서 내가 node-webkit를 개발하는 동안 최대한 홍보도 해왔다. node.js 메일링 리스트에 소개글도 올렸고, 답글도 달아줬다.
node-webkit 게시들을 달며 node-webkit 발표도 했고, node-webkit 샘플 앱도 제작했다.
이렇게 나는 전 세계에 내 힘으로 node-webkit를 알리는 계기를 만들었다.

그리고 node-webkit 개발을 중단하기 전에 Github 별을 천여개 씩이나 받았다. Github에 상위 C++ 프로젝트 10위 안에도 들었다.

첫 사용자

내게 node-webkit 첫 사용자는 정말 중요한 순간이었다. @ibdknoxLight Table editor 을 node-webkit 를 통한 웹 기술로 다시 탄생시켰다. 이후 많은 이들이 node-webkit 에 주목받고 많은 도움이 들어왔다. 이렇게 기쁜 순간을 만들어준 @ibdknox 에게 감사의 말을 전한다.

그 다음 해에 Light Table는 node-webkit 에서 Electron 으로 자리를 옮겼다. 왠지 오랜 친구가 돌아온 것 같았다.

GitHub으로 이동

어느날 Github 에서 비밀리에 Atom 에디터를 시작하면서, @nathansobo 가 node.js로 데스크탑 앱을 개발하는 사람을 구하고 있었다.
나는 Atom을 node-webkit에 마이그레이션하기 위해 필요할 때마다 node-webkit를 개선하는 조건으로 그와 계약했다.

이렇게 반년동안 node-webkit를 개발하다가 인텔 인턴쉽은 이렇게 끝났다. 바로 나는 Github 고객지원부로 일하기 시작했다. 그리고 동시에 node-webkit 개발을 중지하고 뒷일은 @rogerwang 이 모두 맡게 됐다.

Contribution Graph

왜 이렇게 뜨거운 감자인 node-webkit 개발을 중단했을까? 어자피 내가 Github으로 이동하는데 전혀 영향도 없었고, 누가 프로젝트를 운영하는데 나는 상관이 없으니까.

아시다시피, 난 인텔에서 다른 사람의 프로젝트를 진행하고, 프로젝트의 결정권을 가질 수도 없었다. 아무렴 어떤가.
그냥 난 누구의 방해도 없이 node-webkit을 재구성할 수 있고 기능을 추가하면서 장난감 조립하듯이 일하는 게 좋았으니까.
어느날 node-webkit 오픈 소스 규모 커지기 시작했고 말 나오기 무섭게 나의 node-webkit의 권한은 상실됐다.
새 버전을 배포하는 데 있어서 책임이 상급 엔지니어에게 이관되어
내가 일할 수 있는 범위가 사실상 줄어들었고, 내가 좋아하는 기능을 넣을 수 없었다.

비난할 이유가 없다. 인텔 말고도 다른 회사도 그러니. 하지만 단도직입적으로, 더이상 참을 수 없었다.

더 나은 데스크탑 프레임워크 제작

내가 Atom 개발에 참여했을 때, Atom은 CEF에 파일시스템을 운영하기 위한 자바스크립트 바인딩으로 이루어져 있었다. 이게 Atom이 node-webkit로 마이그레이션한 계기가 됐지만, node-webkit가 그때당시 결함이 많다 보니 앞길이 순탄치 않았다.

그래서 난 결국 자체 네이티브 쉘을 만들어 해결하기로 했다. 새로운 쉘은 node-webkit를 개선하는 대신 몇가지 근본적 구조를 바꾸는 방향으로 재구성했다.

이리하여 이 쉘에게 atom-shell 이라고 이름 지었다.

node-webkit 에서 Electron 1.0 까지

그 이후 Electron과 NW.js 에 무슨 일이 일어났는지 내역을 정리했다. Atom과 Atom-shell 은 오픈 소스로 배포했고 그 atom-shell은 Electron으로 개명했고, node-webkit는 NW.js 로 이름을 바꿨다.

그리고 저번 주말에 드디어 Electron 1.0 을 배포했다.

Contribution Graph

Electron은 NW.js의 파생인가?

아마 내가 받은 질문 중 가장 많이 받은 질문이고, 내가 이 글을 쓴 이유이기도 하다. 기술적으로는 Electron은 node-webkit 0.3.6을 재구성했다. 내가 마지막으로 배포한 버전이고 이걸 끝으로 node-webkit 개발을 중단했으니. 그러고 보니 Electron은 원래 node-webkit와 아주 다른 노선을 밟았다.

그러니까 재대로 얘기 좀 하자면, NW.js는 내가 node-webkit 개발한 걸로 시작했고, Electron은 내가 다시한번 node-webkit에 파고든 작품이다.


복터진 개발자네. 군기잡힌 인턴 개발자에서 Electon 메인 개발자가 되기까지…

composite / 2016년 5월 25일 / Piss Development, Waldo Translation / 2 Comments

jQuery paging plugin update

jQuery paging plugin

내가 이걸 개발하고 방치한 지 3년이 지났다.
하지만 의외로 사람들이 페이징 플러그인을 찾다가 내 블로그에 들리기도 한다.
그리고 어느 블로그에서 내가 만든 페이징 플러그인을 소개하기도 했다.
그래도 돌아가긴 하나보다. 안정적으로.

그래서 오늘 오랜만에 재대로 손 좀 대봤다.
0.1.7 에서 0.2.0 으로 업데이트 했다.
기존 버전과 달라진 건 크게 없는데, append 속성이 쓸모 없어져서 제거하고, className 으로 컨테이너 관리 편의성을 높여준 업데이트이다.
나머진 기존 그대로 쓰면 되긴 하지만, 좀 더 편리하게
재호출할 때를 대비하여 일부 속성만 정의해도 기존 속성에서 정의 속성을 덮어씌워 페이징을 구성하겠끔 만들었다.
그렇다 보니 destroy 키워드가 생겼다.

아, 그리고 마지막으로 이건 문서에 안넣었는데, .paging(‘속성명’) 을 통해 속성값을 불러올 수 있다.
이는 아직 실험 단계지만, 조만간 편리하게 페이징이 처리되도록 할 생각이다.

프로젝트 페이지는 여기로 가면 되고,
bower 설치도 지원한다. bower install jquery.paging

언제까지나 유의사항은 “스타일링은 알아서 하라” 이다.

앞으로도 많은 성원 바란다.
감사하다.

독자: 이 미친새끼가 반말하고 지랄이야.

composite / 2016년 1월 26일 / Piss Development / 2 Comments

내가 한번 추천해보는 웹 개발자를 위한 Visual Studio 확장 모음

페북 그룹에 Visual Studio 웹 개발자 추천 확장 모음 링크를 올렸길래 나도 올려본다. 여기에 기재된 확장 도구를 포함하여 내가 쓰고 왜 쓰는지 알리고자 글을 쓴다.
내가 설치한 확장 목록을 이름순으로 볼 수 있다보니 알파벳별로 정렬하는 점 양해 바란다.
아, MS에서 만든 확장은 제외다.

Code Alignment

이름만 봐도 눈치챈 사람도 있을 것이다. 말로 하긴 힘드니 아래 코드로 뭔 프로그램인지 알려주겠다.

    person.HomeTown = "Brisbane"; 
    person.FirstName = "Chris";                
    person.Surname = "McGrath";                
    person.Age = 24;                           
    person.Occupation = "Software Developer";  

=>  person.HomeTown   = "Brisbane";
=>  person.FirstName  = "Chris"; 
=>  person.Surname    = "McGrath"; 
=>  person.Age        = 24; 
=>  person.Occupation = "Software Developer"; 

올드비 개발자들(특히 C/C++ 개발자)에게 단비같은 확장도구인 데다가 무료이다. 도네이션웨어라는 점.
더이상 설명이 필요있나?

ColorSchemeSelector

ColorSchemeSelector

그저 단순한 색상 추출 도구라면 내가 블로그 보다 말았고 그냥 넘어갔겠지만, 이녀석은 그저 단순한 색상 추출기를 뛰어넘어 색상 혼합별로 색상을 추천받아 추출할 수 있다는 점에서 특히 웹 개발자와 디자이너에게 좋은 도구가 될 것이다.
아, 물론 무료다.

Git Diff Margin

Git Diff Margin

Git로 버전관리를 한다면 해당 줄에 바뀐 점을 이렇게 실시간으로 표현해준다는 점이 되겠다. 자주 바뀌는 일이 많은 버전관리 개발자라면 유용할 것이다.
이 확장 또한 링크된 블로그에 소개되어 있으며, 무료이다.

Grunt Launcher

프론트엔드 개발자라면 반드시 한번씩은 들었을 Grunt. 패키징 자동화로 유명한 Grunt와 스케줄별 자동화를 지원하는 Gulp, 프론트엔드의 패키지 매니저인 Bower 명령어까지 지원해준다.
나처럼 node.js를 수동으로 포터블로 설치한 환경이라면 사용 시 세팅에 유의하라.
무료라고. 소개됐다고.

Image Optimizer

프론트 엔드를 위한 확장이 여기 하나 또있다. Visual Studio 자체 지원 이미지 최적화 도구가 있다면 믿겠는가?
같은 이미지에서 이미지 사이즈를 줄여주는데, 자세한 내용은 이미지 최적화 기법 구글 검색 ㄱㄱ.
이미 node.js 등으로 이미지 최적화 확장이 있다면 비교해달라. 난 아직 비교 안해봤다.
무료다.

Mexedge Stylesheet Extension

간단하게 말하면, 스타일시트 소스를 트리구조로 시각화하는 도구다. 프론트엔드 개발자에게는 상당히 편리한 도구다.
확장 링크로 들어가서 스샷을 보면, 그저 단순한 그런 도구가 아니다. 심지어는 파일 내 클래스 목록처럼 표시까지 해준다.
블로그에서도 소개되어 있다. 3명이 기업 운영하고 있는 것으로 보이긴 한데 일단 무료니 그냥 써 주자.

MixEdit

지금 소개하는 확장은 내가 블로그에서도 소개한 바 있으며, 유일하게 무료가 아닌 평가판 확장이다.
Sublime Text를 접하다가 Visual Studio로 개발하다보면 답답하지 않는가? 멀티커서와 멀티셀렉트가 지원되는 확장, 변수를 한꺼번에 바꿀 수 있다면 얼마나 좋을까?
그런 목마름을 Visual Studio에서도 적셔주는 그런 확장 되시겠다.
평가판이긴 하지만 사용기능과 기간에 제한은 없다. 단지, Visual Studio 실행 후 처음 MixEdit 기능을 수행 시 구매 권유 창이 뜰 뿐이다.

Suggested Extensions

얜 좀 재밌는 확장이다. 블로그에 소개되긴 했는데 댓글에 소개된 확장인데, 파일 확장자별로 사용할 수 있는 Visual Studio 확장을 소개시켜주는 확장 되시겠다.
예를 들면 yaml 같은 파일들. IntelliJ IDEA 같은 개발 툴 쓴 사람은 알겠지만 JetBrains 에서는 확장자별로 지가 확장 추천을 해준다. 그런 비슷한 거다.
무료다.

Web Essentials 2015

만약 웹 개발자인 당신이 Visual Studio를 쓰고 있을 때, 이 확장을 쓰고 있다면 이 확장 제작자에게 큰 절을 해야 한다. 블로그에서도 소개도니 웹 개발자 필수 확장!
웹 개발에 모든 것을 제공해주는 확장이다. CSS, HTML, JS 편집에 날개를 달아주며, CoffeeScript, LESS, Sass 같은 확장 언어 편집과 Grunt, npm, bower 등의 설정 편집에 유용한 도구를 제공하는 웹 개발 만능 확장이다.

Visual Studio 2015 사용자에게 주의점은 소스 파일을 Minify하거나 Bundling으로 합치거나, Sass 및 LESS 컴파일 기능을 따로 확장으로 뺐다는 점에 유의해야 한다. 없다고 해매지 말고 내가 링크 소개할 테니 다운 받아라. 이 확장도 무료고 아래 확장도 무료다. 저거 제작자 만나면 반드시 큰 절 해라.

Bundler & Minifier
Web Compiler

나는 여기까지 추천 확장 목록으로 썼다.
여러분의 추천 확장이 있다면, 서슴없이 공유하여 서로 즐거운 개발 세상을 만들어가는 주역이 되길 바란다.
싫어? 싫음 시집가.
끗.

composite / 2015년 9월 9일 / Piss Development / 0 Comments

현재 실무에서 사용 가능한 100만개 Row 지원하는 무료 그리드 라이브러리

구글 검색하다가 어떤 새끼가 블로그에 그리드들은 HTML5 표준 아니고 jQuery 장식 플러그인이 아니라는 등의 불안감을 조성하여 웹을 포기하고 응용으로 돌아가겠끔 글 싸지르고 다닌다.

그게 2011년이었다. 근데 그때도 솔루션을 이미 쓴 곳은 별 문제 없다.

하지만 지금 2014년 HTML5 표준 재정 전인데 위 이슈로 씨부리는 새끼가 아직도 있다. 무시하자.

HTML5 표준에서 뭐하러 그리드 만드냐? 그리드 외에 여러가지 컴포넌트 편리하게 표준 만드는 것만으로도 감사해야지.

어쨌든 니들이 어쩌면 이미 사용하고 있을 테고 앞으로도 필요할 것 같은 무료 그리드 라이브러리를 보라.

1. jqGrid

HTML 웹 프로젝트에서 많이 알려지고 많이 사용하고 있는 프로젝트.

3.7 부터 가상 스크롤 지원으로 100만개 행도 문제없이 출력

현재 쓰기 쉽고 가장 많이 쓰는 제이쿼리 기반 프레임워크

상용 모듈도 출시했으나 기본 jQGrid 라이브러리는 MIT에서 바뀌지 않는다고 공식 블로그에서 밝혔으므로 기업에서 문제없이 쓸 수 있다.

단점은 좀 무겁지만 어느정도 개선됨.

상용의 경우 모바일 지원 및 기술 지원을 받을 수 있음. (물론 영어)

2. SlickGrid

대량 데이터를 순식간에 뿌리는 최초의 라이브러리로 먼저 소문난 라이브러리.

의외로 가볍고 제이쿼리 기반이며 자체 성능이 우수하다.

단점은 어려운 사용법과 뜸한 버전업. 하지만 커뮤니티가 활발하기 때문에 충분히 커버된다.

MIT 라이센스이기 때문에 기업에서 문제없이 쓸 수 있다.

상용이 없으며 기술 지원을 받을 수 없다.

3. DataTables

예전에 비해 많이 성숙해지고 깔끔해졌으며 속도도 향상되고 심지어 CDN까지 지원하는 (jQGrid도 마찬가지지만) 막강한 라이브러리.

초반에 한국에서는 많이 알려져 있지 않고 지금도 이거 쓰는 곳은 찾아보기 힘들 정도로 국내는 인기가 없으나, 지금은 대적할 만 하다.

페이징 기반 그리드에 최적화되고, 그리드에 불필요한 기능은 확장으로 채울 수 있다.

대량 데이터를 위한 가상 스크롤 또한 확장으로 사용 가능하며 기본 다국어가 지원된다.

MIT 라이센스로 기업에서도 쓸 수 있으며, 활발한 커뮤니티로 문제 해결을 할 수 있다.

테이블 태그로 초기화하기 때문에 Fallback 에 능하다. 근데 국내 정서에 필요한 확장 다 깔면 좀 느리다.

특히 가상 스크롤에서 조금 느린 성능을 나타낸다.

기술 지원을 받을 수 있다 (영어지만)

composite / 2015년 1월 30일 / 미분류 / 0 Comments

Javascript Polyfill CDN Service

Financial Times 에서 자바스크립트 및 HTML5 에 최대한 유연하게 대응할 수 있는 CDN을 공개했다.

일단 링크를 보라. https://cdn.polyfill.io/v1/

귀찮게 뭐하러 polyfill 찾아 구하는가?

얘가 그냥 브라우저 확인해서 알아서 polyfill 해준다.

닥치고 써라. HTML5를 여러 브라우저에 최대한 쓰고싶다면.

composite / 2015년 1월 30일 / 미분류 / 0 Comments

한국을 위한 CSS 그리드 디자인 프레임워크

그렇다. 사정은 잘 안다. 부트스트랩이나 파운데이션 같은 올인원 CSS 프레임워크는 안맞을 수밖에.

특히 디자이너가 있고, 기획이 재대로 되어 있다면, 한국 웹 사정에 부트스트랩은 어찌보면 경우에 따라 안어울릴 것이다.

디자인 떡칠해서 화려한 웹페이지 만들어야 직성이 풀리는 한국 웹사정에 안맞다 보니까.

하지만 이런 단어만 들으면 디자이너와 퍼블리셔는 가장 먼저 입에서 시발이라고 나올 것이다.

반응형 웹.

맞다. 반응형 웹의 주인공은 CSS의 미디어 쿼리다. 하지만 배우고 적용하기 까지는 시발 좆같다.

퍼블이나 디자가 왠지 개발자가 되어 가고 있는 기분 같을 것이다.

그럼 시발 개발자는 니들 하는 업무 다하고 있는 개발자도 있는데.

어쨌든, 그래도 자신이 맡은 업무에 충실하면서 클라를 만족하고 싶지 않은가?

그래서 시발 존나 위험한 개발자인 내가 소개한다. 퍼블과 디자인 니들을 위한 반응형 웹을 위한 CSS 프레임워크다.

나머지 디자인과 레이아웃 구성은 니들 꼴리는데로 하면 된다.

1. 960 Grid System (http://960.gs/)

전 세계에 인기를 한몸에 받고, 파생 CSS 프레임워크를 탄생시키게 한 장본인이자 웹에 생산성을 불어넣은 엄청난 놈이다.

이녀석은 웹 페이지의 한 행을 몇 열씩 나누게 하는 방식을 선보였는데, 전 세계적으로 인기를 한몸에 받았다.

이녀석의 특징은 960인데, 페이지의 기본 크기를 960으로 잡고 시작한다. 그리고 한 행당 12단씩 나눌 수 있다.

실질적인 컨텐츠가 들어갈 길이는 940이다. 여백 제외하고 말이다.

사용법이 무진장 간단하다.

<div class=”grid_나눌 숫자”>내용</div>

<div class=”clear”>행 나눔 (주로 공백을 넣는다. &nbsp; 같이.)</div>

예를 들어 12단 나눌 수 있을 경우, 3개씩 나누고자 한다면 이렇게 하면 된다.

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”clear”>&nbsp;</div>

이런 식으로 4+4+4=12 로, 총 12단으로 맞추는 것을 고려하여 4*3=12 니까 3개 div 에 grid_4 클래스를 넣으면 div 를 삽입하면 된다.

존나 쉽지 않은가?

단점은 니들이 원하는 반응형 그리드는 아니다. 타블렛이나 데스크탑에 적합한 레이아웃 구조에 탁월한 선택이다.

하지만 이거와 미디어쿼리를 합치면 반응형 그리드 디자인을 만들 수 있다.

그러면서 왜 이녀석을 소개하냐면 이녀석이 웹 그리드 디자인을 프레임워크로 탄생시킨 원조이기 때문이다.

2. Fluid Baseline Grid (http://fluidbaselinegrid.com/)

이녀석부터 이제 반응형 웹 디자인을 고려한 그리드 디자인 프레임워크 되겠다.

이녀석의 특징은 Baseline 인데, 글씨 크기 위주의 웹을 고려한 그리드 디자인을 생각했다고 보면 된다.

그래서 어찌보면 이미지 떡칠의 한국형 웹과 안맞을 지는 모르겠다. 그래도 소개한다.

이녀석의 특징은 % 단위의 넓이를 나눠서 처리한다는 것이다. 960.gs 또한 이를 지원한다.

그리고 이녀석은 최대 3단계 레이아웃이 있는데,

g1 은 작은 단위로 모바일에 표시 가능하도록 작은 크기의 영역을 잡는다.

g2 는 중간 단위로 타블렛에 표시 가능하도록 중간 크기의 영역을 잡는다.

g3 은 큰 단위의 테스크탑에 표시 가능하도록 큰 크기의 영역을 잡는다.

<div>

    <div class=”g2″>

         난 타블렛에서 하나를 다 잡아 먹는다.

     <div>

    <div class=”g3″>

         난 어느 장치에서 봐도 하나를 다 잡아 먹는다.

     <div>

    <div class=”g1″>

         난 휴대폰에서 하나의 영역을 잡아먹는다.

     <div>

</div>

솔직히 뭐 이 이상은 나눌 일이 없다고 봐도 무방하지 않은가? 그럼 됐다.

3. Negative Grid (http://chrisplaneta.com/free/negativegrid-generator/)

만약 직접 그리드 구조를 짜야 한다면 이녀석을 추천한다. 이녀석은 원하는 크기, 그리드 개수, 여백 등을 지정할 수 있다.

당연히 px 가 아닌 % 이기 때문에 % 단위로 짜야 한다. 만약 px 단위를 원한다면 960 그리드를 써라.

이녀석 또한 960 그리드와 마찬가지로 생성기 시스템인데, % 위주인 방식에서 틀리다.

게다가 가볍다. CSS 생성했는데 보기도 쉽고 내용도 별로 없다. 그리고 prefix 설정도 가능해서 반응형 웹 구성에 잘 맞는다.

사용방법은 대략 이렇다.

<div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

</div>

별거 없다. 나눌 크기를 정해서 col(또는 직접 정한 prefix) 옆에 숫자만 붙여주면 된다. 최대 숫자는 니가 정한대로다. 예를 들어 12개로 나뉘었다면 1부터 12까지를 쓰면 된다.

여백을 만드는 방법은 push(또는 직접 정한 prefix) 옆에 숫자만 붙여넣으면 된다.

난 굳이 미디어 쿼리 혼합하는 방법은 안가르쳐준다. 어자피 반응형 웹을 만들 거고 거기에 대응하기 위해 미디어 쿼리를 배웠을테니까.

그래서 이거와 잘 혼합한다면 깔쌈한 사이트가 만들어질 것이다.

IE를 위해서라면 respond.js 가 필요하다. 그냥 스크립트 쳐넣으면 끝이다 나머진 CSS에 맡겨라. 구글신 영접하면 바로 나온다.

귀찮아서 끝.

니들 그냥 좆돼봐라.

composite / 2014년 2월 27일 / 미분류 / 2 Comments

태그에는

다들 HTML 배우면서 가장 간단하면서 많이 지키는 사항이 있다. 물론 맞는 말이다. 표준이기 때문에.

  • inline 요소 안에는 block 요소를 자식으로 가질 수 없다.
  • block 요소 안에는 inline 및 block 요소가 모두 허용된다.
  • 단, p 요소 안에는 inline 요소만 허용된다.
  • inline 요소 안에는 inline 요소만 허용된다.

근데 나모 웹에디터 때문에 <p> 요소에다가 <div> 넣는 등의 표준을 위반하는 사례가 있다. 그리고 IE 기반 위지윅 에디터가 그리한데, designMode 기능이 기본 문단 태그를 <p> 로 지정했기 때문이다. 그래서 초창기 위지윅 에디터가 상당히 말이 많았고, 그리고 이에 대한 문제를 고치느라 고생하던 시절이 있었다.

하지만 지금은 많은 위지윅 에디터가 문단 태그를 <div> 로 강제하였기 때문에 더이상 HTML 표준 위반 및 XHTML 표준 전선 이상 무!

자. 잡담은 끝내고 이제 본론으로 들어가보자. HTML 표준에는 일단 문장(inline) 요소에는 문단(block) 요소를 넣을 수 없게 되어 있다. 따라서 원래 <a> 태그에 <div> 태그같은 게 들어갈 수 없는게 정설이다.

하지만 HTML5 부터는 얘기가 달라졌다.

마치 p 태그가 인라인 요소만 허용한다는 예외 처럼, a 태그에도 예외가 생겼다.



두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구



그러하다.
HTML5 에서는 <a> 태그 안에 아무 태그나 넣을 수 있게 되었다.
이 때문에, 플랫 디자인 다음이 뜬금없는 카드 디자인 패턴이 나온 것이다.
예제 코드를 보자.
<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>
이렇게 생겼다.
하나의 글 영역 안에 모든 것들을 링크 걸고, 그 안에 제목과 요약 내용, 그리고 read more 라고 링크를 부추기는 글을 넣는다.
이렇게 하면 장점이 뭐냐?
웹 접근성이 향상된다. 모바일이나 특수 컴퓨터 (시력장애인 등을 위한) 에서 링크 클릭에 대한 접근성이 향상된다.
또한 이런 접근성으로 인해 스크립트 의존성이 떨어지며, 원하는 문서를 손쉽게 이동할 수 있는 장점이 생긴다.
바로 접근성을 고려해서 W3C가 이렇게 HTML5 표준과 함께 내놓은 거다.
여담으로, XHTML2 에서는 모든 요소에 href 를 넣을 것을 고려했다고 한다. 바로 이런 접근성에 용이하기 위해.
하지만 알다시피 XHTML2 는 완전히 새로운 표준을 지향했고, 하위 호환성이 철저히 무시한 덕분에 많은 웹 관련 개발자와 디자이너, 연구진들이 반발했고, 그리고 무산된 표준이 바로 XHTML2 였다.
만약 XHTML2 표준으로 웹 페이지를 만들었고, 브라우저가 그걸 지원하려면 정말 엄청 머리 아팠을 것 같지 않은가?
왜냐하면 바로 하위 호환성이 사라지기 때문에, 엔진을 2개 만들어야 하는 꼴이 되니까. 당연히 달갑지 않았던 거다.
지금은 HTML5 에서는 이 표준이 아직 하위 호환성이 적잖아 문제가 있다. 모든 브라우저가 이 표준을 지원한다. 쿼크 모드에 대한 호환성 때문인데, 이 기능이 지원된 게 다행이라 생각하지 않는가? 만약 <div> 가 <a> 로 감쌌다고 지우면, 이건 정말 골치아플 수도 있다.
하지만 아직까지 현재 브라우저에 한계가 있는데,
비록 <a> 태그 안에 모든 태그가 지원된다 해도, 현재 표준에 의한 예외 사항이 있는데, 바로 테이블이다.
테이블 태그 안에 비표준 태그들을 싸그리 지우도록 엔진이 설계한 덕분에, <a> 태그를 <tr> 안에 넣지 못하는 사태가 일어난다.
이에 대응할 지는 아직 지켜봐야 할 단계지만, 이를 지원한다면, 웹 접근성 향상에 어느정도 기여할 것으로 기대된다.
자. 이제 찬양하라. HTML5를!
자세한 링크는 HTML5 에서 신뢰성 있는 정보를 제공하는 HTML5닥터 에서 보도록 한다.

composite / 2014년 2월 18일 / 미분류 / 0 Comments

웹 개발자 도구의 역사

웹디자인의 역사는 뭐 웹디자인 관련 블로그만 검색해도 질리게 나온다.

하지만 웹 디자인을 발전시키게 해준 초석인 웹 개발자 환경의 역사는 구글링을 해봐도 잘 안나왔다.

이 얼마나 슬픈 일인가 개발자들이여!

그래서 내가 정리해준다.

1. 넷스케이프에도 개발자 도구는 있었다.

이 글 보는사람들 중 넷스케이프에 신경쓴 개발자가 몇 있을지는 나도 모르겠지만, 때는 1998년이다.

솔직히 넷스케이프 시절에 필자는 초딩이였다. 그때는 모뎀 인터넷 시절이었고, 인터넷이 종량제이며, 인터넷을 할려면 전화를 못받는다는 단점 때문에 상당히 제한적이었지만, 그래도 나름 문화컬쳐였다. 

그런 초딩 시절에 넷스케이프 4 에 자바스크립트 디버거가 있었는데, John Bandhauer 가 개발한 자바스크립트 디버거는 그때당시 자바스크립트는 그저 옵션에 불과했지만, 자바스크립트 개발하는데 있어서 생산성을 촉진시킨 하나의 유물인 것은 확실하다.


2. Venkman Javascript Debugger.

Venkman Debugger

이 기술을 넷스케이프가 모질라로 올인하면서 디버깅 기술까지 전수받았는데, 2001년 출시한 모질라 기반 자바스크립트 디버거를 Venkman Javascript Debugger 라 불렀다.

이녀석의 강점은 모질라 기반임에도 불구하고 크로스 플랫폼에서도 디버깅 환경을 제공하고자 하는 노력이었다,

그래서 Ajax 가 뜰 때 당시에 이 역사가 재조명되었지만, 다른 개발자 도구가 워낙에 좋아서 거기서 그치는 비운의 도구였다.

debugger; 키워드를 ECMA 표준으로 등재시킨 툴이였고, 별도의 프로세스로 돌아갔어도 불여우가 역시 개발자를 위한 브라우저구나 하는 무릎 탁 치게 하는 기원이였다고 해도 과언이 아니었다.

자세한 내용은 링크를 참고하라. : https://developer.mozilla.org/ko/docs/Venkman

3. DOM 시각화.

당신의 웹 어플리케이션에 동적으로 컨텐츠를 넣었다가 갑자기 레이아웃이 깨졌다면, 어떻게 모니터링하고 대처했을까?

분명 테이블이 잘 만들어진것 같은데 테이블이 무너져 보인다면, 소스를 다시 보면서 캐치해야 하니..

하지만 기존 웹브라우저는 잡아내는 방법이 너무나 제한적이었다. 소스 보기를 해도 원 소스를 보여주지 동적으로 추가된 곳까지 신경써주지는 않았으니까. 어찌나 불편했을까? 뭐.. 한국은 액티브엑스가 동적 컨텐츠를 제공하는데 아주 잘 활용해서 말이 통할려나 모르겠지만.

이것을 해냈다. 해냈어. 불여우가해냈어!

View Source Chart

DOM Inspector. 우리말로는 DOM 검사기.

DOM 검사기는 DOM 구조를 트리 구조로 시각화해서 눈으로 보여주는 아주 획기적인 도구였다.

이 도구 덕분에 테이블 등에 엉뚱한 태그가 들어가서 테이블 구조가 깨지는 문제를 손쉽게 해결할 수 있었고,

동적으로 컨텐츠가 들어갔어도 바로 볼 수 있었다.

XML에 비해 HTML은 엄격하지 않아서 물론 잘못 코딩해도 보이긴 하지만, 레이아웃 깨졌거나 뭐 엉뚱한 글자가 페이지여 보여서 컴플레인 들어오면 이젠 두렵지 않은 도구가 되었다.

하지만 한국은 이때도 액티브엑스 전성기라서 우리나라 웹 페이지는 저 구조에 크게 신경쓰지 않았거나,

테이블 기반 구조로 저게 필요한 상황을 만들었음에도 깨지기만 하면 정말 고치기 힘든 웹 사이트 구조를 만들어냈다.

그래도 저게 있어서 한국의 지랄같이 테이블 의존성 구조에서 어느정도 벗어날 수 있었지만, 그 은혜를 모른다.

정말 테이블 태그로 만든 레이아웃은 미관엔 좋았지만.. 개발과 유지보수가 어려운 단점은 피할 수 없었다.

그게 왜냐면, 디자이너들이 나모 웹에디터같은 위지윅 개발도구에 의지하고, 개발자조차도 거기에 의지한 탓이다.

그나마 테이블은 미리보기에도 그대로 볼 수 있었기 때문이었고, CSS 표현력이 제한적이라서 div 기반의 레이아웃에서 잘 보여준다는 보장이 없었으니까.

그래서 이때 웹 개발 비용이 부담된건 사실이다. 아무리 편해도 그게 한계가 있다는 것을 여실히 보여준 트랜드였던 것이다.

쪽팔리게 개발자가 나모웹에디터나 쓰고.. 으이구..

이제 Ajax 이후 하드코딩의 시대가 도래했는데, 이 DOM 검사기 도구는 하늘이 내려준 선물임은 확실하다.

4. Web Developer for Firefox.

불여우가 왜 웹 개발자를 위한 브라우저인지 다시한번 마음에 새기는 혁신(?)이 왔는데, 

하나의 작은 툴바에서부터 시작됐다. Chris Pederick 이 만든 Web Devloper toolbar 였는데, 웹 개발자를 위한 편의성 도구들을 제공하여 웹 개발에 도움을 주게 만든 일등공신이었다.

이 툴바의 강점은 Disable CSS와 Disable Javascript 기능인데, 이는 크로스 플랫폼, 크로스 브라우징 보기, 그리고 CSS가 적용되지 않은 경우와, 자바스크립트가 비활성화된 브라우저의 경우, 그리고 시맨틱과 웹 접근성 개발에 도움을 주는 기능들이 한자리에 모여서 웹 개발자들에게는 없어서는 안될 도구로 성장했다.

2003년 첫 릴리즈 이후 계속 버전업 해가면서 기능과 성능 최적화가 되고, 처음엔 미약했지만 끝은 비대한 웹개발자에겐 모르면 간첩인 도구가 됐다.

근데 한국의 경우 웹접근성이 주목받은 때가 2010년이다. 외국에 비해 7~8년 늦은 접근성이다. 비즈니스와 편의성에만 추구한 나머지 웹취약계층과 접근성은 개나 줘버렸었다. 가뜩이나 IE에만 신경썼는데 오죽했을까? 인종차별 인종차별 소리지르면서 정적 한국이 내가 보기엔 존나 차별하는것 같다.

그렇다고.

5. 개발자 도구의 시작, Firebug.

불여우가 왜 괜히 웹 개발자를 위한 브라우저일까? 애초부터 그렇게 시작한 거다.

한국에 IE와 불여우, 크롬 3대장이 웹 시장을 주름잡기 시작했는데, 불여우가 일반인에게 쓰기 어려운 브라우저인 이유가 바로 이런 개발자 환경에 신경쓴 환경이기도 하다.

어쨌든, 개발자 도구의 표준안을 마련한 도구, Firebug다.

Firebug HTML Tree

하지만 Firebug가 처음부터 표준안을 선도한 것은 아니었다. 버전 0.2 에서는 자바스크립트 콘솔과 CSS 구조, 선택한 DOM의 속성을 제공한 게 전부였다.

0.3 에서는 DOM 기능에 충실하게 출시해서 DOM 이벤트와 속성, 해당 적용된 DOM의 CSS 속성들도 볼 수 있게 됐다.

그리고 혁신을 이루어낸 것은 버전 0.4 부터인데,

0.3을 기점으로 자체 DOM 검사기를 포함하는 것으로 시작해서, 자바스크립트에 표준 바람을 불게 만든 console 객체를 출시했다. 비록 Firebug 밖에 되지 않았지만, 혁신을 이루게 한 건 사실이다. 귀찮게 로그성 데이터를 DOM에 뿌릴 필요 없었고, 정보도 바로바로 볼 수 있었던 덕에 많은 웹 개발자에게 Firebug는 이제 없어선 안될 도구가 되고, console 객체 또한 조금 늦지만 ECMA 표준에 등재된 쾌거를 이루었다.

그리고 이 주목받은 기능을 등에 업고 1.0을 출시했을 때는 상용 도구로 개발될 예정이었으나, 불여우에 왠 뜬금없는 상용 툴? 뚝.

아 미안. 그냥 공짜임. 콜! 오픈소스다. BSD로. 아주 좋소!

어쨌든, 지금의 Firebug 화면과 유사하게 나온다. 콘솔과 DOM 검사기, CSS와 스크립트 디버거, 그리고 DOM 객체 구조와 네트워크 타이밍까지. 웹 개발에 있어서 제공하는 모든 것들을 제공했다.

현재는 쿠키와 프로파일러, 설정 등 다양한 기능들이 커뮤니티를 통해 제공했다.

그리고 웹 사이트 성능 측정 도구인 YSlow. 웹 개발자라면 다 아는 도구다. 야후까지 가세해서 Firebug는 웹 개발자가 모르면 간첩.

그리고 이에 힘입어 Firebug Lite 까지 출시했는데, Firebug를 다른 브라우저에서 돌리고 웹개발에 편의성을 주도록 개발한 녀석이다.

그래서 오페라 브라우저에 신경쓰는 웹 개발자에겐 가뭄에 비같은 도구로 잘 활용했었다. 지금은 오페라도 자체 개발자 도구 제공해서 상관은 없지만.

IE에게는 가뭄에 산성비같은 도구였다. Firebug가 느리기 때문인데, 이는 Firebug 문제가 아니라 JScript 엔진이 병신같아서 그런 거다. 엔진 자체가 느려 터졌다고.

하지만 IE 8부터 자체 개발자 도구가 생겼으니 굳이 고민을 할 필요는 없어보인다.

현재는 불여우에 자체 개발자 도구로 제공하고, Firebug 보다 더 빠른 성능을 제공해 주지만, 아직도 많은 불여우 기반 웹 개발자는 Firebug를 쓰고 있다.

여담으로, Firebug 또한 한국에서 최고의 개발자 도구로 주목받았을 땐 한글화해준 고마운 사람이 있었다, 하지만 그는 누군지 모르고, 게다가 현재는 Firebug 한글화가 진행되지 않고 있다.

그래서 현재 Firebug 는 받으면 영어로 나오며, Firebug 공식 홈페이지에 한글화 번역자는 등재되지 않고 있다.

왜죠?

6. 개발자 도구의 반격, Internet Explorer.

한국인이야 알다시피 IE는 웹 환경의 혁신(?)을 불러일으킨 브라우저다. 하지만 너무 자체적으로 표준으로만 만들었다 보니 다른 브라우저에서 안되고, 액티브엑스 때문에 갈라파고스화를 만들어낸 주범이었다.

물론 이것도 마소가 독점하려고 일부러 그렇게 만든건 맞다. 하지만 IE의 보안성 부재와 불여우의 선전, 그리고 구글까지 웹 브라우저를 만들고 나서려고 하니 마소에게 똥줄타지 않을 수가 없다보니…

IE 7을 출시했다. 사용자 측면에서는 탭 브라우징이 끝이다. 시발. 장난하냐?

그리고 IE 7의 실패를 맛본 마소는 이번엔 IE 8 을 출시했다. 물론 욕나오는 브라우저긴 하다. 버그 작렬과 쳐진 성능. 즉, IE 6에 익숙했던 똥컴에게 IE8은 지랄같은 존재였던 것이다.

하지만 마소가 이제 점점 웹표준 수순을 밟고 가려는 의도가 점점 보이고 있는 웹브라우저였고,

마소도 몇몇 기술을 웹 표준에 등록했는데, 대표적인 기술이 localStorage 다.querySelector 도 있긴 한데 제한적이니…

참고로 Ajax를 만들어게 이룩한건 IE의 ActiveX 였지만, 모질라의 XMLHttpRequest가 채택되고, IE에서는 XMLDOM 액티브엑스의 래퍼(Wrapper)로 쓰였다.

그리고 IE 8에서 F12를 누르면 개발자 도구가 나오는데, 혁신을 이루게 만든 하나의 기능이 있었는데 바로 “프로파일러”다.

자바스크립트 프로파일러는, 수집하는 동안 사용자가 브라우징하는 동안에 이벤트와 속성, 함수 호출 내역을 기록하는 기능인데, 사실 이걸 재대로 쓰는 개발자는 많지 않지만, 동적 UI 편의성 모니터링과 개선에 이만한 기능이 없다.

그리고 자바스크립트 디버거 성능이 장난이 아니었다. 비주얼 스튜디오로 나태한 디버거를 만들어낸 마소 답게, 비주얼 스튜디오 좀 만졌다면 IE 자스 디버거는 이보다 편할 수 없을 것이다. 굳이 안만져봤다 해도 상당히 좋은 기능으로 자리매김하였다.

하지만 IE 개발자 도구의 단점이 이런 장점을 덮어버렸는데,

DOM 검사기를 제공한 건 잘한 일이지만 동적이지 못한 단점이 있다. 즉, DOM 변경에 대응을 하지 않았다는 것이다. 수동으로 새로고침을 해야지 그 결과를 볼 수 있다. 상당히 불편한 기능이다.

그리고 자바스크립트 콘솔을 제공하는데, Firebug 가 다른 콘솔은 객체만 치면 객체의 대략적인 속성이나 constructor 가 뭔지 알 수라도 있는데, IE에서는 그저 [object] 로 나온다. 시발 어쩌라고.

그리고 네트워크 탭이 없었다. 물론 Fiddler 가 그 역할을 대신해주긴 했지만, Ajax나 동적 스크립트, 그리고 누락된 리소스 알아내는데 Fiddler 켜야 하니 불편하지 않을 수 없었다.

그리하여 IE 9에는 네트워크 탭이 생겼는데, 이녀석인 프로파일러처럼 개발자가 키면 수집하고 안키면 수집 안하는 식이다.

이는 어찌보면 편하기도 하고 불편하기도 한데, 내가 쓴 바로는 그닥 불편하지 않고, 필요한 경우에만 켰다가 필요없는 경우에 끄는 기능도 괜찮다고 생각한다. 키고 끄는게 가능하지만 조금 불편한 감이 있는 Firebug와, 아예 수집만 주구장촹 하는 웹키트 기반에 비해서 IE는 IE만의 특징이 있다고 보면 된다.

IE 10까지 별다른 진척 없다가 IE 11에서 개발자 도구가 플랫 UI를 안고 탈바꿈 하였는데, IE 11의 DOM 검사기는 이제 수동으로 새로고침 안해도 변경되면 반영하게 됐다. 그 외 나머진 별 다를거 없고.

그리고 UI 응답성 테스트가 생겼는데. 그냥 YSlow 비슷하다 보면 된다. 일종의 프로파일러다. UI가 렌더링된 시간을 기록하여 시각적 결과를 제공해준다. 이건 잘만든 기능이다.

이렇게 IE의 개발자 도구도 강력해지긴 했는데, 아직도 고질적인 문제는 IE는 각 버전마다 렌더링이.. 시발.. 아주그냥.. 시발..

7. Webkit, 개발자 도구로 대동단결.

맥으로 웹개발하는 사람이라면 알겠지만, 사파리나 크롬이나 개발자 도구는 똑같이 생겼다. 그 이유인 즉슨, 둘 다 사용하는 엔진인 웹키트가 개발자 도구를 대동단결했으니까. (웹키트 엔진에 번들로 제공한다고.)

웹키트의 개발자 도구는 조금 늦은 감이 있다. 웹키트 자체 DOM 검사기가 2006년에 소개됐으니까.

하지만 초기에 기능이 워낙 강력해서 Firebug 보다 나았던 시절도 있었다는 것.

왜냐면 이녀석은 시각적 효과가 화려하게 제공되고, 자바스크립트 콘솔이 강력했다. 자동완성을 먼저 지원했기 때문이다.

사실 IE 8과 비슷한 시기에 웹키트 기반 개발자 도구가 대중에 공개됐는데, Firebug 에 비해 이녀석은 아예 그냥 모든 사이트라면 F12 만 누르면 죄다 수집하고 분석하고 기록한다.

어찌보면 편하기도 하지만, 프레임으로 지속적으로 불러오는 웹 사이트 구조라면 계속 수집해서 목록이 늘어날수록 성능이 떨어지는 단점이 있다. 이는 어쩔 수 없다.

그래서 조금은 불편한 감이 있기도 하다. 왜냐면 Firebug 와는 달리 특정 기능만 키고 끌 수가 없으니까.

그래도 나름 웹키트 다운 면모가 있다.

그리고 사파리와 크롬은 결국 개발자 도구도 다른 길로 걷게 되는데, 사파리는 웹키트의 주를 이루니 웹키트 흘러가는대로 가지만, 크롬은 웹키트 변형 엔진인 블링크를 만들어 쓰기 시작해서 지금도 비슷하게 생겼지만 점점 달라지고 있다는거.

8. 마치며.

사실 각 플랫폼별로 나열했기 때문에 누가 먼저 하고 그다음 누가 했는지 햇갈릴 것이다. 그건 필자도 인정한다.

한가지 분명한 사실은, 넷스케이프에서 가장 먼저 개발자 도구를 만들기 시작했고, 그 전신을 이어받은 모질라가 먼저 개발자 도구를 만들고 선도한 것은 틀림없는 사실이다.

불여우가 웹 개발자를 위한 브라우저라고 누차 강조한 이유가 그 역사를 달고 태어났기 때문이라고 나는 자신있게 말한다.

어쨌든, 이렇게 개발자 도구가 서로 경쟁하고 선도하고 발전하면서, 웹 개발이 이렇게 발전할 수 있었던게 아닐까 싶다.

웹 디자인도, 웹 개발에 초석이 되지 않았다면, 가뜩이나 웹 디자인에 가장 많은 의존을 하는 CSS 개발도 어려웠을 것이다.

생산성도 향상되고 디자인도 여러가지로 화려해졌지만, 그렇다고 단가가 낮아진 건 아니다.

클라이언트가 요구하는 건 점점 더 다양해지고, 이를 수용할 수 있는 웹 디자이너와 개발자는 그만한 가치가 있기 때문이다.

이렇듯 웹 개발자 도구는, 절대 무시해선 안될 도구다. 특히 웹 개발자는 더. 액티브엑스? 몰라. 그딴거.

개발자 도구. 고맙게 쓰자.

composite / 2014년 2월 10일 / 미분류 / 0 Comments

HTML5 API 정리 프로젝트 1

그렇다. 앞서 포스트에서 설명했듯이 나도 몰랐던 API가 우후죽순 생겼다.

하지만 앞으로도 계속 제안되고, 표준으로 등록되는 API가 많아질 것이다.
왜냐면 아직 표준 확정이 아니고 W3C에서도 Working Draft 상태거던!
이지랄을 하니 HTML5 과 HTML5.1 분리하자고 W3C에서 난리 브루스를 친다.

좋다. 그렇다면 현재 제안되어 Editor’s Draft 라도 나온 API를 알아보도록 한다.

물론 이미 알려져서 많은 이들이 알고 있는 API도 많지만, 나조차도 몰랐던 API가 속속 들이대기 시작할 것이다.

  • Fullscreen API 많이들 알거다. HTML5 게임이나 프리젠테이션을 위한 전체 화면.
  • Page Visibility API 말이 거창하지 그냥 다들 알고있는 모든 태그에 hidden 속성이다. style.display=’none’ 이냐 아니냐.
    하지만 더 특징은 hidden 속성 변경에 따른 이벤트를 제공한다는 점이다.
  • getUserMedia API 이것도 많이 알려져 있듯이 카메라에서 나오는 데이터를 HTML 미디어 표현 요소 <canvas>나 <video> 로 전달할 수 있는 API다.
  • Battery API 이건 순전히 모바일을 위한 API다. 뭐.. 제공해봐야 딸랑 배터리 얼마나 남음이겠지만. 아.. 노트북도 있지.
  • Link prefetching 별거 없고 그냥 미리 불러올 URL만 지정해서 해당 페이지로 이동할때 로딩 없이 바로 이동하는 목적이 있다.
  • WebMIDI 순수 웹으로 미디를 재생한다. 참고로 추억의 게임 포트리스2 블루가 음악이 MIDI 인데, 이걸 돌릴 수 있다. 근데 원본 가지고 있는 이가 얼마나 될런지 모르겠다. 근데 한국은 이런거 관심 없나보다. 추후 내가 포스팅 올리겠다.
  • Vibrate API 말그대로 진동 API로, 스마트폰의 진동 기능과 연동하는 API다. 현재 안드로이드 크롬 베타와 안드로이드 불여우가 지원하고 있다고 한다. 이제 순수웹으로 딜… 아니다.
  • History API 브라우저의 뒤로가기 앞으로가기 뿐만이 아니라 URL과 해시를 갖고 놀 수 있는 API로 뭐 많이들 알려져 있으니 패스.
  • Drag n Drop 요소 드래그앤 드롭. 물론 스크립트로 만든 드래그앤 드롭에 비하면 좀 엉성하지만 모든 환경에 지원하려면 이렇게 해야지. 많이 알려진 기능이다.
  • Geolocation 걍 GPS잖아. 알잖아. 내가 굳이 설명해줘야되?
  • Offline 인터넷 안되도 문서는 봐야겠지? 가지고 댕기면서 뭔가는 해야겠지? 그럼 이거야.
  • Messaging 다른 도메인인라고 스크립트 막는다? 응 그건 맞아. 하지만 이제 간단하게 서로를 전달이라도 할 수 있다는점.
  • Web Workers 자바나 닷넷의 쓰레드 역할. 백그라운드 실행을 담당할 API다. 구버전 IE야 지원을 안하지 그래도 웹오피스에서 이게 무거운 처리에 1등공신이다. 이제 무거운 스크립트를 직접 실행할 필요 없다. 이녀석에게 맡기면 브라우저가 얼지 않고 계속 즐길 수 있다.
  • Storage 단순한 저장 기능이다. 그 이상 그 이하도 아니다. 세팅값 저장에 이만한 거 없고 IE 8부터 지원한다. 당장 채용해도 된다. 근데 이벤트도 있는데 이건 안타깝게도 IE 지원은 안한다.
  • Indexed database 순수 웹상의 DB다. 당연히 도메인 단위로 쓸 수 있다. 하지만 NoSQL이다. 이거 이전에 SQL DB로 지정된 Web SQL Database 도 있긴 하지만 접근성이 떨어지고 기술적인 한계로 표준에서 배재된지 오래다. 이것도 많이 알려져 있으니 알아서 찾아봐.
  • Web sockets 존나게 많이 알려져있고 순수 웹으로 만드는 채팅 등 실시간 소켓통신의 선두주자 웹소켓이다. 구글링해라. 내손아프다. 기쁜소식 하나 알려줄까? 이녀석의 인기가 하늘을 치솟다보니 많은 참여와 수정으로 이제 거의 표준 확정이 되가고 있다.
  • Server-Sent Events7 푸시 알림의 HTML5 버전이라고 보면 된다. 한국에서는 웹소켓 때문에 얘기 묻혔지만 무시하지 마라. 구현이 쉽고 polyfill이 쉽게 제공되기 때문에 웹 사이트상의 푸시 알림이나, 실시간 정보 알리미에 이만한 API가 없다.
  • Microdata 시맨틱 정보 수집에 특화된 API다. 검색 잘되라고. 광고에 관심있다면 이것을 눈여겨보는것도 좋은 선택이다.
  • File API 어쩌다 보니 표준이 됐다. 좀 늦게나마 표준에 포함되서 다행이지. 파일을 말 그대로 다루는 API다. 물론 사용자 컴퓨터에 있는 파일을 맘대로 다룰 수 없고, 사용자가 파일을 요청해야만 다룰 수 있다. 그래봤자 예제는 업로드 뿐.
  • Web Notifications 알리미 API다. 현재 크롬에서 재대로 지원하고 있다. 당연히 사용자 승인이 요구되지만, 이 API가 있다면 CRM, 그룹웨어 같은 엔터프라이즈급 고객/자원관리 어플리케이션에 레드불이 날개를 달아준다.
수집하기 왜이렇게 힘드냐.. W3C 한국지사에 멜좀 보내야겠다. 정리하기 빡세네..

<

p>

composite / 2014년 2월 6일 / 미분류 / 0 Comments