사이트가 실제로 XML 문서로 되어 있기를 바랐는데, 다행히도 정말 XML 문서였음 curl https://xslt.rip/ 명령으로 확인해보면 <html> 태그 안에 “If you're reading this, XSLT was killed by Google.”이라는 문장이 들어 있음
이건 브라우저가 XSLT를 지원하는지 구분하는 영리한 방법임
실제 콘텐츠는 index.xsl에 있고, 제작자는 프론트엔드 디자이너로 dbushell.com이라는 멋진 개인 사이트도 운영 중임
두 사이트 모두 개인적인 감성이 살아 있음
나에게 XSLT는 웹 복잡성을 폭발적으로 늘려서 결국 두 개의 브라우저만 남게 만든 기술처럼 느껴짐
사이트 디자인이 90년대 웹 시절을 떠올리게 해서 묘하게 웃김
텍스트 브라우저(Lynx 등)로 접속하면 그 문장만 보이는데, <noscript>로 “이 사이트는 JavaScript가 필요합니다”라고 뜨는 것과 비슷한 느낌임
이제는 Google이 아닌 브라우저 중 XSLT를 구현한 곳이 남아 있는지 궁금해짐
나는 브라우저에서 XSLT 지원을 없애는 것에 강하게 반대함
개인 사이트에서 JavaScript의 XSLTProcessor와 <?xml-stylesheet …?>를 모두 사용하고 있고, 관련 GitHub 스레드에 의견도 남겼음
하지만 이 사이트는 다소 과장된 표현을 쓰는 것 같음. Google의 보안·유지보수 이유는 진심이라고 생각하지만 방향은 잘못되었다고 봄
이런 페이지는 의사결정자들을 설득하기보다는 오히려 짜증나게 만들 위험이 있음
그런 기능을 쓰는 사람이라면 정말 아주 소수의 엘리트 팀일 것 같음
XSLT 변환을 서버 측에서 하면 최신 도구를 쓸 수 있고, 모든 브라우저에서 동작함
사이트의 과장은 의도된 유머로 보임
웹페이지 하나로 의사결정자를 설득할 수는 없음. 이 페이지의 목적은 단순히 이슈 인식 제고임
libxslt가 거의 유지보수되지 않고 보안 취약점이 많다는 점에서 제거가 타당하다고 봄
만약 XSLT를 살리고 싶다면 Rust로 새 구현체를 만드는 게 최선이었을 것임
나는 소수 의견일지 모르지만, XSLT가 멈춰버린 현실이 안타까움
25년 전 XML+XPath+XSLT 생태계를 대체하려고 수많은 불완전한 라이브러리를 만든 건 인재 낭비였음
SOAP나 XML Schema의 과도함은 인정하지만, JSON의 초기 eval() 방식도 좋은 공학은 아니었음
결국 더 나은 XML 시스템을 만들 수도 있었는데, 새로움에 취해 기존의 장점을 버린 게 아쉬움
좋은 XML 파서는 여전히 거의 없지만, JSON 파서는 많음
Ruby, Python, Java 등에서 XML 파싱은 늘 고통이었고, JSON은 훨씬 단순하고 안정적이었음
JSON 명세는 두 페이지로 끝나지만, XML 명세는 책 한 권임. 이 차이에서 이미 무게감이 다름
예전에 XSLT를 써봤는데 정말 극도로 싫어했음
전담 전문가가 필요할 정도로 복잡했고, 그 자체가 낭비처럼 느껴졌음
그래도 RSS 파일을 브라우저에서 바로 렌더링할 수 있는 등 멋진 활용이 있었음
2010년대의 시맨틱 웹 아이디어가 사라지는 건 아쉬움
나는 XSLT를 거의 쓰지 않지만, Google이 “웹 그 자체”인 양 행동하는 게 짜증남
uBlock Origin을 없애려는 시도도 그렇고, AI 브라우저들이 현실을 왜곡된 형태로 보여주는 것도 싫음
정부나 기업이 중간자 역할을 하며 정보를 통제하는 세상은 원치 않음
Google 검색 품질도 이미 5년 전부터 의도적으로 나빠졌다고 생각함
나도 같은 생각임. XSLT에는 관심 없지만, Google이 HTML을 없애겠다고 하면 누가 막을 수 있을까 하는 피로감이 큼
지금 브라우저 엔진이 사실상 세 개뿐이라는 점이 걱정스러움
Google은 Search, Android, Chrome, AdSense를 분리해야 함
광고 독점, adblock 제거, 앱 설치 제한 등으로 웹 생태계를 장악했음
그래도 이 사이트 디자인은 정말 아름답고, 레트로 감성이 살아 있음
그렇다면 대안 모델은 무엇일까?
Google 내부에서도 “이건 우리가 맡고 싶지 않지만, 다른 누가 할 수 있겠는가”라는 식의 결정이 많았음
OpenGL이 협의체 모델로 실패하고 DirectX에 밀린 사례처럼, 표준의 개방성만으로는 시장을 지키기 어렵다는 교훈이 있음
브라우저 표준도 비슷한 위험을 안고 있음. 결국 누가 목소리를 낼 수 있는가가 중요함
브라우저가 워낙 복잡하니 XSLT 제거 결정에 부분적으로 동의함
개인적으로 XSLT를 써본 적도 없고, RSS와의 연관성도 크지 않다고 느낌
하지만 혹시 모르게 이미 XSLT를 사용하고 있을 수도 있음. 예를 들어 유럽의회 사이트 같은 곳이 그 예임
RSS 피드에 XSLT를 적용하면 브라우저에서 사람이 읽기 쉬운 형태로 보여줄 수 있음 lepture.com의 예시처럼, RSS 리더를 모르는 사용자에게도 도움이 됨
만약 Google이 내일 암을 치료해도 누군가는 “Google이 암을 죽였다”고 할 것 같음
소규모 브라우저 업체가 오래된 XSLT 코드를 유지보수하고 싶어 할 리 없고, 새 브라우저도 추가할 계획이 없을 것임
잘 정리된 결정이라고 생각함
하지만 작은 브라우저들은 원래 필요한 기능만 선택적으로 구현함.
그렇다면 이 결정에 찬성하는 회사가 구체적으로 어디인지 궁금함
“작은 브라우저”라면 대체로 어떤 곳을 말하는지 묻고 싶음
이 사이트는 일종의 로르샤흐 테스트 같음
“Google이 XSLT를 죽였다”는 비판과 “2025년에 XSLT를 밀어붙이는 건 우스꽝스럽다”는 풍자를 동시에 담고 있음
“친구와 가족에게 XSLT를 알려라! 늦기 전에 웹사이트에 추가하라!”는 문구가 그걸 잘 보여줌
명백히 과장을 풍자하는 의도임
하지만 나는 실제로 Atom 피드 때문에 XSLT를 쓰고 있음
정적 사이트에서 RSS를 보기 좋게 렌더링하려면 XSLT가 유일한 방법임
이런 변화는 개인 웹의 자율성을 더 빼앗고, 대형 웹앱 중심으로 몰아가는 흐름임
한 시대의 끝 같음
예전에 XSLT 튜토리얼을 공부하며 XML 문서를 ‘살아 움직이게’ 만드는 게 신기했음
지금도 내 RSS 피드에 스타일을 입히는 데 사용 중임
관련 공지 링크는 Chromium 포럼 글과 Chrome 개발자 문서임
유지보수 부담이 크다는 건 이해하지만, 웹의 작은 즐거움이 또 하나 사라지는 느낌임
Google은 이미 거의 모든 영역을 독점하고 있음
Android 사례(관련 링크)처럼, 이제는 무엇이 허용되고 금지되는지도 Google이 정함
그래서 keepandroidopen.org처럼 keepXSLTAlive.tld 같은 캠페인 사이트를 만들면 좋겠음
혹은 xslt.rip의 UI를 조금 다듬어 저항의 분위기를 살리는 것도 괜찮을 듯함
하지만 Google 비판이 맞다고 해도, 그게 XSLT를 계속 유지해야 할 이유는 아님
기술은 자체의 가치로 평가되어야 함
이 웹페이지 정말 멋짐
갑자기 <iframe>, <blink>, <marquee>, <table> 태그로 90년대식 HTML 페이지를 만들고 싶어짐
Hacker News 의견
사이트가 실제로 XML 문서로 되어 있기를 바랐는데, 다행히도 정말 XML 문서였음
curl https://xslt.rip/명령으로 확인해보면<html>태그 안에 “If you're reading this, XSLT was killed by Google.”이라는 문장이 들어 있음실제 콘텐츠는 index.xsl에 있고, 제작자는 프론트엔드 디자이너로 dbushell.com이라는 멋진 개인 사이트도 운영 중임
두 사이트 모두 개인적인 감성이 살아 있음
사이트 디자인이 90년대 웹 시절을 떠올리게 해서 묘하게 웃김
<noscript>로 “이 사이트는 JavaScript가 필요합니다”라고 뜨는 것과 비슷한 느낌임이제는 Google이 아닌 브라우저 중 XSLT를 구현한 곳이 남아 있는지 궁금해짐
나는 브라우저에서 XSLT 지원을 없애는 것에 강하게 반대함
개인 사이트에서 JavaScript의
XSLTProcessor와<?xml-stylesheet …?>를 모두 사용하고 있고, 관련 GitHub 스레드에 의견도 남겼음하지만 이 사이트는 다소 과장된 표현을 쓰는 것 같음. Google의 보안·유지보수 이유는 진심이라고 생각하지만 방향은 잘못되었다고 봄
이런 페이지는 의사결정자들을 설득하기보다는 오히려 짜증나게 만들 위험이 있음
만약 XSLT를 살리고 싶다면 Rust로 새 구현체를 만드는 게 최선이었을 것임
나는 소수 의견일지 모르지만, XSLT가 멈춰버린 현실이 안타까움
25년 전 XML+XPath+XSLT 생태계를 대체하려고 수많은 불완전한 라이브러리를 만든 건 인재 낭비였음
SOAP나 XML Schema의 과도함은 인정하지만, JSON의 초기
eval()방식도 좋은 공학은 아니었음결국 더 나은 XML 시스템을 만들 수도 있었는데, 새로움에 취해 기존의 장점을 버린 게 아쉬움
Ruby, Python, Java 등에서 XML 파싱은 늘 고통이었고, JSON은 훨씬 단순하고 안정적이었음
전담 전문가가 필요할 정도로 복잡했고, 그 자체가 낭비처럼 느껴졌음
2010년대의 시맨틱 웹 아이디어가 사라지는 건 아쉬움
나는 XSLT를 거의 쓰지 않지만, Google이 “웹 그 자체”인 양 행동하는 게 짜증남
uBlock Origin을 없애려는 시도도 그렇고, AI 브라우저들이 현실을 왜곡된 형태로 보여주는 것도 싫음
정부나 기업이 중간자 역할을 하며 정보를 통제하는 세상은 원치 않음
Google 검색 품질도 이미 5년 전부터 의도적으로 나빠졌다고 생각함
광고 독점, adblock 제거, 앱 설치 제한 등으로 웹 생태계를 장악했음
그래도 이 사이트 디자인은 정말 아름답고, 레트로 감성이 살아 있음
Google 내부에서도 “이건 우리가 맡고 싶지 않지만, 다른 누가 할 수 있겠는가”라는 식의 결정이 많았음
OpenGL이 협의체 모델로 실패하고 DirectX에 밀린 사례처럼, 표준의 개방성만으로는 시장을 지키기 어렵다는 교훈이 있음
브라우저 표준도 비슷한 위험을 안고 있음. 결국 누가 목소리를 낼 수 있는가가 중요함
브라우저가 워낙 복잡하니 XSLT 제거 결정에 부분적으로 동의함
개인적으로 XSLT를 써본 적도 없고, RSS와의 연관성도 크지 않다고 느낌
예시 / 과거 스타일링 설명 / 수동 스타일 적용 예시
lepture.com의 예시처럼, RSS 리더를 모르는 사용자에게도 도움이 됨
만약 Google이 내일 암을 치료해도 누군가는 “Google이 암을 죽였다”고 할 것 같음
소규모 브라우저 업체가 오래된 XSLT 코드를 유지보수하고 싶어 할 리 없고, 새 브라우저도 추가할 계획이 없을 것임
잘 정리된 결정이라고 생각함
그렇다면 이 결정에 찬성하는 회사가 구체적으로 어디인지 궁금함
이 사이트는 일종의 로르샤흐 테스트 같음
“Google이 XSLT를 죽였다”는 비판과 “2025년에 XSLT를 밀어붙이는 건 우스꽝스럽다”는 풍자를 동시에 담고 있음
“친구와 가족에게 XSLT를 알려라! 늦기 전에 웹사이트에 추가하라!”는 문구가 그걸 잘 보여줌
정적 사이트에서 RSS를 보기 좋게 렌더링하려면 XSLT가 유일한 방법임
이런 변화는 개인 웹의 자율성을 더 빼앗고, 대형 웹앱 중심으로 몰아가는 흐름임
한 시대의 끝 같음
예전에 XSLT 튜토리얼을 공부하며 XML 문서를 ‘살아 움직이게’ 만드는 게 신기했음
지금도 내 RSS 피드에 스타일을 입히는 데 사용 중임
관련 공지 링크는 Chromium 포럼 글과 Chrome 개발자 문서임
유지보수 부담이 크다는 건 이해하지만, 웹의 작은 즐거움이 또 하나 사라지는 느낌임
Google은 이미 거의 모든 영역을 독점하고 있음
Android 사례(관련 링크)처럼, 이제는 무엇이 허용되고 금지되는지도 Google이 정함
그래서 keepandroidopen.org처럼 keepXSLTAlive.tld 같은 캠페인 사이트를 만들면 좋겠음
혹은 xslt.rip의 UI를 조금 다듬어 저항의 분위기를 살리는 것도 괜찮을 듯함
기술은 자체의 가치로 평가되어야 함
이 웹페이지 정말 멋짐
갑자기
<iframe>,<blink>,<marquee>,<table>태그로 90년대식 HTML 페이지를 만들고 싶어짐아니, Canvas도 구식이니 WebGPU로 해야겠지