Related
I want to program my xhtml Web Applications without javascript.
What are the alternatives for creating interactive xhtml web applications?
Perhaps java applets which do the tasks of javascript?
Or is there another way?
Thanks for any help!
Javascript is hard to debug, is dynamically typed, strange OOP, could be replaced by any other language when that language will be cut to work at a browser.
I would also like some typesafety in my code what can discover many bugs before running the code.
--EDIT 2--
Have a look at http://www.scala-js.org/.
---EDIT---
So for now there is no real alternative to javascript what is as flexible, widespread and applicable.
What i think is applicable are frameworks/tools who compile one language to another like GWT or coffescript.
Thank you for the detailed answers. The reason for my question was, that web development is getting more complex every day. I prefer languages like Java for stable error outlining and type safety. JavaScript on the other hand is (in my opinion) mysterious in its ways and hard to debug (browser incompatibilities, silent errors, unintuitive operands, dynamic typing,....). I developed Websites with JS for years now and it feels horrible to me due to such debugging problems and code management. Yet the libraries are quite powerful and ease much of the work.
To have an interactive site you need something that can execute code on the client machine.
This is (at the moment) usually JavaScript. In the past this would have also included Flash or Silverlight (both of which are now on the wane).
JavaScript has a big advantage in that it can easily manipulate the HTML elements directly. While it is possible to do that with Silverlight it's not as easy as Silverlight is designed primarily to build self-contained objects.
Google Web Toolkit GWT lets you write java code which compiles to client-side xhtml+javascript. It relinquishes the page-based standard web approach for a more desktop-like interaction (if I remember correctly the API is somewhat similar to many desktop windowing toolkits).
You may (but don't have to) also develop the (java) server logic and have some client-server communication baked in for you by the compiler.
Have a look at http://code.google.com/intl/it-IT/webtoolkit/
Some JavaScript alternatives:
Flash
Silverlight
Java applets
This is not a recommendation, just a list.
If you're really that allergic to JavaScript, there are a number of frameworks that let you write server-side code which generates the JS for you, as other answers mention.
Check out Google Dart - it has reached 1.0 recently, and has started standardization process few days ago (ECMA TC52). It also compatible with currently available browser via highly optimizing dart2js translator, so you can start using it right now :). Much more sane language than JavaScript, IMO.
More can find more information on the official page here: https://www.dartlang.org/ (tools, documentation, sample code, tutorials), and there is also nice introductory video on the YouTube: http://www.youtube.com/watch?v=FqsU3TbUw_s.
As well as applets you have Adobe Flash, Microsoft Silverlight, shortly Chrome NACL. None of these interact with the HTML DOM as seamlessly as JavaScript though.
One thing you can do is simply have the server-side code do all of the processing. You limit yourself to having only CSS available for interactivity, but you can still do just about everything by loading a new page.
If you're considering java applets, then I guess it's necessary to mention Flash and Silverlight (*).
Of course, there are "interactive" web applications that don't use javascript... they use postback. But I don't think this is what you mean.
If you want to target just Internet Explorer, you can use VBScript (Microsoft's proprietary javascript) or even ActiveX. But I doubt that's what you mean, too.
So the onus is on you to answer — why not javascript?
(*) I guess.
I'd be very interested to know what your reasons are for not wanting to use Javascript? The answer to that question will make a big difference to how your question should be answered.
The Javascript language is actually quite powerful. Yes, it does have some quirks, but so do all other languages. A lot of the perceived "problems" with Javascript development in the browser are actually people having issues with the DOM rather than Javascript itself. The DOM, on the other hand is where a lot of the shortcomings and the cross browser issues crop up.
If this is where your problems lie, then you may be better off using a Javascript library such as JQuery, which abstracts away a lot of the direct access to the DOM, and resolves a lot of the cross-browser issues.
If you're using the latest browsers, a lot of the simple effects that previously required Javascript can now be done using CSS. drop-down menus, tabsets, fading, rotation and transition effects. All of this can be done with CSS. However most of them are quite new, and not available in all browsers currently in common use, so you would be better off sticking to Javascript for at least some of them for the time being. Even when they are ready for mainstream use, you'll still need some Javascript to hook them all together.
If you do really have a burning desire to develop using a language other than Javascript, then as you already pointed out, there are other options for programming on the web, such as Java applets. There's also ActiveX controls, Flash and Silverlight, and a few others. However none of them are universally available to all users in the way that Javascript is.
All of them require browser plug-ins of one sort or another, and all of them have issues with users who don't want to install them or corporate environments that don't allow them to be installed. In the case of technologies like ActiveX, they may only be available on certain browsers and operating systems, and (again like ActiveX) they often have security issues.
The only real reason that most of these other technologies existed in the first place was to fill a gap in the capabilities of the browsers at the time. All of these capability issues have now been resolved -- with HTML5 and related technologies driven by Javascript, Flash and Silverlight have been rendered obsolete; ActiveX controls were considered obsolete long ago; and when was the last time you saw a Java applet in mainstream use?
The bottom line is that the browser world is moving very rapidly away from any client-side code other than Javascript, and there are very good reasons for that.
Use pyjamas (google it), you can write normal python code and have it compiled as javascript so you get the best of both worlds, the power and expressiveness of python and the ubiquity of javascript.
Also keep an eye on the Falcon project by Adobe, it's an experimental compiler which translates actionscript 3 (a very powerful language compared to plain javascript) and the flex framework to javascript.
You can also try GWT by Google, where java is used as the client side building code (and yes, it also gets compiled to native javascript).
If it runs on the client's computer and can modify the DOM, it can work. JavaScript is the most widely supported so it'll work out-of-the-box for many people.
Basically, anything which functions like JavaScript can replace it.
Flash can perform basically everything that JavaScript can (graphically, but it can't modify the DOM), but if the user doesn't have Flash Player installed, you're out of luck.
Java can also work, but the same concept applies: if the user doesn't have JRE (or a similar machine)
Silverlight is similar to Flash, but much less supported (I can barely get it to work on my Linux box)
Just curious: why are you looking to replace JavaScript with something else?
This may seem inane, but I actually like using jQuery much better than JavaScript. It makes event handling and Ajax very simple.
I need to implement a paint type program that will run on all major browsers as well as can be packaged as an app on the iPad/iPhone. After some investigation I have learned the following facts (correct me if any are wrong):
Javascript is entirely too slow to handle an app of this type by itself
HTML5 seems like a good solution, it has a canvas tag and everything and can easily be packaged into a UIWebView for a Cocoa app. However, I need to be able to reach the majority market for web users, which unfortunately includes most IE users who aren't using the public beta for IE 9.
Flash vs. Apple
Right now I'm debating just making two completely separate apps, one in OpenGL ES for iPad/iPhone and another in something like Flash for web browsers. I was just wondering if anyone had an immediate solutions in mind to make one app instead?
I'd question the accuracy of your first point (Javascript is too slow). Since it's possible to run Quake II in pure Javascript, it's likely that your paint application is less resource-intensive and thus could also run. Of course, one could ask how much optimisation effort and/or experience is required to write performant Javascript of this standard - I can't give you an answer there.
But I'm certainly sure that it's possible to get enough performance out of Javascript to implement such a paint tool, in any modern browser. That doesn't preclude the other options, though; using JS along with HTML 5 sounds like the ideal solution here for "out of the box" cross-platform compatibility.
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 11 years ago.
HTML and CSS are showing their age.
SASS generates CSS (because CSS isn't clean enough). Graphic Designers don't work in HTML, they work in graphics tools then have to translate it to HTML/CSS. JavaScript has to have abstractions like jQuery, and CSS has a bunch of hacks to even start approaching consistent predictable user experience.
It feels like people are doing some wonderful things despite the technologies, not because of them.
Surely there is a better way?!? Something more closely aligned with the task at hand.. of providing a fluid intuitive (consistent) user experience to let users achieve their goals.
Thoughts?
Nothing, I believe they are here to stay for next 10 years.
The Internet experience might be enhanced by technologies like Flash & Silverlight but what's valuable about Internet is not the technology but the information.
Therefore, breaking Internet compatibility for pure technological enhancement will never work.
BLTML: Bacon, Lettuce and Tomato Markup Language.
In the future, the web with only be used for posting tasty things we want to eat, so it makes sense to develop a language geared just for this.
The pictures of kittens with words on them will likely be supported with a gross hack .
Graphic Designers don't work in HTML
DTP designers don't produce paper and ink either. Design something and produce something, these are separable tasks - when you have an idea for a tv spot you still need lots of technology between your creativeness and the result, the same applies for the web.
Javascript has to have abstractions
like JQuery, and CSS has a bunch of
hacks to even start approaching
consistent predictable user
experience.
Oh man, js doesn't has to have, developers simply like to make their job easier, this rule applies to various programming languages, it's like saying python has to have django. Frameworks and libraries are over the language, they are not a must.
CSS 'has a bunch of hacks' because some browser producers don't give a damn about something called "standards", not because the language is badly designed.
Surely there is a better way?!?
Something more closely aligned with
the task at hand.. of providing a
fluid intuitive (consistent) user
experience to let users achieve their
goals.
What user experience is not provided with html,css,js? I really don't get your point, and what you expect from the Web.
Oh, and if you are like 'you know, you need flash for something or whatever', start getting interested in canvas.
HTML and CSS are here to stay for a long time yet!
While they may not be as intuitive to use for designers as say PhotoShop, well formed HTML is machine readable - this means that it can be used by humans AND computers. This is very important and useful. Imagine a web full of pictures that look beautiful but cannot be crawled or searched by Google?
HTML and CSS are superior because of the structured information that underlines them.
I don't think that HTML and CSS are showing their age, I think that browsers are showing their age. I like being able to describe what I want done, but not HOW to do it.
I guess what I want is browser vendors to use one rendering engine, or if nothing else, a SSL-type of certification for browsers. Kind of a global impartial body that's measures browsers on a quality bar-like scale.
Just like with SSL certification, it's done by a third party. I'm not sure what the pricing structure would be but I don't think you should have to pay for it. I think that it would make a great "works in this browser" logo like the Spam Free and Mal-ware Free logos we've seen popping up on sites over the years. Or perhaps an Acid1, Acid2, Acid3 passed logos for browsers.
I would argue that libraries like JQuery and Prototype exist because browsers all have their quirks. We just got tired of writing all that handling code, so some very smart people did this for us.
Personally I think HTML and CSS are very elegant, and while the W3C certainly isn't hasty, I think it's probably fair to say that a certain browser has been holding back design on the web more than the technologies themselves.
CSS3 has support for fantastic things such as web fonts with #fontface. Javascript engines are becoming increasingly speedy and allowing for things like John Resig's processing port which would have been unimaginable years ago.
We need to see users adopting new browsers at a faster pace, and we need to see vendors getting behind efforts to encourage their users to upgrade.
I think it's a mistake to think that abstractions are a negative thing, and indicate some problem with the base technology - technologies naturally evolve through abstraction. There's some inconsistency in your post in the sense that you decry the need for abstraction, but then mention that you desire consistency - that consistency across clients is achieved through abstraction. I no longer have to worry about how different clients handle the DOM - jquery does this for me. CSS hacks by the same token aren't really necessary, and it's quite acceptable to serve a different stylesheet to that browser; the rendering difference between the other mainstream engines are pretty minimal.
Please also consider that we're still using a lot of "old" technologies (Unix, c, c++ to name a few), because they are functional, elegant and well designed.
Worse is better. HTML and CSS are never going away because of the large volume of content that's written against that platform. Same thing with C. It's a terrible language, but it will always be with us because nearly all software is written in either C or C++.
A huge volume of JAVA means that's never going away. There's still a market for COBOL programmers.
It's a popular idea among some programmers to get really frustrated at a crufty system like HTML/CSS/JS, and think "Hay, let's demolish it and start over". Well you know, I could invent my own phone that is 100 times better, and with better sound quality than any other phone. That's the easy part. The hard part is having someone to call.
Like it or not, HTML/CSS/JS is the technology trio that became popular, and that means millions of people have invested trillions of dollars in producing content for the technology. Millions of people will be quite reluctant to throw that effort away because someone says HTML/CSS/JS sucks.
It's a mysterious thing figuring out what technology is going to become popular. It's not something you can control for the benefit of your own comfort. But at least, you know, there's such lovely computer science concepts as "abstraction", which if you can master it, will be your secret weapon. Jquery is an example, but it can be taken very much further.
The problem would not be to design something to replace HTML/CSS/JS, but to get browser vendors to adopt it. Good luck with that.
As central as the web experience and HTML are in my life and in your life, the only computer most people in the world use is their phone. The web just doesn't work well even on a multitouch touchscreen.
Just like you no longer enter your game using the ROM basic before playing it, and you no longer see text only screens around (well mostly), some day the web is going to be consumed by specialized devices or by specialized applications for your phone. Machine readable web, or in other words, web services. You can call that web 3.0 if you like.
I believe that the problem is not HTML, CSS and JS or their age (they are constantly evolving anyway). Theoretically you should be able to create one version of something and have it work exactly the same across different platforms. Which is where the problem lies: the platforms.
Saying those technologies are old and therefore need replacing is like saying C++ is old and therefore should not be used for game development. They are actually very appropriate and powerful tools for what they were designed for. Therefore I would predict that its not the HTML, CSS and JS that need to or will be replaced, but that the current platforms need to get their shit together (some more than others) and follow the bloody standards!
That said, they do need to keep evolving to stay relevant.
I think XML with XSL is the future. Graphical designer tools would come with their own XSL stylesheets, tailored to the strengths of the tool, and the tool would generate XML files that use the stylesheets.
But I'm no clairvoyant; what's going to be hot in the next 5 years, who knows. :-P
If you listen to Microsoft, Silverlight will feature prominently in the new web. Since it uses XAML, which is just a text file, it has the potential to be search engine friendly.
Others like Flash.
Of course I am sure that something else new will be invented in the future....
I think RIA's like Adobe flex/air/apollo and Silverlight etc will eat into some of the html market share , but not totally replace it.
Some of the issues that plagued RIA's like SEO related stuff, lack of back button support are being resolved.
The good thing with RIA's is that it is browser independent (as long as the user has the right plugin) , I could foresee future browsers launching with RIA support built-in thereby ensuring a 100% market penetration for apps built using them.
For documents and usual web pages, HTML and CSS are there to stay and evolve (Sass is nice indeed).
For applications, mobile code (javascript most probably) driving canvas-like graphics will help merge web apps and internet-enabled desktop applications.
— I wonder how ridiculous these predictions will look like in 10 years :)
Perhaps I'm just unaware of the competitors, but it seems when it comes to client-side scripting in the browser and DOM, Javascript is it. I know there's VBScript, but it really isn't even in the same ballpark as JS (not even cross platform, for starters).
I'm just curious about how this came to be. Surely there would be a general desire for a new language to replace Javascript: built from scratch to do all the things Javascript has been bent and moulded into these days (look at the reliance on JS Libraries).
Momentum. JavaScript has been around for 15 or so years, and browser manufacturers have worked for 15 or so years to make it work in their browsers.
If a competitor came along, it would need to really bring something new to the table in order to convince everyone to a) adopt it, b) live with locking out all the users of older browsers like IE7, Firefox 3.0, Chrome 1.0 etc. and c) find replacements for all existing libraries like jQuery, prototype, extJS etc.
In short: we don't need another Standard, let's rather improve JavaScript and build on the rich foundation that already exists instead of starting back from stone age again.
There is! Ones that spring to mind are Flash, ActiveX, and Java... But these all have their drawbacks. Mainly security and integration with the browser/DOM.
Flash and Java live in their own little world, by design (and to address security issues). They can't alter the HTML around them. ActiveX has access to the DOM, but also everything else on your computer.
JavaScript seems to have found a nice balance between flexibility and security, it can trivially interact and alter the pages HTML/CSS, do "safe" networking, has a decent standard library (which has things like JSON, XmlHttpRequest'sih networking, DOM manipulation, and so on). Most importantly, it's available in basically all vaguely-modern browsers, on all platforms, in a consistent manner (compared to CSS)
There are problems with JavaScript, but nothing major. The biggest is the performance. Load a comment page on Digg and watch your CPU usage. Chance are it will be 100% of one CPU core. There are projects to improve this, like SquirrelFish, TraceMonkey, and other strangely named things. But the performance is adequate to do some extremely impressive things (Google Spreadsheet, for example).
Basically, JavaScript is great, and it's drawbacks aren't nearly as big as the other competitors.
JavaScript won because it was introduced by Netscape in the period when they had above 90% percent market share. IE and other browsers had no choice but to support it also.
If a new language should be introduced, it would have to be either by agreement between all major browser vendors, or in a period where a single browser have enough market share to push it through.
Microsoft could probably have pulled it off some years ago when IE has an extremely large market share (before the rise of Firefox and Safari), but they chose instead (for strategic reasons) to let the browser stagnate.
Today, a new language would require agreement between at least Mozilla, IE and Safari to gain traction, and I think that is highly unlikely. The browser vendors have invested a lot of ressources in optimization, compatibility testing and so on for JavaScript - why should they want to start from scratch with a totally new language - and have to support two languages in parallel for decades to come? The cost greatly outweights any benefits.
Anyway, it is quite unrealistic to believe that a new language designed from scratch could be significantly better than JavaScript.
Show me another language that isn't reliant on libraries?
C, C++, C#, VBs, ... all rely on libraries. The only difference is that they often come with a standard set of libraries.
So do we really want is a standard set of libraries? What we're currently getting is a range of library sets (JQuery, prototype, extjs, mootools, etc). This is a good thing since we the developers get to choose one that suits our needs. In addition these libraries can be included and evolved without changes to the client-side component.
I can think of no compelling language feature missing from Javascript. By compelling I mean so earth shatteringly important that I'd be willing to alienate those browsers that do not support it.
Standardized (ECMA-262)
Common syntax and relatively simple to master
Good browser support
Extendable
Still being developed
Relatively quick based on how much data it needs to process sometimes.
If a good competitor had arrived before 1999 (ECMAScript 3), it would probably be a tie between those two.
There are other languages for client side scripting, but AFAIK, none are integrated into a browser.
Both Flash and Silverlight have their own Languages. Flash has ActionScript, while Silverlight has many and all that work under the DLR including Python and Ruby.
To your second point as to why, more specifically you mention reliance on JS libraries as a flaw in the language; Libraries are popular, not because the language if broken, but because the standard API is broken. The existence of such great libs builds on the power of the language.
There is nothing particularly wrong with JavaScript, it has some features that up to very recently would have been esoteric or academic. First class functions for example.
Also, ubiquity / mass existing runtime deployment is a very compelling feature. ;)
I recommend you to view Douglas Crockford’s presentation about “The JavaScript Programming Language” to learn about the history of JavaScript.
I think Javascript (ECMAScript) with its C like syntax is so popular for some of the reasons C is:
Relatively small number of language
keywords (easier to learn).
Concise and efficient syntax (quick to write).
Easily extendable
through external libraries and APIs that do
not pollute the basic language (ie Browser DOM,FilesystemObject etc).
Creating a new language that will provide many of the current libraries "built-in" is always risky as it starts to limit future applicability of the language and makes learning the base language harder.
This would be even more problematic for a client side browser language because the language designers can't possibly know how the language may be used in the future.
I think Javascript the language is fine in its current role as the "glue" that links so many other client sode technologies.
There are no other competitors because while Javascript is not perfect, it does the job.
I guess because the demand for it would have to be huge for browsers to implement it.
After all, it's the browsers that process and run the JavaScript and you'd have to have a large amount of sites using the language in order to make the browsers interested in implementing it. Then again no-one would use it if there was no browser support in the first place.
i'd say that this is because client side web development is still a very young branch of programming.
if you look at it only now it has become more widespread since we moved to faster "intertubes" :) and we're not using modems anymore.
and the problem for clent based web development is that it's not up to the developer what platform he'll use but it depends on the browser manufacturers.
and they change slow.
VB script's demise was in my opinion its VB-innes. too much unnecessary stuff.
As for javascript it will mature, but it's a start.
Browser support. If its not an MS tech the it most likely will not go into IE. If it's not in IE then no one can use it. If it is an MS tech, then most likely only IE will have the right to use it as it will be closed source and proprietary. If only IE supports it then only some developers will use it.
To challenge JavaScript it must work just as easily and more consistently across all of the major web browsers. Without browser support any new client side web tech is destined to fail.
I think it has to do with standardization, because durring the last browser-war (ie v. netscape) there were two, Netscape's ECMA (+1 Geek point for you if you knew this was the real name for JavaScript) and Microsoft's JScript, obviously ECMA (JavaScript) won out and became the defacto standard.
Now, we have another browser-war in progress and each of the 2 (3 if you count Chrome 12% FFS) major competitors 3 fully (with a few edge-cases) support JavaScript.
My guess is that its ubiquity and ease of integration in any new user agent project. It comes built into almost all browsers so you dont have to download/install/configure anything to have it running. once you look at user agents off desktops (wii, iphone, windows mobile, n95 etc) the availability of any of the contendes dries up quick - so you code for html and javascript becuase it will work most of the time.
I agree with Michael, we should improve Javascript, not worry about competitors because there aren't going to be any, in fact even Javascript 2.0 seems so far from reaching reality.
Since Javascript is such an ambiguous language, we're able to create libraries (jQuery) and even abstractions (Objective-J) and not worry about all the problems that Javascript has at its heart.
After so many years we don't even have CSS implemented same in all the browser, same goes for the JavaScript, IE has one model and rest of browsers has another Model (I mean like Event Handlers and attaching events).
If new competitor comes, it has no chance, neither it has so much time as css and javascript had.
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.