현재 유일하게 완전히 지원되는 언어이며 브라우저에서 DOM 트리 조작을위한 사실상의 표준은 JavaScript입니다. 초심자에게는 버그와 보안 허점으로 만드는 심각한 디자인 문제가있는 것 같습니다.
차세대 브라우저에서 DOM 트리 조작 및 HTTP 요청에 대해 더 나은 (재 설계된) 언어 (자바 스크립트뿐만 아니라)를 도입하려는 기존 또는 계획된 이니셔티브를 알고 있습니까? 그렇다면 Firefox와의 통합을위한 로드맵은 무엇이며, 그렇지 않은 경우 브라우저 플랫폼에서 유일하게 지원되는 언어는 어떤 이유로 (상호 운용성) JavaScript 여야합니까?
이미 jQuery를 사용했고 “자바 스크립트 : 좋은 부분”도 읽었습니다. 실제로 제안은 좋지만 이해할 수없는 것은 왜 JavaScript 만입니까? 서버 측 (좋아하는 OS 플랫폼)에서는 모든 언어로 포트란을 포함하여 DOM 트리를 조작 할 수 있습니다. 클라이언트 측 (브라우저 플랫폼)이 왜 자바 스크립트 만 지원합니까?
답변
자바 스크립트의 문제점은 언어 자체가 아니라 완벽하게 프로토 타이핑 된 동적 언어입니다. OO 배경에서 온다면 약간의 학습 곡선이 있지만 언어의 결함이 아닙니다.
대부분의 사람들은 비슷한 구문과 비슷한 이름을 가지고 있기 때문에 Javascript가 Java와 같다고 가정하지만 실제로는 lisp와 훨씬 비슷합니다. 실제로 DOM 조작에 매우 적합합니다.
실제 문제는 브라우저에 의해 컴파일되므로 클라이언트에 따라 매우 다른 방식으로 작동한다는 것입니다.
실제 DOM은 브라우저에 따라 다를뿐만 아니라 성능과 레이아웃에 큰 차이가 있습니다.
해당 설명을 다음과 같이 수정
여러 개의 해석 된 언어가 지원되었다고 가정하십시오. 여전히 동일한 문제점이 있습니다. 다양한 브라우저는 여전히 버그가 있고 다른 DOM을 가지고 있습니다.
또한 인터프리터가 브라우저에 내장되어 있거나 각 언어에 대한 플러그인 (페이지를 제공하기 전에 확인할 수있는)으로 설치되어 있어야합니다. 자바 스크립트의 일관성을 유지하려면 오랜 시간이 걸렸습니다.
동일한 방식으로 컴파일 된 언어를 사용할 수 없습니다. 그런 다음 수행하는 작업에 대해 쉽게 조사 할 수없는 실행 파일을 소개합니다. 많은 사용자가 실행하지 않도록 선택합니다.
그렇다면 컴파일 된 코드를위한 일종의 샌드 박스는 어떻습니까? 나에게 Java 애플릿처럼 들린다. 또는 Flash의 ActionScript. 또는 Silverlight의 C #
어떤 종류의 IL 표준은 어떻습니까? 그것은 더 많은 잠재력을 가지고 있습니다. 원하는 언어로 개발 한 다음이를 IL로 컴파일 한 다음 브라우저를 JIT로 컴파일하십시오.
Javascript는 이미 IL- GWT를 보았습니다 . Java로 프로그램을 작성할 수 있지만 HTML 및 JS로 배포 할 수 있습니다.
문제의 추가 설명에 따라 수정
자바 스크립트는 브라우저가 지원하는 유일한 언어가 아니거나 그렇지 않았다. Internet Explorer의 어두운 시대로 돌아 가면 자바 스크립트 또는 VBScript 중에서 선택하여 IE에서 실행할 수있다. 기술적으로 IE는 Javascript도 실행하지 않았습니다. JScript를 실행했습니다 (주로 Java 라는 단어에 대해 Sun에 비용을 지불하지 않기 위해 Oracle은 여전히 Javascript 라는 이름을 소유하고 있습니다 ).
문제는 VBScript가 Microsoft의 소유 였지만 그다지 좋지 않았다는 것입니다. Javascript가 기능을 추가하고 FireBug와 같은 다른 브라우저에서 최고 속도의 디버깅 도구를 얻는 동안 VBScript는 IE 전용으로 거의 디버깅 할 수 없었습니다 (IE4 / 5 / 6의 dev 도구는 존재하지 않았습니다). 한편 VBScript는 OS에서 매우 강력한 스크립팅 도구가되기 위해 확장되었지만 브라우저에서 사용할 수있는 기능은 없었습니다 (그리고 이들이 큰 보안 허점이되었을 때).
VBScript를 사용하는 일부 회사 내부 응용 프로그램이 여전히 있으며 일부는 이러한 보안 허점에 의존하며 여전히 IE7을 실행 중입니다 (MS는 마침내 IE6를 종료했기 때문에 IE6 만 중지했습니다).
Javascript를 현재 상태로 가져 오는 것은 악몽이며 20 년이 걸렸습니다. 일부 브라우저에서 언어 기능 (1999 년에 지정됨)이 여전히 누락되어 있고 많은 심이 필요하므로 여전히 일관된 지원을 제공하지 않습니다.
브라우저에서 해석하기위한 대체 언어를 추가하면 두 가지 주요 문제가 있습니다.
-
모든 브라우저 공급 업체가 새로운 언어 표준을 구현하도록하기 – 20 년 동안 Javascript를 위해 관리하지 않은 것.
-
두 번째 언어는 잠재적으로 이미 가지고있는 지원을 희석하여 IE가 두 번째로 Javascript를 지원하지만 VBScript는 (다시) 두 번째로 지원합니다. 브라우저마다 다른 언어로 코드를 작성하고 싶지 않습니다.
자바 스크립트는 ‘완료되지’않았다는 점에 주목해야합니다. 새로운 브라우저에서 더 나아지기 위해 계속 발전하고 있습니다. 최신 버전은 년 앞서 브라우저 ‘구현의 그리고 그들은 다음 하나에 최선을 다하고 있습니다.
답변
자바 스크립트로 컴파일
현재로서는 자바 스크립트로 컴파일되는 언어를 사용하는 것이 현명한 코드를 작성하는 동안 모든 플랫폼에 도달 할 수있는 유일한 현실적인 방법 인 것 같습니다. 이는 오랫동안 계속 남아있을 것입니다. 새로운 오퍼링에는 항상 하나 이상의 공급 업체가 서두르지 않는 이유가 있습니다.
(그러나 나는 이것이 실제로 문제라고 생각하지 않습니다. Javascript는 현재 잘 최적화되어 있습니다. 기계 코드는 직접 작성하면 안전하지 않지만 컴파일 대상 및 실행 언어로 잘 작동합니다.)
너무 많은 옵션
Javascript로 컴파일되는 언어 풀이 계속 증가하고 있습니다. 상당히 포괄적 인 목록은 여기에서 찾을 수 있습니다.
- Coffeescript Wiki 에서 JS로 컴파일되는 언어 목록
주목할만한
나는 주목할만한 몇 가지를 언급 할 것이다 (내가 모르는 보석을 무시하는 것은 의심의 여지가 없다) :
-
Spider 는 2016 년에 등장했습니다. Go, Swift, Python, C # 및 CoffeeScript에 대한 최상의 아이디어를 가지고 있다고 주장합니다. 타입 안전 하지는 않지만 몇 가지 사소한 안전 기능이 있습니다 .
-
Elm : Haskell은 가장 똑똑한 언어 일 수 있으며 Elm은 Haskell for Javascript의 변형입니다. 형식 인식이 간결하고 간결 하며 반응성 템플릿 또는 MVC 스파게티의 깔끔한 대안으로 Functional Reactive Programming 을 제공합니다 . 그러나 절차 적 프로그래머에게는 충격 이 될 수있다 .
-
Google의 Go 는 간결함, 단순성 및 안전을 목표로합니다. Go 코드는 GopherJS에 의해 Javascript로 컴파일 될 수 있습니다 .
-
Dart 는 나중에 Google에서 Javascript를 대체하려는 시도였습니다. 선택적인 타이핑이있는 C / Java와 같은 구문을 통해 인터페이스와 추상 클래스를 제공합니다.
-
Haxe 는 Flash의 ActionScript와 유사하지만 여러 언어를 대상으로 하여 코드를 Java, C, Flash, PHP 및 Javascript 프로그램에서 재사용 할 수 있습니다. 타입 안전하고 동적 인 객체를 제공합니다.
-
Opalang 은 Javascript에 구문 설탕을 추가하여 직접적인 데이터베이스 액세스 , 스마트 연속성, 유형 확인 및 클라이언트 / 서버 분리를 지원합니다. (NodeJS 및 MongoDB에 연결됨)
-
GorillaScript , “일부 일반적인 오류를 방지하면서 사용자에게 권한을 부여하기 위해 컴파일 된 JavaScript로 컴파일 된 언어” Coffeescript와 유사하지만보다 포괄적이며 안전성을 높이고 반복적 인 상용구 패턴을 줄이기위한 여러 가지 추가 기능을 제공합니다.
-
LiteScript 는 Coffeescript와 GorillaScript 사이에 속합니다. “인라인”콜백 및 변수 오타 확인을위한 비동기 / 수율 구문을 제공합니다.
-
Microsoft의 TypeScript 는 함수 인수에 형식 제한을 적용하여 버그가 발생할 수있는 Java 의 작은 수퍼 세트입니다. 마찬가지로 BetterJS를 사용하면 추가 호출을 추가하거나 JSDoc 주석에 유형을 지정하여 순수 Javascript로 제한 사항을 적용 할 수 있습니다. 그리고 Facebook은 유형 추론을 추가로 수행하는 Flow 를 제공했습니다 .
-
LiveScript 는 Coffeescript의 분사 방식으로 간결하게 유명하지만 읽기 쉽지 않습니다. 아마도 팀에게는 최고가 아닐 것입니다.
선택하는 방법?
대체 언어를 선택할 때 고려해야 할 몇 가지 요소가 있습니다 .
-
나중에 다른 개발자가 프로젝트에 참여하는 경우이 언어를 빠르게 배우고 배우는 데 얼마나 걸립니까? 또는 이미 알고있는 기회는 무엇입니까?
-
언어에 기능이 너무 적거나 (코드에 보일러 플레이트로 가득 차 있음) 기능이 너무 많거나 (마스터 링하는 데 시간이 오래 걸리며, 유효한 코드를 해독 할 수 없을 때까지)?
-
프로젝트에 필요한 기능이 있습니까? (프로젝트에 유형 확인 및 인터페이스가 필요합니까? 중첩 콜백을 피하기 위해 스마트 연속성이 필요합니까? 반응성이 많습니까? 향후 다른 환경을 대상으로해야 할 수도 있습니까?)
미래…
Jeff Walker는 “Javascript 문제”에 대한 생각을 불러 일으키는 일련 의 블로그 게시물 을 작성 했습니다. 왜 그가 TypeScript 나 Dart 또는 Coffeescript 가 적절한 솔루션을 제공 하지 않는다고 생각하는지 포함 합니다. 그는 결론적으로 개선 된 언어를위한 몇 가지 바람직한 기능을 제안한다 .
답변
브라우저 플랫폼에서 JavaScript 만 지원되는 언어 여야합니까?
예, 아니오 JavaScript로 컴파일하고 jQuery와 마찬가지로 DOM 조작을 조금 더 쉽게 만들어주는 Dart by Google이라는 대안이 있습니다. 실험하는 것이 재미있을 수 있습니다. 체크 아웃하십시오.
- 구글에서 다트 언어를 참조하십시오
- Microsoft에서 TypeScript 언어 참조
또한보십시오
답변
한때 자바 스크립트가 다루기가 어렵다는 것은 사실이지만 웹 개발 커뮤니티는 그 이후로 먼 길을 왔습니다. 대신 jQuery를 살펴 보는 것이 좋습니다 . 쉽고 다양한 모든 문제를 추상화합니다.
그리고 전반적으로 효과적인 대안은 없습니다. 플래시는 생각 나지만 ECMA 스크립트이기도하며 대부분의 경우 너무 많은 시간이 소요될 수 있습니다.
답변
단기적으로 jQuery와 같은 것을 사용하여 브라우저 비 호환성을 숨길 것입니다. 장기적으로 Silverlight 또는 Adobe AIR와 같은 기술은 미래에 매우 다른 지뢰밭 (그러나 여전히 지뢰밭)을 만들 수 있습니다.
답변
Doug Crockford 는 JavaScript와 그 미래의 나쁜 부분과 좋은 부분에 대해 자세히 설명했습니다. 실제로 1999 년 이후 크게 바뀌지 않았습니다. 좋은 것으로 말할 수 있습니다 (제한을 알고있는 한 거의 모든 브라우저가 동일한 코드를 실행할 수 있음). Doug는 좋은 부분을 보여줍니다 매우 강력한 것으로 판명 된 오해였습니다.
DOM 조작의 경우, JQuery를 끔찍한 DOM API의 대부분을 작성하기 쉬운 매우 우아한 코드에 작성하기 어려운 작업으로 대체하는 클라이언트 측 라이브러리로 살펴보십시오.
답변
JavaScript에 심각한 문제가 있다고 생각되면 Doug Crockford의 책 JavaScript : The Good Parts를 추천 합니다. (또는 Google에서 “Crockford JavaScript”를 사용하여 그가 수행 한 여러 가지 비디오 프레젠테이션을 찾습니다.) Crockford는 안전한 부분 집합과 연습을 스케치하고 피해야 할 언어의 일부를 구체적으로 나열합니다.
DOM을 조작하는 사실상의 수단으로 JavaScript를 대체 할 계획을 알지 못합니다 . 따라서 안전하고 잘 사용하는 방법을 배우십시오.