Hacker News new | comments | show | ask | jobs | submit login
Why don't they implement Python and Ruby on the web browsers? (stackoverflow.com)
122 points by jsnk 1683 days ago | hide | past | web | 141 comments | favorite



The top comment states that any other options are impossible: "At this point we must concentrate on improving the language."

I can't stand this willfully defeatist attitude. It's also not restricted to stack-overflow participants -- this position is pervasive at Mozilla.

Why can't we have a standardized generic bytecode and VMs to run it? Why should the web be locked to a single language forever? Can you imagine if we had locked desktops and mobile only a single implementation language?

Google seems to be the only company actively looking for a solution via NaCL. Most of the web community, on the other hand, regularly opposes efforts to move away from JavaScript as the one true language.


Mozilla is not against a bytecode VM. Mozilla (and the WebKit team minus Google) is against arbitrarily adding new language VMs because they create a major compatibility burden. Remember this:

1) JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.

2) That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.


> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.

JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.

> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.

There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option.

The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".


> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.

True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use.

>There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option.

>The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".

I read the mailing list and that's not the impression I get at all. The impression I get is:

1) JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript.

2) Most of the problems people have with JavaScript are being addressed by EmcaScript.next.

3) For those who have a general syntax/style problem, there are numerous alternatives that compile to JS to choose from, and more are likely to become popular in future as programmers from different backgrounds are compelled to write for the browser.


> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use.

And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years.

This is solvable; it HAS been solved.

> JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript.

This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone.

In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here.

> For those who have a general syntax/style problem, there are numerous alternatives that compile to JS

In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.


> And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years.

Yes, because the old VMs were critically slow. Things like DOM manipulation aren't blocking problems the way they used to be.

> This is solvable; it HAS been solved.

Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language?

> In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.

This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging: http://www.infoq.com/news/2011/08/debug-languages-on-javascr...


> Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language?

Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done.

I'll try to address this new argument.

JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers.

Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited.

In all of these cases it has nothing to do with whiny developers "refusing to write in anything but their favorite language". We're simply attempting to advance the state of the art, because nothing is perfect, especially JavaScript.

> This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging:

It's a work-around, not a solution. JavaScript still isn't an efficient bytecode format, this won't solve performance issues. We've seen similar work on languages that compile down to C, and it's not an adequate solution to debugging, especially when the debuggers benefit from language-specific enhancements.


Excuse my ignorance, but what browser-based non-JS VM was introduced successfully? You mentioned this was done before, and I assume you mean it was done successfully, so just curious to know which one it is?


We were actually discussing JS VM replacement in the browser, related to:

> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways.

The counter-point being that all the major browser vendors have swapped out their VM or performed significant rewrites in the past few years; it's clear that it's possible to implement a new VM and not "break the web in profound ways".


I think you are misreading that quote. It's not replacing a JS VM with another JS VM that's a problem, it's replacing a JS VM with a non-JS specific VM would cause problems and break the web (something that has been proven to happen).

Arguing that you can replace a JS VM with a JS VM doesn't help the case of replacing a JS VM with a non-JS VM.


At the surface level, I could see how your position would appear logical.

However, the nature of the replacement VM doesn't really matter in the context of what we're describing here.

The problems of compatibility remain the same regardless of whether the target VM is a JS-specific VM, or a general purpose VM; reliance on undefined behavior, accidental changes in semantics, optimization bugs, and so on.

If browser makers were able to swap-out the VM, they've already demonstrated the ability to solve the exact same kind of compatibility problems they'd face here.


There is no such thing as general purpose VM.


A VM that provides a standardized bytecode and execution model capable of executing most modern dynamic and static turing complete languages with sufficient performance. This requires more general facilities for common functionality required; refer to tail call support, JVM's invokedynamic, etc.

Or, shorthand, a general purpose browser VM.

Unless, of course, you're arguing that the above is not truly possible, in which case I'd argue that's exactly what Google is exploring via PNaCL, and has (if not completely efficiently) been implemented across existing VMs. The PNaCL choice of LLVM bitcode was likely in error, but regardless, "no such thing" is a stretch.


I'm not saying that it is impossible as clearly there have been good efforts being made. However there is no such thing implemented.


Which comes full circle to my original point, which is that other than Google, nobody with a vested interest is trying, and worse yet, they actively oppose progress on this front.


> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.

JS running on a general VM would be slower. That's against the interests of the user.

People should stop caring what language it is. If you really don't have the skill required to use Javascript, use something easier for you and get it to compile to JS.

I've really never understood developers that bitch and whine about programming languages all day.

Adding alternate languages to the browser does absolutely nothing for the user. It would only be there to appease the "I shall only develop in lisp" extremist developers.


> JS running on a general VM would be slower. That's against the interests of the user.

What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT.

Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?


>> JS running on a general VM would be slower. That's against the interests of the user.

> What do you base this on? It's sounds like an unsupported assumption

No, he is entirely correct.

JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.

The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.

The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.


> JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.

I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.

The investments here occurred long after the VMs were developed.

> The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly.

The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc.

Instead, we do the best general purpose job we can, and it's usually more than fast enough.

What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid.

Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler.

All that said ...

> The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.

Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.


> I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.

> The investments here occurred long after the VMs were developed.

That's a valid point. It is possible that some entirely new kind of VM could work, that was designed from the ground up for both static and dynamic languages. But I don't think we have any good idea of such a thing!

Until we do know how to do this, replacing the JS VMs in browsers would slow everything currently running. And adding another VM alongside it would decrease speed in other ways (see for example the papers that the Apple dev mentions in the WebKit discussion for why Apple opposes adding the Dart VM into WebKit).


I think your points are valid as well.

I'm not ready to take it as a given that we can't build a general purpose VM capable of running JS at or very near current speeds, but it's also not a solved problem.


I agree, I don't think it's impossible. But, we don't know how yet.


It's not the lisp extremists that want this, it's the Python and Ruby ones. Lisp people already have plenty of options: I can think of ParenScript and ClojureScript off the top of my head. (And I'm not even (much of) a Lisp weenie. :)

(parenscript http://common-lisp.net/project/parenscript/)

(clojurescript https://github.com/clojure/clojurescript)


>If you really don't have the skill required to use Javascript...

So it's a lack of skill that makes JavaScript a poor choice for largescale application development?

No.

Developers like this are a large part of the reason we can't have nice things.


> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that

The same thing could have reasonably been said of Flash just a couple of years or so ago. It was on something like 99% of browsers.

> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs.

Why would we need 2? Why not one VM that the additional languages AND JavaScript can all be compiled to? Then here's what you have in the browser:

1. That single VM.

2. A JavaScript compiler that compiles to that VM, so that you can still send JavaScript the traditional way as source code loaded by script tags.

Then, if someone prefers to work in Python or Ruby (or Lua, or whatever), they can compile to the byte code on the server, and send the byte code to the browser.

I'm sure that some will object that this means that if people use those other languages, then essentially they are sending binary to the browser instead of source. However, with all the hacks being done to minimize JavaScript code size, and all the machine generated JavaScript we have now, it is getting harder and harder to consider what gets sent to the client "source code" anymore for a lot of sites.


Why 2 VMs? Can't you compile JavaScript to the imaginary bytecode and have a single unified VM to run them all?


You can, sure. 2 problems:

1) It will undoubtedly be slower than the current JS-quirks optimized VMs.

2) There is a shit-ton of JS on the web that has been tested to work with the current crop of VMs, moving to a new VM almost guarantees breakage. It's the same reason why GNU Screen isn't rewritten despite (supposedly) being a mess.


You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.

You make it sound like the computing world has never introduced a new version of a language that has implications for the older ones and managed to overcome it. Even the web did this (remember putting your scripts in comment tags?).


> You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.

That means both VMs will be in the browser together at some point. That is a hard problem, for example because of cross-VM garbage collection (the WebKit thread where Apple refuses to accept Dart into WebKit references some papers on that).

This will cause an immediate slowdown on existing code, and a very large maintenance burden, for example you typically need to optimize fast paths in the DOM for your VM, with two VMs that is double the work, and if the VMs are allowed to communicate - and they can, if they can both access the DOM - then you have three paths to optimize now.

It's possible to migrate from one version of a language to another - say Python 2.x to 3.x. But they are not both running in the same process and communicating directly with a third shared environment like we would have on the web.

I hate to be negative about this, because as engineers we all love technical challenges. But the fact is, it's very hard to do this stuff well. (And it's even harder to standardize it.) We need to be realistic about this: Compiling into JavaScript is the only way we will see other languages on the web for the foreseeable future.


I'm not aware of anyone disrupting critical code the way you're suggesting. It would be akin to rewriting malloc. I'm not discounting a slow transition akin to what you suggest, but you're talking about a long time frame of supporting 2 VMs side by side. Probably 10+ years.

And even then, you still have to support JavaScript being written directly in HTML <script> tags, something no other language could enjoy. So every browser must include a JavaScript to (new VM) bytecode compiler. JavaScript will always be in a priviledged position.


I do not necessarily think the web needs generic VMs to move forward, or that JS needs replacing (I happen to enjoy JS with all its quirks quite a lot).

I do, however, think that such a transition is possible if the powers that be (Google, Mozilla et. al) could agree on a fairly consistent strategy.

Yes, 2 VMs side by side would probably be needed for some time, but 10+ years? Surely pure JS VMs could be moved to plugin status and be phased out faster than that, especially since someone would just write a compiler that compiled JS to this byte code format. No, it wouldn't be as fast as a VM highly optimized for specific JS quirks, but it could probably suffice.

> It would be akin to rewriting malloc.

Custom mallocs has been written for many different purposes like for example demanding game engines. While certainly a complicated task, it has been done numerous times.

> And even then, you still have to support JavaScript being written directly in HTML <script> tags, something no other language could enjoy. So every browser must include a JavaScript to (new VM) bytecode compiler. JavaScript will always be in a priviledged position.

Why would <script> tags HAVE to contain JS? I see no reason why if we're changing to a generic byte code web, JS in <script> tags could be phased out as well.

However, as I said, I actually like JavaScript and I think experiments of modernization like Dart are approaching the "problem" in the entirely wrong way. I only think that if we "had" to change up, it could be done without much degradation to the user experience if any at all. Some old sites would break, but really, who cares? If you could compile your javascript codebase to byte code and have it still work, every one would do that without much problem.


> It would be akin to rewriting malloc.

Aside from the fact that memory allocators are written, rewritten, and tweaked all the time, your own organization's actions defang this argument: Firefox 3 included a switch to jemalloc.


A version of jemalloc specifically written for mozilla's codebase.

If it were a 100% compatible drop in replacement for malloc, why hasn't every other project switched to jemalloc yet?

(Searching for switching to jemalloc, seems like every group that tried it out found that their code base or use case exposed new problems in jemalloc. That these could be fixed doesn't negate the main point -- you couldn't just switch malloc out in existing codebases and expect everything to work right.)


I don't think I've ever seen a more dramatic real-world example of unwittingly strengthening the point you're arguing against. jemalloc didn't work quite as they wanted, so they customized it, and you really think that's a counterpoint to an argument for trying new and different things?


Ah, you're right, it's so simple! If changing the JS engine breaks a web site, the sites authors will either customize the JS engine, or choose not to switch after all!

No, wait a minute...


In the same vein, why a VM at all? Can't you just compile Python to JavaScript?


If JavaScript never goes away and no other options are built into the web browser, the web will become irrelevant within 10-15 years.

No language lasts forever (especially not one that evolves as slowly as Javascript does), and tying the web to JavaScript and JavaScript only very obviously dooms the web. Not this year or three years from now, but eventually.

That nobody other than Google is making long-view plans for the future in this regard is somewhat insane.


I think you should say rather that web browsers that only run javascript will be irrelevant.

I doubt the web is going anywhere...


Well that was basically the point I was trying to make. The web is going to have to evolve to a post-Javascript future at some point. I believe this will happen no matter how hard the JavaScript-only diehards fight against it. I'm certainly not saying the web is doomed, only that it would be if the JavaScript-only crowd really got their wish (which in the long run they won't, they can't).


A bit cliche but "never is a long." Of course it will be supplanted someday. All it takes is path in a different direction.


If this is a complete puzzle to you, you might spend some time meditating on a parallel issue: why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes? Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed. One of them was even arguably massively successful. Why is the world moving on from them?


> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes?

You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job.

However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform.

HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.*

> Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed.

Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al.

> Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off.

Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.


> You have to remember that HTML is predated by > SGML, and that HTML and its precursors were > designed for the purpose of providing document markup.

I remember. I also remember there have been people arguing all along (back into the mid-90s, at least) that this document-centric approach has been totally unsuitable for a broader platform.

And yet, it's been more successful at delivering applications to the widest possible audience than any other platform. Why is that?

Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years. Then explain why you're certain that having a VM instead of a browser act wouldn't erode those advantages.

(This is the most important part of my comment. Feel free to ignore the rest.)

> HTML has fallen over in this context; > the DOM is ill-suited towards standard > re-usable UI widget programming,

I don't think the evidence is on the side of your claims. Given the sheer number of web pages and apps out there vs the number of desktop apps, the widgets built in to HTML are more widely used and re-used than most desktop API widgets, and the sheer proliferation of derived DOM-composite UI elements out there (particularly contrasted to the desktop) belies any claim of unsuitability for use: DOM elements are creatively styled and glommed together with a regularity that dwarfs anything from the desktop world.

That's use and suitability. Re-use? There are also several well-known and a lot more lesser known libraries that do indeed provide widgets at higher level of abstraction. JavaScript provides ample facilities for abstracting the DOM manipulation behind object and method calls. Whether or not it's used is another question, but any developer that can't learn to do that job in JavaScript either can't do it because they're unwilling to learn how to wield JavaScript, or because they'd be unable to do it with any language and API.

> JS is frustrating for building large applications

How so? There are plenty of developers out there who've found that if you embrace the features the language and most runtimes offer, it isn't any more difficult to build large systems with it than any other language. Though despite that, the language seems poised to embrace some of the features from others if for no other reason than to make developers who already know another language more comfortable.

> Moreover, Adobe Flash was not standardized

Standardized enough that the runtime was successfully targeted by a number of non-Adobe products.

> the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

And of course, our shiny new standard VM will avoid all these problems over its lifetime. ;)

> the performance profile is tremendously bad on mobile devices

It's actually better than I'd expect in a lot of cases, but it's true that it's not good enough for a lot of kinds of apps. But the language is not what's causing the problem, so adding other languages won't fix it, and might introduce other problems.


> Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years.

Ubiquitous cross-platform adoption. Done.

The web grew popular (relative to the Internet population) before it got JavaScript, not after. It wasn't JavaScript that drove widespread adoption, and it wasn't applications built in JavaScript.


> Ubiquitous cross-platform adoption. Done.

Well, that's at least part of the reason why we disagree. The list is longer, and includes (but may not be limited to):

* view source - up until minifiers, there wasn't anything happening on the client side that you couldn't see how it was done yourself.

* gentle learning curve - the entry level to simple web publishing was achievable for anybody who could transfer "view codes" style word-processing concepts to markup and manage file transfer client. A little learning or some copy and paste could take you up the next gentle step to limited scripting.

* Hypermedia nature of the platform - instead of applications being little silos that only interoperate with a relatively small number of apps from the same organization (or other organizations where they've made deals), hypermedia docs were a sprawling web of connections constantly pointing to other document-applications. If you'd dropped a perfect universal VM on every desktop in 1995, it's extremely unlikely things would have fallen out like this. It certainly didn't for the imperfect one.

> The web grew popular (relative to the Internet population) before it got JavaScript, not after. It wasn't JavaScript that drove widespread adoption

A 1995 release means that the first statement is only defensible given the flexible nature of popular. The second statement is truer in decreasing terms through 2004 or so, when it bottoms out.

That's tangential, though. The real question is more along the lines of whether the web would be everything it is now if instead of passing around a single strain of fairly standardized (though expanding over time) markup, we instead were sending drawing instructions and collecting events. Or maybe even a single binary-encoded standard for abstracted document trees designed for optimal machine consumption, generated from various different applications or compiled from other document schemes.

Their answers to that question are why a lot of people think it might be a better idea to have single scripting language, and the one we've got has turned out to be pretty capable so far.


People who complain that js is ugly have no idea how ugly native X development is - I am just glad that the BT/MIC deal fell through so I never had to open that can of worms.


I don't understand this fixation on js either. Even more, i don't understand the fixation on html, css and all so called web technologies. Common, web was never designed for the sort of applications we are trying to make it run. We need a totally new approach.


Arguably there already is a totally new approach, centered around an app store rather than a browser.


A totally new approach just means you have to support two incompatible standards, most likely with more bugs and inconsistencies than you have now. I'd much rather see all the browser momentum we've gained lately going towards more comprehensive support of the existing standards, as flawed as they may be.


Agreed.


A generalized, dynamic-language friendly bytecode to replace Javascript would be great. Please let me choose to use Python for client-side web without resorting to language cross-translation hacks.

Find the commonalities between Ruby, Python and Javascript and such (there are a lot!) and base the VM on that. "Legacy" javascript can then run in the existing VM. For JS, people can choose to compile it or let the browser compile it.

On the other hand I don't like NaCL at all. Even with all the security measures, there is just too much risk in executing native code directly from the web. Also it splits up platforms, splitting the client world into x86 and ARM, instead of allowing for innovation in CPU-land by exposing are more abstract interface. It is a repeat of the "browser plugin" paradigm, which luckily failed.


To a large extent, I think apps are the answer here. (And just to be clear: I'm not conflating apps with app stores).

Consider the early days of the web: remember when Java applets seemed like the way of the future? (Okay, that's perhaps a bit of a stretch).

But I'm serious! What is the net other than a delivery mechanism for things?

How things are implemented is not the issue, the thing people really care about is easily getting software into the hands of end users. How that software happens to work internally is immaterial for most folks.


Yes, what if we had locked mobile to a single language... like Android (Java), iOS (ObjC), WP7 (C#/Silverlight), webOS (JavaScript), Symbian (Symbian/C++). Oh, well... at least we have the glaring success of MeeGo which didn't embrace single language completely.


I'll break this down:

- Android: Java, NDK (C++, C), ObjC (via Apportable), MonoTouch (C#/F#), Lua, JS

- iOS: C, C++, ObjC, JS, Lua, MonoTouch

... actually, that's as far as I want to go. Point is, you can pick your implementation language, and people do.

We're also likely to see additional language explorations on these platforms as they stabilize and mature.


> Android: ObjC ???


I believe these guys have an NDK-based implementation: http://www.apportable.com/


I think the reluctance comes from being burned by Microsoft infusing their own technologies into the web browser in the past.

I realize that Python and Ruby would be standard and open but people still fear the possible fragmentation.


If the browsers were to implement a general purpose VM, the choice of actual high-level languages would be distinct from the browser maker, and open to experimentation and competition.


I don't think it's as cut and dry as that.

What if we do have a general purpose vm. Doesn't each browser still need to implement language compilers for all languages to that vm?

ie what if Microsoft supports langauge foo but not language baz. Chrome supports language baz but not foo and Mozilla only supports their own proprietary language. All of which compile to the common vm.

How do websites written for IE work on Chrome, and visa versa? Do all sites have to have their code byte compiled before shipping?

Then your stuck with performance differences and byte code incompatibilities at best, which is about where we are now.


I think this ignores the reality of the situation we've been in for a long time: different browsers do different things. We've all been quagmired in CSS because one browser renders one way, and one renders another. And we can't seem to get out of this, and it's always going to be this way for as long as there isn't one single browser, so let's just accept it and learn to deal.

I'm personally pro-web standards, but I'm very much anti-Javascript is the only way forever.

Client-side languages have always been a choice that a developer has to make. Should I write my Windows program in .NET, or should I make my users install Python and write in that? Should it be compatible with Python 2.4, or is Python 3 good? Maybe I should just write it for Mac OS X, and that'll have Python 2.6 for sure...

It's for the developer to decide which audience he/she wants to accept/alienate. We've never thrown up our hands and gone "Oh gosh! All this platform stuff such a pain! Let's go back to C and UNIX and forget all this nonsense."

Yet this is the exact same argument being made for not moving towards a VM solution on browsers, and I truly don't understand it.


Servers could serve compiled byte code.

Someody else already mentioned that compiling python or ruby to JavaScript could be an option. We already have clojurescript which does this.


Doh, you are of course correct. I'm not sure how I didn't think of this :)


> Why can't we have a standardized generic bytecode and VMs to run it? Why should the web be locked to a single language forever?

In the beginning, this was the intended design. Which is why you still specify the language when injecting code into the page.

That original design is flawed and does not work well on the web. Adding other languages is a horrible idea.

> Can you imagine if we had locked desktops and mobile only a single implementation language?

Apples and oranges. On both platforms, programs rarely interact with each other and when they do, it's through the OS using a standardized API.

The web is different. One piece of code is always interacting with another piece of code, that is interacting with a third and so on. There is no standardized API. You just call the appropriate function, if available.

To implement other languages, not only would you need to compile to bytecode, add VMs, etc. you would also need to add APIs that would allow communication between different pieces of code, written by different people, in different languages. Even if implemented, which would be a nightmare, it would still stifle the very nature of the web, the very dynamism that makes web apps different.

I don't want the web to become like the desktop or mobile space. I want to pull in code from twitter, facebook, my code, etc. and have it all work together, communicate with each other, and create a dynamic environment, all on one page, client-side. This is only coming into reality now.


The JVM and the CLR have already adequately demonstrated that multiple languages can easily (and with adequate performance) share common libraries and APIs.

Mixing Scala, Java, Ruby, JS, and PHP -- all in one process -- is simple and straight-forward on the JVM.

That said, the language of the web is HTTP and REST and open APIs, not injection/eval of JavaScript.


> The JVM and the CLR have already adequately demonstrated that multiple languages can easily (and with adequate performance) share common libraries and APIs.

Please tell me how code in PHP can get a response from a function in JavaScript? What if that response is a Date object? What if that Date object was extended with additional functionality? What if that Date object stored additional values in unexpected places? A huge advantage of Javascript is that everything is an object and everything can be modified.

When you try to make that work, you'll start placing restrictions on what can and what can't be passed. Global scope will be a nightmare. You'll try to hack together a scheme that casts responses into primitives. In the end, you'll end up with a stifling environment where interoperabilty is a theory that is never used in production because it was crippled to make it functional to the point of being useless.


This generally isn't the case with disparate languages on the JVM. Unless you have a concrete objection with a scientific basis, you're just spreading FUD, and I don't think that contributes to the conversation.


> Unless you have a concrete objection with a scientific basis

I did. Please solve the problem I put forward. If you solve it, you win.


You asked, "How can PHP get a response from a function in JavaScript?" Well, assuming we have the following JavaScript function:

  function multiplyString(str, times) {
    while (times) {
      str += str;
      times -= 1;
    }
    return str;
  }
We could write:

  <?php
    console->log(multiplyString("Hello", 3));
  ?>
You then ask, "What if the response is a Date object?" You would call it the same way, and get back a Date object.

The rest of your question adds a bunch of other suppositions, all of them fairly vague and none of which seem particularly more salient than the first two. If you have a particular reason to think this would be intractable, maybe you could explain in more detail the problem you see, and perhaps an example of where it shows up in popular multi-language runtimes and interfaces.


Your concerns seem ill-founded given that these are solved problems. There are working implementations of low-barrier cross-language compatibility, today, for both the JVM and the CLR.

Here's one example; Rhino provides pretty seamless bridging from JavaScript to Java:

https://developer.mozilla.org/en/Scripting_Java

I've used it to run user-supplied JS inside the JVM.

PHP is pretty easy too:

http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp#JavaPH...

Scala is even more lightweight here:

http://www.codecommit.com/blog/java/interop-between-java-and...

Bear in mind that these are all for the JVM, which wasn't even designed with the intention of being a general-purpose multi-language VM.


> I've used it to run user-supplied JS inside the JVM.

Have you used Java libraries in JS or vice-versa? That's the problem the parent is referring to.


Both directions. There are impedance mismatches, of course, but it's nothing like the doomsday scenario he's claiming.


I can't speak to the JVM, but I know for a fact that some CLR languages have incompatibilities (C# and F# specifically).


> Your concerns seem ill-founded given that these are solved problems.

Then solve the problem I put before you.

It's an easy one. I want to pass a modified Date object with stored procedures that modify the value based on geolocation. I want to pass it from a Javascript function to PHP/Java/whatever. Make it work. Please.


First of all, it's difficult to engage with your productively, as you're particularly confrontational.

That said, if you give me some example code, I'll demonstrate its use in a JavaScript/Java hybrid implementation when I have some spare moments.


> Why can't we have a standardized generic bytecode and VMs to run it?

And why stop there! There are plenty of "languages" that currently compile into HTML and CSS (like HAML and SASS for example). If we have a common VM for scripting then why not a common VM for HTML and CSS as well. Heck, we could do this all with a single VM and a common API. For backwards compatibility, we could use a new HTML tag to enable this VM. Furthermore, as a proof of concept, you could design a plugin for all the major browsers that implements this.


Hey, that sounds familiar...


The browsers themselves are already built and powered using JS. Maintaining a comprehensive API at the speed that web tech advances in more than one client-side scripting language would be hellish -- browser vendors already have enough trouble agreeing on CSS and JS standards. The Stack Overflow article already raised a number of good reasons why not. Not sure why this is garnering so much attention from HN.


Because we all hate javascript.

I just wish they decoupled javascript engines and browsers, made a language agnostic api spec for the DOM, and just let html <script> tags require a language ref and the browser would be expected to try to find a runtime on the local machine or ask the user to install it. The monopolistic nature of javascript in client web browsing is bad for innovation.


Really? You're discounting all of the incredible webapps, games, and social networking on the web. If Javascript was bad for innovation, I sure don't see it.

You're talking language syntax. Although it matters, it practically doesn't. People build stuff no matter what the language looks like. Look at Obj-C, that thing is horrid (syntax-wise) but look at all the developer adoption.

What is bad for innovation is to move back to the 90's where people had to handle local instances of applications, fix versioning problems, and have to install something just because they want one small piece of functionality.


> If Javascript was bad for innovation, I sure don't see it.

This is a fallacy: in absence of a peek at some alternative world where something else was available, you can't tell that javascript improved or worsened the innovation rate.


It seems pretty reasonable to observe the desktop world, though, since it has the properties under discussion, and ask ourselves whether it's easier to deploy an application to a wide audience there or on the web.


Well, the problem is that this confounds all the properties of "the desktop world" with the properties of another client-side substitute for Javascript (like, say, Dart or some language using NaCl)


> webapps

Mostly interesting because of their content and what they do with it on the server.

> games

You've got to be kidding me. There is nothing technically interesting in any web game I've ever seen.

> social networking

Again, has nothing to do with interesting client-side technical challenges and everything to do with the content and community.

> You're talking language syntax.

Don't forget the semantics too.


We don't all hate JavaScript.


> Because we all hate javascript.

You only hate JavaScript when you're starting out. When you get to know the language and how to use it properly, you begin to appreciate it in a very unique way. Until you understand what prototypical programming truly is, you don't understand JavaScript.


I don't think you can dismiss someones dislike for a language as "they don't know how to use it". Common, many people have been building applications on client and server for 15+ years using JS and whatever exists on the backend. And 90% of the time, the backend language is better, and has way better tooling.

So you can understand and master JS (including prototypical programming) and still hate it.


There _is_ a language-agnostic API spec for the DOM; that's the whole point of the DOM specs. It's led to APIs that are a huge pain to use from any language (I've tried it from C++, Java, and JavaScript).


> Because we all hate javascript.

Says who? I love JavaScript, as do a great many other developers. I look at CoffeeScript and all I can think is yuk.


Why arent browser UI's created using HTML, CSS and JS ?


I think the various Mozilla projects actually do have facilities for this, and that some significant portion of the chrome is done this way.

Where browser UIs aren't done this way, though, I suspect it's because the APIs are for components that aren't markup based -- you write the software for the platform with the APIs it provides, or (as I believe Mozilla has done) you write your own platform on top of something else.

I think the real question to ask yourself is -- if the conventional patterns of the desktop API that we'd more or less laid down by the mid 90s were so generally awesome, why didn't some universal client based on them take off instead of the web?

It's not as if we didn't have network aware desktop-style clients at the time...


I think we are asking opposite questions - if web based UI's are so awesome and have no caveats attached for display based apps then why are browsers not written using HTML, CSS and JS ? I am asking this question because I know at least one person from mozilla has replied to this thread.


"why didn't some universal client based on them take off instead of the web?"

Because you had several companies all fighting to have their desktop platform be the standard. The web slipped in the back door because nobody felt threatened by a hyperlink document publishing system. As such, it was the only platform that was available everywhere. Worse is better.

Interestingly, the web is starting to adopt the old desktop model. If you look at many of the emerging frameworks for web development (talking client side here), they all seem to be loosely based on the work of OpenStep.

It is actually a really great question posed by dman. If the web is suitable for applications, the browser chrome should be one of those such applications.


In large part they are. Mozilla Firefox is 80% JS, and the chrome is XUL, an XML language.


One point not in the existing comments is the event driven nature of the browser - even if you're eventually able to have good support for other runtimes in the browser (e.g., you can use Python via the Native Client plugin) most of them have such a large existing codebase of blocking code that I think you'd run into a lot of the same issues that you do now with Ruby & EventMachine, or Python & Twisted.

It's what made Javascript such a great fit for nodejs - no big existing libraries of blocking code, and everybody was already accustomed to doing things in an event driven style due to the browser.


Nothing in these languages prevents them from being event-based or non-blocking. All these languages have perfectly fine callback architectures. Javascript wasn't magically designed to be event-based, its just that the DOM APIs (which have nothing to do with JavaScript) were written in an event-based way because it really couldn't have been done in any other way.

Similarly, if you were to put Python or Ruby in the browser you would necessarily need them to have some sort of DOM APIs (or there wouldn't be very much they could do in the browser). Those DOM APIs would once again be written in an event-based way.

The "big existing libraries of blocking code" would be inconsequential since they would for the most part have nothing to do with the kinds of things you are doing on the web. Who cares if theres some file reading code in Ruby that is blocking? You don't read files in browsers. Think of the opposite proposal: if I went and implemented these same libraries in the same blocking fashion in JavaScript, it wouldn't all of a sudden become a worse language for the browser.


That doesn't make any sense. Javascript libs are just as blocking as any python or ruby lib.

"no big existing libraries of blocking code" (for js) just translates to "no big existing libraries", period.

It's not like javascript has any special support for non blocking code --or that any code that does anything useful and specific (ie. not just handling out work to be done and callback/returned but actually doing the work) can ever be non blocking.


Javascript has anonymous function closures - nice sugar for a non-blocking API. Python doesn't have them.


Javascript is a perfectly reasonable underlying language. Nothing that I know of stops people from compiling python or ruby into javascript.

I would never write pure javascript, but using languages that compile to javascript has been pure joy.

See http://common-lisp.net/project/parenscript/


A byetcode/VM approach would be an improvement on the web client. This has been used successfully for 10+ years on the server (JVM, CLR), so why not learn from things and advance the state of web development.

I don't understand why people defend JS so passionately. It was build in like 2 weeks, wasn't designed to build large complex applications, and hasn't really advanced at all since its inception. There are better options out there and the web development community should welcome any improvements to close the gap from Native to web.


Here's an announcement for a project implementing the Erlang VM in the browser: http://erlang.org/pipermail/erlang-questions/2011-November/0...

While not exactly what the OP is calling for, this is interesting nonetheless, and it does provide a mechanism for using at least one other language in the browser, even if it uses JS as the platform, rather than natively supported.


Tons of languages are doing that: OCaml, Python, Java (and Dart and GWT), C, C++ off the top of my head. I don't think it will catch on, because Javascript has been good enough and these runtimes have overhead.


"closed as off topic by casperOne♦ 8 mins ago"

...

The number of programming topics I have had closed on that site angers me. They are becoming Wikipedia.


It's justified. The site is used for problem solving.

Here the problem isn't the asker's, it can't be meaningfully solved by anyone on the site, and it is a matter of opinion whether any answer comes closer to solving it, or that there is a problem at all.


re: "The site is used for problem solving."

So says YOU. What's so inherently wrong with letting the people decide? Obviously, a few hundred people found that post quite relevant to the website's topic, helpful, and interesting.

What gives Casper the right to destroy hundreds of people's discussion on a topic that they all deem relevant.

The "vote" on that action was approximately 300 to 1. That 1 vote of no confidence by Casper counts more than everybody's for some reason. That is what really gets me.


So says the sites' FAQ:

> You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.

The ability to decide what Stack Overflow is and isn't is what makes it a community, and not a jumble like Yahoo Answers.

And the specifics of closing questions don't have the violence of Wikipedia deletions. I don't approve of deleting user-contributed content, especially when it takes effort to build; closing on SO removes linking to the question, adds a little explanatory blurb, and diverts new attention away from the question. It doesn't destroy user contributions.


Now you (and the site's rules) are just getting pedantic.

What's the legal definition of a "Chatty, open-ended question" or a "practicable, answerable question"? No question is un-answerable or impracticable imho.

Those are some very ridiculous requirements if you ask me, and 300 odd other people who voted in favor of this question and it's answers.

P.S. in the midst of all this argument... CasperOne has added and removed his vote of no confidence for this question. It is now "closed as not constructive by Tim Cooper, lwburk, Tobu, 一二三, Graviton 8 hours ago". So which is it then?


Not everything is subjective. Stack Overflow has a stated purpose, and that purpose is not "whatever the most people feel like disussing." The Internet has proven that cats and politics will win that one every time.


The topic in question is not so far removed from the site's purpose to deem that it's "whatever the most people feel like discussing".

You are correct in that somebody must draw some kind of line somewhere in the sand... but I believe that Somebody jumped the gun on this one, as they have on many of my questions to similar websites in the past.

I think it's more of an elitist thing. "I know the exact rules better than you know the exact rules."

When a user needs to know and abide by every rule of every website on the net, the internet is immediately less interesting.


You referred to the number of votes the post got. I was saying that's a red herring. Given a choice between a great question about the theoretical underpinnings and practical applications of a feature in Clojure 1.4 and a picture of a cat in front of a computer, several orders of magnitude more people would vote for the cat than the programming question. This is why getting a lot of votes doesn't really prove relevance.

As for "I know the exact rules better than you know the exact rules": I don't see that at all. The rules are pretty simple. Here's a summary — if you follow it, you will not get your question locked:

1. Is it about programming?

2. Is it possible to give an objectively correct answer?

3. Is it stated politely?

In the particular case of this question, it doesn't even try to follow #2. It's an interesting question, I agree, but there's no right answer, so it's not a good Stack Overflow question. S:N ratio is extremely important on a site like Stack Overflow (because the people who answer questions well lose interest fast when they can't find good questions to answer, and vice-versa), so it is important to make sure that the site sticks closely to its purpose.

Incidentally, this isn't true of Wikipedia. Some of its rules make the site better, but a lot of the rules exist more for their own sake than because not following them would ruin the site (e.g. an article that's just descriptions of Pokemon episodes is pretty useless, but it doesn't make the article on Afghanistan less useful).


I'm also annoyed by the overly eager closing, but in this case I think it's justified: it's a relatively argumentative question with no real answer. The goal behind StackOverflow is to be something vaguely like interactive documentation for all of programming, so something like this doesn't really fit in. I imagine it might fit better with a site like programmers.stackexchange.com.


The question is not closed at the moment.


Looks like Casper really is a cowardly ghost.


Quoting a comment under the question:

Language preference aside, the fact that no language has good support in the browser, the server and stand-alone totally baffles me.

I do wonder about this. I don't think the challenge of the task is the only answer. I think - guess - the rest of the answer might be that in practice, most developers focus on one of those, maybe two (most probably server and browser), rarely the three of them. I know first hand that some do work on the three, but they must be rare, seeing the interest in this. Maybe the momentum of the app stores bringing web devs to work on apps could gradually make people more aware of the benefits of having a universal language. Don't get me wrong, I enjoy the variety of languages, but I would be very happy to be able to focus and become proficient at one only language, even if that means giving up on some language specific advantages.

Ironically (given of the context of the comment), javascript might be what comes closest today.


The other way to put this question is - Is there sufficient reason/motivation to try to replace Javascript with something else? What does JS lack or what are its limitations?


The lack of keyword default arguments drives me nuts, python just does it so well. Not to mention ===, etc, etc.

None of these things are a showstoppers, but rather amount to "death by paper cut" that in my mind that make the language unsatisfying to use.


You can just use CoffeScript for those little problems.


I've looked at it, and while nifty, makes me worry about leaky abstractions and future support.

Now that you mention it if I'm going to do that, why not use the python-to-javascript compiler from pyjamas? ... hmm.


The difference is that CF is very close to javascript and makes it very easy to transition. But of course, if you prefer python, why not :)

Talking about future support, as CF is included in Rails 3.1, I guess that it should be guaranteed enough.


I looked in to it. While technically possible it looks like you'll have to include a script to implement the python-like objects. That's a bit more than I wanted, just to write javascript in python syntax... so I guess it's not very practical.


"Not to mention ===, etc, etc."

In that context, I read "etc, etc" as a variant of the "etc" operator.


Proper tail-calls! Of course, I think neither Python nor Ruby support them either, but one can dream...


I remember being impressed by a Microsoft project[1] a few years ago that did exactly this, it seems it never took off.

[1] http://visitmix.com/labs/gestalt/


It's based on IronPython/IronRuby/DLR. I've been to a few PyCons and the CPython-based developers never seemed all that interested in it due to library support, and the majority of work happening on UNIX platforms. At the same time .NET developers didn't know what to do with this great set of tools.


If you spend all your energy complaining about JavaScript and demanding the browser vendors provide you with a better replacement the problem here is not JavaScript, it's you.

JavaScript is far from the best language ever created, but it's also far from the worst.

The biggest pain in the ass working with JavaScript on a day to day basis is not JavaScript itself -- most of its follies can be avoided by good programming practices -- it's the DOM.


JS has lots and lots of fundametal issues. Weird OO implementation (argue all you want but prototype inheritance is not what the prevailing wisdom is on how to do OO), no type system (at least give the option!), no packages/modules, no generics.

Don't people want dev tools to better help them building and refactoring web code? Web dev is like 15 years behind server development.


Of course some of these things are being fixed (e.g. modules are being added; there has been talk of optional types). At least when Google or Microsoft aren't dragging their feet and sabotaging the process.

As for generics, I'm not sure what you're looking for there; it's pretty simple to write generic functions in JS, or indeed any language with duck typing, no?


I really don't think it's fair to insist that if anyone doesn't think Javascript is the optimal solution to every client-side web programming problem, they are themselves 'the problem'.

"There are worse things than Javascript" is not a great argument for why nobody should ever try to improve the situation.


Just don't tell me we need to have JavaScript on the server side too, for like, consistency, man.


Mono (actually a fork of it) can already compile C# to run on Chrome NativeClient. So, you're very close, there.

Also, this:

http://mail.python.org/pipermail/python-dev/2009-June/090038...


If Python uses indentation rather than curly braces or keywords, then it would not allow for minimization or obfuscation when used in the browser. This is the main reason IMO Google chose to design Dart with curly braces.


Playing the devil's advocate, if the browser just had a VM and ran bytecode, the syntax wouldn't matter.


> IMO Google chose to design Dart with curly braces.

I don't think minification was a concern. Familiarity was: the world's most popular languages are curly-based so adopting that makes the language easier to learn for millions of coders.


gzip will negate a great deal of that advantage.


This is an interesting implementation of python in the browser. It's a python interpreter written in JS, so you wouldn't need any new software on the users end.

http://www.skulpt.org/


I would prefer a standard byte-code VM inside of every browser so we could just make compilers targeting that VM. Then anyone could choose their preferred language :)


I would too, but what will be the characteristics of that VM?

And who 'owns' the technology?


Well people are doing something:

http://repl.it/

http://syntensity.com/static/python.html

https://github.com/replit/emscripted-ruby


The shortest good answer I can come up with is reducing security exposure. Ending support for JavaScript is not an option, so browser makers would have to deal with the surface of one or two extra languages in addition to JavaScript.

I don't think they need the extra work.


Those languages (which I both quite enjoy) are a bit slow though. Maybe something like Lua which already has a pretty amazing JIT available?


1. why does stackoverflow close all the interesting questions?

2. fuck is wrong with javascript?


Interesting questions don't have definitive answers.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: