브라우저가 haml과 sass를 지원하지 않는 이유는 무엇입니까?


11

웹 사이트를 다운로드하는 데 필요한 시간이 크게 줄어들고 파싱도 더 쉬울 것이라고 생각합니다.

이러한 언어가 표준으로 적용되지 않는 이유는 무엇입니까? 분명히 그들은 원시 HTML과 CSS보다 낫습니다 ...

브라우저는 우리가 중간 HTML / CSS 코드를 제거하지 못하게하는 유일한 방법입니다.


2
많은 이유가 있지만 이전 버전과의 호환성이 큰 것입니다.
sevenseacat 2016 년

그들은 doctype을 기반으로 HTML과 다른 키워드를 기반으로 haml을 감지 할 수 있습니다.
Alexa


Haml에 익숙하지 않지만 일반적으로 다른 템플릿 엔진에 대해서는 렌더링 된 HTML에 데이터를 삽입하기 위해 서버에서 템플릿을 구문 분석해야합니다. 물론 브라우저가이 작업을 수행하는 것이 쉬워지고 있지만, 곧 사라질 것이라고 생각합니다.
Jeremy Heiler 2016 년

SCSS는 브라우저에 구워 져야한다고 생각합니다. 아마도 그들은 Less와 SCSS 사이에 분명한 승자가 나타나기를 기다리고있을 것입니다.
MSC

답변:


15

고려해야 할 또 다른 사항은 표준 조직의 대역폭이 제한되어 있다는 것입니다. 한 번에 많은 작업 만 수행 할 수 있습니다.

이러한 제약 조건을 감안할 때 웹 개발자 스스로 해결할 수없는 문제 (예 : 새 태그 또는 CSS 애니메이션 추가)를 해결하기 위해 노력하고 있습니다 . SASS와 haml은 CSS / HTML로 컴파일하기가 쉽지 않으므로 기본 브라우저 지원의 이점은 사용자가 너무 쉽게 처리 할 수 ​​없기 때문에 제한적입니다.


9

Sass 또는 CoffeeScript와 같은 전 처리기 언어의 가장 큰 장점은 "표준"언어로 컴파일한다는 사실입니다. 이것이 바로 그 점입니다. 표준 CSS 또는 JS로 작업 할 때 웹 개발자가 이미 처리해야하는 수많은 호환성 문제를 추가하지 않고도 "분명히 더 나은"디자인의 모든 이점을 누릴 수 있습니다. 이전 버전과의 호환성은 웹 개발과 관련하여 큰 문제이며 IE6를 염두에 두어야 할 사람은 누구나 동의 할 것입니다.

HTML / CSS / 자바 스크립트 패키지는 오늘날 부적절하게 느껴질 수있는 요소와 요점을 가지고 있지만, 우리가 구축 할 수있는 최소, 그러나 널리 받아 들여지고 이해되고 구현 된 최소를 제공합니다. Haml / Sass / CoffeeScript는 정확하게 그 기능을 수행하므로 유용합니다. 차라리 Sass-Less-Stylus 표준 전쟁에 참여하는 브라우저 개발자를 다루는 것보다 Sass를 서버 측에 유지하고 싶습니다.


5

"기술적으로 더 나은"및 "사용하기 쉬운"은 표준을 만들기위한 많은 기준 중 두 가지입니다. 다음과 같은 많은 것들이 있습니다 :

  • 기존 표준과의 호환성
  • 기존 구현 (비공식적 인 사실상의 표준)
  • 구현에 필요한 노력
  • 기존 사용자 기반 (따라서 커뮤니티 지원, 숙련 된 인력)
  • 기존 툴체인
  • 플랫폼 지원
  • 관련 표준과 통합

HTML과 CSS가이 기준에 대해 새로 온 사람에 비해 압도적 인 이점이 있다는 데 동의해야합니다.


4

sass하고 haml있는 표준 없습니다 . HTML과 CSS 입니다.

둘 다 표준이되었고 ( 그리고 널리 받아 들여지고 사용된다면), 브라우저 제작자들은 그들에 대한 지원을 추가해야 할 강력한 이유가있을 것입니다.


1
무엇을 표준으로 만드는가? 그 것을 사용하는 사람들의 수. 브라우저가 haml 및 sass에 대한 지원을 추가하면 사용자 수가 증가하고 결국 표준은 w3c에서 공식화됩니다.
Alexa

1
@Alexa - 또는 공식 표준 기관 (또는 산업 컨소시엄) 하게 표준을.
Oded

2
@Alexa : 아니요, 그렇게한다면 <blink> 태그가 공식적으로 만들어 졌을 것입니다.
user16764 2016 년

1
@ user16764이지만 Alexa가 옳다고 생각합니다. HTML5는 브라우저가 이미하고있는 작업의 모음 일뿐입니다. 그들은 단지 좋은 말로 표현했습니다.
Arturo Torres Sánchez

3

Firefox, Chrome, Safari 및 Internet Explorer가 지원 될 때까지 Haml을 사용할 수있는 프로덕션 프로젝트는 없습니다. 예전에는 "엔터프라이즈"응용 프로그램은 IE 만 가능했지만 그 시절은 끝났다고 생각합니다. 표준은 최고 수준에서 부과되지 않으며 브라우저 공급 업체가 동의합니다.

따라서 Haml이 표준을 만들려면 Apple, Google, Mozilla Foundation 및 Microsoft가 동의해야합니다. 이것은 사소한 것이 아닙니다. 이 회사들은 일반적으로 기존 기능을 정리하는 대신 기능 확장에 집중할 것입니다.

Haml은 잘 작동하지만 모든 최신 브라우저와 서버가 압축을 지원하므로 실제로 다운로드 측면을 개선하지는 않습니다. 압축 된 Haml과 Html의 크기는 거의 같습니다. 또한 평균 웹 사이트의 다운로드 시간은 대부분 이미지 및 스크립트 코드 다운로드에 있습니다.

이제 더 이상 소수의 사람들이 HTML로 글을 쓰는 것을 명심하십시오. 사람들은 Html을 최종 제품으로 뱉어내는 프레임 워크를 사용합니다. 이러한 프레임 워크 중 어느 것도 지원하지 않기 때문에 Haml을 직접 채택하는 데 어려움을 겪었을뿐만 아니라 기본 마크 업 언어는 컴퓨터에서만 볼 수 있기 때문에 필요하지 않습니다.

브라우저 공급 업체의 관점에서 기존 페이지 기능을 개선하여 (깨끗한 페이지를 제공하는 Haml과 같은 기능을 지원함으로써) WebGL과 같은 완전히 새로운 기능을 추가 할 수 있습니다. 후자는 단지 더 많은 돈을 벌 수 있습니다.


2

예, html 및 CSS보다 더 시원하고 사용하기 쉽습니다. 그러나 html과 CSS는 오랫동안 존재하고 구축되었으며 웹이나 데스크톱의 많은 응용 프로그램에서이를 사용합니다.

따라서 무언가를 표준으로 만드는 것은 쉽지 않습니다. HAML과 SASS는 사용하기에 정말 재미 있고 깨끗하지만 표준이므로 시간이 오래 걸리거나 전혀 걸리지 않습니다. w3c는 개발자를 돌보므로 실제로 html5와 css3에서 html과 css를 향상시킵니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.