7 ms·

I mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was creat

• blowski 11y ago
  I believe that Node can and will become more stable. It feels like it has too much momentum not to. But until it does achieve stability, it's difficult to use it for anything serious without investing a lot of time into it. Perhaps Go is a better comparison than Ruby and Python.
  • untog 11y ago
    it's difficult to use it for anything serious without investing a lot of time into it. Isn't that true for many platforms? Either way, I have multiple apps running Node in production, and I've never had the issues described. You don't have to be as breakneck as Node itself - some things I have are still running v0.10x just fine.
    • blowski 11y ago
      > Isn't that true for many platforms? I would say that the ROI is lower for time spent learning Node. I've found that with all the other languages I've learnt, in a couple of days I've been able to build something useful, leave it running in production and reuse skills learned a year later. With Node, even the name of the language is not stable! A few weeks back I went to install Zombie, and now I have to install iojs and not Node. Assumedly it's now Node again. If you live and breathe the language, subscribe to the mailing lists, go to the meetups, etc, these things might be obvious. But when you're just dipping in and out, it really dents your confidence in the language.
      • nilliams 11y ago
        Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think the time invested jumping in at that low-level is actually useful vs diving in at a higher 'framework level' with some of the other popular web languages. Also it does have superior installer/package-manager/deployment stories compared to say ... Python & Django, which does have an impact on ROI.
        • blowski 11y ago
          > Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter.
          • hcon 11y ago
            Sounds to me like your issue is with the author of Zombie.
            • Touche 11y ago
              Actually it's with jsdom, Zombie's major dependency which dropped Node support pretty soon after IOjs was released.
              • WalterSear 11y ago
                That sounds political, more than anything else.
    • twblalock 11y ago
      I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle. It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.
      • untog 11y ago
        have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong. That's where semantic versioning comes in. Most libraries follow it - if the major version number changes, it's a breaking change. If it doesn't, you're safe to upgrade.
        • Touche 11y ago
          Semantic version doesn't solve compatibility problems, it just makes it more transparent. In some ways semver encourages breaking changes that otherwise might be avoided because, how, a major version bump gives you sufficient warning. There are some major libraries that are on version 15 or greater... there's nothing good from a user's perspective about having a library they use do a major breaking release every other month. What's worse is many libraries take advantage of "it's the wild west until 1.0" rule in semver and simple never release a 1.0.
      • vectorpush 11y ago
        In my experience, Ruby (particularly rubygems) is quite a pain in the ass with regard to package upgrades, especially when the previous developer/ops has leveraged rvm to install multiple combinations of ruby/gem versions. I can't tell you how many times I've had to trace down problems in a project because a single gem fails to upgrade/pull/compile/resolve on 2 out of 4 machines even though the project has an identical gemfile and available ruby version on every server. I contrast this with node/npm where my projects seem to behave identically across deployments (and in some cases, when in a bind, I've even been able to simply tar & scp the project src and have it run without further effort beyond installing node, something I've never been able to do with ruby).
  • weddpros 11y ago
    in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works... I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long. That's not really a sign of instability to me, but rather great work
    • blowski 11y ago
      You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.
      • morgante 11y ago
        Bash scripts talking to Node sounds like a recipe for disaster.
        • mbrock 11y ago
          Why?
        • eyko 11y ago
          Please explain.
      • weddpros 11y ago
        I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems. NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.
        • vkjv 11y ago
          We used to do this and it caused a lot of issues. Shrinkwrap is a must to keep versions stable. NPM and network unreliability can cause failed installs, as well as other issues. Our first major improvement to this work flow was a tar of the app with all of the dependencies coupled with `npm rebuild` after unpacking. This worked quite well. However, recently, we have switched to using Docker to generated this sealed packages which is working great.
• dcwca 11y ago
  > As for no recommend approach - that's deliberate. I don't think most people working on Node want a Rails equivalent This is a useful way to understand what Node is. Node's core API is for building any sort of network service: A DNS server, an SMTP server, HTTP server, socket listener, etc. and so it applies to a wide and varied set of problems. Rails is for building a very specific type of database-backed web application.
  • pluma 11y ago
    Exactly. I don't think Node is a good fit for monolithic CRUD apps. These are already solved problems in various other languages. Instead Node lets you compose small purpose-built modules.
    • techdragon 11y ago
      Now out only problem is how to build decoupled/distributed micro services. I'd argue only Erlang and Elixir are going to survive into the multi core multi server future, but that would be little more than a slightly educated opinion unless I take the time to write a very large explanation with cited references. I don't have time for that this week.
      • vkjv 11y ago
        We are an (almost) completely node.js team and are having quite a bit of success using it for microservices. gRPC makes communication fast and easy, while Docker and Kubernetes make deployment and composition just as simple.
      • pluma 11y ago
        Personally I prefer having a monolithic app at the core and using Node as the glue to tie everything together (e.g. to provide "real-time" features or to integrate third party services). I think what's holding Erlang back is mostly its rather obscure syntax. Only a mother could love that.
• aikah 11y ago
  > I don't think most people working on Node want a Rails equivalent It wouldn't really be possible anyway. Async programming is hard and the shortcuts one can take with synchronous Ruby are impossible with Async Javascript. Nodejs has a "fibers" lib though , but it doesn't look like it is widely popular, but AFAIK it is the only to truly abstract async programming.
  • danneu 11y ago
    Using abstractions like http://koajs.com/ http://koajs.com/ and https://github.com/tj/co https://github.com/tj/co make Node code feel like every other language. var user; try { user = yield db.insertUser('foo') } catch(err) { if (err.code === '23505') { this.flash['error'] = 'Username taken'; this.redirect('/register'); return; } throw err; }
    • aikah 11y ago
      no because you can't write a library which apis are thunks. And your code needs to run in a generator, something you omitted. Fibers are a better alternative , no need for yield and generators everywhere.
      • danneu 11y ago
        Well, I was earnestly sharing run-of-the-mill Koa code since you made async abstractions sound elusive. Didn't realize you just had an agenda. The thing is that people are actually using Koa/co to solve this problem. I've yet to see someone use fibers as their core webapp control flow abstraction.
        • aikah 11y ago
          What agenda do I have ? I have none, I'm just saying using generators do not abstract async calls. The only way to do that is by using fibers. I'm not pushing for anything, i'm just saying that something like rails couldn't be written in nodejs , (and no sails , is nothing like rails in terms of complexity ).
• pfooti 11y ago
  I agree - I think I could get away with arguing that Ruby became popular because of Rails (that may not be completely true, but I and a lot of other devs I know learned about ruby because of rails at least). Node, OTOH, has no central framework that people learn of and then say, "oh, I have to learn node to use XYZ". There are plenty of libraries that provide whatever level of support you want, but one big reason people seem to use Node is for the ease of the DIY process. Honestly, I don't need an all-in-one system, because my system has needs that aren't easily modeled in ActiveRecord (or at least weren't during Rails 3 days when I moved over to Node). Instead, I am doing mix-and-match with smaller libraries to help database access, realtime (websocket) services, OAUTH, and a trad REST backend. I also think it's fair to compare the release of node and the release date of ruby or python - it was really only then that we can start talking about needing frameworks for building web applications that run in the javascript language, whereas the other two languages could have done so right away (or ... later, once the web application world became more than just a cgi gateway on top of a c++ stack, like the lunch menu randomizer I had running back in 1995). Still, no matter how you slice it, node and server-side javascript are still relatively new on the scene, and not necessarily well-suited for an all-in-wonder, highly-opinionated framework.
• AdieuToLogic 11y ago
  > ... Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment... Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1]. We learn from history that we learn nothing from history. George Bernard Shaw[2] 1 - http://docs.oracle.com/cd/E19957-01/816-6411-10/getstart.htm http://docs.oracle.com/cd/E19957-01/816-6411-10/getstart.htm 2 - http://www.wisdomquotes.com/quote/george-bernard-shaw-19.html http://www.wisdomquotes.com/quote/george-bernard-shaw-19.htm...
  • pluma 11y ago
    The JS of 2009 was an entirely different language from the JS Netscape originally created. Plus Netscape's web server was an evolutionary dead end and a proprietary closed-source product. Node was in part influenced by CommonJS, which tried to unify the various competing but relatively obscure (mostly non-browser) JS environments. To say that it learned nothing from the history of SSJS (or JS environments in general) is, frankly, wrong. That said, Netscape's SSJS is entirely unrelated to Node or anything like it[0]. Node lets you write application servers, Netscape's SSJS effectively was more like Rhino-meets-JSP or maybe GWT (i.e. the heavy lifting was apparently implemented in Java, not JS). [0]: http://docs.oracle.com/cd/E19957-01/816-6411-10/jsserv.htm http://docs.oracle.com/cd/E19957-01/816-6411-10/jsserv.htm
    • AdieuToLogic 11y ago
      With utmost respect, I respond to each point you mention below. The JS of 2009 was an entirely different language from the JS Netscape originally created. Plus Netscape's web server was an evolutionary dead end and a proprietary closed-source product. The reason I cited Netscape's server was to unequivocally show that NodeJS did not introduce JavaScript to "a new environment" as the GP stated. Why previous efforts failed to gain traction or if it is even a good idea to use JavaScript to define server-side logic is left as an exercise to the reader. Node was in part influenced by CommonJS, which tried to unify the various competing but relatively obscure (mostly non-browser) JS environments. To say that it learned nothing from the history of SSJS (or JS environments in general) is, frankly, wrong. It would seem we have differing perspectives of history. CommonJS was started in 2009[1], the same year as NodeJS[2]. The lessons of history I implied regarded attempts to use JavaScript as a server-side solution over the past 20-ish years. While you make the distinction: Node lets you write application servers, Netscape's SSJS effectively was more like Rhino-meets-JSP or maybe GWT (i.e. the heavy lifting was apparently implemented in Java, not JS). I suggest that this is irrelevant, as the details of how the JavaScript logic is executed is orthogonal from the fact that systems such as these use JavaScript to define behaviour itself. The fact remains that there have been more than one previous project/offering/effort which had JavaScript as a key component. IMHO, it behooves interested parties to do whatever postmortem examinations possible before committing to the same or significantly similar path. 1 - https://en.wikipedia.org/wiki/CommonJS https://en.wikipedia.org/wiki/CommonJS 2 - https://en.wikipedia.org/wiki/Node.js https://en.wikipedia.org/wiki/Node.js
• sparaker 11y ago
  There is http://sailsjs.org/ http://sailsjs.org/ for people who want a Rails equivalent.