As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am an experienced AS3 programmer, and I've done Flash apps and games on the browser and on mobile (via Adobe AIR, e.g., on Android).
I am about to start developing a game (basic 2D platformer with pixelart graphics. Think about Super Mario World) targeted to both web and mobile platforms. Thus I'm searching for easy deployment to these two kinds of platforms, having basically the same source code.
I'm divided between choosing ActionScript 3.0 (Flash) or HTML5/JavaScript for developing this game.
My main question is, for those who've experienced the same situation before:
What is the safest way to go?
In other words, are there serious disadvantages with one of these frameworks that disallows me to develop multiplatform 2D games?
Or am I just dreaming and practical multiplatform (web and mobile) game development is not so possible? (does someone know how Rovio did it with Angry Birds?)
Here are some pros and cons that I already know:
Pros for AS3/Flash:
The state-of-art for web games.
I'm experienced with it.
(Almost) concealed source code.
On the web, it's browser-independent.
Can run as a "native" app on iOS and Android through Adobe AIR. It's not the best performance experience ever, but I know that you can get playable performances with it.
Cons for AS3/ Flash:
Performance on AIR for mobile is not optimal, so I might end up having to abandon a really cool but expensive feature (or even several features).
People are saying HTML5/Javascript will substitute it.
Pros for HTML5/Javascript:
It's possible to do Flash-quality games using, e.g., engines like ImpactJS or Akihabara.
Seems to be more stable and well supported on mobile in the future.
Deployment as native app is possible through PhoneGap, appMobi, etc.
Cons for HTML5/Javascript:
I have some basic knowledge of this technology.
Source code is wide open exposed.
Performance/behaviour is browser-dependent.
Lacks a solid framework or engine which is free of co$t$.
I've decided to forget about HTML5 for cross-platform game development, and specially for deployment to mobile.
The cons I've pointed out for Flash are much lighter than the cons for HTML5. Basically, for the pixelart kind of games, Flash on mobile performs really well, specially if using some nice engine like Flixel.
For example, the Flixel game Robo Run has great performance both on Android and Flash Player in a browser. I don't have an iOS example for the same game, but I believe it would perform as good as on Android.
Plus, Flash performance on mobile shouldn't be an increasing problem since the hardware on these devices just gets better and better.
After thinking about this HTML5 vs Flash issue for several months, I think there's no point adventuring in HTML5 cross-browser compatibility since Flash has proven to be a sort of Java for 2D games.
I think you have outlined the pros and cons pretty effectively. If cross platform and mobile web development is your top priority, Flash is a good choice. You will have all of the drawbacks you have identified.
If you use javascript/HTML such as the impact engine, you will have a different set of problems, and far less compatibilty on the web side.
However, if having the game be the best it can be, you will need to look elsewhere, because as of the present, there is no code once publish anywhere solution.
Unity 3D has good 3D and 2d mobile capabilities.
Appcellerator may also be your cup of tea.
http://www.appcelerator.com/
But in the final analysis, nothing will beat making different versions for different platforms. in terms of performance, and being best suited to the device. Be sure to evaluate how well your chosen solution allows you to monetize your app as well. You'll likely be building multiple versions just to accomodate differences in revenue models and ad serving capabilities.
=== Update ===
In March of 2012 Adobe updated flash for iOS and Android to include support for OpenGL graphics, 3D and 2D graphics are now possible using flash as a single code base for iOS and Android. The speed is good, and you also can deply the same game to web. Its a great tool. The one drawback is that flash relies on "extensions" to connect to native OS capabilites such as Intents on android or Game Center on iOS. If you plan on using native capabilities extensively, look out for this as an obstacle to development.
As ScanPlayGames said, html5 sound is a big issue. There are some neat WebGL ports though. Dominic at Impact has been doing some amazing stuff. He's got the best framework out there.
Rovio did a port using Google Web Toolkit for the chrome store.
I work for AppMobi. We've got a tool called DirectCanvas for iOS (Android will be coming soon) that increases the performance of games in the webview. One of our partners is developing a game that has the concept of Angry Birds (object A is propelled to destroy other objects). So Box2d support is there (the main thing holding us up from releasing). The performance is awesome, and the average joe doesn't know it's a webview game.
And trust me, you wont' be wasting your time doing development on mobile first for desktop then. We've got some stuff up our sleeves.
I'm a Flash games developer too and did some research on how to migrate to HTML5. There are a lot of obstacles if you come from the Flash/ActionScript3 world. One of those things is JavaScript itself - i know many people like JavaScript, but if you are used to AS3 it is hard. Another thing is the problem with sounds (as mentioned above). The most important thing is that i don't want to start from scratch and i want to use my skills or even migrate code from the past.
To make a long story short i ended up with Googles new programming language called Dart. This language compiles to JavaScript in therefore runs on all modern browsers. The most important thing is that Dart is very similar to ActiontScript3! Then i did an open source library which provides all the Flash API you need for games (The Display List, Bitmaps, Sounds, ...) - i tried to make the library as compatible as possible with the Flash API to simplify the process of porting the source of a game. In the end it was pretty easy because you only need to change a few things.
The game i have migrated:
An ActionScript to Dart comparison:
Some other samples and the link to the source:
I think a big disadvantage of Javascript is that it cannot detect picture's transparent regions so that it can stop reacting while mice hover or click on it.
Since HTML5 was released, any new solution has been created?
I have worked with some people who did a very graphics intensive HTML5 application and the worst thing was doing the sound I remember...every browser had to be done differently. Go look for some open source html 5 game frameworks where people have already done the grunt work of testing across browsers...there are some pretty good ones I think. You dont want to have to be the one QA-ing across environments.
Everyone keeps saying flash is dead, silverlight is dead, and the future is HTML 5. Most technical people I've talked to seem feel that this is a generally accepted fact. Just a matter of when the spec will be finalized, and when each major browser will finally incorporate all the individual features. But it seems to me there's a big elephant in this room: where are the tools?
Flash. Maybe on it's way out, but it had one hell of a designer. It had drawing tools, layers, timeline support, tweening, etc. It made building rich UI and animations REALLY EASY, which is why it's everywhere. Without flash I'm assuming we turn to canvas? We can't be planning on doing all our UI in code? Where is my 'Canvas Studio MX'?
Video. So we agreed on a totally open/free format with ogg vorbis. Sweet. Is there a good open source set of libraries out there for converting/authoring an ogg file?
Javascript. If we jump on board the HTML5 bus, we're pretty much all agreeing that the engine runs only on Javascript right? Is there some really effective JS IDE out there? Notepad++ is good, but is there something that can make refactoring a really huge application NOT a PITA? And here I'm referring to the fact that JS is dynamically typed, and so today it seems really difficult to get A)Intellisense, and B)Refactoring Support(Rename Method, Get Reference Count etc.). Either the language needs to change, or we need a really smart editor.
Maybe I'm raving here, but I'm a web dev by profession, and I would LOVE to get away from propietary compilers and overcomplicated,convoluted 'super tools' that cause more problems that they fix. But these points seems like real problems to me, and I'm surprised they aren't being given more attention. Or maybe they are, and if so, please feel free to show me the light :)
Web developers come from a variety of backgrounds ranging from Computer science to Graphic design. The coding environment they use reflects this variety and whilst some coders are comfortable writing an entire application using only Textmate, some others prefer to work with Aptana, the Flash IDE or Dreamweaver ( no quality comparison here ).
I think your point is valid , if Flash is about to be replaced by HTML5 , the web developers who were using tools such as the Flash IDE will expect tools on the par with what they're used too.
Another way to look at your question could be to wonder if Flash's announced death isn't the death of a certain vision of the web. A vision led by creatives who , not comfortable with the pure coding approach , could nonetheless express themselves with Flash, which to a certain extent , hid some of the complexities of programming or at least made it easier for them to tackle.
I agree that there are some tools missing at the moment and as PatrickS mentions, it depends on your perspective and what you are used too.
A website developer would be fairly happy at the moment. Not much changes for them. They keep the same workflow and as more tools become available they will be added to their environment - and besides, they can get by with just copying-n-pasting with notepad etc.
An animator can currently not do much with HTML5. They require a tool such as Flash IDE. It must also integrate with packages such as illustrator. Could be a while before we see a stable, usable tool.
An Applications developer (which is the area that I fall into) will probably try to avoid HTML5. Simply because JavaScript is not suitable for large applications development. Netbeans at the very least exists and appears to support things like code completion, refactoring etc which will help if you end up having to do some serious JS development- but I suspect it does not match Visual Studio.
A games developer developing something of significance would have the same issues at the applications developer and animator. While yes you can make a game just through code, things like platformers, adventures games etc really need a Flash IDE to layout all the graphic assets. Likewise, for programming, JavaScript will be more pain than AS3 or C#
Flash: There are a number of strong languages that do amazing things without the nice fluffy UI and timeline, layers and such. I'm sure one will come along, but is not a show-stopper, not do many people care right now - so no elephant (IMHO).
Javascript: There is no shortage of places IDE's where you can use Javascript. Sure you can use Notepad if you like, or else Eclipse, TextMate etc... I see an editor as an aid and not a dependency when refactoring code. JS has its problems but to date its proven (again, just my opinion) that it has more to offer to compensate for that.
I'd like to write some small applications for Windows and OSX.
Portable is good. For instance, the simple TclKit solution for TCL would work well if I could stand to look at Tcl for any length of time.
I'm considering using Javascript + extensions -- I really like Javascript -- seems to me there should be some way to connect a Javascript engine to WxWin or even the Tk toolset -- it's been done for Perl, Python, Ruby, etc. Why not JS?
Any comments appreciated.
I would rather recommend using Adobe Air execution container, it offers way more capabilities / OS integration features compared to HTA of Microsoft or even XULRunner of Mozilla.
If you want to write a desktop app in Javascript, check out HTA: http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx
Here is an example of an app that I wrote a long time ago in HTA: http://www.boltbait.com/htmleditor/
Hope this helps.
If you have experience with HTML+JS web applications, I'd recommend Mozilla XULRunner. It gives you native-looking interface widgets (every piece of Firefox interface is a XUL element), and a workflow similar to building HTML-based interface.
You define the interface using XUL, an XML-based language, so it's almost like writing HTML, minus browser incompatibilities and CSS (you can use CSS, but only if you want). All application logic can be written in JavaScript, but in XULRunner you can do a lot more in JS than in a browser (read/write files, execute system commands, make cross-domain XMLHTTPRequests, and a lot of other stuff).
More: http://xulplanet.com/
A lot of example applications: http://code.google.com/p/xulapps/
Mac OS X users tend to dislike applications that don't follow usability guidelines of the platform (menu must be at top of the screen, standard shortcuts & drag'n'drop must work, "OK" must be at right-hand side of alertboxes, no "Apply" button in prefs and so on).
With one-size-fits-all toolkit this may be very difficult to achieve.
The good news is that there's JavaScript<>Cocoa bridge that can be used to create stand-alone full-featured Mac OS X application in JS – just keep front-end and back-end of your application separate enough to be able to plug different UI for each OS.
Rhino would probably give you access to swing. Though, I don't know how much work would be involved.
On the other hand, building a swing app with JRuby is so easy even a sock puppet can do it, so it shouldn't be too hard.
Definitely if you want to implement it using JavaScript, Adobe Air is the way to go. You will even have support on Linux.
Give Titanium Appceletaror a look: http://www.appcelerator.com/.
Would it not make sense to support a set of languages (Java, Python, Ruby, etc.) by way of a standardized virtual machine hosted in the browser rather than requiring the use of a specialized language -- really, a specialized paradigm -- for client scripting only?
To clarify the suggestion, a web page would contain byte code instead of any higher-level language like JavaScript.
I understand the pragmatic reality that JavaScript is simply what we have to work with now due to evolutionary reasons, but I'm thinking more about the long term. With regard to backward compatibility, there's no reason that inline JavaScript could not be simultaneously supported for a period of time and of course JavaScript could be one of the languages supported by the browser virtual machine.
Well, yes. Certainly if we had a time machine, going back and ensuring a lot of the Javascript features were designed differently would be a major pastime (that, and ensuring the people who designed IE's CSS engine never went into IT). But it's not going to happen, and we're stuck with it now.
I suspect, in time, it will become the "Machine language" for the web, with other better designed languages and APIs compile down to it (and cater for different runtime engine foibles).
I don't think, however, any of these "better designed languages" will be Java, Python or Ruby. Javascript is, despite the ability to be used elsewhere, a Web application scripting language. Given that use case, we can do better than any of those languages.
I think JavaScript is a good language, but I would love to have a choice when developing client-side web applications. For legacy reasons we're stuck with JavaScript, but there are projects and ideas looking for changing that scenario:
Google Native Client: technology for running native code in the browser.
Emscripten: LLVM bytecode compiler to javascript. Allows LLVM languages to run in the browser.
Idea: .NET CLI in the browser, by the creator of Mono: http://tirania.org/blog/archive/2010/May-03.html
I think we will have JavaScript for a long time, but that will change sooner or later. There are so many developers willing to use other languages in the browser.
Answering the question - No, it would not make sense.
Currently the closest things we have to a multi-language VM are the JVM and the CLR. These aren't exactly lightweight beasts, and it would not make sense to try and embed something of this size and complexity in a browser.
Let's examine the idea that you could write a new, multilanguage VM that would be better than the existing solution.
You're behind on stability.
You're behind on complexity (way, way, behind because you're trying to generalize over multiple languages)
You're behind on adoption
So, no, it doesn't make sense.
Remember, in order to support these languages you're going to have to strip down their APIs something fierce, chopping out any parts that don't make sense in the context of a browser script. There are a huge number of design decisions to be made here, and a huge opportunity for error.
In terms of functionality, we're probably only really working with the DOM anyway, so this is really an issue of syntax and language idom, at which point it does make sense to ask, "Is this really worth it?"
Bearing in mind, the only thing we're talking about is client side scripting, because server side scripting is already available in whatever language you like. It's a relatively small programming arena and so the benefit of bringing multiple languages in is questionable.
What languages would it make sense to bring in? (Warning, subjective material follows)
Bringing in a language like C doesn't make sense because it's made for working with metal, and in a browser there isn't much metal really available.
Bringing in a language like Java doesn't make sense because the best thing about it is the APIs anyway.
Bringing in a language like Ruby or Lisp doesn't make sense because JavaScript is a powerful dynamic language very close to Scheme.
Finally, what browser maker really wants to support DOM integration for multiple languages? Each implementation will have its own specific bugs. We've already walked through fire dealing with differences between MS Javascript and Mozilla Javascript and now we want to multiply that pain five or six-fold?
It doesn't make sense.
On Windows, you can register other languages with the Scripting Host and have them available to IE. For example VBScript is supported out of the box (though it has never gained much popularity as it is for most purposes even worse than JavaScript).
The Python win32 extensions allowed one to add Python to IE like this quite easily, but it wasn't really a good idea as Python is quite difficult to sandbox: many language features expose enough implementation hooks to allow a supposedly-restricted application to break out.
It is a problem in general that the more complexity you add to a net-facing application like the browser, the greater likelihood of security problems. A bunch of new languages would certainly fit that description, and these are new languages that are also still developing fast.
JavaScript is an ugly language, but through careful use of a selective subset of features, and support from suitable object libraries, it can generally be made fairly tolerable. It seems incremental, practical additions to JavaScript are the only way web scripting is likely to move on.
I would definitely welcome a standard language independent VM in browsers (I would prefer to code in a statically typed language).
(Technically) It's quite doable gradually: first one major browser supports it and server has the possibility to either send bytecode if current request is from compatible browser or translate the code to JavaScript and send plain-text JavaScript.
There already exist some experimental languages that compile to JavaScript, but having a defined VM would (maybe) allow for better performance.
I admit that the "standard" part would be quite tricky, though. Also there would be conflicts between language features (eg. static vs. dynamic typing) concerning the library (assuming the new thing would use same library). Therefore I don't think it's gonna happen (soon).
If you feel like you are getting your hands dirty, then you have either been brainwashed, or are still feeling the after affects of the "DHTML years". JavaScript is very powerful, and is suited well for its purpose, which is to script interactivity client side. This is why JavaScript 2.0 got such a bad rap. I mean, why packages, interfaces, classes, and the like, when those are clearly aspects of server-side languages. JavaScript is just fine as a prototype-based language, without being full-blown object oriented.
If there is a lack of seamlessness to your applications because the server-side and client-side are not communicating well, then you might want to reconsider how you architect your applications. I have worked with extremely robust Web sites and Web applications, and I have never once said, "Hmm, I really wish JavaScript could do (xyz)." If it could do that, then it wouldn't be JavaScript -- it would be ActionScript or AIR or Silverlight. I don't need that, and neither do most developers. Those are nice technologies, but they try to solve a problem with a technology, not a... well, a solution.
I don't think that a standard web VM is that inconceivable. There are a number of ways you could introduce a new web VM standard gracefully and with full legacy support, as long as you ensure that any VM bytecode format you use can be quickly decompiled into javascript, and that the resulting output will be reasonably efficient (I would even go so far as to guess that a smart decompiler would probably generate better javascript than any javascript a human could produce themselves).
With this property, any web VM format could be easily decompiled either on the server (fast), on the client (slow, but possible in cases where you have limited control of the server), or could be pre-generated and loaded dynamically by either the client or the server (fastest) for browsers that don’t natively support the new standard.
Those browsers that DO natively support the new standard would benefit from increased speed of the runtime for web vm based apps. On top of that, if browsers base their legacy javascript engines on the web vm standard (i.e. parsing javascript into the web vm standard and then running it), then they don’t have to manage two runtimes, but that’s up to the browser vendor.
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.
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
as WebAssembly evolves it will support more languages than C/C++, and we hope that other compilers will support it as well.
I let you have a closer look at the official page of the project, it is truly exciting!
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!
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.
well, considering all browsers already use a VM, I don't think it will be that difficult to make a VM language for the web.
I think it would greatly help for a few reasons:
1. since the server compiles the code, the amount of data sent is smaller and the client doesn't waist time on compiling the code.
2. since the server can compile the code in preparation and store it, unlike the client which tries to waist as little time quickly compiling the JS, it can make better code optimizations.
3. compiling a language to byte code is way easier then transpiling to JS.
as a final note (as someone already said in another comment), HTML and CSS compile down to a simpler language, not sure if it counts as byte code, but you could also send compiled html and css from the server to the client which would reduce parse and fetch times
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.