7 ms·

I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've

I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.

alayek 9y ago
You should try. I come from a traditional Java shop, and a year ago wouldn't have thought of doing anything serious with Node JS. Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far. With some type-system like Flow or TypeScript, you can manage huge projects in Node JS. I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node. This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc. But so far, I think Node is headed in the right direction.
falcolas 9y ago
It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
- todd3834 9y ago
  What does it warn you about? Not trolling, honest question.
  - falcolas 9y ago
    That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
    - ovao 9y ago
      I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Should we collectively eschew what's possible due to individual language gripes?
      - fundabulousrIII 9y ago
        No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.
        ovao 9y ago
        > collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
        fundabulousrIII 9y ago
        I'm sorry, what don't you understand? Complexity is best discussed by those who introduce it. To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?
        ovao 9y ago
        > what don't you understand Exactly what I asked. > Any educated comment on these sentiments? Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't, by itself, disqualify a language from being used in any particular context. As for JavaScript being a wart, I don't really agree with that sentiment. I think that's attributable to some pretty strong and level-headed language evolution making what was once a very blunt scripting instrument into something somewhat reasonably suited to larger-scale applications.
- woah 9y ago
  Js is a scripting language that relies on the program being scripted to interact with the outside world. In browsers, this is the DOM and xhr APIs. On servers, this is the node stdlib which lets you interact with the system. The fact that this kind of modularity bothers you is bizarre.
  - thehardsphere 9y ago
    It is a modularity that is an unnecessary point of failure compared to other choices available, and involves poor abstractions for Javascript to use things it was not intended to use.
- devnill 9y ago
  >To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
- deleted 9y ago
  [deleted]
- ridiculous_fish 9y ago
  Favorite node / libc impedance mismatch is the stat() call. stat() returns an inode, which is a 64 bit integer. But JS doesn't have 64 bit integers, so it just gets rounded to the closest representable double. So node will sometimes identify two different files as the same file. https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115
- collyw 9y ago
  Its been a while since I wrote and Java, but when I did you needed a page of code just to open a file.
- Larrikin 9y ago
  Kotlin is slowly becoming s language that can do all of that. It's production ready for anything that uses java, js support is coming along great, and their slowly moving towards native.
ashark 9y ago
The front end/back end sharing argument never appealed to me. In practice, how much are you actually going to be able to share? No way it's worth it. What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits) Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages. [EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.
- jtmarmon 9y ago
  the front/backend sharing stuff matters more these days with server side rendered apps, but I've used nodejs plenty for this lifetime and have no plans to touch the stuff again for serious applications
  - duderific 9y ago
    It's kind of funny how you say "these days with server side rendered apps". At one time not so long ago, there were only server side rendered apps.
- Someone 9y ago
  I think most of what you share is the effort needed to learn the language. Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain) I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.

alayek 9y ago

You should try. I come from a traditional Java shop, and a year ago wouldn't have thought of doing anything serious with Node JS. Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far. With some type-system like Flow or TypeScript, you can manage huge projects in Node JS. I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node. This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc. But so far, I think Node is headed in the right direction.

falcolas 9y ago

It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.

todd3834 9y ago
What does it warn you about? Not trolling, honest question.
- falcolas 9y ago
  That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
  - ovao 9y ago
    I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Should we collectively eschew what's possible due to individual language gripes?
    - fundabulousrIII 9y ago
      No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.
      - ovao 9y ago
        > collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
        fundabulousrIII 9y ago
        I'm sorry, what don't you understand? Complexity is best discussed by those who introduce it. To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?
        ovao 9y ago
        > what don't you understand Exactly what I asked. > Any educated comment on these sentiments? Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't, by itself, disqualify a language from being used in any particular context. As for JavaScript being a wart, I don't really agree with that sentiment. I think that's attributable to some pretty strong and level-headed language evolution making what was once a very blunt scripting instrument into something somewhat reasonably suited to larger-scale applications.
woah 9y ago
Js is a scripting language that relies on the program being scripted to interact with the outside world. In browsers, this is the DOM and xhr APIs. On servers, this is the node stdlib which lets you interact with the system. The fact that this kind of modularity bothers you is bizarre.
- thehardsphere 9y ago
  It is a modularity that is an unnecessary point of failure compared to other choices available, and involves poor abstractions for Javascript to use things it was not intended to use.
devnill 9y ago
>To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
deleted 9y ago
[deleted]
ridiculous_fish 9y ago
Favorite node / libc impedance mismatch is the stat() call. stat() returns an inode, which is a 64 bit integer. But JS doesn't have 64 bit integers, so it just gets rounded to the closest representable double. So node will sometimes identify two different files as the same file. https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115
collyw 9y ago
Its been a while since I wrote and Java, but when I did you needed a page of code just to open a file.
Larrikin 9y ago
Kotlin is slowly becoming s language that can do all of that. It's production ready for anything that uses java, js support is coming along great, and their slowly moving towards native.

ashark 9y ago

The front end/back end sharing argument never appealed to me. In practice, how much are you actually going to be able to share? No way it's worth it. What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits) Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages. [EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.

jtmarmon 9y ago
the front/backend sharing stuff matters more these days with server side rendered apps, but I've used nodejs plenty for this lifetime and have no plans to touch the stuff again for serious applications
- duderific 9y ago
  It's kind of funny how you say "these days with server side rendered apps". At one time not so long ago, there were only server side rendered apps.
Someone 9y ago
I think most of what you share is the effort needed to learn the language. Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain) I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.