Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discussing a bytecode standard in browsers

aminutewithbrendan.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Discussing a bytecode standard in browsers

#11

Post by jbjohns »

Joeri wrote: post #3

The curious thing about the demand for bytecode in browsers is that there doesn't seem to be a practical reason to do it. Bytecode doesn't seem to bring better performance, as flash doesn't outperform javascript. And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. Javascript-to-javascript compilation (closure compiler) is more p…

>The curious thing about the demand for bytecode in browsers is that there doesn't seem to be a practical reason to do it.

Really? Javascript is an opinionated high level language. I wonder how many people using Javascript these days actually write it. Personally I haven't bothered to learn Javascript, I just use libraries in my preferred languages to generate it. This works fine for me so long as I don't have to debug it...

Re: Discussing a bytecode standard in browsers

#12

Post by protomyth »

lukev wrote: post #9
Joeri wrote: post #3

The curious thing about the demand for bytecode in browsers is that there doesn't seem to be a practical reason to do it. Bytecode doesn't seem to bring better performance, as flash doesn't outperform javascript. And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. Javascript-to-javascript compilation (closure compiler) is more p…

> And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. I've met tons who WANT to use other languages. The reason they don't cross-compile more often is that for the most part cross-compilation sucks - it is impossible to debug through, for one thing. GWT managed to get around most of these issues which is why it's so popular, but…

To add, I get the feeling that a standard byte code would create a huge number of compilers specifically so people could use the same language they are using on the server for client work. I would also expect a VM running the byte code to migrate back to the servers.

Re: Discussing a bytecode standard in browsers

#13

Post by chc »

Joeri wrote: post #10
j_baker wrote: post #8

Earlier quoted context omitted.

I think bytecode in the browser would be useful even if we still used it to run pre-compiled JavaScript code that got no speed benefit. Not only would it remove the problem of different browsers having different versions of the language standard, but it would allow the language to evolve without having to wait for every browser to catch up to the standard.

Yeah, but all the popular bytecode engines end up being versioned anyway. I don't doubt that bytecode would allow for adding some syntactic sugar without upgrading the browser engine, but so does JS-to-JS compilation, which is available today, even on IE6. And if people really wanted those features, wouldn't there be tons of objective-j programmers?

No, because Objective-J essentially just adds Objective-C syntax on top of JavaScript — but most people don't particularly love the syntax of Objective-C. You look at one language's lack of popularity and extrapolate that people just must not like languages.

Re: Discussing a bytecode standard in browsers

#14

Post by jimmyjazz14 »

Joeri wrote: post #3

The curious thing about the demand for bytecode in browsers is that there doesn't seem to be a practical reason to do it. Bytecode doesn't seem to bring better performance, as flash doesn't outperform javascript. And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. Javascript-to-javascript compilation (closure compiler) is more p…

I would much prefer to be able to use another language in the browser, if languages are tools then programmers developing for browsers only currently have one tool available to them (unless you count html and css) which I see as a pretty major stumbling block towards new innovations.

Re: Discussing a bytecode standard in browsers

#15

Post by stcredzero »

lukev wrote: post #9
Joeri wrote: post #3

The curious thing about the demand for bytecode in browsers is that there doesn't seem to be a practical reason to do it. Bytecode doesn't seem to bring better performance, as flash doesn't outperform javascript. And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. Javascript-to-javascript compilation (closure compiler) is more p…

> And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. I've met tons who WANT to use other languages. The reason they don't cross-compile more often is that for the most part cross-compilation sucks - it is impossible to debug through, for one thing. GWT managed to get around most of these issues which is why it's so popular, but…

The reason they don't cross-compile more often is that for the most part cross-compilation sucks - it is impossible to debug through, for one thing.

So, is the issue really the ability to use source debugging? We could still treat Javascript as an Intermediate Language and add a Source Pointer data format that would enable source debuggers in the cross-compiled languages.

In fact, we could build such things into Firefox and Chromium ourselves!

Re: Discussing a bytecode standard in browsers

#17

Post by Joeri »

stcredzero wrote: post #15
lukev wrote: post #9

Earlier quoted context omitted.

> And web developers don't seem to want to use other languages, given that aside from GWT (almost) nobody cross-compiles from another language. I've met tons who WANT to use other languages. The reason they don't cross-compile more often is that for the most part cross-compilation sucks - it is impossible to debug through, for one thing. GWT managed to get around most of these issues which is why it's so popular, but…

The reason they don't cross-compile more often is that for the most part cross-compilation sucks - it is impossible to debug through, for one thing. So, is the issue really the ability to use source debugging? We could still treat Javascript as an Intermediate Language and add a Source Pointer data format that would enable source debuggers in the cross-compiled languages. In fact, we could build such things into Fire…

My point exactly. The demand for other languages is clearly not big enough for people to have hacker together an implementation of it on top of what's there today. It can be done, it's just that very few people are busy doing it.

Re: Discussing a bytecode standard in browsers

#18

Post by Joeri »

chc wrote: post #13
Joeri wrote: post #10

Earlier quoted context omitted.

Yeah, but all the popular bytecode engines end up being versioned anyway. I don't doubt that bytecode would allow for adding some syntactic sugar without upgrading the browser engine, but so does JS-to-JS compilation, which is available today, even on IE6. And if people really wanted those features, wouldn't there be tons of objective-j programmers?

No, because Objective-J essentially just adds Objective-C syntax on top of JavaScript — but most people don't particularly love the syntax of Objective-C. You look at one language's lack of popularity and extrapolate that people just must not like languages.

First of all, a lot more people like that syntax than you make it out to be. It's popular enough that objective-j should have caught on. The fact that it didn't is telling.

Secondly, I was only using it as an example. I base my opinion on the lack of popularity of all cross-compilation engines except GWT. There's two ways of looking at that. One is that GWT proves the demand for other languages because of its success. The other is that GWT proves the demand for other languages is not that big, because otherwise those other languages would have GWT-like platforms in the field already. I'm partial to the latter.

Post reply on HN