5 ms·

You are on a path to enlightenment. JavaScript is an elegant and truly flexible language - very well suited to the roll we have given it in remote (and until r

by bdfh42 16y ago

You are on a path to enlightenment. JavaScript is an elegant and truly flexible language - very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments. I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions.

pedrocr 16y ago
>You are on a path to enlightenment. It's starting with a bit of rage though :) > JavaScript is an elegant and truly flexible language To me it looks like it has a beautiful prototype-OO language trapped inside it somewhere. The point is more I'd rather get the work done with the tools I like than be forced to learn it. > very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments I find strange that what suits the environment is a language instead of a bytecode interpreter of some sort. Lua seems to have pretty compact implementations for example. > I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions. I have issues with that I know but what I always feel is that I am struggling with that plus figuring out how to properly iterate an array or implement a dictionary (both things I've found to be ugly and/or non-trivial in Javascript)
- bdfh42 16y ago
  Perhaps time for a little zen ;) >I'd rather get the work done with the tools I like Well you can - within your own computing environment but when you want to reach out and run code on your user's computer then you have to take the tools available. In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing. <language instead of a bytecode interpreter It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform. <properly iterate an array Just picking on of your points here - It may be that you can solve each obstacle just the once and retain that solution into the future. As an example try https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach https://developer.mozilla.org/en/JavaScript/Reference/Global... for how to add "forEach" functionality to an array - an array which (of course) can contain objects of any type. I just love the ability to work with arrays (collections) of objects representing server side classes.
  - pedrocr 16y ago
    Thanks for the reply >In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing. We have enough VM's that can do the same, it's not really a technical issue, which is what frustrates me. >It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. Yep, and I'd rather be able to target that. > JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform. It isn't fully portable really. Much less than any standardized bytecode anyway. One thing I've also struggled with is that I not only have to figure out Javascript I have to figure out each browser's take on it. I've had the same code fail subtly on Chrome while working fine on Firefox. > for how to add "forEach" functionality to an array I implemented this kind of thing in my own code and it works although the "block" syntax is a bit ugly ("function() {}"). > I just love the ability to work with arrays (collections) of objects representing server side classes. I'm not sure what you mean here. One bit that has frustrated me is replicating in Javascript code what I already have for the same concepts/models in Rails. Although some of that is surely bad separation between client and server on my part.
    - bdfh42 16y ago
      You are probably aware of these anyway but - just in case... jQuery (and other frameworks) deal with almost all browser compatibility issues when it comes to the UI. JSON is a great format for passing class properties from server to client and back again making it reasonably straightforward to connect (via AJAX) JavaScript objects with server side classes.
tzs 16y ago
I think the problem he's highlighting is with the browser executing a specific language. If it used a bytecode system, like JVM, CLR, or similar, you could still use Javascript--just compiled down to the appropriate bytecode. But others could use Ruby, or Python, or Java, or C#, or any other language that can be compiled to the appropriate bytecode.
- count 16y ago
  They're not mutually exclusive. Coffeescript[1], for example, compiles to javascript, but isn't javascript itself. I'd bet most browsers have a JVM installed as well, so there's that... [1]http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
- lelele 16y ago
  Javascript _is_ the bytecode system. Many people have laughed after Joel Spolski for Wasabi. Well, Joel had the right idea: just use whatever in-house language you want, just be careful to translate it in a language/platform your customers are more likely to have installed already,

by bdfh42 16y ago

pedrocr 16y ago

>You are on a path to enlightenment. It's starting with a bit of rage though :) > JavaScript is an elegant and truly flexible language To me it looks like it has a beautiful prototype-OO language trapped inside it somewhere. The point is more I'd rather get the work done with the tools I like than be forced to learn it. > very well suited to the roll we have given it in remote (and until recently) pretty simplistic client environments I find strange that what suits the environment is a language instead of a bytecode interpreter of some sort. Lua seems to have pretty compact implementations for example. > I suggest that your issues are not with JavaScript per se but with managing the flow of data and functionality between the server and the client. I am not suggesting that will become easy but, with experience, you will find workmanlike solutions. I have issues with that I know but what I always feel is that I am struggling with that plus figuring out how to properly iterate an array or implement a dictionary (both things I've found to be ugly and/or non-trivial in Javascript)

bdfh42 16y ago
Perhaps time for a little zen ;) >I'd rather get the work done with the tools I like Well you can - within your own computing environment but when you want to reach out and run code on your user's computer then you have to take the tools available. In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing. <language instead of a bytecode interpreter It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform. <properly iterate an array Just picking on of your points here - It may be that you can solve each obstacle just the once and retain that solution into the future. As an example try https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach https://developer.mozilla.org/en/JavaScript/Reference/Global... for how to add "forEach" functionality to an array - an array which (of course) can contain objects of any type. I just love the ability to work with arrays (collections) of objects representing server side classes.
- pedrocr 16y ago
  Thanks for the reply >In this instance we have a (broadly) common language that runs on Windows, Mac, Linux and then some - thats pretty amazing. We have enough VM's that can do the same, it's not really a technical issue, which is what frustrates me. >It would be trite to point out that what you have "under the hood" in JavaScript implementations is a pretty good JIT bytecode interpreter. Yep, and I'd rather be able to target that. > JavaScript code represents a fully portable version of the code that will run in the user chosen browser on the user chosen hardware platform. It isn't fully portable really. Much less than any standardized bytecode anyway. One thing I've also struggled with is that I not only have to figure out Javascript I have to figure out each browser's take on it. I've had the same code fail subtly on Chrome while working fine on Firefox. > for how to add "forEach" functionality to an array I implemented this kind of thing in my own code and it works although the "block" syntax is a bit ugly ("function() {}"). > I just love the ability to work with arrays (collections) of objects representing server side classes. I'm not sure what you mean here. One bit that has frustrated me is replicating in Javascript code what I already have for the same concepts/models in Rails. Although some of that is surely bad separation between client and server on my part.
  - bdfh42 16y ago
    You are probably aware of these anyway but - just in case... jQuery (and other frameworks) deal with almost all browser compatibility issues when it comes to the UI. JSON is a great format for passing class properties from server to client and back again making it reasonably straightforward to connect (via AJAX) JavaScript objects with server side classes.

tzs 16y ago

I think the problem he's highlighting is with the browser executing a specific language. If it used a bytecode system, like JVM, CLR, or similar, you could still use Javascript--just compiled down to the appropriate bytecode. But others could use Ruby, or Python, or Java, or C#, or any other language that can be compiled to the appropriate bytecode.

count 16y ago
They're not mutually exclusive. Coffeescript[1], for example, compiles to javascript, but isn't javascript itself. I'd bet most browsers have a JVM installed as well, so there's that... [1]http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
lelele 16y ago
Javascript _is_ the bytecode system. Many people have laughed after Joel Spolski for Wasabi. Well, Joel had the right idea: just use whatever in-house language you want, just be careful to translate it in a language/platform your customers are more likely to have installed already,