6 ms·

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 defea

• johno215 15y ago
  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.
  • nupark2 15y ago
    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.
    • chollida1 15y ago
      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.
      • aiscott 15y ago
        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.
        • chollida1 15y ago
          Doh, you are of course correct. I'm not sure how I didn't think of this :)
      • Lewisham 15y ago
        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.
• maratd 15y ago
  > 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.
  • nupark2 15y ago
    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.
    • maratd 15y ago
      > 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.
• MatthewPhillips 15y ago
  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.
  • nupark2 15y ago
    > 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".
    • maximusprime 15y ago
      > 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.
      • 15y ago
• zokier 15y ago
  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.
  • nupark2 15y ago
    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.
    • rat87 15y ago
      > Android: ObjC ???
      • nupark2 15y ago
        I believe these guys have an NDK-based implementation: http://www.apportable.com/ http://www.apportable.com/
• wvenable 15y ago
  > 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.
  • rsanders 15y ago
    Hey, that sounds familiar...
• wwweston 15y ago
  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?
  • nupark2 15y ago
    > 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.
• idonthack 15y ago
  JavaScript is your common bytecode.
• lang 15y ago
  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.
  • winteriscomming 15y ago
    Agreed.
  • cageface 15y ago
    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.
  • sciurus 15y ago
    Arguably there already is a totally new approach, centered around an app store rather than a browser.
• bitops 15y ago
  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.
• wladimir 15y ago
  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.