Flash를 사용하지 말라는 지시가 저에게 왔을 때는 재설계할 시간이 없었습니다. 제 목표는 Flash의 시각적 부분과 구분할 수 없게 하는 것이었지, 유효한 마크업, 점진적 개선법, 508 섹션 접근성 등은 아니었습니다.

예전에 MooTools(와 초기의 moo.fx)를 인터페이스 엘리먼트에 애니메이션 효과를 주려고 사용해 본 적이 있었습니다. 하지만 그것(혹은 다른 JS 라이브러리)을 이용해 전체 사이트를 만들어 본 적은 없었습니다. 게다가 포지셔닝이 무척 중요한 사이트를 작성해본 적도 없어서 CSS도 도전이었습니다.

저는 수많은 Mootools의 내장 Assets를 사용했습니다: AJAX, 툴팁, 슬라이더

페이지 전환은 효과들을 초합해 만들었습니다. 기본적으로 세 개의 레이어가 있습니다: 프레임, 컨텐트, (보통은 감춰진) 배경. 사용자가 새 페이지로 이동하면 다음과 같은 일이 일어납니다:

1. 배경이 현재 페이지의 흐린 스크린샷으로 바뀐다(즉시 바뀜. 이미지는 미리 로딩되어있다).
2. 컨텐트 영역의 투명도가 증가하면서, 흐린 배경 이미지가 드러난다(300 ms).
3. 새 컨텐트가 AJAX를 통해 로딩된다(각 컨텐트 페이지는 1KB 정도이다; 라운지는 4KB).
4. 컨텐트 영역의 투명도가 다시 감소하여 불투명 상태로 된다(300ms).

컨텐트는 중복 컨텐트의 필요를 제거하기 위해 PHP include를 사용해서 HTML로 가장 먼저 놓아졌습니다.(부수적으로, 진입폼과 유효성검사도 PHP로 작성되었습니다.) 몇 개의 브라우저(Firefox, IE6, Safari, Opera, Lynx, IE6+, JAWS)에서 표현이나 기능면에서 문제가 없음에 만족하고 나서, 저는 이벤트 리스너를 작성하기 시작했습니다.

JavaScript가 작성되고 나면, 우리는 테스트를 다시 했습니다. 결국, 우리가 해야할 일은 배경 음악과 몇 개의 두번째 애니메이션(회전) 뿐이었습니다. 여전히, 많은 사람들은 그것이 Flash이겠거니 하고 있습니다.

Firefox용의 Firebug, YSlow 그리고 Web Developer toolbar는 개발기간동안 값을 헤아릴 수 없을만큼 귀한 도구였습니다.

• 전체 JavaScript는 59KB (51KB는 Mootools + 라이브러리 8KB)
• CSS 30.9KB (조건절을 통한 MSIE용 CSS 4.7KB 포함)
• 전체 사이트 2.59MB (이미지 2.11MB)
  

Pipes는 또 Prograph와 몹시 유사하게 보입니다(데이터 플로우 프로그래밍 회사이고 1992~1995년까지 제가 일했었습니다).

초기의 빌더는 [다른 프레임웍]을 이용해 작성했었는데, 이것이 둔하다는 것을 알게되었습니다. 문자 그대로 일주일내내 날짜 선택기를 색상 선택기로 바꾸는데 허비하고 나서야, 포기하고 말았습니다. 제 친구가 jQuery를 권했고 깔끔하고 빠른 모습에, JavaScript에서 HTML을 분리하는 방법의 아름다움에 반해버렸습니다. 그래서 빌더를 바로 2주만에 jQuery로 재작성했습니다. 그 직후 Opus Capital로부터 투자를 받고, 사람들을 고용하려고 했을 때, 우리 개발자들 4명중 3명은 jQuery 메일링 리스트에서 찾았습니다. 그런 식으로 진행되는게 꽤 재미있죠; 프로그램이 끝내주는 새 라이브러리로 작동했기때문에 완전한 방법을 찾는 것을 끝냈습니다.

1. 완전히 커스터마이징 되는 사진 갤러리 - 우리의 갤러리 인터페이스는 사진을 갤러리에 추가하고 정렬하기위한 드래그-앤-드롭 기능을 제공합니다. 실시간 커스터마이징 옵션은 사용자들이 실시간으로 갤러리의 색상과 글꼴을 커스터마이징 할 수 있게 합니다. 몇 개의 미리 설정된 갤러리 테마도 사용가능합니다. 다음은 예제 화면입니다:

2. 프로파일 페이지 - 모든 사용자는 자신들의 사진, 태그, 갤러리를 품위있게 표시하는 완벽한 프로파일 페이지를 가집니다.

3. 커뮤니티 기능 - 커뮤니티 기능또한 다른 사이트보다 우수합니다. 친구들의 최근 업로드나 갤러리를 보는 것으로 그들의 활동을 추적할 수 있는 기능과 친구들의 유형(친구/가족)을 정하고 여러분의 사진/갤러리/프로필을 수정할 수 있는 권한을 줄 수 있습니다.

4. 편집 - 편집 기능은 Ajax / JavaScript 를 통해서 이루어지고, 기본적인 크롭, 여러 효과, 화질, 비율 고정등의 기능을 다룹니다. 또한 단계별 버저닝(우리의 기본적인 버저닝 기능과 비교되는)과 더 많은 편집 효과와 관리 기능(배치 편집, 워터 마크 등)을 포함한 보다 다양한 굳건한 기능들을 곧 선보일 것입니다.

5. 웹스페이스 - 우리는 늘 사용자들의 풀사이즈 사진들을 저장하고 개별 사진에 크기나 월별 용량 제한을 두지 않았습니다. 계정 유형(무료 혹은 프로)에 따른 전체 용량의 제한만 있을 뿐입니다.

6. 사용성 - 모든 백엔드 기능은 "실시간"으로 라이트박스 창에서 이루어지기때문에, 최소한의 페이지 리로드만 일어나며 이는 사진과 갤러리를 작업하는데 있어 상당한 효율성의 증가를 가져왔습니다.

Sam Foster씨가 Dojo를 이용해 키보드 단축키를 지원하는 디렉토리 리스트 예제를 만들었습니다.

탭키 혹은 마우스 클릭으로 우측 상단에 있는 박스로 이동해, 목록을 필터링할 수 있습니다

Dojo 응용프로그램들이 어떤 식으로 작동하는지 보여주는 좋은 예제인 것 같습니다:

글쓴이가 작년 1월에 event driven application design in JavaScript 에 대해 쓴 적이 있는데, 이 아이디어에 영감을 얻은 Caridy Patiño씨가 Bubbling Library를 작성했습니다.

Caridy는 YUI 블로그에 버블링 라이브러리를 이용한 디커플링 방법을 작성했습니다.

본질적으로, 그의 해결책은 여러분이 응용프로그램 모듈에서 커스텀 이벤트를 가지고 실행순서나 가능성에 상관없이 이벤트를 살펴볼 수 있도록 합니다. 만약 이벤트의 순서에 종속적으로 된다면 단순하게 커스텀 이벤트를 사용하는 것은 꽤 곤란할 수도 있습니다. Caridy씨가 제안한 디커플링 해결책은 걱정거리를 하나 줄여주게 될 것입니다.

Mitchell Amihod씨가 YUI에서 조금 언급된 부분인 YAHOO.lang의 기능에 대한 글을 썼습니다.

그는 isNull(), isUndefined(), isValue() 등의 타입 체크 함수에 대한 이야기로 시작했고, 그 다음에 trim() 함수에 대해 말했습니다.

YUI에 치환 형식의 작은 템플릿 언어가 있다는 사실을 알고 계셨나요?

setInterval/setTimeout 호출을 래핑하지 않은 DHTML 라이브러리는 없겠죠:

Jacob Seidelin 씨가 Flash를 사용하지 않고 순수 JavaScript로만 동영상 플레이어를 만들었다고 합니다: 처음엔 바이너리 파일을 바로 읽을까 하다가 마음을 바꿔먹고 생각해낸 것이 JSON 포맷으로 비디오를 표시하는 JSONVid 였다고 합니다.

아래 포맷을 보면 이해하시겠지만, 프레임 한장 한장을 base64 형태의 데이터로 내보낸 것입니다! (Crazy! 라는 말이 저절로 나와요):

[code:JScript]
{
  frm : "JSVID",   // format id tag
  ver : 1,  // version number of format
  width : 320,  // width of video
  height : 240,  // height of video
  rate : 15,  // framerate (frames per second)
  frames : 495,  // number of frames in file
  data : {
    video : [ // here comes 495 data:uris containing base64 encoded jpeg image frames
      "https://t1.daumcdn.net/cfile/tistory/2550BE4256E6943610",
      "https://t1.daumcdn.net/cfile/tistory/2647263C56E6943631",
      ...
    ]
  }
}

처음에는 각각의 프레임을 이미지 객체로 만들어서 캔버스 엘리먼트에 drawImage()를 이용해 렌더링하려고 했습니다. 잘 동작했고, 성능도 좋았지만(Opera에서는 CPU를 과하게 사용하긴 했습니다만), 보통의 이미지 태그만을 사용해서 각 프레임별 data:uri를 src 속성을 통해 바꿔주기만 하면 되겠다라고 생각했습니다. 변화는 Firefox와 Safari에서는 겨우 알아챌 수 있을 정도였고, Opera에서는 다소 나아져서 작동되었습니다. 그래서, 저는 캔버스를 버리고보통의 이미지들만 사용했습니다.

이제는, 똑같은 이미지 태그에 data:uri 만 변경하는 것을 계속하면 Firefox가 메모리를 다 잡아 먹을 것처럼 보였습니다. 그래서, 각각의 프레임마다 다음 프레임을 위한 새로운 이미지 객체를 만들고 저장해두었습니다. 동영상이 재생됨에 따라, 이전 프레임 이미지는 새로운 이미지 객체로 대체되었습니다. 이것은 잘 동작하는 것 같았지만 재생 전에 매번 이미지 객체를 생성하는 만큼 짜증스러운 딜레이가 생겼습니다. 그래서 결국 이미지 생성을 실제 렌더링 주기로 옮겨서 프레임 이미지가 이미 생성되어있는지 확인하고 없는 경우에만 새로 만들도록 했습니다.

이렇게 사용하면 된다고 합니다:

from JSONVid: Pure JavaScript Video Player on Ajaxian