JavaScript의 대안

JavaScript의 대안

---

현재 유일하게 완전히 지원되는 언어이며 브라우저에서 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 만 중지했습니다).

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로 컴파일 될 수 있습니다 .

• 다트 는 구글이 나중에 자바 스크립트를 대체하려는 시도였다. 선택적인 타이핑이있는 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의 분사 방식으로 간결하게 유명하지만 읽기 쉽지 않습니다. 아마도 팀에게는 최고가 아닐 것입니다.

선택하는 방법?

When choosing an alternative language, there are some factors to consider:

• If other developers join your project in future, how long will it take them to get up to speed and learn this language, or what are the chances they know it already?

• Does the language have too few features (code will still be full of boilerplate) or too many features (it will take a long time to master, and until then some valid code may be undecipherable)?

• Does it have the features you need for your project? (Does your project need type-checking and interfaces? Does it need smart continuations to avoid nested callback hell? Is there a lot of reactivity? Might it need to target other environments in future?)

The future...

Jeff Walker has written a thought-provoking series of blog posts about "the Javascript problem", including why he thinks neither TypeScript, nor Dart nor Coffeescript offer adequate solutions. He suggests some desirable features for an improved language in the conclusion.

---

should be JavaScript the only supported language on the browser platform ?

Yes and no. There is an alternative out there called Dart by Google which does compile to JavaScript and just like jQuery it tries to make DOM manipulation a bit easier. It may be fun to experiment, check it out.

• From Google see The dart language
• From Microsoft see TypeScript language

See also

• Elm
• Kal

---

It is true that Javascript was at one point notoriously hard to deal with but the web development community has come a long way since. Instead, I would encourage you to have a look at jQuery. It's easy and abstracts away all the various problems.

And there really are no alternatives that work across the board. Flash comes to mind but that too is ECMA script and it's probably over kill for most things.

---

Short term, I'd use things like jQuery to hide the browser incompatibilities. Long term, technologies like Silverlight or Adobe AIR may make this a very different minefield (but still a minefield) in the future.

---

Doug Crockford gave a talk to Google detailing the bad and good parts of JavaScript and its future. It actually hasn't changed much at all since 1999--which can be said to be a good thing (pretty much all browsers can run the same code as long as you're aware of their limitations) and Doug shows where the good parts were mostly misunderstandings that turn out to be very powerful.

For DOM manipuluation, look at JQuery as a client-side library that replaces most of the awful DOM API with operations that are a pain to write to pretty elegant bits of code that are easier to write.

---

If you're thinking that JavaScript has deep issues, I recommend Doug Crockford's book, JavaScript: The Good Parts. (Or Google for "Crockford JavaScript" to find several video presentations he's done.) Crockford sketches out a safe subset and set of practices, and specifically lists some parts of the language to avoid.

I'm unaware of plans to replace JavaScript as the de facto means of manipulating the DOM. So best learn to use it safely and well.

---

In terms of client side Javascript is the only way to manipulate the DOM. In terms of server side there are a multitude of ways.

---

Internet Explorer supports pluggable scripting languages, although the only one reliably included with IE besides JScript is VBScript.

As far as I have seen, there seems to be a general sort of bias toward dynamic languages in the browser, and JavaScript seems to fill this need adequately enough that network effects make any other language a non-starter. The language is actually quite powerful, though its implementation in browsers leaves much to be desired.

---

If you're willing to restrict your customers/visitors to specific browsers, and possibly willing to require them to install a plug-in, you could look at MS Silverlight -- a readable overview is on wikipedia. With Silverlight 2, you can run, client-side, code you've written in C#, IronPython, IronRuby, VB.NET, etc; the free Moonlight clone of Silverlight, from the Mono project, promises to bring the same functionality to Linux.

In practice, most developers of web apps and sites prefer to reach wider audiences than Silverlight (and eventually Moonlight) can currently deliver -- which means sticking with Javascript, or possibly Flash (which uses a similar programming language, Actionscript).

So, gaining substantial mindshare, adoption and traction for anything else is proving to be an uphill fight even for Microsoft with its large groups of engineers and marketing budgets and a free-software project on the side (to possibly ease worries about proprietary lock-in) -- which may help explain why there's very little interest, e.g. on the part of the Mozilla Foundation, in pushing towards such a goal. "Apart from interoperability", you say: but clearly the issue of interoperability is THE biggie here, given what we observe wrt Silverlight's progress...

---

As already said, you have Flash (ActionScript, which is a derived language from Javascript) and Silverlight/Moonlight (IronPython, IronRuby, JScript, VBScript, C#) that can run in the browser via plugins (the first one being much more ubiquitous).

There is also another alternative if you like Ruby: HotRuby, it's a ruby implementation in javascript that will run in the browser. It is not very mature yet, but you can have a look at it.

---

One thing I haven't seen mentioned (oh, I see Alcides mentioned HotRuby while I was writing and Nosredna mentioned GWT and Script#) and would like to throw out there is there are a number of implementations of [insert language]-on-JavaScript (eg. translators that allow you to convert Ruby, Python, C#, Java, Obj-J/Cappuccino [similar to Obj-C/Cocoa] or Processing [for Canvas] to JavaScript either on the client or before deployment [and some of which also feature various abstraction libraries]). Of course there's a performance overhead if it is being translated on the client, but if you are more comfortable with another language it will allow you some flexibility.

Personally, though, I recommend learning to love JavaScript. It's an excellent, powerful language, and pretty elegant once you get to know it. I'm facing the opposite dilemma, chomping at the bit to have a capable server-side JavaScript/DOM solution that meets all of my needs. /unsolicited opinion

---

No. JavaScript is it, but it will evolve. The next version is "JavaScript Harmony," and you can learn more if you Google that.

Now and then someone suggests putting a byte code interpreter into the browsers alongside JavaScript. Probably won't happen, at least for awhile.

I happen to love JavaScript. But there are other solutions, including GWT, which compiles Java to JavaScript and Script#, which compiles C# to JavaScript.

---

Jquery (still javascript but) it will really help you they have support for almost all the browsers and it isn't really that hard to learn :)

---

JavaScript is the English language of the web. English historically spread because it had a strong navy conquering various countries. This is comparable to big companies that conquered the web with JavaScript. It's a language clobbered together from multiple European sources (Greek, Latin, Germanic languages, French even some Chinese and Indian words). JavaScript borrowed a lot of concepts throughout the years from other languages (structural, OO, functional). English is spoken in different places with slight variations in dialect and accent, that can render understanding difficult. Just like JavaScript has different browsers interpreting it a bit differently.

Even though English is easy to learn initially, it has very inconsistent pronunciation and more exceptions than rules. Just like JavaScript it's always there to offer a surprise.

Despite the different accents, JavaScript is the lingua franca of the web. Just like you might not be English and write here in English, every web browser has a certain degree of English understanding. IE6 is like the guy who says on his resume that he's fluent, but only went to a two week course on English as a foreign language.

There have been attempts to supplant English as the worlds main language, e.g. Esperanto. But all of them failed, because most people on earth speak some English. In the same way it will be difficult to introduce better alternatives to JavaScript.

---

I don't think Javascript will be replaced any time soon. For a completely different approach to rich clients, you might want to investigate Flex, which is a Flash-based technology.

---

Maybe something like haxe (see haxe.org) could help you. It is a language which seems cleaner than JavaScript and can be compiled down to JavaScript, so it can be run inside a browser.

I know that this is not a direct answer to your question, but I thought it might be interesting for you, nevertheless.

---

Many people understand that Javascript isn't best and prettiest language ever. However, it is currently supported by browsers, and thus it will be extremely hard to introduce a different language. We simply don't need another browser war.

This explains why I know of no plans of switching to a different client-side language.

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

참고 URL : https://stackoverflow.com/questions/930716/alternatives-to-javascript