4 ms·

> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language I didn't say it was just for minor work

> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today. It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages. Why anyone thinks server-side javascript is a good idea is beyond me.

marknutter 13y ago
> Why anyone thinks server-side javascript is a good idea is beyond me. That someone would want to use the same language to write both their client and server side code is beyond you?
- Herald_MJ 13y ago
  When that language is javascript, yes.
  - mwcampbell 13y ago
    Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
    - Herald_MJ 13y ago
      I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries). My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
- jfb 13y ago
  Largely, yes. The problem domains are different. The usage patterns are different. The constraints are different. Why not be pragmatic and pick an appropriate technology for each use case?
  - marknutter 13y ago
    > Why not be pragmatic and pick an appropriate technology for each use case I suppose you know what's appropriate.
    - jfb 13y ago
      Defensive much? All I was saying is that I don't find the "uses the same language" argument dispositive.
      - marknutter 13y ago
        I don't mean to be defensive, I personally don't use JS on the server side, but I don't see any problems with other people doing it. No more than I would have problems with people using, say, Ruby.
        WayneDB 13y ago
        You responded to someone who said "I disagree that it's expressive in comparison to other modern languages." Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining. Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"
  - mambodog 13y ago
    I'd argue that many applications have plenty of concerns for which sharing code between the server and client is clearly pragmatic: http://nerds.airbnb.com/wp-content/uploads/2012/10/shared-js-app.png.scaled1000.png http://nerds.airbnb.com/wp-content/uploads/2012/10/shared-js...
- jiggy2011 13y ago
  Code reuse is an advantage I guess. For example you want fast responsive validations as the user enters data, but for security reasons you need to do final validations on the server. You have objects on the client that you want to persist to the server but you don't want to have to write two models.
tg3 13y ago
Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).
- mwcampbell 13y ago
  This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality. An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).
  - tg3 13y ago
    The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client. Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core. Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.
wslh 13y ago
> I said it was created for minor workflow events I remember those times when Javascript was only used for changing button images in the mouse over event! It was a powerful extra to designers to have this knowledge.
smrtinsert 13y ago
I agree, its a mess with regard to expression - isn't that why this thread exists? The language is fun to write but eye-gouging to maintain. Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide. After coding JS by hand for years (while doing other languages) I'm done with it. I'm ready to go preprocessor full time, either static language based but also interested in lisp variants, because if I have to go typeless, might as well do it in style. I tried CoffeeScript for a while, but the philosophy is too similar to JS to keep my interest. It did reduce the code dramatically though, on avg about 70%.
- mwcampbell 13y ago
  I see your point, but JavaScript is much more popular than any of the other languages designed to compile to it. Thus, even if one works in a restricted and somewhat tedious subset of JS (such as the one encouraged by the Google Closure Compiler and used by the Closure Library), wouldn't it still be easier to find already-qualified developers than if one uses Haxe or ClojureScript or Dart?
- kybernetikos 13y ago
  > Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide. Not really. We do the strict conventions thing and have had a lot of success with it. Being able to run in a browser is a huge, huge advantage. If I had a nice statically typed language that gave me that advantage as well as javascript does, I'd probably switch to it, because by inclination I prefer the compiler to do more work for me, but there's no way I want to leave behind having my code work for anything with a browser and f5 to see my code in action.

marknutter 13y ago

> Why anyone thinks server-side javascript is a good idea is beyond me. That someone would want to use the same language to write both their client and server side code is beyond you?

Herald_MJ 13y ago
When that language is javascript, yes.
- mwcampbell 13y ago
  Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
  - Herald_MJ 13y ago
    I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries). My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
jfb 13y ago
Largely, yes. The problem domains are different. The usage patterns are different. The constraints are different. Why not be pragmatic and pick an appropriate technology for each use case?
- marknutter 13y ago
  > Why not be pragmatic and pick an appropriate technology for each use case I suppose you know what's appropriate.
  - jfb 13y ago
    Defensive much? All I was saying is that I don't find the "uses the same language" argument dispositive.
    - marknutter 13y ago
      I don't mean to be defensive, I personally don't use JS on the server side, but I don't see any problems with other people doing it. No more than I would have problems with people using, say, Ruby.
      - WayneDB 13y ago
        You responded to someone who said "I disagree that it's expressive in comparison to other modern languages." Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining. Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"
- mambodog 13y ago
  I'd argue that many applications have plenty of concerns for which sharing code between the server and client is clearly pragmatic: http://nerds.airbnb.com/wp-content/uploads/2012/10/shared-js-app.png.scaled1000.png http://nerds.airbnb.com/wp-content/uploads/2012/10/shared-js...
jiggy2011 13y ago
Code reuse is an advantage I guess. For example you want fast responsive validations as the user enters data, but for security reasons you need to do final validations on the server. You have objects on the client that you want to persist to the server but you don't want to have to write two models.

tg3 13y ago

Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).

mwcampbell 13y ago
This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality. An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).
- tg3 13y ago
  The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client. Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core. Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.

wslh 13y ago

> I said it was created for minor workflow events I remember those times when Javascript was only used for changing button images in the mouse over event! It was a powerful extra to designers to have this knowledge.

smrtinsert 13y ago

I agree, its a mess with regard to expression - isn't that why this thread exists? The language is fun to write but eye-gouging to maintain. Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide. After coding JS by hand for years (while doing other languages) I'm done with it. I'm ready to go preprocessor full time, either static language based but also interested in lisp variants, because if I have to go typeless, might as well do it in style. I tried CoffeeScript for a while, but the philosophy is too similar to JS to keep my interest. It did reduce the code dramatically though, on avg about 70%.

mwcampbell 13y ago
I see your point, but JavaScript is much more popular than any of the other languages designed to compile to it. Thus, even if one works in a restricted and somewhat tedious subset of JS (such as the one encouraged by the Google Closure Compiler and used by the Closure Library), wouldn't it still be easier to find already-qualified developers than if one uses Haxe or ClojureScript or Dart?
kybernetikos 13y ago
> Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide. Not really. We do the strict conventions thing and have had a lot of success with it. Being able to run in a browser is a huge, huge advantage. If I had a nice statically typed language that gave me that advantage as well as javascript does, I'd probably switch to it, because by inclination I prefer the compiler to do more work for me, but there's no way I want to leave behind having my code work for anything with a browser and f5 to see my code in action.