표준 브라우저 가상 머신이 아닌 자바스크립트를 사용하는 이유는 무엇입니까?

표준 브라우저 가상 머신이 아닌 자바스크립트를 사용하는 이유는 무엇입니까?

클라이언트 스크립팅에만 특화된 언어(정말로 특화된 패러다임)를 사용해야 하는 것이 아니라 브라우저에서 호스팅되는 표준화된 가상 머신을 통해 일련의 언어(자바, 파이썬, 루비 등)를 지원한다는 것이 말이 되지 않을까요?

제안을 명확히 하기 위해, 웹 페이지는 자바스크립트와 같은 상위 언어 대신 바이트 코드를 포함할 것입니다.

자바스크립트는 진화론적인 이유로 인해 단순히 지금 우리가 작업해야 하는 것이라는 실용적인 현실은 이해하지만 장기적으로 더 생각하고 있습니다.하위 호환성과 관련하여 인라인 자바스크립트가 일정 기간 동안 동시에 지원되지 않을 이유는 없으며 물론 자바스크립트가 브라우저 가상 머신에서 지원하는 언어 중 하나가 될 수도 있습니다.

네.타임머신이 있다면, 돌아가서 많은 자바스크립트 기능들이 다르게 설계되었는지 확인하는 것이 중요한 취미가 될 것입니다(즉, IE의 CSS 엔진을 설계한 사람들이 IT 분야에 진출하지 않도록 하는 것입니다).하지만 그런 일은 일어나지 않을 것이고, 우리는 지금 그것을 고수하고 있습니다.

시간이 지나면 다른 더 나은 설계 언어와 API가 컴파일되어 웹의 "기계 언어"가 될 것이라고 생각합니다(그리고 다양한 런타임 엔진 결함을 해결합니다).

그러나 이러한 "더 나은 설계 언어"는 자바, 파이썬, 루비가 될 것이라고 생각하지 않습니다.자바스크립트는 다른 곳에서 사용할 수 있음에도 불구하고 웹 애플리케이션 스크립팅 언어입니다.그 사용 사례를 고려할 때, 우리는 그 어떤 언어보다도 더 잘할 수 있습니다.

저는 자바스크립트가 좋은 언어라고 생각하지만, 클라이언트 쪽 웹 애플리케이션을 개발할 때 선택할 수 있으면 좋겠습니다.기존의 이유로 인해 JavaScript를 사용하지 못하고 있지만 시나리오를 변경하려는 프로젝트와 아이디어가 있습니다.

1. Google Native Client: 브라우저에서 네이티브 코드를 실행하기 위한 기술입니다.
2. Emscripten: 자바스크립트로 LLVM 바이트코드 컴파일러.브라우저에서 LLVM 언어를 실행할 수 있습니다.
3. 아이디어 : .NET CLI in 브라우저, Mono 제작자 : http://tirania.org/blog/archive/2010/May-03.html

오랫동안 자바스크립트를 보유하게 될 것으로 생각하지만, 그것은 조만간 바뀔 것입니다.브라우저에서 다른 언어를 사용할 의향이 있는 개발자들이 매우 많습니다.

질문에 답하는 것 - 아니요, 말이 안 됩니다.

현재 다국어 VM에 가장 가까운 것은 JVM과 CLR입니다.이것들은 완전히 가벼운 짐승들은 아니며, 브라우저에 이와 같은 크기와 복잡성을 가진 무언가를 내장하려고 시도하는 것은 말이 되지 않을 것입니다.

기존 솔루션보다 더 나은 새로운 다국어 VM을 작성할 수 있다는 아이디어에 대해 알아보겠습니다.

• 당신은 안정성이 뒤떨어져 있습니다.
• 복잡성(여러 언어를 사용하여 일반화하려고 하기 때문에 훨씬 더 복잡해집니다.)
• 당신은 입양이 늦었습니다.

아니, 말이 안 돼요

이 언어들을 지원하기 위해서는 브라우저 스크립트의 상황에서 이해가 되지 않는 부분을 잘라내고, 이 언어들의 API들을 맹렬한 것으로 잘라내야 한다는 것을 기억하세요.여기에는 수많은 설계 결정이 내려져야 하고, 오류가 발생할 수 있는 엄청난 기회가 있습니다.

기능적인 측면에서, 우리는 아마도 DOM으로만 실제로 작업하고 있을 것입니다. 그래서 이것은 구문과 언어 아이돔의 문제인데, 이 시점에서 "이것이 정말 가치가 있습니까?"라고 묻는 것이 타당합니다.

서버 사이드 스크립팅은 이미 원하는 언어로 제공되고 있기 때문에, 염두에 두고 말씀드리는 것은 클라이언트 사이드 스크립팅뿐입니다.상대적으로 작은 프로그래밍 분야이기 때문에 여러 언어를 도입하는 이점은 의문입니다.

어떤 언어를 도입하는 것이 타당하겠습니까? (경고, 주관적 자료는 다음과 같습니다.)

C와 같은 언어를 도입하는 것은 메탈로 작동하기 위해 만들어졌고 브라우저에서는 실제로 사용할 수 있는 메탈이 많지 않기 때문에 말이 되지 않습니다.

자바와 같은 언어를 가져오는 것은 말이 되지 않습니다. 어차피 가장 좋은 것은 API이기 때문입니다.

자바스크립트는 스킴에 매우 가까운 강력한 동적 언어이기 때문에 루비나 리스프 같은 언어를 도입하는 것은 말이 되지 않습니다.

마지막으로, 어떤 브라우저 제조업체가 여러 언어에 대해 DOM 통합을 지원하기를 원합니까?각 구현에는 고유한 버그가 있습니다.우리는 이미 MS 자바스크립트와 모질라 자바스크립트의 차이를 다루면서 화재를 겪었는데 이제 그 고통을 5배나 6배로 늘리려고 하는 겁니까?

말이 안된다.

Windows(윈도우)에서는 Scripting Host(스크립팅 호스트)에 다른 언어를 등록하고 IE에서 사용할 수 있도록 할 수 있습니다.예를 들어 VBScript는 즉시 지원됩니다(대부분의 경우 자바스크립트보다 더 나쁜 목적을 가지고 있기 때문에 큰 인기를 얻은 적은 없지만).

Python win32 확장 기능을 사용하면 Python을 이와 같이 IE에 쉽게 추가할 수 있지만 Python은 샌드박스하기가 매우 어렵기 때문에 실제로 좋은 아이디어는 아니었습니다. 많은 언어 기능이 제한된 애플리케이션이 발생할 수 있을 만큼 구현 후크를 노출하기 때문입니다.

일반적으로 브라우저와 같은 넷페이싱 애플리케이션에 복잡성을 더할수록 보안 문제가 발생할 가능성이 높아진다는 것이 문제입니다.많은 새로운 언어들이 분명히 그 설명에 맞을 것이고, 이 언어들은 또한 여전히 빠르게 발전하고 있는 새로운 언어들입니다.

자바스크립트는 보기 흉한 언어이지만 선택적인 기능의 하위 집합을 신중하게 사용하고 적절한 객체 라이브러리의 지원을 통해 일반적으로 상당히 견딜 수 있게 만들 수 있습니다.자바스크립트에 대한 실질적인 추가가 웹 스크립팅이 진행될 수 있는 유일한 방법인 것 같습니다.

브라우저의 표준 언어 독립 VM을 환영합니다(정적으로 입력된 언어로 코딩하는 것을 선호합니다).

(기술적으로) 단계적으로 꽤 가능합니다. 먼저 주요 브라우저 하나가 이를 지원하고 서버는 호환되는 브라우저에서 현재 요청할 경우 바이트 코드를 전송하거나 코드를 자바스크립트로 변환하여 일반 텍스트 자바스크립트를 전송할 수 있습니다.

이미 자바스크립트로 컴파일하는 실험 언어가 일부 존재하지만 정의된 VM을 사용하면 성능이 향상될 수 있습니다.

하지만 "표준" 부분이 상당히 까다롭다는 것은 인정합니다.또한 라이브러리와 관련하여 언어 기능(예: 정적 타이핑 대 동적 타이핑) 간에 충돌이 발생합니다(새로운 것이 동일한 라이브러리를 사용한다고 가정합니다).따라서 저는 그런 일이 (곧) 일어나지 않을 것으로 생각합니다.

만약 여러분이 손이 더러워지고 있다고 느낀다면, 여러분은 세뇌를 당했거나 아직도 "DHTML" 시절의 후유증을 느끼고 있는 것입니다.자바스크립트는 매우 강력하며, 상호작용성 클라이언트 쪽을 스크립트로 작성하는 목적에 적합합니다.이것이 자바스크립트 2.0이 그렇게 나쁜 랩을 받은 이유입니다.왜 패키지, 인터페이스, 클래스 등이 서버측 언어의 측면임이 분명한데도 말입니다.자바스크립트는 완전한 객체 지향성이 없이 프로토타입 기반 언어로서 괜찮습니다.

서버 측과 클라이언트 측의 통신이 원활하지 않아 응용프로그램이 원활하지 않은 경우 응용프로그램을 설계하는 방법을 다시 생각해 볼 수 있습니다.저는 매우 강력한 웹 사이트와 웹 애플리케이션을 사용해 왔지만, "음, 자바스크립트가 (xyz를) 할 수 있기를 정말 바랍니다."라고 말한 적은 없습니다.만약 그렇게 할 수 있다면 자바스크립트가 아니라 액션스크립트, AIR, 실버라이트가 될 것입니다.저는 그것이 필요하지 않고 대부분의 개발자들도 필요하지 않습니다.좋은 기술이긴 하지만 문제를 해결하려고 하는 건...뭐, 해결책이 있습니다.

표준 웹 VM이 그렇게 상상할 수 없다고 생각합니다.사용하는 모든 VM 바이트코드 형식을 신속하게 자바스크립트로 디컴파일할 수 있는 한, 새로운 웹 VM 표준을 우아하고 완벽한 레거시 지원을 통해 도입할 수 있는 여러 가지 방법이 있습니다.결과 출력이 상당히 효율적일 것입니다(스마트 디컴파일러가 사람이 직접 만들 수 있는 어떤 자바스크립트보다 더 나은 자바스크립트를 생성할 것이라고 추측하기까지 했습니다).

이 속성을 사용하면 모든 웹 VM 형식을 서버에서(빠르게), 클라이언트에서(속도가 느리지만 서버를 제한적으로 제어하는 경우에는 가능) 쉽게 디컴파일할 수 있으며, 새 표준을 기본적으로 지원하지 않는 브라우저의 경우 클라이언트 또는 서버에서(빠르게) 사전 생성하여 동적으로 로드할 수 있습니다.

새 표준을 기본적으로 지원하는 브라우저는 웹 VM 기반 앱의 런타임 속도가 향상됨으로써 이점을 얻을 수 있습니다.또한 브라우저가 기존 자바스크립트 엔진을 웹 vm 표준에 기반(즉, 자바스크립트를 웹 vm 표준에 파싱한 후 실행)하는 경우 두 번의 런타임을 관리할 필요는 없지만, 이는 브라우저 공급업체의 몫입니다.

자바스크립트는 페이지를 직접 제어할 수 있는 유일하게 잘 지원되는 스크립팅 언어이지만 플래시는 더 큰 프로그램을 위한 매우 좋은 기능을 가지고 있습니다.최근에는 JIT를 사용하며 바이트코드를 즉시 생성할 수도 있습니다(예를 들어 플래시를 사용하여 사용자 입력 수학 식을 네이티브 바이너리까지 컴파일하는 런타임 표현 평가를 확인하십시오)Haxe 언어는 추론과 함께 정적 타이핑을 제공하며 바이트코드 생성 능력을 통해 선택한 거의 모든 런타임 시스템을 구현할 수 있습니다.

이 오래된 질문에 대한 빠른 업데이트.

"웹 페이지가 자바스크립트와 같은 상위 언어 대신 바이트 코드를 포함할 것"이라고 단언한 모든 사람들은 "발생하지 않을 것"입니다.

2015년 6월 W3C는 다음과 같은 웹어셈블리를 발표했습니다.

웹에 컴파일하기에 적합한 휴대용, 크기 및 부하 시간 효율적인 새로운 포맷

이것은 여전히 실험적이지만, 파이어폭스의 야간 및 Chrome Canary에서는 이미 프로토타입 구현이 일부 진행되고 있으며 이미 시연이 진행되고 있습니다.

현재 WebAssembly는 대부분 C/C++에서 제작하도록 설계되어 있습니다.

WebAssembly가 진화함에 따라 C/C++보다 더 많은 언어를 지원하게 될 것이며, 다른 컴파일러들도 이를 지원하기를 바랍니다.

프로젝트의 공식 페이지를 자세히 볼 수 있게 해 드렸습니다, 정말 신납니다!

이 질문은 정기적으로 다시 제기됩니다. 이에 대한 저의 입장은 다음과 같습니다.

A) 발생하지 않을 것이고 B)는 이미 여기에 있습니다.

뭐라고요?제가 설명해 드리겠습니다.

광고 A

VM은 그저 보편적인 마법 장치 같은 것이 아닙니다. 대부분의 VM은 특정 언어와 특정 언어 기능에 최적화되어 있습니다. 정적 타이핑에 최적화된 JRE/Java(또는 LLVM)를 사용합니다. 동적 타이핑이나 다른 것들을 구현할 때 애초에 자바가 지원하지 않았던 문제들과 단점들이 분명히 있습니다.

따라서 다양한 언어 기능(테일콜 최적화, 정적 및 동적 타이핑, foo boo, ...)을 지원하는 "일반 다목적 VM"은 엄청나고 구현하기 어려우며 우수한 성능을 얻기 위해 최적화하기도 어려울 것입니다. 하지만 저는 언어 디자이너나 VM 전문가가 아닙니다. 틀렸을 수도 있습니다.아직 아무도 그 생각을 못했습니까?흠, 흠.

광고 B

이미 여기: 바이트코드 컴파일러/vm이 없을 수도 있지만 실제로 필요는 없습니다. faik javascript는 turing complete이므로 다음 중 하나가 가능해야 합니다.

1. 언어 X에서 자바스크립트로 번역기 만들기 (예: 커피 스크립트)
2. 언어 X(예: brainfuck)를 해석하는 통역기를 자바스크립트로 만듭니다.네, 실적이 최악일 수도 있지만, 모든 걸 가질 순 없어요.

광고 C

뭐라고요? 애초에 C점이 없었어요!?왜냐하면 아직... 구글 NACL. 누구든지 할 수 있다면 구글입니다.구글이 그것을 작동시키자마자, 당신의 문제들은 해결됩니다.하지만, 어, 절대로 작동하지 않을 수도 있어요, 모르겠어요.지난번에 읽었을 때 정말 까다로운 종류의 해결되지 않은 보안 문제들이 있었습니다.

---

그 외에:

• javascript는 1995년 = 15년 이래로 존재해 왔지만, 오늘날 브라우저 구현은 다릅니다(최소한 더 이상 참을 수 없는 것은 아닙니다).그래서, 만약 당신이 아직 새로운 것을 시작한다면, 당신은 2035년쯤에 크로스 브라우저에서 작동하는 버전이 있을 수도 있습니다. 적어도 작동하는 서브셋.미묘하게 다를 뿐입니다호환성이 필요합니다.개선하려고 하지 않는 것은 의미가 없습니다.

• 또한 읽을 수 있는 소스코드는 어떻습니까?많은 회사들이 자신들의 코드를 "일종의" 오픈 소스로 제공하고 싶어하지 않을 것이라는 것을 알고 있습니다.개인적으로, 저는 제가 수상한 것을 의심하거나 그것으로부터 배우고 싶다면 출처를 읽을 수 있어서 매우 기쁩니다.소스코드 만세!

물론이죠. 실버라이트는 사실상 고객 측면에 불과합니다.네트워크 기반 VM.

당신의 추론에는 오류가 좀 있습니다.

1. 표준 브라우저의 표준 가상 시스템은 결코 표준이 될 수 없습니다.우리는 4개의 브라우저를 보유하고 있으며 IE는 '표준'과 관련하여 이해관계가 상충됩니다.다른 세 가지는 빠르게 발전하고 있지만 신기술의 채택 속도는 느립니다.전화기의 브라우저, 작은 장치,...

2. 서로 다른 브라우저와 과거 이력에 JS를 통합하면 JS의 힘을 과소평가하게 됩니다.당신은 표준을 약속하지만, 초기에 표준이 맞지 않았기 때문에 JS를 못마땅해 합니다.

3. JS는 AIR/와 동일하지 않습니다.NET/... 등등.현재의 JS는 목표에 완벽하게 부합합니다.

장기적으로는 펄과 루비가 자바스크립트를 대체할 수 있을 것입니다.그러나 이 언어들의 채택은 느리고 JS를 절대로 인수하지 않을 것으로 알려져 있습니다.

어떻게 정의를 내리십니까?브라우저에 가장 적합한가요, 아니면 개발자에게 가장 적합한가요? (Plus ECMAscript는 자바스크립트와 다르지만, 그것은 기술적인 부분입니다.)

저는 자바스크립트가 강력하면서도 우아할 수 있다고 생각합니다.불행하게도 제가 만난 대부분의 개발자들은 실제 프로그래밍 언어가 아닌 필요악으로 취급합니다.

제가 즐기는 기능은 다음과 같습니다.

• 기능을 일류 시민으로 취급하기
• 언제든지 어떤 물체에 기능을 추가하고 제거할 수 있는 것(별로 유용하지 않지만 그럴 때는 기분이 좋아짐)
• 그것은 역동적인 언어입니다.

그것은 다루기에 재미있고 확립되어 있습니다.클라이언트 스크립팅을 위한 "최상의" 것은 아닐 수도 있지만, 분명 즐거운 일이기 때문에 주변에 있는 동안 즐기십시오.

브라우저의 호환성 때문에 동적 페이지를 만들 때 답답하다는 것에는 동의하지만, UI 라이브러리를 통해 완화될 수 있습니다.그것은 더 이상 자바스크립트 자체에 대해 열리지 않아야 합니다. 스윙은 자바에 대해 열려야 합니다.

자바스크립트는 브라우저의 표준 가상 머신입니다.예를 들어, OCaml과 Haskell은 둘 다 자바스크립트를 출력할 수 있는 컴파일러를 가지고 있습니다.제한 사항은 자바스크립트 언어가 아니며, 제한 사항은 자바스크립트를 통해 접근할 수 있는 브라우저 객체, 그리고 컴퓨터를 손상시키지 않고 안전하게 자바스크립트를 실행할 수 있도록 보장하는 접근 제어 모델입니다.현재 접근 제어 기능이 매우 열악하기 때문에 자바스크립트는 안전상의 이유로 브라우저 객체에 대한 접근이 매우 제한적으로만 허용됩니다.하모니 프로젝트는 이 문제를 해결하려고 합니다.

멋진 생각이네요.한 걸음 더 나아가지 그래요?

• HTML 파서 및 레이아웃 엔진(브라우저의 모든 복잡한 비트)을 동일한 VM 언어로 작성합니다.
• 엔진을 웹에 게시합니다.
• 사용할 레이아웃 엔진에 대한 선언문과 해당 URL을 페이지에 제공합니다.

그러면 모든 클라이언트에 새로운 브라우저를 밀어낼 필요 없이 브라우저에 기능을 추가할 수 있습니다. 관련된 새로운 비트가 웹에서 동적으로 로드됩니다.또한 브라우저에서 작동했던 모든 것과 역호환성을 유지하는 말도 안 되는 복잡함 없이 새로운 버전의 HTML을 게시할 수 있습니다. 호환성은 페이지 작성자의 책임입니다.우리는 HTML 이외의 마크업 언어도 실험하게 됩니다. 그리고 물론 우리는 fancy J를 쓸 수 있습니다.IT는 엔진에 컴파일하여 원하는 언어로 웹 페이지를 스크립팅할 수 있습니다.

자바스크립트 외에 어떤 언어라도 가능한 스크립팅 언어로 환영합니다.

자바스크립트보다 다른 언어를 사용하는 것이 더 좋을 것 같습니다.자바는 아마도 태그 사이에 잘 맞지는 않겠지만 하스켈, 클로쥬르, 스칼라, 루비, 그루비와 같은 언어가 도움이 될 것입니다.

얼마 전에 루비스크립트를 보고 왔는데...http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby 및 http://code.google.com/p/ruby-in-browser/
아직 실험적이고 진행 중이지만 유망해 보입니다.
방금 찾은 .Net의 경우: http://www.silverlight.net/learn/dynamic-languages/ 방금 사이트를 찾았지만 흥미로워 보입니다.Apple Mac에서도 작동합니다.

위의 내용이 자바스크립트의 대안을 제공하는 데 얼마나 효과가 있는지는 모르겠지만, 언뜻 보면 꽤 멋져 보입니다.잠재적으로 이를 통해 Java 또는 를 사용할 수 있습니다.브라우저의 샌드박스 내에서 기본적으로 브라우저에서 제공되는 넷 프레임워크.

안전의 경우, 언어가 JVM(또는 .Net 엔진) 내부에서 실행되는 경우, VM에서 보안을 관리하므로 최소한 브라우저 내부에서 실행되는 모든 것에 대해 걱정할 필요가 없습니다.

그럴지도 모르지만, 그러기 위해서는 주요 브라우저들이 이들을 지원하도록 해야 합니다.IE 지원이 가장 어려울 것 같습니다.자바스크립트는 이용 가능하다고 믿을 수 있는 유일한 것이기 때문에 사용됩니다.

제가 ECMAscript 등에 대해 이야기한 개발자들의 대다수는 결국 문제가 스크립트 언어가 아니라 그것이 노출하는 우스꽝스러운 HTML DOM 때문이라는 것을 인정하게 됩니다.DOM과 스크립팅 언어를 혼동하는 것은 ECMA스크립트와 관련하여 공통적인 고통과 좌절의 원인이 됩니다.또한, IIS는 서버측 스크립팅에 JScript를 사용할 수 있으며, Rhino와 같은 것을 사용하면 ECMAscript에서 독립 실행형 앱을 만들 수 있습니다.한동안 ECMAscript를 사용하여 이러한 환경 중 하나에서 작업을 해보고 의견이 변경되는지 확인해 보십시오.

이런 절망은 한동안 계속되고 있습니다.특정 문제를 포함하거나 다시 게시할 수 있도록 편집하는 것이 좋습니다.여러분은 여러분이 얻는 안도감에 기분 좋게 놀랄지도 모릅니다.

오래된 장소이지만, 여전히 시작하기에 좋은 장소: 더글러스 크록포드의 장소.

저희가 VB스크립트를 이미 가지고 있잖아요?잠시만요, IE만 지원합니다!
VM에 대한 좋은 아이디어도 마찬가지입니다.Lua를 사용하여 내 페이지를 스크립팅했는데 브라우저에 바이트코드로 변환할 파서가 없으면 어떻게 합니까?물론, 바이트코드 파일을 받아들이는 스크립트 태그를 상상할 수 있습니다. 그것도 꽤 효율적일 것입니다.
그러나 경험상 웹에 새로운 것을 도입하는 것은 어렵다는 것을 알 수 있습니다. 이와 같은 근본적인 새로운 변화를 도입하려면 몇 년이 걸릴 것입니다.SVG나 CSS3를 지원하는 브라우저는 몇 개입니까?

게다가 JS에서 '더러운'이란 게 뭔지 모르겠네요.아마추어들이 코드화해 다른 곳에서 모방한 나쁜 관행을 전파하면 못생길 수 있지만, 마스터들은 그것이 우아한 언어가 될 수 있다는 것을 보여주었습니다.Perl과 약간 비슷한 경우: 종종 난독화된 언어처럼 보이지만 완벽하게 읽을 수 있습니다.

이것을 확인하세요 http://www.visitmix.com/Labs/Gestalt/ - 사용자가 실버라이트를 설치한 한 파이썬이나 루비를 사용할 수 있습니다.

이것은 아주 좋은 질문입니다.

JS에서 더 큰 프로그램을 개발할 수 있는 좋은 무료 IDE가 부족하기 때문에 JS에서만 문제가 되는 것은 아닙니다.나는 오직 하나만 무료인 이클립스를 알고 있습니다.또 다른 좋은 것은 마이크로소프트의 비주얼 스튜디오이지만 무료는 아닙니다.

왜 공짜일까요?웹 브라우저 공급업체가 데스크톱 앱을 온라인 앱으로 대체하고 싶다면 프로그래머인 우리에게 좋은 개발 도구를 제공해야 합니다.간단한 텍스트 편집기, JSLint 및 내장된 Google Chrome 디버거를 사용하면 50,000줄의 자바스크립트를 만들 수 없습니다.당신이 마코히스트가 아니라면요.

1987년 볼랜드가 터보 파스칼 4.0을 위한 IDE를 만들었을 때 프로그래밍의 혁명이었습니다.그로부터 24년이 지났습니다.부끄러운 것은 2011년에도 많은 프로그래머들이 코드 완성, 구문 검사, 적절한 디버거를 사용하지 않는다는 것입니다.아마도 좋은 IDE가 너무 적기 때문일 것입니다.

프로그래머가 Windows, Linux, MacOS, iOS, Symbian 등과 싸울 수 있는 애플리케이션을 구축하려면 웹 브라우저 공급업체가 프로그래머를 위한 적절한 (무료) 도구를 만드는 것이 좋습니다.

현실적으로 모든 브라우저가 오랫동안 사용할 언어는 자바스크립트밖에 없기 때문에 다른 언어를 사용하면 매우 좋겠지만 실제로는 그렇게 될 수 없습니다.

말씀하시는 이 "표준화된 VM"은 매우 크기 때문에 모든 주요 브라우저에서 채택해야 할 것이며, 다른 많은 브라우저보다 웹 사이트에 적합하기 때문에 대부분의 사이트에서 자바스크립트를 계속 사용할 것입니다.

이 VM의 각 프로그래밍 언어를 샌드박스화하고 각 언어가 시스템에 액세스하는 양을 줄여야 하므로 언어를 많이 변경하고 많은 기능을 제거하거나 다시 구현해야 합니다.반면에 자바스크립트는 이미 이것을 염두에 두고 있고, 오랫동안 해왔습니다.

아마도 당신은 구글의 네이티브 클라이언트를 찾고 있을 것입니다.

어떤 의미에서 자바 바이트코드와 같은 일반적인 것 대신 브라우저에서 자바스크립트와 같은 더 표현적인 언어를 갖는 것은 더 열린 웹을 의미했습니다.

저는 이것이 그렇게 쉬운 문제가 아니라고 생각합니다.우리는 JS에 갇혀 있다고 말할 수 있지만, jQuery, Prototype, Scriptaculous, MooTools 및 모든 환상적인 라이브러리로 인해 정말 그렇게 나쁜가요?

JS는 경량이며, 현대 브라우저에서 사용되는 새로운 자바스크립트 엔진인 V8, TraceMonkey, SquarlFish를 사용하면 더욱 그렇습니다.

또한, 문제가 있다는 것을 알고 있지만, 초기 보안 문제와 같이 이러한 문제들을 해결할 수 있습니다.브라우저에서 Ruby 코드를 실행하거나 다른 모든 것을 실행할 수 있도록 하는 이미징.보안 샌드박스는 흠잡을 데 없이 행해져야 합니다.그리고 그거 알아?파이썬 사람들은 이미 두 번이나 실패했습니다.

HTML이나 CSS처럼 자바스크립트도 시간이 지나면 수정되고 개선될 것 같습니다.그 과정은 길겠지만, 이 세상에서 모든 것이 가능한 것은 아닙니다.

저는 당신이 "자바스크립트가 단순히 우리가 지금 작업해야 할 것이라는 실용적인 문제를 이해하지 못한다"고 생각하지 않습니다.사실 그것은 매우 강력한 언어입니다.자바 애플릿은 수년간 브라우저에 있었는데, 지금은 어디에 있습니까?

어쨌든, 당신은 고객을 위해 일을 하기 위해 "더러워"질 필요가 없습니다.예를 들어, GWT를 사용해 봅니다.

... 당신 말은...

자바와 자바 애플릿 플래시와 어도비 AIR 등..

일반적으로 모든 RIA 프레임워크는 고객의 요구를 충족시킬 수 있습니다. 그러나 모든 사용자에게 사용에 대한 대가가 있습니다(예: 브라우저에서 실행 시간 또는/및 속성 또는 순수 데스크톱보다 적은 옵션) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks .

웹 이외의 언어로 웹을 개발하려면 GWT: 자바를 개발하고 자바스크립트로 컴파일합니다.

이미 바이트코드 인터프리터가 있는 VM이 모두 있고, 바이트코드도 모두 다르기 때문입니다.{차크라(IE), 파이어폭스(거미원숭이), 사파리(다람쥐 물고기), 오페라(카라칸).

죄송합니다, 크롬(V8)은 IA32 머신 코드로 컴파일된 것 같습니다.

모든 브라우저가 이미 VM을 사용하는 것을 고려하면 웹용 VM 언어를 만드는 것은 그리 어렵지 않을 것으로 생각합니다.
다음과 같은 몇 가지 이유로 큰 도움이 될 것 같습니다.
1. 서버가 코드를 컴파일하기 때문에 전송되는 데이터의 양이 적으며 클라이언트는 코드를 컴파일할 때 시간을 낭비하지 않습니다.
2. 서버는 코드를 준비하여 컴파일하고 저장할 수 있기 때문에, JS를 빠르게 컴파일하는 클라이언트와는 달리 더 나은 코드 최적화를 할 수 있습니다.
3. 언어를 바이트 코드로 컴파일하는 것이 JS로 변환하는 것보다 훨씬 쉽습니다.

(다른 코멘트에서 이미 누군가가 말했듯이) 최종 노트로서 HTML과 CSS는 더 간단한 언어로 컴파일됩니다. 바이트 코드로 계산되는지 확실하지 않지만 서버에서 클라이언트로 컴파일된 HTML과 CSS를 보낼 수 있으므로 구문 분석 및 페치 시간을 줄일 수 있습니다.

IMO, 자바스크립트, 언어는 문제가 아닙니다.자바스크립트는 사실 표현력이 뛰어나고 강력한 언어입니다.고전적인 OO 기능이 없어서 평판이 안 좋은 것 같지만, 저는 프로토타입 그루브를 더 많이 사용할수록 더 마음에 듭니다.

문제는 우리가 웹에서 지원할 수밖에 없는 많은 브라우저 전반에 걸쳐 불완전하고 일관성이 없는 구현이라는 것입니다.jQuery와 같은 자바스크립트 라이브러리는 이러한 더러운 느낌을 완화하는 데 큰 도움이 됩니다.

언급URL : https://stackoverflow.com/questions/86426/why-javascript-rather-than-a-standard-browser-virtual-machine