4 ms·

Can't wait for the general sentiment to turn to match. Whereas PHP has been sneered at by non-PHP devs since time immemorial, JavaScript is seeing widespread up

Can't wait for the general sentiment to turn to match. Whereas PHP has been sneered at by non-PHP devs since time immemorial, JavaScript is seeing widespread uptake by supposedly "senior" people across the spectrum. I've asked several of these people to explain the attraction (one of whom had a fascination with the even-worse CoffeeScript) and thus far I have not really come across a satisfactory explanation. To me, JavaScript is still the language you only use when you have to because it's the only runtime the browser vendors will embed.

stcredzero 10y ago
I've asked several of these people to explain the attraction http://quoteinvestigator.com/2013/02/10/where-money-is/ http://quoteinvestigator.com/2013/02/10/where-money-is/ Javascript is a "workable" or "decent" language, and it happens to run where the users are. This is also a large part of why C++ was a success and C before it.
- cookiecaper 10y ago
  This works when you're executing code "where the users are", as I conceded in the parent post (it's the language you use when you have to). It doesn't explain why they'd willingly switch away from another server-side language to re-implement the whole thing in server-side JavaScript.
  - stcredzero 10y ago
    Because it's the same code as the client, which is "where the users are." I guess you'd assert that having the same language on the client and server doesn't justify the cost of using the language.
    - cookiecaper 10y ago
      Correct. This argument, IMO, is mainly made by programmers who are afraid of working in more than one language at once, traditionally .NET developers who are used to an entire, ready-made, tied-up-in-a-bow ecosystem being dropped on their doorstep. I have a lot of trouble sympathizing with that perspective (even though I've had multiple jobs as a full-time .NET developer). JavaScript is not good. We should be working to get it out of the way, not converting everything in our environments to run on it.
  - debaserab2 10y ago
    I can't really defend their language choice perse, but if you look at the aims of the project - make a terminal that's consistent across platforms and focuses on extendability and interface, what IS your best option? Writing natively for each platform doesn't seem feasible. Using something browser based that has many of those cross platform kinks ironed out doesn't seem like that bad of a choice if that's your top priority. Whether or not that makes it a solid, durable terminal program is another question, though.
    - jsjohnst 10y ago
      There's numerous cross-platform alternatives to using JavaScript. Not saying they are inherently better, but there are a hundred different ways to accomplish this.
      - debaserab2 10y ago
        OK, sure, but not exactly what I was pointing out. If your goal is to provide a consistent look and user experience across platforms and be easily extendable, what do you choose? Feel free to name one.
        jsjohnst 10y ago
        Remember, this is a terminal emulator. It's fairly easy to get a consistent look and feel, even across platforms. You asked for one, here's five: * GTK+ * wxWidgets * Swing * SWT * Tcl/Tk You then mentioned "easily extendable". I'm not sure if you'll agree Swing/SWT are easily extendable (I'd argue they can be), but wxWidgets and GTK+ have bindings available in many common scripting languages (heck, even PHP!) which are just as easy to extend as JavaScript is. Again, I'm not arguing any of these are better suited, just responding to your point that there was no alternative.
        debaserab2 10y ago
        I said it "isn't a bad choice", not "there is no other alternative". Of the 5 alternates you provided, can you name me an app that runs on major platforms that people describe as a good user experience? Not just that they work, but that they serve as good example of how to design a user experience. The only one that I can think of that I use on an everyday basis is the JetBrains apps which are built in java, although what UI implementation they're using I'm unsure. Beyond that, all the good cross platform apps that I can think that aren't using something webkit based (slack/atom/discord/etc) use native OS GUI implementations. I'm sure there are others, but it's hard to completely discredit the browser-as-an-app approach. From what I gathered from the project, it's aim is to go beyond being just another terminal emulator and provide a certain amount of bells and whistles through its interface. Turns out interface bells and whistles is something that HTML+CSS+Javascript has nailed pretty well while remaining cross platform compatible.
  - jsjohnst 10y ago
    The only really "good" reason in my opinion is to use the same code that renders the page in the browser to be used to render the page on the server. I've never seen this done well in production though. Dav Glass did some awesome hack day projects in the early days of Node.js demonstrating how this could work for Yahoo mail. Hit your inbox for the first time in a browser session and it'll send back a full HTML page rather than a bunch of JS files and expect the client to render before anything appears. With this you could have less than one second full render times for a complex single page app. Imagine if Gmail did something like this, you wouldn't need to leave a tab open to avoid the 5-10sec it takes from login till inbox shows. Furthermore, you could build this out further where if the "compose page" JavaScript hadn't loaded yet, you could then roundtrip to the server and get the markup rather than waiting on it to parse and execute on a slower machine. Not saying everyone should do this obviously, but it is a valid use case for JavaScript on the server if done right IMHO.
- flukus 10y ago
  This is a desktop app, "where the users are" isn't a compelling argument because it could be in practically any language and have the same barrier to entry.

stcredzero 10y ago

I've asked several of these people to explain the attraction http://quoteinvestigator.com/2013/02/10/where-money-is/ http://quoteinvestigator.com/2013/02/10/where-money-is/ Javascript is a "workable" or "decent" language, and it happens to run where the users are. This is also a large part of why C++ was a success and C before it.

cookiecaper 10y ago
This works when you're executing code "where the users are", as I conceded in the parent post (it's the language you use when you have to). It doesn't explain why they'd willingly switch away from another server-side language to re-implement the whole thing in server-side JavaScript.
- stcredzero 10y ago
  Because it's the same code as the client, which is "where the users are." I guess you'd assert that having the same language on the client and server doesn't justify the cost of using the language.
  - cookiecaper 10y ago
    Correct. This argument, IMO, is mainly made by programmers who are afraid of working in more than one language at once, traditionally .NET developers who are used to an entire, ready-made, tied-up-in-a-bow ecosystem being dropped on their doorstep. I have a lot of trouble sympathizing with that perspective (even though I've had multiple jobs as a full-time .NET developer). JavaScript is not good. We should be working to get it out of the way, not converting everything in our environments to run on it.
- debaserab2 10y ago
  I can't really defend their language choice perse, but if you look at the aims of the project - make a terminal that's consistent across platforms and focuses on extendability and interface, what IS your best option? Writing natively for each platform doesn't seem feasible. Using something browser based that has many of those cross platform kinks ironed out doesn't seem like that bad of a choice if that's your top priority. Whether or not that makes it a solid, durable terminal program is another question, though.
  - jsjohnst 10y ago
    There's numerous cross-platform alternatives to using JavaScript. Not saying they are inherently better, but there are a hundred different ways to accomplish this.
    - debaserab2 10y ago
      OK, sure, but not exactly what I was pointing out. If your goal is to provide a consistent look and user experience across platforms and be easily extendable, what do you choose? Feel free to name one.
      - jsjohnst 10y ago
        Remember, this is a terminal emulator. It's fairly easy to get a consistent look and feel, even across platforms. You asked for one, here's five: * GTK+ * wxWidgets * Swing * SWT * Tcl/Tk You then mentioned "easily extendable". I'm not sure if you'll agree Swing/SWT are easily extendable (I'd argue they can be), but wxWidgets and GTK+ have bindings available in many common scripting languages (heck, even PHP!) which are just as easy to extend as JavaScript is. Again, I'm not arguing any of these are better suited, just responding to your point that there was no alternative.
        debaserab2 10y ago
        I said it "isn't a bad choice", not "there is no other alternative". Of the 5 alternates you provided, can you name me an app that runs on major platforms that people describe as a good user experience? Not just that they work, but that they serve as good example of how to design a user experience. The only one that I can think of that I use on an everyday basis is the JetBrains apps which are built in java, although what UI implementation they're using I'm unsure. Beyond that, all the good cross platform apps that I can think that aren't using something webkit based (slack/atom/discord/etc) use native OS GUI implementations. I'm sure there are others, but it's hard to completely discredit the browser-as-an-app approach. From what I gathered from the project, it's aim is to go beyond being just another terminal emulator and provide a certain amount of bells and whistles through its interface. Turns out interface bells and whistles is something that HTML+CSS+Javascript has nailed pretty well while remaining cross platform compatible.
- jsjohnst 10y ago
  The only really "good" reason in my opinion is to use the same code that renders the page in the browser to be used to render the page on the server. I've never seen this done well in production though. Dav Glass did some awesome hack day projects in the early days of Node.js demonstrating how this could work for Yahoo mail. Hit your inbox for the first time in a browser session and it'll send back a full HTML page rather than a bunch of JS files and expect the client to render before anything appears. With this you could have less than one second full render times for a complex single page app. Imagine if Gmail did something like this, you wouldn't need to leave a tab open to avoid the 5-10sec it takes from login till inbox shows. Furthermore, you could build this out further where if the "compose page" JavaScript hadn't loaded yet, you could then roundtrip to the server and get the markup rather than waiting on it to parse and execute on a slower machine. Not saying everyone should do this obviously, but it is a valid use case for JavaScript on the server if done right IMHO.
flukus 10y ago
This is a desktop app, "where the users are" isn't a compelling argument because it could be in practically any language and have the same barrier to entry.