41–50 of 144 posts
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.
Earlier quoted context omitted.
> 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…
> 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…
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.
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…
> 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…
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 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…
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?
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…
Earlier quoted context omitted.
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…
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.
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.
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.
Why arent browser UI's created using HTML, CSS and JS ?
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...
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…
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 poin…
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 +webgl provide a modern successor. A generic rendering environment with client-side code execution.
Earlier quoted context omitted.
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 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?).