왜 XSLT가 웹에서 그렇게 자주 사용되지 않습니까? [닫은]

XSLT는 성숙하고 널리 인정되는 표준입니다.

브라우저 (구 IE에서도) 및 서버 측에서 사용할 수 있습니다 (nginx에는 XSLT 모듈이 있으며 물론 프로그래밍 언어에서 사용할 수 있습니다). 구현이 컴파일되었으므로 Python 또는 JS보다 훨씬 빠릅니다. JS 구현 Saxon JS는 적어도 폴백으로 사용될 수 있습니다. Jinja, Angular, Ruby 's Slim, ASP 및 PHP 템플릿은 그리 가깝지 않습니다.

IDE에서 XSL 템플릿을 쉽게 확인할 수 있습니다. Jinja 또는 Angular에 몇 개의 IDE가 도움이 될 수 있습니까?

XSLT를 사용하여 UI와 데이터를 분해하는 것이 완벽한 아이디어 인 것 같습니다.

분명히 구현은 일부 경우에 다른 결과를 줄 수 있지만 클라이언트 측에서 템플릿을 만드는 경우에만 문제가됩니다. 또한 HTML, CSS 및 클라이언트 측에서 수행되는 다른 모든 항목과 동일합니다.

그렇다면 왜 XSLT가 아닌가?

XSLT는 최신 대화식 웹에서 실제로 유용한 역할을하지 않습니다. XSLT의 목적은 한 XML 언어에서 다른 XML 언어로 변환하는 것입니다. 그러나 실제로는 처음부터 그렇게 할 필요가 없습니다. 기술이 해결하도록 설계된 문제가 없다면 기술이 얼마나 강력하고 빠르고 잘 지원되는지는 중요하지 않습니다.

XSLT 사용 사례가 사라진 몇 가지 이유가 있습니다.

• HTML이 이겼습니다. XSLT는 일부 의미 적 마크 업 형식의 "풍부한 텍스트"컨텐츠를 HTML로 변환하는 데 유용해야했습니다. 그러나 HTML 자체는 완벽하게 훌륭한 형식이므로 처음에는 콘텐츠에 사용하고 변환을 건너 뛰지 않겠습니까?
• CSS가 훨씬 강력 해졌습니다. XSLT의 약속 중 하나는 소스 마크 업을 깨끗하고 시맨틱하게 유지 한 다음이를 "프레젠테이션 HTML"로 변환하여 브라우저간에 작동하며 요소 등을 재배치 할 수 있다는 것입니다. 그러나 요즘에는 프리젠 테이션 HTML이 필요하지 않습니다. 시맨틱 HTML을 사용하면 CSS가 필요한 스타일과 레이아웃을 수행 할 수 있습니다.
• XML은 유비쿼터스 형식의 데이터가되지 못했습니다. 데이터베이스에서 SQL 데이터를 가져올 때는 먼저 XML로 변환 한 다음 XSLT를 통해 변환하는 것보다 템플릿으로 직접 병합하는 것이 훨씬 간단합니다. 그리고 JSON은 클라이언트 측의 구조화 된 데이터를 위해 XML을 거의 대체하지 않았습니다.
• XSLT는 한 번에 전체 문서를 변환하도록 설계되었습니다. 그러나 최신 대화 형 웹 페이지에서는 작은 조각의 데이터가 항상 조금씩 다운로드되어 페이지에 병합됩니다.
• 데이터는 그렇게 복잡하지 않습니다. 대부분의 사용 사례에서 자리 표시 자와 리피터가있는 간단한 템플릿 형식으로 작업을 올바르게 해결합니다. XSLT는 훨씬 강력하지만 추가 전력이 거의 필요하지 않으며 복잡성과 추악한 비용이 엄청납니다.

XSLT는 하나의 구조화 된 소스 형식에서 인쇄, PDF 및 정적 웹 페이지와 같은 여러 게시 형식으로 단방향 프로세스를 수행 할 수있는 게시에서 나왔습니다. 대부분의 웹 사이트는이 사용 사례에 맞지 않습니다.

"웹에서"의 의미에 따라 다릅니다.

XSLT는 매우 널리 사용됩니다. StackOverflow 질문의 수와 같은 메트릭에서 판단 할 수있는 한, 상위 30 개 프로그래밍 언어로되어 있으며, 이는 아마도 SQL 이후의 최상위 데이터 모델 별 프로그래밍 언어가 될 것입니다.

그러나 XSLT는 클라이언트 측, 즉 브라우저에서 널리 사용되지 않습니다. 일반적으로 HTTP 요청에 대한 응답으로 요청시 콘텐츠를 제공하기 위해 서버 측에서 사용되거나 게시 워크 플로의 일부로 배치 모드에서 사용됩니다. 물론 웹과 관련이 거의없는 많은 응용 프로그램 (예 : 인쇄 출판)에서도 사용됩니다.

XSLT가 브라우저에서 광범위하게 사용되지 않는 데는 여러 가지 이유가 있습니다. 주된 이유는 적합한 XSLT 지원이 브라우저 공급 업체로부터 매우 느리게 이루어 졌기 때문입니다. 모든 브라우저에서 사용 가능할 때까지 아무도 사용하지 않았으며, 모든 브라우저에서 사용 가능할 때까지 사람들이 브라우저에서 수행하고자하는 작업 ( "Web 2.0"기억) 및 XSLT 구현은 이전되었습니다. 브라우저에서 AJAX를 사용하여 대화식 응용 프로그램을 작성하거나 데이터를 가져 오는 데 도움이되지 않았습니다.

Saxonica (면책 조항,이 제품은 내 제품 임)는 Saxon-JS와의 차이를 막으려 고 시도했지만 제품은 파티의 후발 업체이며 클라이언트 측 웹 개발은 패션 중심적이므로 충분하지 않습니다. 모든 기술 상자를 체크하는 제품. 패션 중심의 일부는 대부분의 데이터 지향 사이트 (문서 지향 사이트와 구별됨)가 XML이 아닌 JSON으로 이동 한 것입니다. JSON은 Javascript에서 훨씬 쉽게 조작 할 수 있기 때문입니다.

또 다른 문제는 XSLT가 사랑이나 싫어하는 언어라는 것입니다. 선언적이고 규칙에 기초한 기능 중심의 패러다임은 높은 수준의 특성으로 인해 많은 사람들에게 호소하지만 프로그래밍 경험 만있는 사람에게는 컴퓨터에 정확히 무엇을해야하고 수행해야하는지 지시하는 명령형 코드를 작성하는 것 외에는 소외 될 수 있습니다 어떤 순서.

이 질문에 대답하고 주로 의견 기반으로 닫는 것 사이에서 앞뒤로 움직입니다. 자, 여기 내 플립이 있습니다 :

간단히 말해서, XML은 엉터리 프로그래밍 언어를 만들기 때문입니다. XSLT 의 의미 는 있지만 훨씬 더 좋은 구문 은 완전히 다른 문제라고 생각합니다. 예를 들어 정말 멋진 Lisp 기반 XML 변환 언어가 있습니다.

XSLT는 트리 재 작성 언어, 기능적 언어 또는 절차 적 언어 중 어느 것을 원하는지 결정할 수 없습니다. 그것은 그들 모두의 기능을 가지고 있지만, 실제로는 그다지 좋지 않습니다. 세 가지 측면 중 어느 쪽이든 더 나은 언어가 있습니다.

XML 자체는 99.9 %의 사례에서 이전 버전과 호환되지 않는 정크처럼 보입니다.

XML이 즉시 우수한 대체 기능을 갖지 않는 유일한 유스 케이스는 docx 또는 odf와 같은 것이며 SGML이 더 나을 수도 있습니다 *. 즉, 큰 변형이 적용되어 화면과 프린터에 올바르게 표시 될 수 있도록 모든 종류의 사물이 서로 중첩되어있는 매우 풍부한 문서 구조를 가지고 있습니다.

거의 항상 XML은 구조화 된 데이터를 전달하는 데 사용되며 XSLT는 구조화 된 문서 데이터를 문서 데이터로 변환하도록 설계된 것으로 보입니다. 그 유스 케이스가 죽어 가고 있습니다. JSON은 구조화 된 데이터에 대해 XML보다 직접적으로 우수합니다. ** 마크 다운과 YAML은 간단한 형식의 데이터보다 우수합니다. XML의 초기 합병은 Java 및 Javacript의 기본 제공 파서였습니다. JSON은 JSON 소스가 신뢰할 수있는 경우 (어린 시절 대부분)에 내장 파서를 활용하여 이러한 장벽을 무너 뜨 렸습니다.

그리고 세상이 바뀌 었습니다. 내장 라이브러리 장점은 이제 사소한 장점입니다. XHTML은 완전히 거부되었고 그 대체물은 그것으로부터가 아니라 전임자로부터 물려 받았습니다.

XML은 이제 그것을 받기 원하는 사람과 직접 대화하는 데 사용되며 원하는 형식으로 전체 천으로 생성되거나 반대로 전송 된 형식에서 직접 개체 모델을 읽고 파싱합니다. 더 이상 스토리지 형식 또는 범용 교환 형식의 경우 더 이상 스키마에서 스키마로 변환 할 필요가 없습니다.

* 그들은 대학에서 SGML이 구현되지 않았다고 가르쳤다. 그들은 거짓말했다.

** JSON에서 잘못된 숫자 형식에 대한 불만을 들었습니다. 반면 XML에는 숫자 형식이 없으므로 문자열의 모든 데이터 유형을 채우는 것만으로도 XML에 비해 유리합니다.