5 ms·

Ruby, Let's Take a Break. I Want To Date Node For a While.

16 points by gmuller 15y ago

bascule 15y ago
I'm confused, what does this post have to do with Ruby, other than a brief mention about how Ruby's syntax is different from other languages?
- ramblerman 15y ago
  I'm confused about what it has to do with node. project euler stuff is just javascript, might as well run it in the browser.
  - gmuller 15y ago
    That's true ramblerman, and actually I wrote some of this in the console window of Chrome. The real point I was trying to prove (mostly to myself) is that javascript can work as a server-side scripting platform to quickly create short scripts. Node is simply my interpreter for it (and more). That actually points out another bonus. I can POC something in javascript in a browser window, and if I want to graduate it to a server side script its mostly a copy-and-paste operation. The post is mostly about convenience. I use javascript all the time. Now I can use it more. I love ruby, I just end up having to relearn it every time I use it because I don't use it often. Node is just the vehicle of that convenience.
davemo 15y ago
A friend who is wrapping up the last year of his computer science education asked me last night "so what's this node.js stuff all about?". I thought about it for a few seconds and then told him the value of writing a web-app in node was the ability to use 1 language from top to bottom. In my experience, most of the detractors of node seem to miss the value that a homogenous programming environment can bring. I'm interested to see how your courtship with node pans out over the long term; good post :)
- andrewvc 15y ago
  I've used node, and I just don't see it. You can share fragments of code, but for reasons of both security and logic not much more. In my view, the evented nature of node negates most of the pluses of one language. Additionally, javascript is a shitty language if what you want is a large amount of business logic. Python and ruby are much more concise and expressive. This is a huge win that a lot of people overlook. Now, if you need to throw together a chat service or push service really quickly, I see the value, but that's about it. Of course for that, I'd just use clojure or java.
  - ootachi 15y ago
    Er... you want expressiveness, so you ditch JavaScript and use Java?
  - crazygringo 15y ago
    I suggest trying CoffeeScript with node for more conciseness and expressivity, and one of the async helpers to mitigate the complexity of the "evented nature of node" -- letting you avoid huge nested callbacks. These two things together completely transform Node, so much that I can't even imagine coding without them.
switz 15y ago
The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.
- judofyr 15y ago
  I keep hearing about this, but has anyone actually done this?
  - gphil 15y ago
    And furthermore, what are the security ramifications of doing this? At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side. However, going in the other direction (sending JSON from server to client) is a very common pattern.
    - sespindola 15y ago
      This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them. Data sanitization and validation on the backend should be as thourough as that of the client, if not more.
      - StavrosK 15y ago
        Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.
        tfb 15y ago
        My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically <script src="script.js"></script>. The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data. As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS. But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.
lowglow 15y ago
The problem with the internet is that people now have the ability to affect a larger amount of opinions than ever before, for better or worse. I think node is cool, and definitely has its place. I think it's a bit premature when people start talking about it being a full stack replacement. I certainly believe under some circumstances node really shines, but you need to pick your battles using the right tool for the right job. Stay educated and understand why something works to solve a particular problem well.
- gmuller 15y ago
  Whoa, who said anything about full stack replacement. I use a variety of stacks, I was simply pointing out that since I'm using Javascript all over the place anyway, I might start using it on the server side as well. Things I use Ruby for generally amount to one-off jobs or shell-scripts. I constantly have to remind myself of the syntax, since all I use all day long are variants of C syntax(C#, java, javascript). It'll take me 10 minutes to whip up what would take me 30 in ruby, simply because I don't use ruby often enough to internalize the syntax. node provides me with a way to write the same shell scripts in javascript.
StavrosK 15y ago
I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?
- bascule 15y ago
  > I don't want to have one process per request, so the obvious thing was to use something asynchronous There's these amazing things called threads you can use too
  - StavrosK 15y ago
    Why would I do that when 99% of the time is spent waiting on the http call to return?
    - bascule 15y ago
      Because unless you have an unusually high (>1000) concurrency level for your HTTP connections, threads are a more than adequate solution to the problem.
- deleted 15y ago
  [deleted]
- michaelfairley 15y ago
  There are also threads, which are typically much easier to program for than an asynchronous system, but will still let you have more than 1 request per process.
  - StavrosK 15y ago
    I don't know, it seems that greenlets are basically exactly as easy to program with as threads, from a quick skim of the docs.
mikeryan 15y ago
The strange thing about this is that I've found that both make great additions to my toolbox, and when making my language choice I don't pick JS or Ruby so much as I pick Node or Rails/Sinatra and I don't do the same things with each stack. I've long gotten past worrying too much about languages Ruby and JS are so close to each other that switching between the two is a frictionless process.
nato1138 15y ago
The same, but I am swapping Rails for Chicago Boss.
AdrianRossouw 15y ago
i do node all day every day, but i've actually found it sub-optimal for shell scripts / one-off jobs. For me these tend to take the form of import scripts or batch files that have to process various different files and stick it in a database. There's a lot of conceptual overhead that comes with asynchronous IO for these kinds of tasks. However, some of the things that node allows you to do is kind of spectacular too. On a recent project I had to parse data from a set of csv files, while pre-processing the data and pushing it into a Couch database. At the same time I needed to generate a sqlite database with spatially aware geographic indexes using parts of the data, so we could build maps from the data. I ended up having a situation where the data was streaming into the couch database waaaay faster than the sqlite db could write the records, which resulted in the process growing in memory bogging the entire application down (the csv files could be uploaded via a form as well). The solution ended up being that because my csv parser was building on the stream classes in node, i could literally pause/resume the stream based on the state of the buffer(s). This is exactly the same technique you would use when building an http proxy or limiting the transfer rate of file uploads. This is some pretty low level stuff to have to get into for a simple import script, and if I were to do it in something other than JS I would probably have used temporary files or separate processes or whatever. Debugging and testing this kind of problem is not really straightforward either. As always YMMV, but I have become more appreciative of plain bash scripting as of late. edit: formatting

16 points by gmuller 15y ago

I'm confused, what does this post have to do with Ruby, other than a brief mention about how Ruby's syntax is different from other languages?

ramblerman 15y ago
I'm confused about what it has to do with node. project euler stuff is just javascript, might as well run it in the browser.
- gmuller 15y ago
  That's true ramblerman, and actually I wrote some of this in the console window of Chrome. The real point I was trying to prove (mostly to myself) is that javascript can work as a server-side scripting platform to quickly create short scripts. Node is simply my interpreter for it (and more). That actually points out another bonus. I can POC something in javascript in a browser window, and if I want to graduate it to a server side script its mostly a copy-and-paste operation. The post is mostly about convenience. I use javascript all the time. Now I can use it more. I love ruby, I just end up having to relearn it every time I use it because I don't use it often. Node is just the vehicle of that convenience.

davemo 15y ago

A friend who is wrapping up the last year of his computer science education asked me last night "so what's this node.js stuff all about?". I thought about it for a few seconds and then told him the value of writing a web-app in node was the ability to use 1 language from top to bottom. In my experience, most of the detractors of node seem to miss the value that a homogenous programming environment can bring. I'm interested to see how your courtship with node pans out over the long term; good post :)

andrewvc 15y ago
I've used node, and I just don't see it. You can share fragments of code, but for reasons of both security and logic not much more. In my view, the evented nature of node negates most of the pluses of one language. Additionally, javascript is a shitty language if what you want is a large amount of business logic. Python and ruby are much more concise and expressive. This is a huge win that a lot of people overlook. Now, if you need to throw together a chat service or push service really quickly, I see the value, but that's about it. Of course for that, I'd just use clojure or java.
- ootachi 15y ago
  Er... you want expressiveness, so you ditch JavaScript and use Java?
- crazygringo 15y ago
  I suggest trying CoffeeScript with node for more conciseness and expressivity, and one of the async helpers to mitigate the complexity of the "evented nature of node" -- letting you avoid huge nested callbacks. These two things together completely transform Node, so much that I can't even imagine coding without them.

switz 15y ago

The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.

judofyr 15y ago
I keep hearing about this, but has anyone actually done this?
- gphil 15y ago
  And furthermore, what are the security ramifications of doing this? At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side. However, going in the other direction (sending JSON from server to client) is a very common pattern.
  - sespindola 15y ago
    This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them. Data sanitization and validation on the backend should be as thourough as that of the client, if not more.
    - StavrosK 15y ago
      Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.
      - tfb 15y ago
        My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically <script src="script.js"></script>. The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data. As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS. But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.

lowglow 15y ago

The problem with the internet is that people now have the ability to affect a larger amount of opinions than ever before, for better or worse. I think node is cool, and definitely has its place. I think it's a bit premature when people start talking about it being a full stack replacement. I certainly believe under some circumstances node really shines, but you need to pick your battles using the right tool for the right job. Stay educated and understand why something works to solve a particular problem well.

gmuller 15y ago
Whoa, who said anything about full stack replacement. I use a variety of stacks, I was simply pointing out that since I'm using Javascript all over the place anyway, I might start using it on the server side as well. Things I use Ruby for generally amount to one-off jobs or shell-scripts. I constantly have to remind myself of the syntax, since all I use all day long are variants of C syntax(C#, java, javascript). It'll take me 10 minutes to whip up what would take me 30 in ruby, simply because I don't use ruby often enough to internalize the syntax. node provides me with a way to write the same shell scripts in javascript.

StavrosK 15y ago

I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?

bascule 15y ago
> I don't want to have one process per request, so the obvious thing was to use something asynchronous There's these amazing things called threads you can use too
- StavrosK 15y ago
  Why would I do that when 99% of the time is spent waiting on the http call to return?
  - bascule 15y ago
    Because unless you have an unusually high (>1000) concurrency level for your HTTP connections, threads are a more than adequate solution to the problem.
deleted 15y ago
[deleted]
michaelfairley 15y ago
There are also threads, which are typically much easier to program for than an asynchronous system, but will still let you have more than 1 request per process.
- StavrosK 15y ago
  I don't know, it seems that greenlets are basically exactly as easy to program with as threads, from a quick skim of the docs.

mikeryan 15y ago

The strange thing about this is that I've found that both make great additions to my toolbox, and when making my language choice I don't pick JS or Ruby so much as I pick Node or Rails/Sinatra and I don't do the same things with each stack. I've long gotten past worrying too much about languages Ruby and JS are so close to each other that switching between the two is a frictionless process.

nato1138 15y ago

The same, but I am swapping Rails for Chicago Boss.

AdrianRossouw 15y ago

i do node all day every day, but i've actually found it sub-optimal for shell scripts / one-off jobs. For me these tend to take the form of import scripts or batch files that have to process various different files and stick it in a database. There's a lot of conceptual overhead that comes with asynchronous IO for these kinds of tasks. However, some of the things that node allows you to do is kind of spectacular too. On a recent project I had to parse data from a set of csv files, while pre-processing the data and pushing it into a Couch database. At the same time I needed to generate a sqlite database with spatially aware geographic indexes using parts of the data, so we could build maps from the data. I ended up having a situation where the data was streaming into the couch database waaaay faster than the sqlite db could write the records, which resulted in the process growing in memory bogging the entire application down (the csv files could be uploaded via a form as well). The solution ended up being that because my csv parser was building on the stream classes in node, i could literally pause/resume the stream based on the state of the buffer(s). This is exactly the same technique you would use when building an http proxy or limiting the transfer rate of file uploads. This is some pretty low level stuff to have to get into for a simple import script, and if I were to do it in something other than JS I would probably have used temporary files or separate processes or whatever. Debugging and testing this kind of problem is not really straightforward either. As always YMMV, but I have become more appreciative of plain bash scripting as of late. edit: formatting