5 ms·

If all you're building is a service proxy to a database, node will get you very far really fast. Its thin layer will allow you write a clean REST api that consu

If all you're building is a service proxy to a database, node will get you very far really fast. Its thin layer will allow you write a clean REST api that consumers can reliably call. Javascript does not scale well though when a project grows to hundreds of thousands of lines of code, but that shouldn't stop you from investigating TypeScript, Dart, or even Coffeescript.

lowboy 13y ago
I am a proponent (and user) of CoffeeScript, but it won't help you very much with maintainable architecture. It's mostly just syntactic sugar over normal JavaScript.
- lightblade 13y ago
  I work on a large web application that sits currently at 50k lines of CoffeeScript and spans 10+ feature branches at all time. No, it does not scale. Especially true when the project also spans that many branches. Everyone merging up and down the branches. You get to have backend people merging frontend codes without much problem because it's all dynamic. Then you found out it was a bad merge in production because CoffeeScript doesn't care. The fact that CoffeeScript makes braces optional causes a lot of problem because when it fails, it fails silently. Bad merge happens, but you'll want it to fail loudly when it does happens. Out of Dart, TypeScript and CoffeeScript, I recommend TypeScript for large scale projects. Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries.
  - dragonwriter 13y ago
    > Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries. You mean "JavaScript libraries", not "other JavaScript libraries". Dart is a language one of whose implementations is a compiler-to-JS, but it most assuredly is not, and does not pretend to be, a JavaScript library.
  - lowboy 13y ago
    It sounds like you've got an organizational problem if merging and the lack of a staging server are the main source of issues for you. How does a bad merge get onto production? Why are "backend people" working on frontend code? Do you have a testing framework? Do you use a module system like CommonJS or AMD? Is your team trying to treat JS/CS like a strongly-typed OOP language? TypeScript seems good if you come from an enterprise/Java background and are used to OOP with static typing.
    - lightblade 13y ago
      Bad merge get into production all the time :) I think the best example is the recent Apple SSL issue. Backend people don't work on the frontend code, but they do perform catch up merge from master branch. These merges may conflicts and can result in bad merge. Testing only helps to a certain point, not everything is testable. I don't see how module system can make merging issue go away, but I do think static-typing will make these things fail faster and louder. I do have a bit of Java background. I moved from strictly typed Java world to less strictly typed ActionScript world to now even less strictly typed JavaScript world. I dabbled a bit of Haskell while working with JavaScript. Coming from Java to JavaScript, the dynamic type system of JavaScript is a breath of fresh air. But it is Haskell that made me starting to truly appreciate static type system.
beejiu 13y ago
What are you basing "Javascript does not scale well" on? If you are careful about delegating to worker nodes and avoid blocking, Node.js scales quite well for CPU intensive problems. If you have a really CPU intensive problem, you can invoke an external program to do heavy calculations for you.
- drakaal 13y ago
  Node.js is asynchronous, not Non-blocking. Don't use the two interchangeably, because they aren't interchangeable. Not understanding this leads to pain and suffering on a massive scale.
  - buckbova 13y ago
    It is described as non-blocking by almost everyone. If untrue, please tell me why. http://nodejs.org/ http://nodejs.org/ > Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
    - drakaal 13y ago
      You wake up in the morning and say, "I wish I had a Samsung Galaxy S5". Async: you tell your personal assistant to go get you one. You continue your day, eat breakfast, build a shrine to hold your new phone and he comes back and says "they were out, I'm sorry, do you want me to go back and get an iPhone instead?" Non-Blocking: you try to click the buy it now on Amazon and it says, "Out of stock. Would you like to order and have fulfilled when back in stock?" you click yes. You eat breakfast, write the next Flappy Bird, and get actual work done. 4 days later it comes back in stock and your new phone arrives. If you missed the difference, Async, is "fire and check back later". Non-blocking is "error instantly, Perform later or in parallel". There are other differences but this is an easy analogy, that shows how the two are not synonyms.
      - deleted 13y ago
briantakita 13y ago
commonjs modules are a great abstraction. I have a codebase in the 10^5 magnitude of LoC. It's a pleasure to work with. I don't see any code maintenance issues with scaling 1 or 2 orders of magnitude. Maybe memory issues? But then, it probably makes sense to break up your services.

lowboy 13y ago

I am a proponent (and user) of CoffeeScript, but it won't help you very much with maintainable architecture. It's mostly just syntactic sugar over normal JavaScript.

lightblade 13y ago
I work on a large web application that sits currently at 50k lines of CoffeeScript and spans 10+ feature branches at all time. No, it does not scale. Especially true when the project also spans that many branches. Everyone merging up and down the branches. You get to have backend people merging frontend codes without much problem because it's all dynamic. Then you found out it was a bad merge in production because CoffeeScript doesn't care. The fact that CoffeeScript makes braces optional causes a lot of problem because when it fails, it fails silently. Bad merge happens, but you'll want it to fail loudly when it does happens. Out of Dart, TypeScript and CoffeeScript, I recommend TypeScript for large scale projects. Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries.
- dragonwriter 13y ago
  > Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries. You mean "JavaScript libraries", not "other JavaScript libraries". Dart is a language one of whose implementations is a compiler-to-JS, but it most assuredly is not, and does not pretend to be, a JavaScript library.
- lowboy 13y ago
  It sounds like you've got an organizational problem if merging and the lack of a staging server are the main source of issues for you. How does a bad merge get onto production? Why are "backend people" working on frontend code? Do you have a testing framework? Do you use a module system like CommonJS or AMD? Is your team trying to treat JS/CS like a strongly-typed OOP language? TypeScript seems good if you come from an enterprise/Java background and are used to OOP with static typing.
  - lightblade 13y ago
    Bad merge get into production all the time :) I think the best example is the recent Apple SSL issue. Backend people don't work on the frontend code, but they do perform catch up merge from master branch. These merges may conflicts and can result in bad merge. Testing only helps to a certain point, not everything is testable. I don't see how module system can make merging issue go away, but I do think static-typing will make these things fail faster and louder. I do have a bit of Java background. I moved from strictly typed Java world to less strictly typed ActionScript world to now even less strictly typed JavaScript world. I dabbled a bit of Haskell while working with JavaScript. Coming from Java to JavaScript, the dynamic type system of JavaScript is a breath of fresh air. But it is Haskell that made me starting to truly appreciate static type system.

beejiu 13y ago

What are you basing "Javascript does not scale well" on? If you are careful about delegating to worker nodes and avoid blocking, Node.js scales quite well for CPU intensive problems. If you have a really CPU intensive problem, you can invoke an external program to do heavy calculations for you.

drakaal 13y ago
Node.js is asynchronous, not Non-blocking. Don't use the two interchangeably, because they aren't interchangeable. Not understanding this leads to pain and suffering on a massive scale.
- buckbova 13y ago
  It is described as non-blocking by almost everyone. If untrue, please tell me why. http://nodejs.org/ http://nodejs.org/ > Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
  - drakaal 13y ago
    You wake up in the morning and say, "I wish I had a Samsung Galaxy S5". Async: you tell your personal assistant to go get you one. You continue your day, eat breakfast, build a shrine to hold your new phone and he comes back and says "they were out, I'm sorry, do you want me to go back and get an iPhone instead?" Non-Blocking: you try to click the buy it now on Amazon and it says, "Out of stock. Would you like to order and have fulfilled when back in stock?" you click yes. You eat breakfast, write the next Flappy Bird, and get actual work done. 4 days later it comes back in stock and your new phone arrives. If you missed the difference, Async, is "fire and check back later". Non-blocking is "error instantly, Perform later or in parallel". There are other differences but this is an easy analogy, that shows how the two are not synonyms.
    - deleted 13y ago

briantakita 13y ago

commonjs modules are a great abstraction. I have a codebase in the 10^5 magnitude of LoC. It's a pleasure to work with. I don't see any code maintenance issues with scaling 1 or 2 orders of magnitude. Maybe memory issues? But then, it probably makes sense to break up your services.