현재 유일하게 완전히 지원되는 언어이며 브라우저에서 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를 대체 할 계획을 알지 못합니다 . 따라서 안전하고 잘 사용하는 방법을 배우십시오.

클라이언트 측면에서 자바 스크립트는 DOM을 조작하는 유일한 방법입니다. 서버 측면에서 여러 가지 방법이 있습니다.

Internet Explorer는 플러그 가능한 스크립팅 언어를 지원하지만 JScript 외에 IE에 포함 된 유일한 언어는 VBScript입니다.

내가 본 한, 브라우저에서 동적 언어에 대한 일반적인 편견이있는 것처럼 보이며 JavaScript는 네트워크 효과로 인해 다른 언어가 아닌 다른 언어를 만들기에 충분할 정도로이 요구를 충분히 채우는 것으로 보입니다. 이 언어는 실제로 강력하지만 브라우저에서의 구현은 바람직하지 않습니다.

고객 / 방문자를 특정 브라우저로 제한하고 플러그인 설치를 요구할 경우 MS Silverlight를 볼 수 있습니다. 읽을 수있는 개요는 Wikipedia에 있습니다. Silverlight 2를 사용하면 C #, IronPython, IronRuby, VB.NET 등으로 작성한 클라이언트 쪽 코드를 실행할 수 있습니다. Mono 프로젝트에서 무료로 제공 되는 Silverlight의 Moonlight 복제본은 Linux에 동일한 기능을 제공 할 것을 약속합니다.

실제로 대부분의 웹 응용 프로그램 및 사이트 개발자는 Silverlight (및 궁극적으로 Moonlight)가 현재 제공 할 수있는 것보다 더 많은 사용자에게 도달하는 것을 선호합니다. 이는 Javascript 또는 Flash (유사한 프로그래밍 언어 인 Actionscript를 사용함)를 사용하는 것을 의미합니다.

따라서 대규모 엔지니어 그룹과 마케팅 예산 , 측면 에서 자유 소프트웨어 프로젝트를 통해 Microsoft의 경우에도 상당한 마인드, 채택 및 견인력을 얻는 것은 어려운 일임이 입증되었습니다 (독점적 인 잠금 문제를 쉽게 해결할 수 있음) )-모질라 재단과 같은 목표에 대해 관심이없는 이유를 설명하는 데 도움이 될 수 있습니다. "상호 운용성 제외"라고 말하지만 Silverlight의 진행 상황을 보면 상호 운용성 문제가 가장 큰 문제입니다.

이미 말했듯이 플래시 (자바 스크립트에서 파생 된 언어 인 ActionScript)와 플러그인을 통해 브라우저에서 실행할 수있는 Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #)가 있습니다 (첫 번째는 훨씬 더 보편적 임) .

Ruby : HotRuby 를 좋아하는 경우 또 다른 대안이 있습니다 . 브라우저에서 실행될 자바 스크립트의 루비 구현입니다. 아직 성숙하지는 않았지만 살펴볼 수 있습니다.

내가 언급하지 않은 한 가지는 (오, 내가 쓰는 동안 Alcides가 HotRuby를 언급하고 Nosredna가 GWT와 Script #를 언급 한 것을 보았고) [언어 삽입]에 대한 많은 구현이 있다는 것을 버리고 싶다. JavaScript (예 : Ruby , Python , C # , Java , Obj-J / Cappuccino [Obj-C / Cocoa와 유사] 또는 처리 [캔버스 용]를 클라이언트 또는 배포 전 [및 일부]의 JavaScript 로 변환 할 수있는 번역기 그중에서도 다양한 추상화 라이브러리가 있습니다]). 물론 클라이언트에서 번역되는 경우 성능 오버 헤드가 있지만 다른 언어에 더 익숙한 경우 약간의 유연성이 허용됩니다.

개인적으로 JavaScript를 사랑하는 법을 배우는 것이 좋습니다. 훌륭하고 강력한 언어이며 일단 알게되면 매우 우아합니다. 나는 반대의 딜레마에 직면하고 있으며, 모든 요구를 충족시키는 유능한 서버 측 JavaScript / DOM 솔루션을 갖기 위해 조금씩 뛰어 들었다. 원치 않는 의견

아니요. JavaScript는 있지만 진화 할 것입니다. 다음 버전은 "JavaScript Harmony"이며 Google에서 자세히 알아볼 수 있습니다.

이제 누군가가 바이트 코드 인터프리터를 JavaScript와 함께 브라우저에 넣을 것을 제안합니다. 아마도 잠시 동안은 일어나지 않을 것입니다.

나는 JavaScript를 좋아한다. 그러나 Java를 JavaScript로 컴파일하는 GWT, C #을 JavaScript로 컴파일하는 Script # 등의 다른 솔루션이 있습니다.

Jquery (여전히 자바 스크립트이지만) 거의 모든 브라우저를 지원하고 실제로 배우기가 어렵지 않습니다. :)

JavaScript는 웹의 영어입니다. 영어는 여러 나라를 정복하는 강력한 해군이 있었기 때문에 역사적으로 퍼졌습니다. 이것은 JavaScript로 웹을 정복 한 대기업과 비교할 수 있습니다. 여러 유럽 소스 (그리스어, 라틴어, 게르만어, 프랑스어, 중국어 및 인도어)에서 함께 사용되는 언어입니다. JavaScript는 수년 동안 다른 언어 (구조적, OO, 기능적)에서 많은 개념을 빌 렸습니다. 영어는 방언과 억양이 약간 씩 다른 곳에서 사용되며 이해를 어렵게 할 수 있습니다. JavaScript에는 다른 브라우저가 약간 다르게 해석하는 것처럼.

처음에는 영어를 배우기 쉽지만 발음에 일관성이없고 규칙보다 더 많은 예외가 있습니다. JavaScript와 마찬가지로 항상 놀라움을 제공합니다.

다른 억양에도 불구하고 JavaScript는 웹의 언어입니다. 영어가 아니고 영어로 작성하는 것처럼 모든 웹 브라우저에는 어느 정도의 영어 이해력이 있습니다. IE6는 자신의 이력서에 유창하다고 말하지만 외국어로서의 영어에 대한 2 주 과정에만 갔다는 사람과 같습니다.

에스페란토와 같이 영어를 세계의 주요 언어로 대체하려는 시도가있었습니다. 그러나 지구상의 대부분의 사람들이 영어를 사용하기 때문에 그들 모두는 실패했습니다. 같은 방식으로 JavaScript에 대한 더 나은 대안을 도입하는 것은 어려울 것입니다.

Javascript가 곧 바뀔 것이라고 생각하지 않습니다. 리치 클라이언트에 대한 완전히 다른 접근 방식을 사용하려면 Flash 기반 기술인 Flex를 조사 할 수 있습니다.

haxe (haxe.org 참조)가 도움이 될 수 있습니다. JavaScript보다 깨끗하고 JavaScript로 컴파일 할 수있는 언어이므로 브라우저 내에서 실행할 수 있습니다.

나는 이것이 귀하의 질문에 대한 직접적인 답변이 아니라는 것을 알고 있지만 그럼에도 불구하고 귀하에게 흥미로울 것이라고 생각했습니다.

많은 사람들이 Javascript가 최고의 언어가 아니라는 것을 알고 있습니다. 그러나 현재 브라우저에서 지원되므로 다른 언어를 도입하기가 매우 어렵습니다. 우리는 단순히 다른 브라우저 전쟁이 필요하지 않습니다.

이것은 다른 클라이언트 측 언어로 전환 할 계획이없는 이유를 설명합니다.

그러나 DOM 모델과 그 작동 방식에 대해 생각하기 시작하면 Javascript가 그렇게 나쁘지 않다고 생각합니다. JS가 지저분한 많은 것들이 DOM 모델의 작동 방식의 결과입니다.