자바스크립트의 대안

StackOverflow https://stackoverflow.com/questions/930716

  •  06-09-2019
  •  | 
  •  

문제

현재 완전히 지원되는 유일한 언어이자 브라우저의 DOM 트리 조작에 대한 사실상의 표준은 JavaScript입니다.초보자에게 버그와 보안 허점이 가득한 지뢰밭이 되는 심각한 설계 문제가 있는 것 같습니다.

차세대 브라우저에서 DOM 트리 조작 및 HTTP 요청을 위해 모든 종류의(자바스크립트뿐만 아니라) 더 나은(재설계된) 언어를 도입하기 위한 기존 또는 계획된 이니셔티브를 알고 계십니까?그렇다면 Firefox와 같은 통합을 위한 로드맵은 무엇입니까? 그렇지 않다면 (상호 운용성과 별개로) 어떤 이유로 JavaScript가 브라우저 플랫폼에서 유일하게 지원되는 언어여야 합니까?

나는 이미 jQuery를 사용했고 "javascript:좋은 부분."실제로 제안은 좋지만 내가 이해할 수 없는 것은 다음과 같습니다.왜 자바스크립트만?서버 측(귀하가 선호하는 OS 플랫폼)에서는 포트란을 포함한 모든 언어로 DOM 트리를 조작할 수 있습니다.클라이언트 측(브라우저 플랫폼)이 javascript만 지원하는 이유는 무엇입니까?

도움이 되었습니까?

해결책

자바스크립트의 문제는 언어 자체가 아닙니다. 자바스크립트는 완벽하게 훌륭한 프로토타입의 동적 언어입니다.OO 배경에서 왔다면 약간의 학습 곡선이 있지만 언어의 잘못은 아닙니다.

대부분의 사람들은 Javascript가 구문과 이름이 비슷하기 때문에 Java와 같다고 생각하지만 실제로는 lisp에 훨씬 더 가깝습니다.실제로 DOM 조작에 매우 적합합니다.

진짜 문제는 이것이 브라우저에 의해 컴파일된다는 것인데, 이는 클라이언트에 따라 매우 다른 방식으로 작동한다는 것을 의미합니다.

실제 DOM은 브라우저에 따라 다를 뿐만 아니라 성능과 레이아웃에도 엄청난 차이가 있습니다.

문제의 다음 설명을 수정하세요.

여러 가지 해석된 언어가 지원된다고 가정해 보십시오. 여전히 동일한 문제가 있습니다.다양한 브라우저에는 여전히 버그가 있으며 DOM이 다릅니다.

또한 각 언어에 대해 브라우저에 통역사가 내장되거나 플러그인(페이지를 제공하기 전에 확인할 수 있음)으로 설치되어야 합니다.Javascript의 일관성을 유지하는 데 오랜 시간이 걸렸습니다.

컴파일된 언어를 같은 방식으로 사용할 수 없습니다. 그러면 수행하는 작업을 쉽게 조사할 수 없는 실행 파일을 도입하게 됩니다.많은 사용자가 실행을 허용하지 않기로 선택합니다.

그렇다면 컴파일된 코드를 위한 일종의 샌드박스는 어떻습니까?나에게는 Java 애플릿처럼 들립니다.또는 Flash의 ActionScript.또는 Silverlight의 C#입니다.

IL 표준은 어떻습니까?그것은 더 많은 잠재력을 가지고 있습니다.원하는 언어로 개발한 다음 IL로 컴파일하면 브라우저가 JIT합니다.

단, Javascript는 이미 그런 IL입니다. GWT.Java로 프로그램을 작성할 수 있지만 HTML 및 JS로 배포할 수 있습니다.

문제의 추가 설명에 따라 편집합니다.

Javascript는 브라우저가 지원하는 유일한 언어가 아닙니다.Internet Explorer 암흑기에는 IE에서 실행하기 위해 Javascript 또는 VBScript 중에서 선택할 수 있었습니다.기술적으로 IE는 Javascript를 실행하지도 않았습니다. JScript (주로 Sun에 단어 비용을 지불하지 않기 위해 자바, Oracle은 여전히 ​​​​이름을 소유하고 있습니다 자바스크립트).

문제는 VBScript가 Microsoft의 독점 제품이었지만 그다지 좋지 않았다는 것입니다.Javascript가 기능을 추가하고 다른 브라우저(예: FireBug)에서 최고의 디버깅 도구를 얻는 동안 VBScript는 IE 전용으로 유지되었으며 디버깅이 거의 불가능했습니다(IE4/5/6의 개발 도구는 존재하지 않았습니다).동시에 VBScript는 OS에서 매우 강력한 스크립팅 도구로 확장되었지만 브라우저에서는 이러한 기능 중 어느 것도 사용할 수 없었습니다(그리고 사용할 당시 엄청난 보안 구멍이 되었습니다).

여전히 VBScript를 사용하는 일부 기업 내부 애플리케이션이 있으며(일부는 이러한 보안 허점에 의존함) 여전히 IE7을 실행하고 있습니다(MS가 최종적으로 IE6을 종료했기 때문에 IE6만 중지했습니다).

Javascript를 현재 상태로 만드는 것은 악몽이었고 20년이 걸렸습니다.일부 브라우저에는 언어 기능(1999년에 지정)이 여전히 누락되어 있고 많은 shim이 필요하므로 여전히 일관된 지원이 없습니다.

브라우저에서 해석하기 위한 대체 언어를 추가하는 것은 두 가지 주요 문제에 직면합니다.

  • 모든 브라우저 공급업체가 새로운 언어 표준을 구현하도록 하고 있습니다. 이는 20년 동안 여전히 Javascript에 대해 관리하지 못한 것입니다.

  • 두 번째 언어는 잠재적으로 이미 가지고 있는 지원을 희석시켜 (예를 들어) IE가 이류 Javascript 지원을 가지도록 허용하지만 (역시) 훌륭한 VBScript를 지원합니다.저는 정말 다른 브라우저에 대해 다른 언어로 코드를 작성하고 싶지 않습니다.

Javascript는 '완성'되지 않았다는 점에 유의해야 합니다. Javascript는 새로운 브라우저에서 더 나아지기 위해 계속 진화하고 있습니다.그만큼 최신 버전 브라우저 구현보다 몇 년 앞서 있으며 다음 구현을 위해 노력하고 있습니다.

다른 팁

자바스크립트로 컴파일

현재로서는 Javascript로 컴파일되는 언어를 사용하는 것이 더 스마트한 코드를 작성하면서 모든 플랫폼에 접근할 수 있는 유일한 현실적인 방법인 것으로 보이며 이는 오랫동안 유지될 가능성이 높습니다.새로운 제품이 있으면 하나 이상의 공급업체가 제품을 출시하기 위해 서두르지 않는 데에는 항상 이유가 있습니다.

(근데 이건 별 문제가 아닌 것 같아요.이제 Javascript는 훌륭하게 최적화되었습니다.기계어 코드도 손으로 작성하면 안전하지 않지만 컴파일 대상 및 실행 언어로는 잘 작동합니다.)

너무 많은 옵션

Javascript로 컴파일되는 언어 풀이 점점 늘어나고 있습니다.상당히 포괄적인 목록은 여기에서 찾을 수 있습니다:

주목할만한

나는 주목할 만하다고 생각하는 몇 가지를 언급하겠습니다(물론 내가 알지 못하는 몇 가지 보석은 무시합니다):

  • 거미 2016년에 등장.Go, Swift, Python, C# 및 CoffeeScript의 최고의 아이디어를 취한다고 주장합니다.형식이 안전하지는 않지만 약간의 사소한 내용이 있습니다. 안전 설비.

  • 느릅나무:하스켈은 아마도 가장 똑똑한 언어 Elm은 Haskell for Javascript의 변형입니다.유형을 잘 인식하고 간결하며 다음을 제공합니다. 함수형 리액티브 프로그래밍 반응형 템플릿이나 MVC 스파게티에 대한 깔끔한 대안으로 사용됩니다.하지만 꽤 그럴 수도 있어요 절차적 프로그래머에게는 충격.

  • 구글의 가다 간결성, 단순성 및 안전성을 목표로 합니다.Go 코드는 다음과 같이 Javascript로 컴파일될 수 있습니다. 고퍼JS.

  • 다트 이는 Google이 나중에 Javascript를 대체하려는 시도였습니다.선택적 입력이 포함된 C/Java와 유사한 구문을 통해 인터페이스와 추상 클래스를 제공합니다.

  • 학세 Flash의 ActionScript와 비슷하지만 여러 언어를 타겟팅 따라서 코드를 Java, C, Flash, PHP 및 Javascript 프로그램에서 재사용할 수 있습니다.유형이 안전하고 동적 개체를 제공합니다.

  • 오팔랑 Javascript에 구문 설탕을 추가하여 제공합니다. 직접 데이터베이스 액세스, 스마트 연속, 유형 확인 및 클라이언트/서버 분리 지원.(NodeJS 및 MongoDB와 연결되어 있습니다.)

  • 고릴라스크립트, "일부 일반적인 오류를 방지하면서 사용자에게 권한을 부여하도록 설계된 자바스크립트 컴파일 언어입니다." Coffeescript와 유사하지만 더 포괄적이며 안전성을 높이고 반복적인 상용구 패턴을 줄이기 위한 다양한 추가 기능을 제공합니다.

  • 라이트스크립트 Coffeescript와 GorillaScript 사이 어딘가에 속합니다."인라인" 콜백을 위한 비동기/수율 구문을 제공하고 변수 오타를 확인합니다.

  • 마이크로소프트의 타입스크립트 함수 인수에 유형 제한을 적용할 수 있는 Javascript의 작은 상위 집합으로, 몇 가지 버그를 잡을 수 있습니다.비슷하게 BetterJS 추가 호출을 추가하거나 JSDoc 주석에 유형을 지정하여 제한 사항을 적용할 수 있지만 순수 Javascript에서는 가능합니다.이제 Facebook이 제안한 흐름 추가로 유형 추론을 수행합니다.

  • 라이브스크립트 간결함으로 인기가 있었지만 나에게는 읽기 쉽지 않은 Coffeescript의 분사입니다.아마도 팀에게는 최고가 아닐 것입니다.

선택하는 방법?

언제 고르는 대체 언어가 있습니다. 고려해야 할 요소:

  • 나중에 다른 개발자가 귀하의 프로젝트에 참여한다면 그들이 이 언어를 익히고 배우는 데 얼마나 시간이 걸릴까요? 아니면 그들이 이미 이 언어를 알고 있을 가능성이 얼마나 됩니까?

  • 언어에 기능이 너무 적거나(코드가 여전히 상용구로 가득 차 있음) 너무 많습니까(숙달하는 데 시간이 오래 걸리고 그때까지 일부 유효한 코드를 해독할 수 없음)?

  • 프로젝트에 필요한 기능이 포함되어 있나요?(프로젝트에 유형 검사와 인터페이스가 필요합니까?중첩된 콜백 지옥을 피하려면 스마트 연속이 필요합니까?반응이 많나요?향후에는 다른 환경을 대상으로 해야 합니까?)

미래...

제프 워커가 쓴 많은 생각을 하게 만드는 시리즈 "Javascript 문제"에 대한 블로그 게시물(그가 둘 다 생각하지 않는 이유 포함) 타입스크립트, 도 아니다 다트 ...도 아니다 커피스크립트 적절한 솔루션을 제공합니다.그는 향상된 언어에 대한 몇 가지 바람직한 기능을 제안합니다. 결론.

JavaScript가 브라우저 플랫폼에서 유일하게 지원되는 언어가되어야합니까?

예 그리고 아니오. Google의 Dart라는 대안이있어 JavaScript로 컴파일하고 jQuery처럼 DOM 조작을 좀 더 쉽게 만들려고합니다. 실험하는 것이 재미있을 수 있습니다.

또한보십시오

JavaScript가 어느 시점에서 다루기가 어렵다는 것은 사실이지만 웹 개발 커뮤니티는 그 이후로 먼 길을 왔습니다. 대신, 나는 당신이 jQuery. 쉽고 다양한 문제를 쉽게 추상화합니다.

그리고 실제로 전반적으로 작동하는 대안은 없습니다. 플래시가 떠 오지만 ECMA 스크립트이며 아마도 대부분의 사람들이 죽일 것입니다.

단기적으로 jQuery와 같은 것들을 사용하여 브라우저 비 호환성을 숨 깁니다. 장기적으로 Silverlight 또는 Adobe Air와 같은 기술은 미래에 매우 다른 지뢰밭 (여전히 지뢰밭)으로 만들 수 있습니다.

더그 크록 포드 Google과 대화를 나누었습니다 JavaScript의 나쁜 부분과 미래를 자세히 설명합니다. 실제로 1999 년 이래로 전혀 변하지 않았습니다. 이는 좋은 일이라고 할 수 있습니다 (거의 모든 브라우저는 한계를 알고있는 한 거의 모든 브라우저가 동일한 코드를 실행할 수 있음) 및 Doug는 좋은 부품이 어디에 있는지 보여줍니다. 매우 강력한 것으로 판명 된 대부분 오해였습니다.

DOM 조작의 경우 jQuery를 클라이언트 측 라이브러리로보십시오. 대부분의 끔찍한 DOM API를 작성하기 쉬운 꽤 우아한 코드에 쓸 수있는 고통 인 작업으로 대체하는 클라이언트 측 라이브러리로보십시오.

JavaScript에 깊은 문제가 있다고 생각한다면 Doug Crockford의 책을 추천합니다. JavaScript : 좋은 부분. (또는 "Crockford JavaScript"의 Google은 자신이 수행 한 여러 비디오 프레젠테이션을 찾습니다.) Crockford는 안전한 서브 세트와 연습 세트를 스케치하고 특히 피해야 할 언어의 일부를 나열합니다.

JavaScript를 대체 할 계획을 알지 못합니다 사실상 DOM을 조작하는 수단. 안전하고 잘 사용하는 법을 배우는 것이 가장 좋습니다.

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

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

내가 보았던 한, 브라우저에는 동적 언어에 대한 일반적인 편견이있는 것으로 보이며, JavaScript는 네트워크 효과가 다른 언어를 스타터로 만들기에 충분히 이러한 요구를 충족시키는 것으로 보입니다. 언어는 실제로 매우 강력하지만 브라우저에서의 구현은 많은 것을 원합니다.

고객/방문자를 특정 브라우저로 제한하고 플러그인을 설치하도록 요구할 수도 있다면 MS 실버 라이트 - 읽을 수있는 개요가 켜져 있습니다 위키 백과. Silverlight 2를 사용하면 C#, Ironpython, Ironruby, VB.net 등으로 작성한 클라이언트 측, 코드를 실행할 수 있습니다. 무료 월광 모노 프로젝트의 실버 라이트 클론은 동일한 기능을 Linux에 가져올 것을 약속합니다.

실제로, 대부분의 웹 앱 및 사이트 개발자는 Silverlight (및 결국 Moonlight)보다 더 넓은 청중에게 도달하는 것을 선호합니다. 이는 JavaScript를 고수하거나 플래시 (유사한 프로그래밍 언어, ActionScript)를 사용하는 것을 의미합니다.

따라서 다른 모든 것에 대한 상당한 마인드 쉐어, 채택 및 견인력을 얻는 것은 많은 엔지니어 그룹과 마케팅 예산을 가진 Microsoft에게도 오르막길로 입증됩니다. 그리고 측면에있는 프리 소프트웨어 프로젝트 (독점적 잠금에 대한 걱정을 용이하게하기 위해)-예를 들어 모질라 재단 측에서 관심이 거의없는 이유를 설명하는 데 도움이 될 수 있습니다. "상호 운용성을 제외하고", 당신은 다음과 같이 말합니다. 그러나 분명히 상호 운용성 문제는 WRT Silverlight의 진행 상황을 관찰하는 것을 감안할 때 여기서 큰 문제입니다.

이미 말했듯이 플래시 (JavaScript에서 파생 된 언어 인 ActionScript) 및 Silverlight/Moonlight (Ironpython, Ironruby, JScript, C#)가 플러그인을 통해 브라우저에서 실행될 수 있습니다 (첫 번째는 훨씬 더 유비쿼터스입니다). .

루비를 좋아한다면 또 다른 대안이 있습니다. 핫 루비, 브라우저에서 실행되는 JavaScript의 Ruby 구현입니다. 아직 성숙하지는 않지만 볼 수 있습니다.

내가 언급하지 않은 한 가지 (오, 나는 Alcides가 글을 쓰는 동안 Hotruby를 언급하고 Nosredna가 GWT와 Script#을 언급 한 것을 본다), [삽입 언어] -on-의 여러 구현이 있습니다. JavaScript (예 : 변환 할 수있는 번역기 루비, 파이썬, 씨#, 자바, OBJ-J/CAPPUCCINO OBJ-C/Cocoa와 유사] 또는 처리 캔버스의 경우] 클라이언트 또는 배포 전에 JavaScript에서 (일부는 다양한 추상화 라이브러리를 특징으로합니다]). 물론 클라이언트에서 번역 된 경우 성능 오버 헤드가 있지만 다른 언어에 더 편한 경우 유연성이 있습니다.

그러나 개인적으로는 JavaScript를 사랑하는 법을 배우는 것이 좋습니다. 그것은 훌륭하고 강력한 언어이며, 일단 당신이 그것을 알게되면 꽤 우아합니다. 나는 반대의 딜레마에 직면하고 있으며, 내 모든 요구를 충족시키는 유능한 서버 측 JavaScript/dom 솔루션을 갖기 위해 비트를칩니다. /원치 않는 의견

아니요. JavaScript이지만 발전 할 것입니다. 다음 버전은 "JavaScript Harmony"이며 Google이라면 더 많은 것을 배울 수 있습니다.

이제 누군가는 바이트 코드 통역사를 JavaScript와 함께 브라우저에 넣을 것을 제안합니다. 아마도 적어도 잠시 동안 일어나지 않을 것입니다.

나는 JavaScript를 좋아합니다. 그러나 Java를 JavaScript 및 Script#로 컴파일하는 GWT를 포함한 다른 솔루션이 있으며 C#을 JavaScript로 컴파일합니다.

jQuery (여전히 JavaScript이지만) 실제로 거의 모든 브라우저를 지원하고 실제로 배우기가 어렵지는 않습니다 :)

JavaScript는 웹의 영어입니다. 영어는 역사적으로 다양한 국가를 정복하는 해군이 강력했기 때문에 역사적으로 퍼졌습니다. 이것은 JavaScript로 웹을 정복 한 대기업과 비슷합니다. 그것은 여러 유럽 출처 (그리스어, 라틴어, 게르인 언어, 프랑스어, 심지어 중국어와 인도의 단어)에서 함께하는 언어입니다. JavaScript는 다른 언어 (구조, OO, 기능적)에서 수년 동안 많은 개념을 빌 렸습니다. 영어는 방언과 악센트가 약간 변하는 다른 장소에서 사용되므로 이해가 어려워 질 수 있습니다. JavaScript와 마찬가지로 브라우저가 다른 브라우저를 조금 다르게 해석합니다.

영어는 처음에는 배우기 쉽지만 규칙보다 일관성이없는 발음과 예외가 있습니다. JavaScript와 마찬가지로 항상 놀라움을 줄 수 있습니다.

다른 액센트에도 불구하고 JavaScript는 웹의 링구아 프랑카입니다. 영어가 아니고 영어로 글을 쓰는 것처럼 모든 웹 브라우저에는 어느 정도의 영어 이해가 있습니다. IE6은 이력서에서 자신이 유창하다고 말하는 사람과 비슷하지만 외국어로서 영어로 2 주일 밖에되지 않았습니다.

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

JavaScript가 곧 교체 될 것이라고 생각하지 않습니다. 풍부한 고객에 대한 완전히 다른 접근 방식의 경우 플래시 기반 기술인 Flex를 조사 할 수 있습니다.

어쩌면 Haxe (Haxe.org 참조)와 같은 것이 도움이 될 수 있습니다. JavaScript보다 깨끗해 보이는 언어이며 JavaScript로 컴파일 할 수 있으므로 브라우저 내에서 실행할 수 있습니다.

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

많은 사람들은 JavaScript가 가장 좋고 예쁘지 않다는 것을 이해합니다. 그러나 현재 브라우저에서 지원되므로 다른 언어를 도입하기가 매우 어렵습니다. 우리는 단순히 다른 브라우저 전쟁이 필요하지 않습니다.

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

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

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top