5 ms·

Bytecode on the web is a shitty idea. The minifiers and obfuscators out there are already breaking "view source" and with that the spirit of the web. Besides:

by lerouxb 14y ago

Bytecode on the web is a shitty idea. The minifiers and obfuscators out there are already breaking "view source" and with that the spirit of the web. Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot?

icebraining 14y ago
I think minifiers and obfuscators already destroyed any hope of learning from websites. But on the other hand, Github and the likes are a much better learning source than we ever had.
- bmj 14y ago
  With the advent of pretty print in Chrome's web development console (and add-ons available for Firefox), minifiers are less of an issue for learning how a site works. I suspect that minifier arguments are no-win situations: either someone doesn't like that they can't easily read the JavaScript, or someone complains it takes too long to load the scripts for a given page.
  - nilved 14y ago
    I like sites that have a predictable `.min.js` convention; if I want to see the source code for `main.min.js`, I visit `main.js`.
tomjen3 14y ago
Only if you assume that view source was ever a good idea. If the writer wants you to see the source, you can download it elsewere (githun, etc) if not, there is no difference between not getting the source to office 98 and not getting the source to google docs.
- coderdude 14y ago
  It was certainly a good idea. When the Web was young and there was no GitHub, viewing a page's source made it so that you could see by example how every page worked. It exposed you to a huge number of possibilities. The Web partially owes its success to this feature because without it far fewer people would have made it to the stage where they could produce their own pages. Every web developer/designer has used this to help them -- guaranteed. Besides, the feature would have sprung up anyway whether the browser vendors wanted it included or not. Third parties would have stepped in. It's plain text transmitted over the wire. Unlike the source of Office 98 which is not retrievable from the Office 98 binary, a page's source is readily available to the machine that has to cobble it all together when viewing that page.
- JonnieCache 14y ago
  The presence of the View Source item in the context menu of all web browsers is where many people first interacted with source code. Long may it remain there.
- im3w1l 14y ago
  Never underestimate the power of sensible defaults.
exDM69 14y ago
> Bytecode on the web is a shitty idea. In my book, some kind of byte code or other intermediate language is a lot better idea than distributing the source code of web apps. There are a lot of disadvantages to delivering programs (for immediate execution) as source code. Note: this is orthogonal to open source and licensing. So what would be needed is an intermediate program representation that: - Is well defined - Is a good compilation target from various source languages - Is easy to validate for correctness and security - Is fast to interpret and compile - Distributed in fast to read binary format - Suits a dynamic language In my opinion LLVM IR or CLR bytecode are the most technically suitable alternatives out of existing ones. The web has quite a long legacy of Javascript and a tradition of supporting deprecated browsers so this kind of revolution is unlikely to happen any time soon. > Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? JVM, CLR and LLVM are all popular compilation targets that are used with dozens of different source languages each. Bytecode and program representation was never the hard part, it's the frameworks of the OS/platform underneath.
- masklinn 14y ago
  LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked), and developers of JVM-based language have almost as much work bridging the differences between their language's semantics and Java's (for which the JVM's bytecode exists first and foremost) as they'd need to create a new runtime. > Bytecode and program representation was never the hard part Bytecode is very much a hard part if you're trying to support more than a single language, many bytecode have both language and VM semantics leaking in, which essentially makes them even less useful than cross-language compilation.
  - exDM69 14y ago
    > LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked) Most of LLVM IR is portable, but naturally there are target-specific parts. If LLVM IR was to be used in the web, these target specific parts would be defined for the "web" target. LLVM IR is used in a similar manner in NaCl and OpenCL where it is used as a portable binary format. > Bytecode is very much a hard part if you're trying to support more than a single language It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used.
batista 14y ago
>Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? Really? Remember the CLR and JVM?
- MatthewPhillips 14y ago
  Where are the CLR or JVM implementations of JavaScript that run as fast as V8 or Chakra?
  - jfoutz 14y ago
    I can't speak to the CLR, but the JVM isn't bad at all. http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php But, microbenchmarks, blah blah blah.
  - batista 14y ago
    What that has to do with anything? The post I replied to said that "language neutral bytecode project neve worked" and brought up Parrot as an example. He was not specific to them not working for Javascript. Now, besides off context, your comment is wrong in four ways: 1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages. 2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript. 3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too. 4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
    - MatthewPhillips 14y ago
      JavaScript is very relevant because there is tons of legacy code that has to run equally as fast in this new bytecode VM as it runs today under the various engines. The choice of VM comes down to how well it works with dynamic languages. JVM and CLR are both modeled after statically typed languages. Microsoft spent quite a bit of money trying to put JavaScript on top of .NET but finally gave up, and today it places it's IE platform on equal footing with .NET.

by lerouxb 14y ago

icebraining 14y ago

I think minifiers and obfuscators already destroyed any hope of learning from websites. But on the other hand, Github and the likes are a much better learning source than we ever had.

bmj 14y ago
With the advent of pretty print in Chrome's web development console (and add-ons available for Firefox), minifiers are less of an issue for learning how a site works. I suspect that minifier arguments are no-win situations: either someone doesn't like that they can't easily read the JavaScript, or someone complains it takes too long to load the scripts for a given page.
- nilved 14y ago
  I like sites that have a predictable `.min.js` convention; if I want to see the source code for `main.min.js`, I visit `main.js`.

tomjen3 14y ago

Only if you assume that view source was ever a good idea. If the writer wants you to see the source, you can download it elsewere (githun, etc) if not, there is no difference between not getting the source to office 98 and not getting the source to google docs.

coderdude 14y ago
It was certainly a good idea. When the Web was young and there was no GitHub, viewing a page's source made it so that you could see by example how every page worked. It exposed you to a huge number of possibilities. The Web partially owes its success to this feature because without it far fewer people would have made it to the stage where they could produce their own pages. Every web developer/designer has used this to help them -- guaranteed. Besides, the feature would have sprung up anyway whether the browser vendors wanted it included or not. Third parties would have stepped in. It's plain text transmitted over the wire. Unlike the source of Office 98 which is not retrievable from the Office 98 binary, a page's source is readily available to the machine that has to cobble it all together when viewing that page.
JonnieCache 14y ago
The presence of the View Source item in the context menu of all web browsers is where many people first interacted with source code. Long may it remain there.
im3w1l 14y ago
Never underestimate the power of sensible defaults.

exDM69 14y ago

> Bytecode on the web is a shitty idea. In my book, some kind of byte code or other intermediate language is a lot better idea than distributing the source code of web apps. There are a lot of disadvantages to delivering programs (for immediate execution) as source code. Note: this is orthogonal to open source and licensing. So what would be needed is an intermediate program representation that: - Is well defined - Is a good compilation target from various source languages - Is easy to validate for correctness and security - Is fast to interpret and compile - Distributed in fast to read binary format - Suits a dynamic language In my opinion LLVM IR or CLR bytecode are the most technically suitable alternatives out of existing ones. The web has quite a long legacy of Javascript and a tradition of supporting deprecated browsers so this kind of revolution is unlikely to happen any time soon. > Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? JVM, CLR and LLVM are all popular compilation targets that are used with dozens of different source languages each. Bytecode and program representation was never the hard part, it's the frameworks of the OS/platform underneath.

masklinn 14y ago
LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked), and developers of JVM-based language have almost as much work bridging the differences between their language's semantics and Java's (for which the JVM's bytecode exists first and foremost) as they'd need to create a new runtime. > Bytecode and program representation was never the hard part Bytecode is very much a hard part if you're trying to support more than a single language, many bytecode have both language and VM semantics leaking in, which essentially makes them even less useful than cross-language compilation.
- exDM69 14y ago
  > LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked) Most of LLVM IR is portable, but naturally there are target-specific parts. If LLVM IR was to be used in the web, these target specific parts would be defined for the "web" target. LLVM IR is used in a similar manner in NaCl and OpenCL where it is used as a portable binary format. > Bytecode is very much a hard part if you're trying to support more than a single language It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used.

batista 14y ago

>Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? Really? Remember the CLR and JVM?

MatthewPhillips 14y ago
Where are the CLR or JVM implementations of JavaScript that run as fast as V8 or Chakra?
- jfoutz 14y ago
  I can't speak to the CLR, but the JVM isn't bad at all. http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php But, microbenchmarks, blah blah blah.
- batista 14y ago
  What that has to do with anything? The post I replied to said that "language neutral bytecode project neve worked" and brought up Parrot as an example. He was not specific to them not working for Javascript. Now, besides off context, your comment is wrong in four ways: 1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages. 2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript. 3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too. 4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
  - MatthewPhillips 14y ago
    JavaScript is very relevant because there is tons of legacy code that has to run equally as fast in this new bytecode VM as it runs today under the various engines. The choice of VM comes down to how well it works with dynamic languages. JVM and CLR are both modeled after statically typed languages. Microsoft spent quite a bit of money trying to put JavaScript on top of .NET but finally gave up, and today it places it's IE platform on equal footing with .NET.