1P by GN⁺ | ★ favorite | 댓글 1개
  • 웹과 커뮤니케이션의 핵심 기술을 여럿 만든 Mozilla가 Firefox·Thunderbird·FirefoxOS·Rust·Servo 같은 자산과 기회를 충분히 살리지 못했다는 비판을 받음
  • Firefox는 여전히 빠르고 효율적인 독립 FOSS 브라우저 엔진을 갖고 있으며, PDF 주석과 로컬 번역처럼 Chrome과 다른 강점이 남아 있음
  • Rust·JavaScript·Thunderbird·KaiOS로 이어지는 기술 유산은 넓지만, Mozilla의 전략은 이를 파워 유저용 제품군으로 묶어내지 못한 상태임
  • 브라우저 시장은 Chromium 계열이 약 4분의 3에 가까운 점유율을 차지하고, Firefox는 Statcounter 기준 3% 미만으로 내려감
  • Firefox와 Thunderbird는 Chrome을 따라가기보다 세로 탭, 트리 탭, 강력한 확장, 멀티프로토콜 메시징을 앞세운 숙련 사용자용 클라이언트로 차별화할 여지가 있음

Firefox가 아직 강한 이유

  • Mozilla는 상업 벤더와 독립된 유일한 전체 FOSS 브라우저 엔진을 보유한 독립 조직임
  • Firefox는 여전히 강력하고 빠르며 리소스 효율적인 브라우저로 평가됨
    • 브라우저 안에서 PDF를 렌더링할 뿐 아니라 수정·주석도 가능함
    • Firefox 118은 개인정보 보호 중심의 로컬 브라우저 내 언어 번역을 제공함
    • 일부 단축키와 탐색 기능은 파워 유저에게 유용할 수 있음
  • 자동차 내 소프트웨어의 개인정보 보호 문제를 다룬 보고서처럼 Mozilla의 보안 연구도 여전히 중요한 역할을 함

Rust와 JavaScript로 남은 언어 유산

  • Mozilla는 Rust와 JavaScript라는 두 프로그래밍 언어의 역사와 연결돼 있음
  • Rust는 Mozilla가 만든 언어이며, 주요 운영체제 전반으로 확산되고 있음
    • 팬데믹 6개월 시점에 Mozilla는 Rust 팀 전체를 해고했고, 차세대 렌더링 엔진 Servo도 중단됨
    • Rust와 Servo는 이후 각각 재단과 새 거처를 찾음
  • Netscape는 1995년 Netscape 2.0과 함께 JavaScript를 도입함
    • 당시 발표에서는 개발자에게 “관심이 있을 수 있다”고 했지만, JavaScript는 이후 웹 핵심 기술이 됨

Thunderbird가 보여주는 통합 클라이언트 가능성

  • Mozilla는 크로스플랫폼 메시징 클라이언트 Thunderbird 개발을 지원함
  • 오랫동안 방치된 시기가 있었지만, 개발자들은 기능 통합을 계속 이어감
    • 2015년 Thunderbird 38은 Lightning 애드온에서 온 캘린더 기능을 통합함
    • 2017년 Thunderbird 51은 Instantbird에서 온 IRC·XMPP 채팅 지원을 추가함
    • 2020년 Thunderbird 78은 EnigMail 애드온을 대체하는 PGP 이메일 암호화를 통합함
    • 2022년 Thunderbird 102는 Matrix 채팅을 지원함
    • 2023년 Thunderbird 115는 Supernova로 불렸던 개편 UI를 적용함
  • Android 버전 Thunderbird도 준비 중임
  • Pidgin과 libPurple는 Slack, WhatsApp, Telegram, RocketChat, Signal, Mattermost 등에 연결하는 플러그인을 갖고 있음
    • Thunderbird가 이를 채택·갱신해 Chat Core에 더하면, 여러 서비스를 한곳에서 다루는 범용 커뮤니케이션 클라이언트가 될 수 있음

FirefoxOS와 KaiOS로 남은 모바일 기회

  • Mozilla는 모바일 OS Boot2Gecko를 만들었고 FirefoxOS라는 이름으로 제공했으나, 2016년에 공식 중단함
  • FirefoxOS는 이후 KaiOS라는 이름으로 재출발함
    • KaiOS는 2018년 Google 투자를 받음
    • KaiOS 소유자는 여전히 1억 6천만 대 기기를 주장함
    • Finnfund는 사하라 이남 아프리카 확장을 돕기 위해 KaiosTech에 340만 달러를 투자함
    • GitHub의 KaiOS 코드에는 여전히 Mozilla 상표가 남아 있음
  • 이 프로젝트는 postmarketOS와 경쟁하거나 합쳐질 수 있는 유명 FOSS 프로젝트가 되지 못했고, Mozilla도 이를 적극적으로 되찾지 않고 있음

Netscape 계열에 남은 다른 기술들

  • 원래 “Mozilla”는 Netscape Communicator에서 나온 인터넷 도구 모음이었음
    • 브라우저
    • 이메일과 USENET을 포함한 메시징 클라이언트
    • 캘린더
    • 주소록
    • Collabra에서 인수한 워크플로
    • HTML 편집기
  • 이 통합 제품군은 현재 Seamonkey Project 형태로 남아 있음
  • HTML 편집기는 동적 웹 콘텐츠 확산으로 덜 보이게 됐지만, Mozilla 코드 기반의 BlueGriffon이 대표적인 FOSS HTML 편집기로 남아 있음
  • Mozilla 계열에는 한때 음악 플레이어 Songbird도 있었음
    • 여러 회사가 자체 클라이언트 없이 스트리밍하기 어렵게 만드는 상황에서는 이런 영역에도 여지가 있을 수 있음
  • Netscape Directory Server에서 유래한 LDAP 서버 코드는 현재 389 Directory Server로 이어짐
    • Red Hat은 관련 제품을 Red Hat Directory Server로 판매함
    • Oracle도 오래된 Netscape Enterprise Server를 아직 지원함

Chromium 중심으로 굳어진 웹 엔진 시장

  • 현대 웹은 단순 HTML 페이지가 아니라, 클라이언트와 서버 양쪽에서 실행되는 프로그램에 가까움
  • Slack과 Teams처럼 로컬 앱처럼 보이는 서비스도 자체 단일 사이트 브라우저 안에서 실행되는 JavaScript 애플릿이며, Google의 브라우저 엔진을 사용함
  • 스마트폰의 70% 이상은 Linux 기반 Android이고, 브라우저도 Google 코드 기반이 70% 이상임
    • Chrome은 약 64%
    • Edge는 5.4%
    • Opera와 Samsung Browser는 합쳐 약 5%
    • Vivaldi와 Brave도 Chromium 기반임
  • Safari는 Chromium이 아닌 브라우저 중 가장 큰 점유율을 갖고 있지만 20% 미만임
    • Safari의 WebKit은 Chromium의 Blink 엔진의 기원임
    • Safari는 거의 Apple OS에 한정됨
    • Linux에서는 GNOME Web, 코드명 Epiphany가 WebKit 브라우저로 언급됨
  • Firefox는 Statcounter 추정 기준 3% 미만으로 내려감

Chrome을 따라가는 전략의 한계

  • Firefox는 Linux에서 지배적인 브라우저이며, Ubuntu Mantic Minotaur에서는 기본적으로 유일한 독립형 앱으로 언급됨
  • Linux 사용자는 대체로 파워 유저에 가깝기 때문에, Firefox가 이 층을 겨냥할 여지가 있음
  • Chrome을 흉내 내는 방식은 Mozilla에 성공 전략이 되기 어려움
    • Firefox 29의 Australis Chrome 유사 테마는 사용자 불만을 낳았고 Pale Moon의 동력이 됨
    • Firefox Quantum은 XUL 애드온을 없앴고, 일부 사용자는 Waterfox Classic이나 Basilisk로 이동함
    • Windows XP 사용자는 MyPal을 사용함
  • Microsoft의 Chromium 기반 Edge도 세로 탭을 제공하지만, Firefox는 기본 세로 탭이 없음
    • Firefox에서 제대로 된 세로 탭을 쓰려면 설정 파일을 만져야 함
  • Vivaldi는 Chrome보다 기능을 더 많이 제공하는 브라우저에도 시장이 있음을 보여줌

파워 유저용 Firefox와 Thunderbird라는 선택지

  • Firefox는 Chrome을 따라가기보다 파워 유저용 브라우저라는 방향을 더 강하게 택할 수 있음
  • Firefox가 차별화할 수 있는 기능은 다음과 같음
    • 살아남은 강력한 확장 기능의 번들 제공
    • 세로 탭 또는 트리 구조 탭을 어느 화면 가장자리에서든 지원
    • 메뉴 바와 단축키 강화
    • 멀티스레드 다운로드 통합
    • BitTorrent 지원 실험
    • Firefox Developer Edition에서 실험적 기능 제공
    • 과거 Firefox가 갖고 있던 사용자 맞춤성 복원
  • Thunderbird는 여러 서비스와 연결되는 범용 커뮤니케이션 클라이언트가 될 수 있음
    • libPurple를 채택·갱신하고 Thunderbird Chat Core에 통합하면 개선 여지가 큼
  • Chrome과 그 파생 브라우저는 일반 사용자에게 맡기고, Mozilla는 키보드 중심의 숙련 사용자를 위한 크로스플랫폼 도구를 만들 수 있음

댓글과 토론

Hacker News 의견들
  • 현대의 웹 표준이 사실상 Chrome 기능 집합의 동의어가 된 상황에서 Mozilla의 역할은 하나뿐이라고 봄: Google이 브라우저 독점이 아닌 척할 수 있게 Weekend at Bernie's처럼 들고 다니는 존재임
    iOS에 다른 엔진이 등장하면 몇 년 안에 웹사이트들이 비 Chrome 브라우저를 막기 시작할 것이고, 일부 스킨 브라우저도 함께 막힐 가능성이 큼. 그러면 Mozilla는 명분용 가림막으로도 쓸모가 없어질 듯함. 끔찍한 상황이고, Mozilla가 빠져나갈 길은 잘 안 보임

    • Firefox가 Chrome의 완전한 브라우저 지배를 막고 있다고 생각한다면 시대에 뒤처진 것임
      그 자리는 오래전부터 iPhone의 Safari가 차지했음. Firefox는 데스크톱 브라우저로는 가장 좋아하지만, 브라우저 시장에서 데스크톱은 핵심이 아님. 기기 전체 기준으로는 Edge조차 Firefox보다 사용률이 높음
      https://gs.statcounter.com/browser-market-share
    • 그 변명은 몇 년 동안 통했지만, 이제 Firefox 점유율이 무의미한 수준까지 줄어든 뒤에는 더 이상 설득력이 없음
      가능한 모든 통계를 보면 Chrome은 Apple의 울타리 밖, 즉 최근에야 현실적인 선택지가 된 Apple 생태계를 제외한 “자유 시장”에서 80% 이상을 차지함
    • Safari의 시장 점유율은 오래전부터 Firefox를 압도함. 정말 그런 명분용 가림막이 있다면 Mozilla가 아니라 Apple임
    • 독일에서는 다행히 Firefox가 아직 전체 시장의 10% 이상, 데스크톱에서는 거의 20%를 차지함
    • 비 Chrome 브라우저 차단이 시작돼도, 브라우저 확장 기능으로 Firefox가 원하는 브라우저인 척하게 만드는 건 꽤 쉬움
  • 인용문 중 “Mozilla가 Rust 팀을 해고해 Servo를 죽였고, Rust가 Google의 Go보다 빛나서 그랬던 것 아니냐”는 대목은 편집 단계에서 걸러졌어야 할 정말 어리석은 곁가지임. 특히 “GoLang” 표기까지 이상함
    Thunderbird에 대한 Mozilla의 관여도도 과장됐음. 지금 관계는 사실상 의례적인 수준임. 또 1998년에 AOL이 오픈소스를 약속했고 4년 뒤 오픈소스 버전이 나왔다는 식의 서술은 약속 이행이 지연된 것처럼 보이게 함. 실제로 Netscape는 2개월 만에 소스 코드를 공개했고, 이후 4년은 오래된 코드를 버리고 다른 제품군의 1.0 출시로 이어진 재작성을 결정하는 데 걸린 시간임

    • GoLang 대목을 보고 계속 읽기 어려웠음. 정말 말도 안 되는 암시임
      Mozilla가 고급 사용자층에 더 집중해야 한다는 데는 어느 정도 동의하지만, 이 글은 현대 Mozilla 조직의 실제 초점과 가야 할 방향을 조사했다기보다 저 effort 잡담에 가까워 보임
    • “Golang”은 한때 Google이 승인하던 Go의 동의어였고, 공식 도메인도 한동안 golang.org였음
    • 글쓴이임. 그 곁가지는 100% 의도적이었고, Mozilla가 Google과 더 공격적으로 경쟁하지 않는 이유로 그런 주장이 HN 등에서 자주 나오는 걸 봤기 때문에 넣었음
      그 주장을 1분도 믿지 않기 때문에 일부러 “surely not”이라고 썼음. “golang”은 공식 명칭 중 하나이고, 그냥 “go”는 오해하기 쉽고 검색하기 어렵기 때문임. 대문자는 강조였고, 중간 대문자 표기는 스크린 리더 사용자에게도 도움이 됨. Thunderbird와 Mozilla 관계가 의례적이라는 주장에는 근거가 필요함. Netscape의 오픈소스 약속 이행에는 지연이 있었고, 4년 뒤 재작성 제품군의 1.0이 나왔다는 세부는 논점과는 부차적임. 오픈소스 결정과 Netscape 5 재작성을 같은 시점에 한 건 매우 어리석었지만 이해는 됨. 25년 전 일이니 한 줄로 지나갈 만한 내용이지, 이렇게 머리카락을 쪼갤 수준은 아니라고 봄
    • Thunderbird는 Mozilla Foundation이 완전히 소유한 회사가 유지보수함. 그게 어떻게 “의례적”이라는 건지 모르겠음
  • Rust를 쓰던 Servo 팀 전체를 해고하고, 이어 문서팀 대부분인 MDN을 줄인 뒤 CEO에게 연봉 인상을 준 게 시작이었음

    • 그 CEO를 정말 싫어함. 해당 직책을 채우는 데 이전 경험이나 능력이 주요 기준이 아니었던 또 하나의 예임
    • Baker는 그보다 훨씬 오래전부터 재앙이었지만, 그 사건은 “나는 이 자리에 전혀 적합하지 않다”는 가장 큰 신호 중 하나였음
    • 진짜 시작은 Brendan Eich를 내쫓았을 때였음
    • 그건 몰랐음. 휴대폰에서는 Firefox를 쓰지만, 데스크톱에서는 Firefox보다 MDN을 더 많이 씀
  • Mozilla가 2010년대 초반의 궤적을 계속 갔더라면 좋았을 것 같음
    Brendan Eich가 있을 때는 목적과 정체성이 분명해 보였음. Rust가 될 것의 탄생, PDF 다운로드가 일반적이던 시절의 PDF.js, Firefox OS, Google이 밀던 NaCl을 밀어낸 WebAssembly의 전신 asm.js 등 흥미로운 일이 많았음. 이후 어쩌다 길을 잃었는지는 모르겠음

    • Brave를 비판할 수는 있지만, Eich의 다음 브라우저 사업인 Brave는 실제로 꽤 대단한 일을 하고 있음
      Tor 통합만 해도 상당히 급진적인 개인정보 보호 기능이고, “암호화폐잖아”라고 할 수는 있어도 적어도 Google과 독립적으로 돈 버는 방법을 찾으려 함. Mozilla와 달리 Brave는 광고 없는 수익화 가능한 웹을 만들려고 시도하고, Mozilla는 말 그대로 현 상태에 모든 매출을 의존함
    • Firefox의 추락은 Mozilla 리더십보다 브라우저 선택 화면 규제 종료와 Google의 점점 공격적인 Chrome 광고 영향이 더 큼
      Google이 Chrome 개발과 마케팅에 쏟아부은 수십억 달러에 맞설 수 있는 곳은 없음. Google은 현대 웹의 문지기이고, Apple조차 관련성을 유지하려고 애씀
    • Firefox OS가 Mozilla가 포기한 뒤 성공했다는 데, 관련 링크를 줄 수 있음?
  • Mozilla 매출의 90%가 Google/Alphabet에서 나온다는 건 느슨하게 말해 “Mitchell Baker의 급여 90%는 Google이 낸다”, “Mitchell Baker는 간접적으로 Google을 위해 일한다”는 뜻임
    Mozilla는 “이상한 이웃”이 아니라 통제된 반대편이고, 이 불건전한 관계를 깨거나 Google의 발을 밟으면 CEO 보수도 타격을 받을 것임. Mozilla 개발자와 사용자 다수가 친 Google 성향은 아니겠지만, 여기서 중요한 건 관점이 아니라 현금임

    • 이건 전혀 설득력이 없음. Google은 Mozilla를 통제하지 않음
      Google보다 더 많이 내고 싶어 할 회사들이 있고, 실제로 몇 년간 Yahoo가 그랬음. Mozilla는 여러 방식으로 계속 Google의 발을 밟고 있으며, 그게 Mitchell Baker의 보수에 악영향을 준다는 신호는 전혀 없음. 현재 Mozilla 매출에서 Google 비중도 90%보다 상당히 낮을 것 같지만, 그건 논점과 별개임
  • 브라우저에서 가장 중요한 건 사용자 맞춤 설정이 가능하다는 점이라서, 그게 제한되면 매우 짜증남. 최근 Firefox 업데이트에서 그런 일이 생겼음
    Firefox가 업데이트된 뒤 브라우저 시작 직후에는 더 이상 bookmarklet을 실행할 수 없게 됨. javascript:alert(123) 같은 bookmarklet은 모든 페이지, 심지어 about:blank에서도 잘 작동하지만 설정의 “빈 페이지”로 시작한 직후에는 안 됨. 보통 탐색 세션의 첫 단계로 “TekMol이 B 페이지나 C 페이지에 없으면 A 페이지로 보내라”는 bookmarklet을 쓰고, A에서 시작해 다시 눌러 B로, 또 눌러 C로 가는 흐름을 쓰는데 지금은 깨졌음. 최신 Firefox의 회귀 버그 같음

    • 지금까지 본 것 중 가장 특이한 작업 흐름 중 하나임. “소프트웨어가 명시적이든 암묵적이든 뭔가를 지원하면 누군가는 거기에 의존한다”는 문장이 떠오름
      bookmarklet의 JavaScript로 웹사이트를 순환하는 건 예상 밖이지만, 고쳐지면 좋겠음. 이미 티켓이 없다면 새로 올려보는 게 좋겠음
    • “홈페이지와 새 창” 설정을 “빈 페이지”에서 “사용자 지정 URL”로 바꾸고 about:newtab으로 설정한 뒤, “새 탭”은 “빈 페이지”로 바꾸면 우회할 수 있을 것 같음
    • 이 경우에 도움이 될지는 모르겠지만, 나도 bookmark에 javascript:를 더 이상 못 쓰는 그 “개선”에 당했고, 관련 JavaScript를 감싼 data: URL로 우회할 수 있었음
      <https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...>
    • 내가 Firefox에 남아 있는 유일한 이유는 여러 줄 탭 때문임. 오래전 Firefox 플러그인으로 익숙해진 작업 흐름이고, 지금은 CSS로 브라우저를 사용자 지정해서 구현할 수 있음
      다만 Firefox가 대략 10개 버전쯤 오를 때마다 이게 깨져서 다시 해결책을 찾아야 함
    • NYXT를 시도해볼 생각은 해봤음?
  • Rust와 Go를 비교하는 저 주장은 이해가 안 되고, 특히 둘은 목적이 완전히 다름. Rust는 시스템 프로그래밍, Go는 클라우드 서버 쪽에 가깝기 때문임

    • 맞음. 언어 이름을 잘못 표기한 것도 글쓴이가 Go에 익숙하지 않다는 꽤 분명한 신호임
      Go가 Rust와 매우 다른 용도로 쓰인다는 점도 이해하지 못한 듯함. 그래서 Servo가 중단된 이유를 그쪽으로 제안하는 건 매우 기괴해 보임
    • 실제로는 둘이 많이 겹침. 사람들이 왜 아니라고 하는지 잘 이해가 안 됨
      시스템 프로그래밍, 즉 많은 시스템 호출을 다루는 일을 많이 해봤는데 Go로도 충분히 잘됨. 하드 실시간 시스템 같은 걸 만드는 게 아니라면 Go를 배제할 이유를 모르겠음
    • 무료 언어들 사이에는 사업 경쟁도 없음. Google을 포함한 모든 대기업은 Rust를 바라보고 있고 성공하길 원함
      Rust가 Go를 “위협한다”는 말은 의미가 애매함. Google이 Go에 대한 외부 기여에 의존하는 것도 아님
    • 인용된 문장만 봐도 글의 나머지를 읽을 가치가 없겠다는 신호가 너무 많았음
  • 몇 년 전 Mozilla HQ를 방문했는데, 장소도 사람들도 좋았지만 조직이 정체성 위기와 관성에 동시에 시달린다는 느낌이 강했음
    Baker는 운영자로서는 훌륭하고 Mozilla는 여전히 탄탄한 수입을 올리지만, Mozilla가 기존의 여유에 기대 살기보다 새롭고 확장된 의미로 진화하려면 외향적이고 선제적인 기술 비전가 유형이 절실히 필요했거나 지금도 필요하다고 봄. 공정하게 말하면 Baker도 Mozilla의 계속되는 미션에 대해 블로그에 썼음
    https://blog.lizardwrangler.com/2023/03/31/a-quarter-century...
    그래도 시장 점유율을 키우고 진화하려면 더 적극적이고 공개적인 접근이 필요해 보임

    • 300만 달러로는 부족하다고 믿는 사람에게 왜 공정해야 하는지 모르겠음
      본인의 무능 때문에 실제로 일을 만들어내는 많은 사람들을 해고하게 된 뒤, 추가로 200만 달러가 더 필요하다고 결정한 사람임
  • Chrome이 Firefox를 그렇게 이긴 이유에 대한 표준적인 답이 하나나 몇 개쯤 있는지 궁금함
    Chrome은 Firefox 탭 하나가 브라우저 전체를 먹통으로 만들던 시절에 탭별 샌드박싱을 했던 것으로 기억하지만, 그게 평균 사용자에게 엄청난 차이를 만들었을지는 의외임. Firefox가 기억보다 훨씬 자주 충돌했거나, Chrome이 출시 당시 훨씬 빨랐을 수도 있음. 나는 Firefox UI를 최소화하고 Vim처럼 만들어주던 확장 Pentadactyl 때문에 2016년쯤까지 Firefox를 썼고, 그걸 유지하려고 LTS Firefox를 실행했던 것 같음. 그립다. 뉴욕에 있어서 그런지 주변에 올해 Arc로 옮긴 사람이 많고, 어디까지 갈지 기대됨
    [1] https://en.wikipedia.org/wiki/Pentadactyl

    • 답의 일부는 Chrome이 나올 당시 Google이 기술자들에게 얼마나 큰 호감을 얻고 있었는지 지금 사람들이 잊고 있다는 것임
      오픈소스였고, Google 없이도 쉽게 실행할 수 있었고, 웹 표준을 따르지 않거나 자체 표준을 만들던 Internet Explorer에 맞서는 거인이었음. 그리고 정말 좋았음. 기술자들이 지금처럼 Google과 Chrome을 보게 되기까지는 몇 년이 걸렸음. Chrome 출시 당시 가장 많은 표를 받은 HN 글은 이것임
      https://news.ycombinator.com/item?id=291946
    • 처음에는 내게 Firefox보다 훨씬 빨랐던 것으로 기억함. UI도 훨씬 보기 좋았고, 당시에는 아주 매끈했음
      그때는 전환이 꽤 쉽고 당연하게 느껴졌음
    • 세계에서 가장 많이 방문되는 사이트인 Google 홈페이지에 Chrome 설치를 권하는 광고 자리가 있었음
      검색 결과 페이지가 아니라, 입력창 하나만 있는 그 빈 흰색 홈페이지였음. 참고로 그 자리는 Google 제품이 아닌 것에는 한 번도 제공된 적이 없음
    • Firefox로 Google 서비스를 방문할 때마다 “웹은 Chrome에서 더 좋다” 같은 배너와 다운로드 버튼이 떴음
      내가 Firefox를 설정해준 모든 사람, 부모님이나 비기술자 친구들은 결국 Chrome으로 바꿨음. 물어보면 “Google이 더 낫다고 해서”라고 답했음
    • 다른 이들이 말한 실제 장점에 더해, Google은 Java 업데이트나 SourceForge 다운로드 같은 것에 Chrome 번들을 넣도록 돈을 냈던 것으로 기억함
      일반 사용자를 움직이는 데는 실제 이점만큼이나 이런 방식이 큰 영향을 줬을 것 같음
  • 사람들이 XUL/XPCOM의 상실을 아쉬워하는 이유는 이해하지만, 그걸 Chrome을 흉내 내기 위한 것처럼 말하는 건 정직하지 않아 보임
    그 기술들을 제거하면서 다중 프로세스 Firefox가 가능해졌고 안정성이 강화됐음. 여기와 다른 곳의 댓글을 보면 오히려 그 변화가 사람들을 브라우저로 다시 돌아오게 만든 요인 중 하나였음. WebExtensions를 도입하거나 시작한 것도 말이 됐다고 봄. Chrome이 이미 너무 큰 인지도를 갖고 있어서 완전히 새로운 걸 내놓기 어려웠기 때문임

    • 100% 고통스럽고 짜증났지만, 동시에 100% 기술적으로 타당한 이유로 한 일이었음
      Chromium의 텍스트 선택 방식이 이상하고 둔하고 다른 어디에서도 못 본 방식이라서, 항상 Firefox나 그 이전에는 Opera Presto를 선호했음. 이건 Electron 앱을 알아보는 방법이기도 함. 하지만 Firefox는 정말 느렸고, XUL에서 벗어나는 건 그걸 고치는 중요한 단계였음. 다만 Firefox가 “X가 더 인기 있고, X가 Y를 하니 우리도 Y를 해야 한다”는 함정에 빠졌다고 느끼긴 함. 현재 사용자층이 있는 이유가 바로 Y가 아니라 Z를 하기 때문이라는 점을 잊은 듯함. 하지만 그건 별개의 문제임
    • 완전히 동의함. 예전에는 사람들이 Firefox가 느리다고 한탄했음
      내 경우에도 동기식 확장 API 때문에 몇 초씩 멈출 때가 있었음. XPCOM 제거, 다중 프로세스 전환, 비동기 WebExtensions 전환은 기술적으로 절대적으로 필요했음. 지금은 성능이 좋음
    • 아님. Firefox 48은 이미 다중 프로세스를 지원했음
      Mozilla는 WebExtensions 개발이 시작된 뒤 개발자들에게 XUL 확장을 다중 프로세스와 호환되게 만들라고 요구했음. Firefox 57에서 XUL 확장을 비활성화했고, XUL은 그 뒤에 점진적으로 제거했음
    • 글쓴이임. XUL/XPCOM 제거가 Chrome을 흉내 내기 위한 것이라고 말한 적 없음
      암시조차 하지 않았고, 이 댓글을 읽고 눈썹이 모자를 들어 올릴 정도로 올라갔음. 그런 생각은 들어본 적도 없음. 내가 어디에서 XUL 제거가 Chrome을 흉내 내기 위한 것이라고 썼는지 짚어줬으면 함