5 ms·

Wondering how many startups are on Node nowadays

• camus 14y ago
  A lot ! i bet as much as startup using python or ruby as their backend. NodeJS is not for everything so it would be interesting to know how they use it. I'll be curious about what their persistance layer is too. I like the new interface , it's cleaner that it has ever been , BUT if i get pushed too much spammy stuffs i'll quit. Right now i dont see why i should use that, all my connections are gone ...
  • jmspring 14y ago
    NodeJS and Python Twisted have a commonality in terms of async development. If you are wanting to stick with "one" language for both server and client-side, then Node is a good choice.
    • prezjordan 14y ago
      When does sharing code between the client and server actually happen? I can't think of any use-cases.
      • va9 14y ago
        Not sure though. But top of it you would probably use backbone.js in both server and client. Another advantage is we have UI developers who are now writing server code to be much more. To some level it is giving a path way for one language everywhere paradigm. However, server side coding required much more capabilities like performant code, scaling etc., but for normal websites it is easy to go with node as it kills some amount learning curve.
      • untog 14y ago
        My situation was different to this, but when sharing C# between a backend server and an iPhone app I found it tremendously useful to use the same models, and just JSON encode/decode them to transmit between the two.
      • dpup 14y ago
        Off the top of my head: Data types - Both concrete classes or helpers for manipulating data. Input Validation - Do it client-side to do it fast, but double check on the server. Formatting - Larger web apps often need to format things from dates to users to numbers on client-side generated data without the server hop. Templates - Many templating systems are compatible with multiple languages, but its easier if there's just one output type.
      • deoxxa 14y ago
        Very, very rarely. Along with "now you can get your frontend developers to write backend code!", it's one of those oft-cited but spectacularly bad reasons to start using JavaScript for non-client stuff. In saying this, I use node for a heck of a lot at work, but that's mostly because some of the workflows available (streams and events specifically) are perfectly suited to the programs I write in it; not because it lets jQuery monkeys crank out substandard backend code.
      • coenhyde 14y ago
        I just built and launched https://popbasic.com/ https://popbasic.com/. It shares the router, controllers, actions and templates between the client and server. I have the "frontend" that runs client and server which then talks to an api. It works pretty good because i can serve out a full page request (good for SEO and fast load times) then boot the same application on the client so subsequent navigation is fast.
        • tferris 14y ago
          Beautiful site, thanks for sharing!
          • coenhyde 14y ago
            Cheers. I don't consider myself a designer. This is the first creative thing i've done in 10 years, so it's good to know i can still make something that looks good :).
      • bdcravens 14y ago
        Even if never, the idea is to reuse skills, not code. (In the same way that you reuse little code from Rails apps when build Chef recipes) That's not entirely true - you can reuse some libraries between client and server-side: underscore's utility functions are the underpinning for many node modules, sizzle and jQuery is great for DOM parsing when writing screen scrapers, etc. There's browserify if you want to run node modules in the browser.
      • rdwallis 14y ago
        There are tons and tons of use cases for sharing code between server and client. Why would you want to write things twice? The only reason it is not more common is that programming is generally done in different languages on the server and client. I built an ebook reader that can process ebooks in javascript. Because IE does not support the File API the server needs to pick up the slack when users are on that browser. Sharing code means I don't need to program two versions and I only have to patch bugs once. It's also common to share validation code. This allows you to check data client-side and then again once it reaches the server using the same code.
      • deleted 14y ago
        [deleted]
• untog 14y ago
  A lot (and I code in it day-to-day) but part of me actually wonders why. Node is great for websocket-type, async operations. As a normal web server, serving pages? I feel as though other platforms might work better.