표준 브라우저 가상 머신이 아닌 왜 JavaScript입니까?
특수 언어 (실제로 특수 패러다임)를 사용하지 않고 브라우저에서 호스팅되는 표준화 된 가상 머신을 통해 언어 세트 (Java, Python, Ruby 등)를 지원하는 것이 합리적이지 않습니까? 클라이언트 스크립팅 전용?
제안을 명확히하기 위해 웹 페이지에는 JavaScript와 같은 고급 언어 대신 바이트 코드가 포함됩니다.
나는 진화론 적 이유 때문에 JavaScript가 우리가 지금해야 할 일이라는 실제적인 현실을 이해하지만, 장기적으로 더 생각하고 있습니다. 이전 버전과의 호환성과 관련하여 일정 기간 동안 인라인 JavaScript를 동시에 지원할 수 없었으며 JavaScript는 브라우저 가상 머신에서 지원하는 언어 중 하나 일 수 있습니다.
그래 확실히 우리가 타임머신을 가지고 있다면, 돌아가서 많은 자바 스크립트 기능이 다르게 설계되었는지 확인하는 것은 큰 취미가 될 것입니다 (IE의 CSS 엔진을 디자인 한 사람들이 결코 IT에 들어 가지 않도록하는 것). 그러나 그것은 일어나지 않을 것이고, 우리는 지금 그것에 붙어 있습니다.
시간이 지나면 웹에 대한 "기계 언어"가 될 것으로 의심되며, 더 잘 설계된 다른 언어와 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 표준으로 구문 분석 한 후 실행) 두 개의 런타임을 관리 할 필요는 없지만 브라우저 공급 업체에 달려 있습니다. .
While Javascript is the only well-supported scripting language you can control the page directly from, Flash has some very nice features for bigger programs. Lately it has a JIT and can also generate bytecode on the fly (check out runtime expression evaluation for an example where they use flash to compile user-input math expressions all the way to native binary). The Haxe language gives you static typing with inference and with the bytecode generation abilities you could implement almost any runtime system of your choice.
this question resurfaces regularly. my stance on this is:
A) wont happen and B) is already here.
pardon, what? let me explain:
ad A
a VM is not just some sort of universal magical device. most VMs are optimized for a certain language and certain language features. take the JRE/Java (or LLVM): optimized for static typing, and there are definitely problems and downsides when implementing dynamic typing or other things java didn't support in the first place.
so, the "general multipurpose VM" that supports lots of language features (tail call optimization, static & dynamic typing, foo bar boo, ...) would be colossal, hard to implement and probably harder to optimize to get good performance out of it. but i'm no language designer or vm guru, maybe i'm wrong: it's actually pretty easy, only nobody had the idea yet? hrm, hrm.
ad B
already here: there may not be a bytecode compiler/vm, but you don't actually need one. afaik javascript is turing complete, so it should be possible to either:
- create a translator from language X to javascript (e.g. coffeescript)
- create a interpreter in javascript that interprets language X (e.g. brainfuck). yes, performance would be abysmal, but hey, can't have everything.
ad C
what? there wasn't a point C in the first place!? because there isn't ... yet. google NACL. if anyone can do it, it's google. as soon google gets it working, your problems are solved. only, uh, it may never work, i don't know. the last time i read about it there were some unsolved security problems of the really tricky kind.
apart from that:
javascript's been there since ~1995 = 15 years. still, browser implementations differ today (although at least it's not insufferable anymore). so, if you start something new yet, you might have a version working cross browser around 2035. at least a working subset. that only differs subtly. and needs compatibility libs and layers. no point in not trying to improve things though.
also, what about readable source code? i know a lot of companies would prefer not to serve their code as "kind-of" open source. personally, i'm pretty happy i'm able to read the source if i suspect something fishy or want to learn from it. hooray for source code!
Quick update on this old question.
Everyone who affirmed that a "web page would contain byte code instead of any higher-level language like JavaScript" "won't happen".
June 2015 the W3C announced WebAssembly that is
a new portable, size- and load-time-efficient format suitable for compilation to the web.
This is still experimental, but there is already some prototypal implementation in Firefox nightly and Chrome Canary and there is already some demonstration working.
Currently, WebAssembly is mostly designed to be produced from C/C++, however
I let you have a closer look at the official page of the project, it is truly exciting!
Indeed. Silverlight is effectively just that - a client side .Net based VM.
There are some errors in your reasoning.
A standard virtual machine in a standard browser will never be standard. We have 4 browsers, and IE has conflicting interests with regard to 'standard'. The three others are evolving fast but adoption rate of new technologies is slow. What about browsers on phones, small devices, ...
The integration of JS in the different browsers and its past history leads you to under-estimating the power of JS. You pledge a standard, but disapprove JS because standard didn't work out in the early years.
As told by others, JS is not the same as AIR/.NET/... and the like. JS in its current incarnation perfectly fits its goals.
In the long term, Perl and Ruby could well replace javascript. Yet the adoption of those languages is slow and it is known that they will never take over JS.
How do you define best? Best for the browser, or best for the developer? (Plus ECMAScript is different than Javascript, but that is a technicality.)
I find that JavaScript can be powerful and elegant at the same time. Unfortunately most developers I have met treat it like a necessary evil instead of a real programming language.
Some of the features I enjoy are:
- treating functions as first class citizens
- being able to add and remove functions to any object at any time (not useful much but mind blowing when it is)
- it is a dynamic language.
It's fun to deal with and it is established. Enjoy it while it is around because while it may not be the "best" for client scripting it is certainly pleasant.
I do agree it is frustrating when making dynamic pages because of browser incompatibilities, but that can be mitigated by UI libraries. That should not be held against JavaScript itself anymore than Swing should be held against Java.
JavaScript is the browser's standard virtual machine. For instance, OCaml and Haskell now both have compilers that can output JavaScript. The limitation is not JavaScript the language, the limitation is the browser objects accessible via JavaScript, and the access control model used to ensure you can safely run JavaScript without compromising your machine. The current access controls are so poor, that JavaScript is only allowed very limited access to browser objects for safety reasons. The Harmony project is looking to fix that.
It's a cool idea. Why not take it a step further?
- Write the HTML parser and layout engine (all the complicated bits in the browser, really) in the same VM language
- Publish the engine to the web
- Serve the page with a declaration of which layout engine to use, and its URL
Then we can add features to browsers without having to push new browsers out to every client - the relevant new bits would be loaded dynamically from the web. We could also publish new versions of HTML without all the ridiculous complexity of maintaining backwards compatibility with everything that's ever worked in a browser - compatibility is the responsibility of the page author. We also get to experiment with markup languages other than HTML. And, of course, we can write fancy JIT compilers into the engines, so that you can script your webpages in any language you want.
I would welcome any language besides javascript as possible scripting language.
What would be cool is to use other languages then Javascript. Java would probably not be a great fit between the tag but languages like Haskell, Clojure, Scala, Ruby, Groovy would be beneficial.
I came a cross Rubyscript somewhile ago ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby and http://code.google.com/p/ruby-in-browser/
Still experimental and in progress, but looks promising.
For .Net I just found: http://www.silverlight.net/learn/dynamic-languages/ Just found the site out, but looks interesting too. Works even from my Apple Mac.
Don't know how good the above work in providing an alternative for Javascript, but it looks pretty cool at first glance. Potentially, this would allow one to use any Java or .Net framework natively from the browser - within the browser's sandbox.
As for safety, if the language runs inside the JVM (or .Net engine for that matter), the VM will take care of security so we don't have to worry about that - at least not more then we should for anything that runs inside the browser.
Probably, but to do so we'd need to get the major browsers to support them. IE support would be the hardest to get. JavaScript is used because it is the only thing you can count on being available.
The vast majority of the devs I've spoken to about ECMAScript et. al. end up admitting that the problem isn't the scripting language, it's the ridiculous HTML DOM that it exposes. Conflating the DOM and the scripting language is a common source of pain and frustration regarding ECMAScript. Also, don't forget, IIS can use JScript for server-side scripting, and things like Rhino allow you to build free-standing apps in ECMAScript. Try working in one of these environments with ECMAScript for a while, and see if your opinion changes.
This kind of despair has been going around for some time. I'd suggest you edit this to include, or repost with, specific issues. You may be pleasantly surprised by some of the relief you get.
A old site, but still a great place to start: Douglas Crockford's site.
Well, we have already VBScript, don't we? Wait, only IE supports it!
Same for your nice idea of VM. What if I script my page using Lua, and your browser doesn't have the parser to convert it to bytecode? Of course, we could imagine a script tag accepting a file of bytecode, that even would be quite efficient.
But experience shows it is hard to bring something new to the Web: it would take years to adopt a radical new change like this. How many browsers support SVG or CSS3?
Beside, I don't see what you find "dirty" in JS. It can be ugly if coded by amateurs, propagating bad practice copied elsewhere, but masters shown it can be an elegant language too. A bit like Perl: often looks like an obfuscated language, but can be made perfectly readable.
Check this out http://www.visitmix.com/Labs/Gestalt/ - lets you use python or ruby, as long as the user has silverlight installed.
This is a very good question.
It's not the problem only in JS, as it is in the lack of good free IDEs for developing larger programs in JS. I know only one that is free: Eclipse. The other good one is Microsoft's Visual Studio, but not free.
Why would it be free? If web browser vendors want to replace desktop apps with online apps (and they want) then they have to give us, the programmers, good dev tools. You can't make 50,000 lines of JavaScript using a simple text editor, JSLint and built-in Google Chrome debugger. Unless you're a macohist.
When Borland made an IDE for Turbo Pascal 4.0 in 1987, it was a revolution in programming. 24 years have passed since. Shamefully, in the year 2011 many programmers still don't use code completion, syntax checking and proper debuggers. Probably because there are so few good IDEs.
It's in the interest of web browser vendors to make proper (FREE) tools for programmers if they want us to build applications with which they can fight Windows, Linux, MacOS, iOS, Symbian, etc.
Realistically, Javascript is the only language that any browsers will use for a long time, so while it would be very nice to use other languages, I can't see it happening.
This "standardised VM" you talk of would be very large and would need to be adopted by all major browsers, and most sites would just continue using Javascript anyway since it's more suited to websites than many other browsers.
You would have to sandbox each programming language in this VM and reduce the amount of access each language has to the system, requiring a lot of changes in the languages and removal or reimplementation of many features. Whereas Javascript already has this in mind, and has done a for a long time.
Maybe you're looking for Google's Native Client.
In a sense, having a more expressive language like Javascript in the browser instead of something more general like Java bytecode has meant a more open web.
I think this is not so easy issue. We can say that we're stuck with JS, but is it really so bad with jQuery, Prototype, scriptaculous, MooTools, and all fantastic libraries?
Remember, JS is lightweight, even more so with V8, TraceMonkey, SquirrelFish - new Javascript engines used in modern browsers.
It is also proved - yeah, we know it has problems, but we have lots of these sorted out, like early security problems. Imaging allowing your browser to run Ruby code, or anything else. Security sandbox would have to be done for scratch. And you know what? Python folks already failed two times at it.
I think Javascript is going to be revised and improved over time, just like HTML and CSS is. The process may be long, but not everything is possible in this world.
I don't think you "understand the pragmatic issue that JavaScript is simply what we have to work with now". Actually it is very powerful language. You had your Java applet in browser for years, and where is it now?
Anyhow, you don't need to "get dirty" to work on client. For example, try GWT.
... you mean...
Java and Java applet Flash and Adobe AIR etc..
In general, any RIA framework can fill your needs; but for every one there's a price to pay for using it ( ej. runtime avalible on browser or/and propietary or/and less options than pure desktop ) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks
For developing Web with any non-web languaje, you've GWT: develop Java, compile to Javascript
Because they all have VMs with bytecode interpreters already, and the bytecode is all different too. {Chakra(IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera(Carakan).
Sorry , I think Chrome (V8) compiles down to IA32 machine code.
IMO, JavaScript, the language, is not the problem. JavaScript is actually quite an expressive and powerful language. I think it gets a bad rep because it's not got classical OO features, but for me the more I go with the prototypal groove, the more I like it.
The problem as I see it is the flaky and inconsistent implementations across the many browsers we are forced to support on the web. JavaScript libraries like jQuery go a long way towards mitigating that dirty feeling.
JavaScript is your only native, standard option available. If you want lots of power, grab jQuery, but if you need to do a bunch more, consider writing an addon for Firefox? or similar for IE etc.
'IT story' 카테고리의 다른 글
| Android 및 XMPP : 현재 사용 가능한 솔루션 (0) | 2020.05.29 |
|---|---|
| REST 웹 서비스에서 일괄 작업을 처리하기위한 패턴? (0) | 2020.05.29 |
| 오류 : R에서… 기능을 찾을 수 없습니다 (0) | 2020.05.29 |
| mysql 확장은 더 이상 사용되지 않으며 향후 제거 될 예정입니다. 대신 mysqli 또는 PDO를 사용하십시오. [duplicate] (0) | 2020.05.29 |
| 모범 사례 다국어 웹 사이트 (0) | 2020.05.29 |