Live data from Hacker News

Why don't they implement Python and Ruby on the web browsers?

stackoverflow.com

81–90 of 144 posts

Re: Why don't they implement Python and Ruby on the web browsers?

#81
post #49

Earlier quoted context omitted.

> 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…

> 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 po…

> 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.

Re: Why don't they implement Python and Ruby on the web browsers?

#83
post #63

Earlier quoted context omitted.

> 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 lang…

> 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 producti…

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?

Re: Why don't they implement Python and Ruby on the web browsers?

#84
post #63

Earlier quoted context omitted.

> 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 producti…

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".

Re: Why don't they implement Python and Ruby on the web browsers?

#85
post #78
post #72

Earlier quoted context omitted.

> 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 f…

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.

Re: Why don't they implement Python and Ruby on the web browsers?

#86
post #84

Earlier quoted context omitted.

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 t…

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.

Re: Why don't they implement Python and Ruby on the web browsers?

#87
post #81

Earlier quoted context omitted.

> 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 po…

> 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.

Re: Why don't they implement Python and Ruby on the web browsers?

#88

Earlier quoted context omitted.

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 d…

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 tags, something no other language could enjoy. So every brows…

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 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 tags HAVE to contain JS? I see no reason why if we're changing to a generic byte code web, JS in 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.

Re: Why don't they implement Python and Ruby on the web browsers?

#89
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.

Re: Why don't they implement Python and Ruby on the web browsers?

#90
post #26

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 programmin…

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.

Post reply on HN