3 ms·

What the use case for something like this? Am I missing something?

by 5vforest 14y ago

astrodust 14y ago
Porting existing code without having to re-implement. Keeping a single reference implementation of a particular method.
- rgovind 14y ago
  on related note, when and if node.js takes off, does it make sense to have a php-to-javascript compiler so people don't need to redo a lot of stuff?
mikesea 14y ago
Rewriting your entire Rails app in Node so that it goes faster!
Sanddancer 14y ago
Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.
- MatthewPhillips 14y ago
  ? Doesn't this show that we aren't stuck with the same hammer? Opal is a different hammer.
  - rrouse 14y ago
    Not really. You're still using Javascript in the end.
    - ville 14y ago
      How is that a bad thing? Source code VMs are easier to secure and as the tooling improves, you don't need to look a the generated JS anymore to debug, it becomes "byte code".
- rcthompson 14y ago
  Wasn't that the original goal of Java, like, 20 years ago?
  - Sanddancer 14y ago
    It was, but the big issue there was that sun decided to keep all the keys of the castle to themselves. Hence the desire for an open bytecode format.
- iso8859-1 14y ago
  Native Client? Or PNaCl if you insist on extreme portability.
threedaymonk 14y ago
If you can perform computation on the client, you can avoid some round trips to the server. Of course, you can't trust the client, so you still need to perform (some of) the same computations on the server. If you can use the same code for both client and server, then it opens up the possibility of sending chunks of logic over the wire. Here's a trivial example: a website uses Markdown for comment formatting. You can improve the feedback cycle, especially for those who aren't overly familiar with Markdown, by rendering a preview on the client side. However, this means that you need two Markdown parsers, one in your server-side language, and one in JavaScript. That's a potential duplication of effort. Someone has already written a JS Markdown parser, but it might not have exactly the same behaviour as your server implementation. So why not just write the code once and have it work on both sides? I have a feeling that there are a lot more interesting things that you can do with split computation, but I haven't seen many examples yet. I think they'll come.

What the use case for something like this? Am I missing something?

astrodust 14y ago

Porting existing code without having to re-implement. Keeping a single reference implementation of a particular method.

rgovind 14y ago
on related note, when and if node.js takes off, does it make sense to have a php-to-javascript compiler so people don't need to redo a lot of stuff?

mikesea 14y ago

Rewriting your entire Rails app in Node so that it goes faster!

Sanddancer 14y ago

Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.

MatthewPhillips 14y ago
? Doesn't this show that we aren't stuck with the same hammer? Opal is a different hammer.
- rrouse 14y ago
  Not really. You're still using Javascript in the end.
  - ville 14y ago
    How is that a bad thing? Source code VMs are easier to secure and as the tooling improves, you don't need to look a the generated JS anymore to debug, it becomes "byte code".
rcthompson 14y ago
Wasn't that the original goal of Java, like, 20 years ago?
- Sanddancer 14y ago
  It was, but the big issue there was that sun decided to keep all the keys of the castle to themselves. Hence the desire for an open bytecode format.
iso8859-1 14y ago
Native Client? Or PNaCl if you insist on extreme portability.

threedaymonk 14y ago

If you can perform computation on the client, you can avoid some round trips to the server. Of course, you can't trust the client, so you still need to perform (some of) the same computations on the server. If you can use the same code for both client and server, then it opens up the possibility of sending chunks of logic over the wire. Here's a trivial example: a website uses Markdown for comment formatting. You can improve the feedback cycle, especially for those who aren't overly familiar with Markdown, by rendering a preview on the client side. However, this means that you need two Markdown parsers, one in your server-side language, and one in JavaScript. That's a potential duplication of effort. Someone has already written a JS Markdown parser, but it might not have exactly the same behaviour as your server implementation. So why not just write the code once and have it work on both sides? I have a feeling that there are a lot more interesting things that you can do with split computation, but I haven't seen many examples yet. I think they'll come.