브라우저 개발과 관련된 웹 개발자의 역사

웹 개발자는 이와 같은 웹 페이지를 만드는 사람입니다. 여기서 우리가 어떻게 협력하고 있는지 생각해 보세요. 독서 측면의 당신과 나는 HackerNoon의 편집자의 지원을 받아 더 나은 작가가 되어가고 있습니다.

개발자들이 보이나요? 아마도 그렇지 않을 것입니다. 그들이 좋은 일을 했기 때문입니다. 우리는 그들이 웹 개발의 미래 에 대해 읽고 있는 것을 보게 될 것입니다.

반면에 제가 이 기사를 통해 제공하는 것은 웹 개발자의 출현, 이것이 브라우저의 역사와 어떻게 연관되어 있는지, 그리고 이들의 협력이 어떻게 브라우저 개발 일정에 다시 불을 붙였는지 잠시 멈춰서 생각해 볼 수 있는 기회입니다.

웹을 위한 새로운 종류의 엔지니어

+

웹 초기에는 많은 소프트웨어 엔지니어들이 웹 페이지 측면에서 웹 개발에 큰 관심을 기울이지 않았습니다. 왜 그럴까요? 당신이 엔지니어라면 기관차에서 가장 먼저 오는 승객이나 기관차 자체에 깊은 인상을 받겠습니까?

Home of Fine HyperText Products 의 Jason Kottke는 다음과 같이 잘 썼습니다.

NCSA 모자이크를 사용하여 대학 지하 물리학 연구실에서 처음으로 월드 와이드 웹을 서핑하는 것은 제가 지금까지 경험한 것 중 가장 종교적인 경험에 가까웠습니다. 그것은 내 인생을 완전히 바꿔놓은 벼락이었습니다.

그러나 그 첫인상은 해커(그리고 화가)가 사용자 인터페이스 측면에서 주제에 접근할 수 있게 해주었습니다. 따라서 모자이크 브라우저의 발명과 혁신은 웹 개발 기회의 시작을 의미합니다.

1993년 초, 국립슈퍼컴퓨터응용센터 (NCSA)는 일리노이 대학의 모자이크 브라우저의 첫 번째 버전을 출시했습니다. 이 소프트웨어는 연구 커뮤니티에서 널리 사용되는 X Window System 환경에서 실행되었으며 친숙한 창 기반 상호 작용을 제공했습니다. 얼마 지나지 않아 NCSA는 PC 및 Macintosh 환경용 버전도 출시했습니다. 이러한 대중적인 컴퓨터에 신뢰할 수 있는 사용자 친화적인 브라우저가 존재한다는 사실은 WWW의 확산에 즉각적인 영향을 미쳤습니다.

도구로서의 브라우저가 이면의 인프라가 잠재력을 보여주면서 어떻게 많은 의미를 갖기 시작했는지 주목하세요.

1993년 4월 30일, CERN은 WorldWideWeb의 소스 코드를 로열티 없이 무료 소프트웨어로 만들었습니다. 1993년 말까지 알려진 웹 서버는 500개가 넘었고 WWW는 인터넷 트래픽의 1%를 차지했는데, 그 당시에는 많은 것처럼 보였습니다(나머지는 원격 액세스, 이메일 및 파일 전송이었습니다).

어디에서나 지식에 접근할 수 있는 가능성을 보여주는 친숙한 인터페이스 때문에 그것은 초현실적인 경험이었습니다. 아마도 어디에서나 지식에 접근할 수 있는 가능성을 보여주는 친숙한 인터페이스로 ChatGPT를 사용할 때 느꼈던 것과 다르지 않을 것입니다. 다음 기사에서 모자이크의 역사와 웹의 발명에 대해 읽어 보세요.

보기 소스: 예제 복사를 통해 학습

하지만 웹페이지는 매우 단순했습니다. 당시 우리(컴퓨터 공학도)는 Bell Labs의 Dennis Ritchie 가 쓴 페이지처럼 페이지가 얼마나 단순한지를 기준으로 똑똑한 사람을 찾았습니다.

컴퓨터 과학 강의에 참석하지 않고 웹을 가지고 노는 것이 아니라 호기심 많은 사용자로 거기에 있었을 때 나는 또한 웹 페이지의 소스를 볼 수 있게 해주는 브라우저에 통합된 메뉴 옵션을 우연히 발견했습니다. 그건 그렇고, 거의 하룻밤 사이에 그 모자이크 브라우저는 넷스케이프(Netscape)로 불렸습니다.

Jim Nielsen은 The Spirit of View-Source 에서 어떻게 Netscape 브라우저가 웹의 모든 페이지에 대해 즉각적으로 학습 기회를 제공했는지 확인했습니다.

그의 기사에서 그는 Coders 책에서 Clive Thompson의 관찰을 인용했습니다.

귀하가 방문한 모든 단일 웹 페이지에는 그것이 어떻게 생성되었는지 보여주는 코드가 포함되어 있습니다. 전체 인터넷은 프로그래밍 방법 가이드 라이브러리가 되었습니다.

이제 "웹"이 가장 인기 있는 것이라고 상상해 보십시오. 우리 중 얼마나 많은 사람들이 다른 사람의 아이디어를 복사하여 결국 배우려고 페이지 소스를 확인하고 있는지 상상해 보십시오. 이것은 우리가 마법을 볼 수 있었던 "소스 보기 시대"였습니다.

최신 브라우저 메뉴에는 여전히 "페이지 소스 보기"가 있지만 웹 페이지 소스를 보면 신비해 보이는 것을 볼 수 있습니다.

JavaScript: 제어 및 상호 작용

잘 알려진 또 다른 변곡점은 Netscape가 프로그래밍 언어인 JavaScript를 다시 활성화했을 때 나타났습니다. 이를 통해 웹 개발자는 웹 페이지의 특정 측면을 제어하고 상호 작용을 제어할 수 있는 스크립트를 만들 수 있었습니다.

JavaScript 의 발명가이자 현재 Brave Software The Browser That Cares about your Privacy 의 CEO인 Brendan Eic h는 웹의 땅에서 JavaScript를 사용한 영웅의 여정을 요약한 슬라이드를 제공했습니다. 그의 요점은 JavaScript가 항상 우아하다고 여겨지는 것은 아니지만 결국에는 많이 사용되고 지속적으로 개선되고 있음을 알 수 있도록 도와줍니다.

다음 스크린샷은 Netscape 2 브라우저 인터페이스에서 호출되는 경고 상자를 보여줍니다. 웹 개발자는 JavaScript를 사용하여 시각적 경고(코드 디버깅)를 시작하고 웹 양식 제어, 입력 양식 값 유효성 검사 및 기타 사용 사례와 같은 불가능한 작업을 수행했습니다.

호기심 많은 사용자가 "소스 보기"를 통해 페이지의 JavaScript에 대해 배울 수 있다는 것은 말할 필요도 없습니다. HTML 페이지는 HTML 요소, 하이퍼링크, 이미지, 스타일 및 JavaScript 코드를 통해 사이트에 대한 많은 표현과 논리적 구조를 전달하는 봉투였습니다.

동적 HTML: 레이아웃 사용자 정의 및 애니메이션

그리고 <layer> 라는 HTML의 새 태그를 통해 또 다른 기회가 활성화되었습니다. 1997년경 Netscape는 개발자를 위한 새로운 API가 포함된 Netscape Communicator Preview Release를 출시했습니다. 보도 자료에 따르면, “ 동적 HTML은 HTML의 중요한 이정표로서 디자이너에게 웹 페이지 레이아웃에 대한 더 많은 유연성과 제어 기능을 제공하는 동시에 사용자에게 더 높은 수준의 상호 작용성을 제공합니다. ”

나중에 <layer /> 태그는 <div />가 되었습니다. 당시의 기술 혁신은 다음 3D 그림이 초기 DHTML 기술 노트 중 하나에서 보여주듯이 HTML의 시각적 부분인 요소를 다른 요소 위에 배치하는 기능과 관련이 있었습니다.

지금으로서는 1997년의 다음 시연을 경험할 수 없지만 그 기차(단순한 이미지)가 마치 당신을 향해 다가오는 것처럼 움직이는 것을 상상해 보십시오.

트릭은 JavaScript를 사용하여 다양한 크기의 이미지 가시성을 전환하여 애니메이션의 환상을 만드는 것으로 구성되었습니다. 이 페이지는 또한 다른 방법을 사용하여 기관차 소리를 시작했습니다.

그 시점에서 브라우저 전쟁이 최고조에 달했고, 나처럼 Netscape용 페이지를 작성하기 시작한 개발자들은 나와는 달리 Internet Explorer용 페이지를 제작하기 시작했습니다. 이러한 차이점과 필요한 기술은 개발자가 웹 개발자로 채용되는 이유가 되었습니다. DHTML 운동의 규모와 복잡성은 1000페이지가 넘는 이 인기 있는 책의 내용과 관련이 있습니다.

웹 표준

브라우저 전쟁의 주요 결과는 Netscape가 소스 코드를 오픈 소스로 공개했다는 것입니다. Project Code Rush 에 설명된 대로 여기에 Mozilla라는 이름이 표시됩니다. 그 과정은 전략적이고 복잡하며 위험했습니다. 이는 당시 CEO였던 Jim Barksdale이 인정한 바와 같이 대담한 조치였습니다.

“어느 회사도 감당할 수 없는 엄청난 양의 새로운 인력(현재 Netscape Navigator Communicator에 기여)이 제품 개선에 중요한 변화를 가져오길 바랍니다. 이것이 경쟁사에 어떻게 작용할지는 아직 두고 볼 일입니다.” 짐 박스데일 @ 코드 러시 2013

오픈 소스 기반 외에도 Mozilla의 주요 전략은 웹 개발자의 관심을 끌었습니다. 바로 웹 표준 지원입니다. 이를 돕기 위해 Netscape는 새로운 기술 전도사 팀을 구성했습니다. 그중에는 개발자들 사이에서 유명 인사가 된 CSS 전문가 Eric Meyer도 있습니다. 그들의 목적은 웹 개발자의 요구에 반향을 일으켰습니다. 즉, 독점적인 차이점을 끝내고 모든 브라우저에서 작동하는 페이지를 구현하기 위한 공통 기반을 갖기 위한 것입니다. Eric은 우리의 싸움을 축하했습니다.

“여기 Bob Clary, Marcio Galli, Katsuhiko Momoi, Chris Nalls, Tristan Nitot, Arun Ranganathan, Doron Rosenberg 및 Susie Wyshak이 있습니다. 우리는 선의의 싸움을 벌였으며 DevEdge 자체의 재설계에 대한 정보를 포함하여 훌륭한 자료를 많이 만들었습니다. “

위의 사진은 큰 사진의 작은 부분이라는 점을 명심하세요. 그 중 또 다른 부분은 나중에 Mozilla 개발자 네트워크로 성장한 Mozilla의 문서화 노력이었습니다.

단일 페이지 애플리케이션과 AJAX 방식

개발자들은 표준을 준수하는 방식으로 웹 페이지를 수정하는 동시에 페이지를 한계까지 밀어붙였습니다. Gmail과 같은 사용 사례가 등장 하고 웹 서비스 와 같은 이니셔티브를 통해 우리는 단일 페이지 애플리케이션 에 대한 아이디어를 고려할 수 있게 되었습니다. 웹 페이지가 소프트웨어 애플리케이션처럼 작동할 수 있다면 어떨까요? 다음 기사는 당시 전도자들이 쓴 내용을 보여줍니다.

• WSDL 프록싱을 사용하여 Netscape 7.1/Mozilla 1.4에서 웹 서비스에 액세스하기 (2003년 6월 6일)
• 표준 기반 접이식 목차 위젯(CTOCWidget) (2003년 5월 20일)
• 내부 탐색: 탐색 패러다임을 통한 웹 탐색 확장 (2003년 5월 16일)

이러한 노력에도 불구하고 변곡점은 옛 서부에서도 찾아왔다. 2005년 샌프란시스코의 Jesse James Garrett은 " Ajax: 웹 애플리케이션에 대한 새로운 접근 방식"이라는 제목의 중요한 기사를 썼습니다. Jesse는 전 세계 웹 개발에 영향을 미친 사용자 경험 디자이너였습니다. AJAX는 개발자가 대화형 기능을 추가하고 웹 애플리케이션의 동작을 생성하려는 의도를 전달하기 위해 사용하는 인기 있는 용어가 되었습니다.

단일 페이지 애플리케이션을 만들기 위해 누군가를 고용하려면 AJAX를 아는 웹 개발자를 고용해야 했습니다.

개발자의 가장 친한 친구 - 개발자 추가 기능 도구 및 페이지 검사

Mozilla 프로젝트는 이제 Firefox와 함께 이 전설을 이어갔습니다. Firefox는 Mozilla의 장점을 계승했으며 성능, 보안 및 표준 지원 측면에서 준비 수준에 도달했습니다. 그러나 전환점은 시장 점유율이 아니라 페이지 테스트 및 문제 해결에 도움이 되는 내장 도구 덕분에 개발자의 신뢰를 얻었다는 것입니다.

Netscape에서 근무했던 Joe Hewitt 가 작성한 Firebug 확장은 2006년에 출시되었으며 웹 개발자가 페이지를 디버깅하는 데 도움이 되는 브라우저 추가 기능이 점점 더 많이 사용되는 순간을 구축하는 데 도움이 되었습니다. Firebug의 사용은 2007년 Mozilla에 고용된 John Resig가 작성한 유명한 jQuery 라이브러리 의 등장과도 관련이 있습니다.

제품 관리자는 개발자가 페이지를 테스트하고 더 빠르게 제공하기 위해 Firefox를 사용하고 있다는 사실을 인식하지 못했습니다. 시장 점유율 측면에서 기본 브라우저가 Internet Explorer인 경우에도 마찬가지였습니다. 웹 개발자가 사용하는 페이지 구축을 돕는 도구로서의 Firefox는 세계적인 현상이었습니다. Mozilla 기여자인 Clauber와 Mario가 발표한 2008년 프레젠테이션 (Firefox - 개발자의 가장 친한 친구)을 보면 더 잘 이해할 수 있습니다.

주요 슬라이드에서 그들은 웹 표준 지원과 JavaScript 디버깅을 위한 개발 추가 기능으로 인해 Firefox를 개발 프레임워크로 사용하는 것이 중요하다고 언급했습니다.

나머지는 역사입니다 - JS 라이브러리 및 프레임워크

이제 다음 단계에 대해 이야기하는 게 제 정신이 아닌가요?

안 돼요. 웹 개발자라면 발생한 일의 열기와 복잡성을 느낄 수도 있습니다. 브라우저는 진화했고, 페이지도 진화했으며, 개발자도 진화했다는 말로 이 파티를 마무리하겠습니다. 그리고 모든 선수들이 빠른 속도로(너무 빠른 속도로) 똑같이 기여하고 있다고 말하는 것은 제가 과거를 되돌아보고 축하하고 싶을 정도입니다.

몇 가지 메모가 중요합니다. 하나는 서버 측 측면을 언급하지 않았다는 것입니다. 웹 개발자가 프런트엔드, 백엔드 또는 풀스택으로 분기했다는 점은 인정하지만 이러한 반영을 구조와 통합하는 것은 어려울 것입니다.

또 다른 하나는 "개발자의 가장 친한 친구인 Firefox"로 알려진 순간이 웹 페이지와 함께 제공되는 라이브러리의 증가와 동시에 일어났다는 것입니다. 좋은 예는 jQuery 라이브러리입니다. 따라서 "개발자의 가장 친한 친구로서의 jQuery + Firefox" 시대는 실제로 페이지 코드가 복잡해지기 시작하고 더 많은 엔지니어링 역할이 요구되는 현상이었습니다. 페이지의 클라이언트 측에 더 많은 버그가 있었습니다.

이러한 관찰은 React와 같은 라이브러리의 출현과 JavaScript 시대의 위대한 가스라이팅(The Great Gaslighting)이 지적한 복잡한 세계를 고려할 수 있는 문을 열어줄 것입니다.

이 기사의 리드 이미지는 "초기 인터넷 브라우저" 프롬프트를 통해 HackerNoon의AI 이미지 생성기 에 의해 생성되었습니다.