특수 언어 (실제로 특수 패러다임)를 사용하지 않고 브라우저에서 호스팅되는 표준화 된 가상 머신을 통해 언어 세트 (Java, Python, Ruby 등)를 지원하는 것이 합리적이지 않습니까? 클라이언트 스크립팅 전용?
제안을 명확히하기 위해 웹 페이지에는 JavaScript와 같은 고급 언어 대신 바이트 코드가 포함됩니다.
나는 진화론 적 이유 때문에 JavaScript가 우리가 지금해야 할 일이라는 실제적인 현실을 이해하지만, 장기적으로 더 생각하고 있습니다. 이전 버전과의 호환성과 관련하여 일정 기간 동안 인라인 JavaScript를 동시에 지원할 수 없었으며 JavaScript는 브라우저 가상 머신에서 지원하는 언어 중 하나 일 수 있습니다.
답변
그래 확실히 우리가 타임머신을 가지고 있다면, 돌아가서 많은 자바 스크립트 기능이 다르게 설계되었는지를 확인하는 것이 중요한 취미가 될 것입니다. 그러나 그것은 일어나지 않을 것이고, 우리는 지금 그것에 붙어 있습니다.
시간이 지나면 웹에 대한 “기계 언어”가 될 것으로 의심되며, 더 잘 설계된 다른 언어와 API가 컴파일되어 다른 런타임 엔진 foible을 충족시킵니다.
그러나 이러한 “더 나은 디자인 언어”는 Java, Python 또는 Ruby 일 것이라고 생각하지 않습니다. Javascript는 다른 곳에서도 사용할 수 있지만 웹 응용 프로그램 스크립팅 언어입니다. 그러한 유스 케이스를 감안할 때, 우리는 그 어떤 언어보다 더 잘할 수 있습니다.
답변
JavaScript는 좋은 언어라고 생각하지만 클라이언트 측 웹 응용 프로그램을 개발할 때 선택하고 싶습니다. 레거시 이유로 우리는 JavaScript를 고수하고 있지만 해당 시나리오를 변경하려는 프로젝트와 아이디어가 있습니다.
- Google Native Client : 브라우저에서 기본 코드를 실행하기위한 기술
- Emscripten : 자바 스크립트로 LLVM 바이트 코드 컴파일러. 브라우저에서 LLVM 언어를 실행할 수 있습니다.
- 아이디어 : Mono를 만든 브라우저의 .NET CLI : http://tirania.org/blog/archive/2010/May-03.html
우리는 오랫동안 JavaScript를 가질 것이라고 생각하지만 조만간 변경 될 것입니다. 브라우저에서 다른 언어를 사용하려는 개발자가 너무 많습니다.
답변
응답 질문을 – 아니, 그것은 의미가 없다.
현재 다국어 VM에 가장 가까운 것은 JVM과 CLR입니다. 이것들은 정확히 가벼운 짐승은 아니며 브라우저 에이 크기와 복잡성을 가진 무언가를 포함시키고 시도하는 것은 의미가 없습니다.
기존 솔루션보다 나은 새로운 다국어 VM을 작성할 수 있다는 아이디어를 살펴 보겠습니다.
- 당신은 안정성에 뒤쳐져 있습니다.
- 복잡성 뒤에 있습니다 (여러 언어를 일반화하려고하기 때문에 길, 방법, 뒤에 있습니다)
- 당신은 입양에있어
따라서 아닙니다. 말이되지 않습니다.
이러한 언어를 지원하기 위해서는 브라우저 스크립트와 관련이없는 부분을 잘라내어 API를 맹렬하게 제거해야합니다. 여기에는 수많은 디자인 결정이 있으며 오류가 발생할 수있는 큰 기회가 있습니다.
기능면에서 우리는 어쨌든 DOM을 실제로 사용 하고있을 것 입니다. 따라서 이것은 실제로 구문 및 언어 idom의 문제입니다.이 시점에서 “정말 가치가 있습니까?”
서버 측 스크립팅은 이미 원하는 언어로 제공되므로 클라이언트 측 스크립팅 만 유념해야 합니다. 상대적으로 작은 프로그래밍 분야이므로 여러 언어를 사용하는 이점은 의문의 여지가 있습니다.
어떤 언어를 도입하는 것이 이치에 맞습니까? (주의, 주관적인 자료는 다음과 같습니다)
C와 같은 언어로 가져 오는 것은 금속 작업을 위해 만들어 졌기 때문에 의미가 없으며 브라우저에는 실제로 사용할 수있는 금속이 많지 않습니다.
Java와 같은 언어로 가져 오는 것은 어쨌든 API이기 때문에 의미가 없습니다.
JavaScript는 Scheme과 매우 유사한 강력한 동적 언어이므로 Ruby 또는 Lisp와 같은 언어로 가져 오는 것은 의미가 없습니다.
마지막으로 어떤 브라우저 제작자가 실제로 여러 언어에 대한 DOM 통합을 지원하고자합니까? 각 구현에는 고유 한 버그가 있습니다. 우리는 이미 MS Javascript와 Mozilla Javascript의 차이점을 다루면서 화재를 겪어 왔으며 이제 그 고통을 5-6 배로 늘리고 싶습니까?
말이되지 않습니다.
답변
Windows에서는 스크립팅 호스트에 다른 언어를 등록하여 IE에서 사용할 수 있습니다. 예를 들어 VBScript는 기본적으로 지원되지만 (대부분의 경우 JavaScript보다 훨씬 인기가 높지 않지만) 인기가 없습니다.
Python win32 확장을 사용하면 이와 같이 IE에 Python을 쉽게 추가 할 수 있었지만 Python은 샌드 박스하기가 매우 어려우므로 실제로 좋은 생각이 아닙니다. .
일반적으로 브라우저와 같은 네트워크 응용 프로그램에 복잡성을 더 많이 추가할수록 보안 문제가 발생할 가능성이 높습니다. 많은 새로운 언어들이 그 설명에 확실히 들어 맞을 것이며, 이들은 여전히 빠르게 발전하고있는 새로운 언어들입니다.
JavaScript는 추악한 언어이지만 선택적인 기능의 하위 집합을 신중하게 사용하고 적절한 객체 라이브러리를 지원함으로써 일반적으로 상당히 견딜 수 있습니다. 웹 스크립팅이 발전 할 수있는 유일한 방법은 JavaScript에 점진적이고 실용적으로 추가하는 것 같습니다.
답변
브라우저에서 표준 언어 독립 VM을 환영합니다 (정적으로 유형이 지정된 언어로 코딩하는 것을 선호합니다).
(기술적으로) 점진적으로 수행 할 수 있습니다. 첫 번째 주요 브라우저가 지원하며 서버는 현재 요청이 호환되는 브라우저에서 온 경우 바이트 코드를 보내거나 코드를 JavaScript로 변환하고 일반 텍스트 JavaScript를 보낼 수 있습니다.
JavaScript로 컴파일되는 몇 가지 실험 언어가 이미 존재하지만 VM을 정의하면 성능이 향상 될 수 있습니다.
그러나 “표준”부분은 매우 까다로울 것입니다. 또한 라이브러리와 관련된 언어 기능 (예 : 정적 대 동적 입력) 사이에 충돌이있을 수 있습니다 (새로운 것이 동일한 라이브러리를 사용한다고 가정). 따라서 나는 그것이 일어날 것이라고 생각하지 않습니다 (곧).
답변
손이 더러워진 것 같은 느낌이 든다면 세뇌를 받았거나 여전히 “DHTML 연도”의 영향을 느끼고있는 것입니다. JavaScript는 매우 강력하며 대화 형 클라이언트 쪽을 스크립팅하는 목적에 적합합니다. 이것이 JavaScript 2.0이 나쁜 랩을 얻은 이유입니다. 패키지, 인터페이스, 클래스 등이 서버 측 언어의 분명한 측면 인 이유는 무엇입니까? JavaScript는 완전한 객체 지향적이지 않은 프로토 타입 기반 언어로 적합합니다.
서버 쪽과 클라이언트 쪽이 제대로 통신하지 않아서 응용 프로그램이 원활하지 않으면 응용 프로그램을 설계하는 방법을 다시 고려할 수 있습니다. 저는 매우 강력한 웹 사이트 및 웹 응용 프로그램을 사용해 왔으며 “음, JavaScript가 (xyz)를 할 수 있으면 좋겠다”고 한 번도 말한 적이 없습니다. 그렇게 할 수 있다면 JavaScript가 아니라 ActionScript 또는 AIR 또는 Silverlight가됩니다. 나는 그것을 필요로하지 않으며 대부분의 개발자도 마찬가지입니다. 그것들은 훌륭한 기술이지만, 해결책이 아닌 기술 문제를 해결하려고 노력합니다.
답변
표준 웹 VM이 상상할 수 없다고 생각하지 않습니다. 사용하는 모든 VM 바이트 코드 형식을 자바 스크립트로 빠르게 디 컴파일 할 수 있고 결과 출력이 합리적으로 효율적으로 유지되는 한, 새로운 웹 VM 표준을 우아하고 완벽하게 레거시 지원할 수있는 여러 가지 방법이 있습니다. 심지어 스마트 디 컴파일러가 아마도 인간이 스스로 생성 할 수있는 자바 스크립트보다 더 나은 자바 스크립트를 생성 할 것이라고 생각하기까지합니다.
이 속성을 사용하면 모든 웹 VM 형식을 서버 (빠른), 클라이언트 (느리지 만 서버에 대한 제어가 제한적인 경우 가능)에서 쉽게 디 컴파일하거나 사전에 생성하여 동적으로로드 할 수 있습니다 새로운 표준을 기본적으로 지원하지 않는 브라우저의 경우 클라이언트 또는 서버 (가장 빠름)
새로운 표준을 기본적으로 지원하는 브라우저는 웹 vm 기반 앱의 런타임 속도가 향상되는 이점이 있습니다. 또한 브라우저가 웹 vm 표준을 기반으로 기존 자바 스크립트 엔진을 기반으로하는 경우 (예 : 자바 스크립트를 웹 vm 표준으로 구문 분석 한 후 실행) 두 개의 런타임을 관리 할 필요는 없지만 브라우저 공급 업체에 달려 있습니다. .
