3 ms·

I tried to make this point in this submission: http://news.ycombinator.com/item?id=1790311 http://news.ycombinator.com/item?id=1790311 The fact that it also r

by pedrocr 16y ago

I tried to make this point in this submission: http://news.ycombinator.com/item?id=1790311 http://news.ycombinator.com/item?id=1790311 The fact that it also ranted about Javascript shifted the discussion though

mattmanser 16y ago
Just keep on saying it! I've also been coming to the same conclusion and saying it, though just like you ranting about other stuff brought negative reactions: http://news.ycombinator.com/item?id=1860623 http://news.ycombinator.com/item?id=1860623 http://news.ycombinator.com/item?id=1815214 http://news.ycombinator.com/item?id=1815214 But I'm glad to see more and more people are starting to argue for a pro-choice stance on languages in the browser.
user24 16y ago
I remembered that post when I saw this headline. I think from a philosophical viewpoint it's a good idea - though I've no idea what the implementation difficulties might be (could google have created V8 if we had a bytecode system?). But from a practical stance, what's the benefit? What would it achieve?
- pedrocr 16y ago
  >But from a practical stance, what's the benefit? What would it achieve? The reasons I outlined in my post were things like having a single form validation codebase, deployed both server side and client side. More ambitiously you could have the same codebase used for the server-side online portions of something like gmail and also retarget that to use for offline gmail. Basically the big divide between your server-side and client-side codebases would start to disappear. Seems like Google's native client system is a great step in this direction. Soon enough it may be possible to target say Lua to LLVM bytecode and deploy that to a browser in a bundle of javascript. If the browser supports NaCi you execute the LLVM bytecode with the built-in VM, if not you have a fallback bytecode interpreter in Javascript. That way you get full coverage of browsers with only degradation of performance when NaCi isn't available. I'm not sure however how fast you could make the Javascript fallback. If it is very slow it may not be workable.

by pedrocr 16y ago

mattmanser 16y ago

Just keep on saying it! I've also been coming to the same conclusion and saying it, though just like you ranting about other stuff brought negative reactions: http://news.ycombinator.com/item?id=1860623 http://news.ycombinator.com/item?id=1860623 http://news.ycombinator.com/item?id=1815214 http://news.ycombinator.com/item?id=1815214 But I'm glad to see more and more people are starting to argue for a pro-choice stance on languages in the browser.

user24 16y ago

I remembered that post when I saw this headline. I think from a philosophical viewpoint it's a good idea - though I've no idea what the implementation difficulties might be (could google have created V8 if we had a bytecode system?). But from a practical stance, what's the benefit? What would it achieve?

pedrocr 16y ago
>But from a practical stance, what's the benefit? What would it achieve? The reasons I outlined in my post were things like having a single form validation codebase, deployed both server side and client side. More ambitiously you could have the same codebase used for the server-side online portions of something like gmail and also retarget that to use for offline gmail. Basically the big divide between your server-side and client-side codebases would start to disappear. Seems like Google's native client system is a great step in this direction. Soon enough it may be possible to target say Lua to LLVM bytecode and deploy that to a browser in a bundle of javascript. If the browser supports NaCi you execute the LLVM bytecode with the built-in VM, if not you have a fallback bytecode interpreter in Javascript. That way you get full coverage of browsers with only degradation of performance when NaCi isn't available. I'm not sure however how fast you could make the Javascript fallback. If it is very slow it may not be workable.