Why don't they implement Python and Ruby on the web browsers?
stackoverflow.com
stackoverflow.com
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.
I realize that Python and Ruby would be standard and open but people still fear the possible fragmentation.
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.
Someody else already mentioned that compiling python or ruby to JavaScript could be an option. We already have clojurescript which does this.
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.
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 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".
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.
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?
> 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.
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.
> 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'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.
(parenscript http://common-lisp.net/project/parenscript/)
(clojurescript https://github.com/clojure/clojurescript)
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.
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.
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.
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...
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.
> 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".
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.
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.
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.
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 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?).
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, 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.
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.
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.)
No, wait a minute...
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.
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 doubt the web is going anywhere...
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.
- 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.
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.
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.
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.
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.
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.
Have you used Java libraries in JS or vice-versa? That's the problem the parent is referring to.
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.
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.
I did. Please solve the problem I put forward. If you solve it, you win.
function multiplyString(str, times) {
while (times) {
str += str;
times -= 1;
}
return str;
}
<?php
console->log(multiplyString("Hello", 3));
?>
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Says who? I love JavaScript, as do a great many other developers. I look at CoffeeScript and all I can think is yuk.
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.
So you can understand and master JS (including prototypical programming) and still hate it.
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...
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.
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.
"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.
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.
I would never write pure javascript, but using languages that compile to javascript has been pure joy.
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.
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.
...
The number of programming topics I have had closed on that site angers me. They are becoming Wikipedia.
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.
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.
> 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.
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?
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.
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).
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.
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.
Now that you mention it if I'm going to do that, why not use the python-to-javascript compiler from pyjamas? ... hmm.
Talking about future support, as CF is included in Rails 3.1, I guess that it should be guaranteed enough.
In that context, I read "etc, etc" as a variant of the "etc" operator.
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.
Don't people want dev tools to better help them building and refactoring web code? Web dev is like 15 years behind server development.
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?
"There are worse things than Javascript" is not a great argument for why nobody should ever try to improve the situation.
Also, this:
http://mail.python.org/pipermail/python-dev/2009-June/090038...
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.
And who 'owns' the technology?
I don't think they need the extra work.
2. fuck is wrong with javascript?