6 ms·

Why I’m staying with Node

48 points by webista 12y ago

aikah 12y ago
I dont find this blogpost very interesting. The point of TJ's post was that concurrency in Nodejs was hard compared to Go,so was error management.It's not about one using Go or NodeJS,more about the fact that it is harder to build concurrent servers that dont crash on error in NodeJS than in Go. Furthermore I personally dont rely on anything to OP wrote, so wether he stays or leaves nodejs doesnt matter.
Artemis2 12y ago
Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.
- dang 12y ago
  > Is there really any practical example of sharing code between back-end and front-end? Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.
- aikah 12y ago
  This is the weakest argument for the use of nodejs in my opinion. But I can imagine people sharing models and validation code in an AJAX heavy app.
- bryanlarsen 12y ago
  Shared code can be a huge win in certain scenarios. 1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2] 2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to records in a database database. Now imagine that you need to do some sort of batch operation to these documents. If your code is written in Node, you just run your client code on the server. Instead of directly manipulating the database from your batch workers, you use the standard REST & WebSocket API that your clients do. This is called a service-oriented code structure, and there are huge advantages to this; so big that everybody is switching to it. Node makes it almost free. 1: https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow https://github.com/wvl/highbrow
  - rimantas 12y ago
    Regarding the first point… what's the point really? Either you render it on the client, or you render it on the server, then client couldn't care less what did you use to render it as long as it gets HTML it wanted. If you feel the need to render something in both places I feel that you have some seriously overcomplicated architecture. Regarding the second point: if the client modifies the document through the API calls, who cares what technology is used to implement those API methods?
- jaxytee 12y ago
  I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.
eknkc 12y ago
So? I don't think TJ wrote his post just for the sake of complaining or comparing Node with Go. He had a decision, and had to tell the community he was leaving because, you know, a lot of people uses his modules. I rely on a couple of his modules and I liked that he took some time to explain why he'll not be working on them anymore. This post is no more interesting than blogging "I'll keep drinking my morning coffee.. Just as always."
- chdir 12y ago
  Agreed, on the other hand it is OK to disagree with the shortcoming in node (from previous post) & point them out. It's important for the community to not lose faith because one star dropped out.
- currysausage 12y ago
  Yeah, but it's hosted on Medium, so it looks beautiful and weighty. (scnr)
- ericclemmons 12y ago
  Posts like this are warranted because some took TJ's move to Go as "jumping ship" on Node, especially when he expressed concern over Node's future. The author correctly frames it as a personal decision in which tool to use for which job.
Mithaldu 12y ago
> Hiring for Go — I wouldn’t even know where to start. Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job. You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to learn whatever else your company might need in the future, and writes better code by way of having a focus on programming knowledge, not language knowledge.
- pjmlp 12y ago
  I haven't seen this type of hiring since the .com bubble days. Nowadays either one has the right keywords on the CV or good luck.
  - watwut 12y ago
    Yeah, but that might have something to do with perceived shortage of developers.
- talloaktrees 12y ago
  How to train a new employee on Go: Day 1: complete the tour - http://tour.golang.org/ http://tour.golang.org/ and read "How to Write Go Code" http://golang.org/doc/code.html http://golang.org/doc/code.html Day 2-3: read Effective Go - http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Take a whole week, if you feel it is necessary.
  - eyko 12y ago
    This was exactly how I did it. The Effective Go part took me longer, since I actually jumped into porting a couple of small ruby libraries I picked (not mine, just ones I was familiar with) so that had me jumping to and from the book to the terminal/editor, so it probably took me like 5 days to port both libraries into Go code that I was happy with. After that I had also read enough online to be familiar with the tools and the environment. Go is a really small language, but the ecosystem is rich.
dlsym 12y ago
"And for that matter, I guess that makes Java, German." Well, now I feel offended.
- talloaktrees 12y ago
  Java should be Indonesian if you really think about it
  - twic 12y ago
    Does that make Oracle the Dutch East India Company?
  - TheOtherHobbes 12y ago
    An archipelago of lush but unstable islands prone to earthquakes and volcanoes?
human_error 12y ago
> Hiring for Go — I wouldn’t even know where to start Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn programming from scratch. So, when you want to hire someone to code in Go, you just hire a developer and tell them they're going to code in Go. After getting used with Go, they would be all set.
- chdir 12y ago
  In principle, I agree that picking up programming languages for a good programmer shouldn't be a challenge but this analogy doesn't go too far. There are fine nuances about a programming language that you need to learn to be a good programmer. Whereas a car is mostly a commute tool for many. You can switch a browser like a car, but switching a language is a bit more involved.
  - nawitus 12y ago
    I agree with your point, but Go in particular doesn't seem very different from, say, C/C++. I think the average programmer who knows C/C++ can pick it up rather quickly, even though going from Java to JavaScript takes significantly longer.
    - crdoconnor 12y ago
      Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things. You also need to develop a full understanding of the package/library/framework ecosystem, which can take years. This isn't transferable knowledge, either, but it's absolutely vital to understanding a language. Knowing that requests is a great python library, for instance, and knowing when (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C. I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.
_random_ 12y ago
"With Node you can literally share your code between the front and back of a system." Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?
- crdoconnor 12y ago
  It makes sense if your app flat out requires a lot of javascript on the client side. I find that javascript is most often an overused crutch on the client side, though. It's used more for premature optimization and making your website look shinier than it is anything really very useful. Nonetheless, some webapps really do require a lot of it.
  - rimantas 12y ago
    > It makes sense if your app flat out requires a lot of > javascript on the client side. Well, you can take a different look: spend some time thinking why does your app requires a lot of JavaScript, and is it really necessary. Even if the answer is still "yes" that may be a good exercise.
eliben 12y ago
> We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere. The "alas" in this quote is sad. Sad to be using tools you hate.
- jvickers 12y ago
  I feel the same way about JavaScript, to some extent at least. I don't hate JavaScript - but I think that the web would be better if it moved towards making another language standard as well. I don't know which language would be best, Dart looks like a good candidate when it is more mature.
bryanlarsen 12y ago
Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features. Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services. That being said, Node is particularly well suited for consuming services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit. The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic. The other killer feature for node.js has already been mentioned: combining both server and client side rendering with https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr or https://github.com/wvl/highbrow https://github.com/wvl/highbrow.
- neebz 12y ago
  slightly off-topic but I am pretty interested in learning about SOA architecture using Node.js apps. Can you refer any guides/links ?
  - bryanlarsen 12y ago
    Hmmm, I couldn't find any simple examples. Basically, all it means that you're running Backbone.js on the server as well. If you're just using Backbone.js models & collections it's pretty straightforward. But if you Google for running Backbone.js on the server, you get links for people running Backbone.js views (as well as models and collections) on the server. That's a little more involved, but the work has been done for you by frameworks such as rendr. A good starting place might be: https://github.com/rendrjs/rendr-examples https://github.com/rendrjs/rendr-examples I'm only familiar with Backbone. If your models are written in Ember or Angular or (?) instead of Backbone, I can't help you but would be very interesting in knowing how myself...
goblin89 12y ago
> With Node you can literally share your code between the front and back of a system. I think sharing code is dangerous as it tightens component coupling and makes architecture less flexible and more complex. An average web project nowadays seems to be a back with many fronts: end-user website, admin interface, iOS app, Android app, Windows app… Making all fronts equal in their separation IMO keeps the architecture more predictable and easier to understand. Like DRY but with design decisions instead of lines of code. Also, I don't see how you can be flexible without making API the only point of contact for your back(s). That way you don't lock yourself in and can rewrite any component with another framework or language, once requirements change sufficiently. I imagine it's much harder to do if you have everything in one Node project.
- couchand 12y ago
  I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project. First, why. To your point about DRY but with design decisions instead of lines of code, that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again. Building a system that has every problem solved (at least) twice in (at least) two different languages is what makes architecture harder to understand, and more importantly maintain. Ok, how. You create lots of little modules that each do one thing well. They declare their dependencies on your other modules, so it's actually much harder to introduce coupling between components. You use the modules appropriate to whichever part of the system you're building. A practical example: you want to validate user input. You have a series of business rules that must be checked before you allow an update. Of course you want to check them on the client, so you can provide valuable feedback as quickly as possible. But you also must check them on the server, to prevent a wily user from circumventing your rules. How do you architect this system? If you're sharing code, you just write a function to check the rules and call it in both places. If you're not, you end up reimplementing the rule in both places. But of course you'd like to at least share the rule definitions, so you end up writing the rules in JSON or something and then building parallel rule loaders in both places. Or if you're me you just give up and use Node instead.
TheMagicHorsey 12y ago
If you want to be DRY, a nicer option is clojurescript/clojure. Clojurescript + Om is a pretty nice combo for the browser.

48 points by webista 12y ago

aikah 12y ago

I dont find this blogpost very interesting. The point of TJ's post was that concurrency in Nodejs was hard compared to Go,so was error management.It's not about one using Go or NodeJS,more about the fact that it is harder to build concurrent servers that dont crash on error in NodeJS than in Go. Furthermore I personally dont rely on anything to OP wrote, so wether he stays or leaves nodejs doesnt matter.

Artemis2 12y ago

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.

dang 12y ago
> Is there really any practical example of sharing code between back-end and front-end? Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.
aikah 12y ago
This is the weakest argument for the use of nodejs in my opinion. But I can imagine people sharing models and validation code in an AJAX heavy app.
bryanlarsen 12y ago
Shared code can be a huge win in certain scenarios. 1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2] 2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to records in a database database. Now imagine that you need to do some sort of batch operation to these documents. If your code is written in Node, you just run your client code on the server. Instead of directly manipulating the database from your batch workers, you use the standard REST & WebSocket API that your clients do. This is called a service-oriented code structure, and there are huge advantages to this; so big that everybody is switching to it. Node makes it almost free. 1: https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow https://github.com/wvl/highbrow
- rimantas 12y ago
  Regarding the first point… what's the point really? Either you render it on the client, or you render it on the server, then client couldn't care less what did you use to render it as long as it gets HTML it wanted. If you feel the need to render something in both places I feel that you have some seriously overcomplicated architecture. Regarding the second point: if the client modifies the document through the API calls, who cares what technology is used to implement those API methods?
jaxytee 12y ago
I sometimes write server code in the browser before porting it to the server. I find it quicker to debug with Chrome.

eknkc 12y ago

So? I don't think TJ wrote his post just for the sake of complaining or comparing Node with Go. He had a decision, and had to tell the community he was leaving because, you know, a lot of people uses his modules. I rely on a couple of his modules and I liked that he took some time to explain why he'll not be working on them anymore. This post is no more interesting than blogging "I'll keep drinking my morning coffee.. Just as always."

chdir 12y ago
Agreed, on the other hand it is OK to disagree with the shortcoming in node (from previous post) & point them out. It's important for the community to not lose faith because one star dropped out.
currysausage 12y ago
Yeah, but it's hosted on Medium, so it looks beautiful and weighty. (scnr)
ericclemmons 12y ago
Posts like this are warranted because some took TJ's move to Go as "jumping ship" on Node, especially when he expressed concern over Node's future. The author correctly frames it as a personal decision in which tool to use for which job.

Mithaldu 12y ago

> Hiring for Go — I wouldn’t even know where to start. Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job. You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to learn whatever else your company might need in the future, and writes better code by way of having a focus on programming knowledge, not language knowledge.

pjmlp 12y ago
I haven't seen this type of hiring since the .com bubble days. Nowadays either one has the right keywords on the CV or good luck.
- watwut 12y ago
  Yeah, but that might have something to do with perceived shortage of developers.
talloaktrees 12y ago
How to train a new employee on Go: Day 1: complete the tour - http://tour.golang.org/ http://tour.golang.org/ and read "How to Write Go Code" http://golang.org/doc/code.html http://golang.org/doc/code.html Day 2-3: read Effective Go - http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Take a whole week, if you feel it is necessary.
- eyko 12y ago
  This was exactly how I did it. The Effective Go part took me longer, since I actually jumped into porting a couple of small ruby libraries I picked (not mine, just ones I was familiar with) so that had me jumping to and from the book to the terminal/editor, so it probably took me like 5 days to port both libraries into Go code that I was happy with. After that I had also read enough online to be familiar with the tools and the environment. Go is a really small language, but the ecosystem is rich.

dlsym 12y ago

"And for that matter, I guess that makes Java, German." Well, now I feel offended.

talloaktrees 12y ago
Java should be Indonesian if you really think about it
- twic 12y ago
  Does that make Oracle the Dutch East India Company?
- TheOtherHobbes 12y ago
  An archipelago of lush but unstable islands prone to earthquakes and volcanoes?

human_error 12y ago

> Hiring for Go — I wouldn’t even know where to start Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn programming from scratch. So, when you want to hire someone to code in Go, you just hire a developer and tell them they're going to code in Go. After getting used with Go, they would be all set.

chdir 12y ago
In principle, I agree that picking up programming languages for a good programmer shouldn't be a challenge but this analogy doesn't go too far. There are fine nuances about a programming language that you need to learn to be a good programmer. Whereas a car is mostly a commute tool for many. You can switch a browser like a car, but switching a language is a bit more involved.
- nawitus 12y ago
  I agree with your point, but Go in particular doesn't seem very different from, say, C/C++. I think the average programmer who knows C/C++ can pick it up rather quickly, even though going from Java to JavaScript takes significantly longer.
  - crdoconnor 12y ago
    Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things. You also need to develop a full understanding of the package/library/framework ecosystem, which can take years. This isn't transferable knowledge, either, but it's absolutely vital to understanding a language. Knowing that requests is a great python library, for instance, and knowing when (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C. I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.

_random_ 12y ago

"With Node you can literally share your code between the front and back of a system." Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?

crdoconnor 12y ago
It makes sense if your app flat out requires a lot of javascript on the client side. I find that javascript is most often an overused crutch on the client side, though. It's used more for premature optimization and making your website look shinier than it is anything really very useful. Nonetheless, some webapps really do require a lot of it.
- rimantas 12y ago
  > It makes sense if your app flat out requires a lot of > javascript on the client side. Well, you can take a different look: spend some time thinking why does your app requires a lot of JavaScript, and is it really necessary. Even if the answer is still "yes" that may be a good exercise.

eliben 12y ago

> We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere. The "alas" in this quote is sad. Sad to be using tools you hate.

jvickers 12y ago
I feel the same way about JavaScript, to some extent at least. I don't hate JavaScript - but I think that the web would be better if it moved towards making another language standard as well. I don't know which language would be best, Dart looks like a good candidate when it is more mature.

bryanlarsen 12y ago

Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features. Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services. That being said, Node is particularly well suited for consuming services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit. The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic. The other killer feature for node.js has already been mentioned: combining both server and client side rendering with https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr or https://github.com/wvl/highbrow https://github.com/wvl/highbrow.

neebz 12y ago
slightly off-topic but I am pretty interested in learning about SOA architecture using Node.js apps. Can you refer any guides/links ?
- bryanlarsen 12y ago
  Hmmm, I couldn't find any simple examples. Basically, all it means that you're running Backbone.js on the server as well. If you're just using Backbone.js models & collections it's pretty straightforward. But if you Google for running Backbone.js on the server, you get links for people running Backbone.js views (as well as models and collections) on the server. That's a little more involved, but the work has been done for you by frameworks such as rendr. A good starting place might be: https://github.com/rendrjs/rendr-examples https://github.com/rendrjs/rendr-examples I'm only familiar with Backbone. If your models are written in Ember or Angular or (?) instead of Backbone, I can't help you but would be very interesting in knowing how myself...

goblin89 12y ago

> With Node you can literally share your code between the front and back of a system. I think sharing code is dangerous as it tightens component coupling and makes architecture less flexible and more complex. An average web project nowadays seems to be a back with many fronts: end-user website, admin interface, iOS app, Android app, Windows app… Making all fronts equal in their separation IMO keeps the architecture more predictable and easier to understand. Like DRY but with design decisions instead of lines of code. Also, I don't see how you can be flexible without making API the only point of contact for your back(s). That way you don't lock yourself in and can rewrite any component with another framework or language, once requirements change sufficiently. I imagine it's much harder to do if you have everything in one Node project.

couchand 12y ago
I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project. First, why. To your point about DRY but with design decisions instead of lines of code, that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again. Building a system that has every problem solved (at least) twice in (at least) two different languages is what makes architecture harder to understand, and more importantly maintain. Ok, how. You create lots of little modules that each do one thing well. They declare their dependencies on your other modules, so it's actually much harder to introduce coupling between components. You use the modules appropriate to whichever part of the system you're building. A practical example: you want to validate user input. You have a series of business rules that must be checked before you allow an update. Of course you want to check them on the client, so you can provide valuable feedback as quickly as possible. But you also must check them on the server, to prevent a wily user from circumventing your rules. How do you architect this system? If you're sharing code, you just write a function to check the rules and call it in both places. If you're not, you end up reimplementing the rule in both places. But of course you'd like to at least share the rule definitions, so you end up writing the rules in JSON or something and then building parallel rule loaders in both places. Or if you're me you just give up and use Node instead.

TheMagicHorsey 12y ago

If you want to be DRY, a nicer option is clojurescript/clojure. Clojurescript + Om is a pretty nice combo for the browser.