4 ms·

I know this post is about speed, but you should always remember that with node.js you only need JS developers while with Go you are probably going to need both

I know this post is about speed, but you should always remember that with node.js you only need JS developers while with Go you are probably going to need both Go and JS (for front-end stuff) developers. Just my two cents.

cenhyperion 13y ago
Or developers that are comfortable with both JS and Go.
gtaylor 13y ago
At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. The other neat thing is that if your frontend and UI are cleanly separated, you can swap them out individually without the other even noticing. If our backend gets to be too sluggish, I can replace it with something lower level gradually over time (Go?) without leaving a bunch of deprecated backend JS cruft to clean out.
- purplelobster 13y ago
  As a single developer on a project, I use js on the front-end, NodeJS and CouchDB (views written in js). This means that every step of the way is js, json and http, which is extremely liberating for me, as someone who's just starting out with web development.
- ef4 13y ago
  I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming. Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and make sure they stayed in sync. Now I can implement once and run the same code in both places. And other interesting possibilities open up. The server can just run the client's data synchronization code to pull changes from another server, giving realtime server-to-server replication nearly "for free".
  - snupples 13y ago
    I love having the server and client share the same codebase. I'm working on a webapp that mimics functionality of an existing desktop application -- mostly as a self-educational project. As I'm writing it and adding features, I can push processing from server-side to client-side and vice versa with hardly more than a copy and paste of the relevant chunk of code. Say I don't really care about the security of some particular process, and I really don't want to use up any additional resources on the server for it, I can just push that load to the client browser in a couple clicks. Did I just write some feature into the client that I suddenly realize presents a security problem? With node, there's no need to change my frame of mind or rethink how to do something in a different language -- just copy and paste from client.js to server.js and do some slight cleanup.
thezilch 13y ago
Nay. You're going to need both backend (routing, security, caching, HTTP, more caching, SQL/ORM/whatever, MVC, search/document stores, etc) developers and frontend (HTML, CSS, HTML5 (Re: "the hard stuff"), AJAX/JSONP/CORS/whatever). Off the cuff, knowing another language is going to be very little of the overhead, especially when you consider one side is dealing with local services and the other is dealing with mostly DOM (or using some library / "another language" to view the DOM in another light).
- ebiester 13y ago
  I am a "full stack" developer. I know the ins and outs of both my front and back end stacks (Groovy in my case), and I have a pretty good sense of the patterns required in this case. However, one of the more frustrating pieces of this is that I never dive deep into one paradigm. I'm continually having to work bilingually. When I was working with node.js, I didn't feel nearly as much bilingual stress (even though I've written backends in python, ruby, java, groovy, and scala!) As such, my single person one-off and side projects will be in node.js. It's about cognitive overhead in the moment. I agree that it's a mediocre solution for larger teams and enterprise is not its sweet spot, but it's great for projects in the small.
  - thezilch 13y ago
    I didn't, by any means, intend to say it is not a good setup or denigrate you. I don't think anyone is wrong for using, even big teams, and I might even use the setup myself for certain projects. Only that it is rare to find really good full-stack developers, and those developers willing to work equally on both ends of the stack. And that a majority of work is thinking about the architecture and product; only hand waving 5% of the time is going to be spent context switching languages. I'd lose most of that time not having a richer language than what JS 1.5 offers, and if backend JS ever gets 1.7+ features, I am certain the browsers are not in the same stride, at which point I lose again.
    - ebiester 13y ago
      With the new transpilers, I don't think that's as much of a problem so long as one stays to modern (IE9+) browsers. (Let's see if this really comes true, but I know a few node.js types are anticipating this.) In the domain I'm in (internal enterprise cough) I find that most people are expected to be full stack. On the other hand, these tend to be more simple UIs in general, so the front end knowledge isn't as vital (cue 'good' full stack developer comments...)
diminoten 13y ago
There's a school of thought in software dev that a developer is a developer is a developer, and should be able to do all the things a developer should do. That said, you hire "backend-focused" developers, "front-end" developers, etc., but to me that still means they should be able to do whatever tasks are necessary (Go, JS) to get their job done.

cenhyperion 13y ago

Or developers that are comfortable with both JS and Go.

gtaylor 13y ago

At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. The other neat thing is that if your frontend and UI are cleanly separated, you can swap them out individually without the other even noticing. If our backend gets to be too sluggish, I can replace it with something lower level gradually over time (Go?) without leaving a bunch of deprecated backend JS cruft to clean out.

purplelobster 13y ago
As a single developer on a project, I use js on the front-end, NodeJS and CouchDB (views written in js). This means that every step of the way is js, json and http, which is extremely liberating for me, as someone who's just starting out with web development.
ef4 13y ago
I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming. Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and make sure they stayed in sync. Now I can implement once and run the same code in both places. And other interesting possibilities open up. The server can just run the client's data synchronization code to pull changes from another server, giving realtime server-to-server replication nearly "for free".
- snupples 13y ago
  I love having the server and client share the same codebase. I'm working on a webapp that mimics functionality of an existing desktop application -- mostly as a self-educational project. As I'm writing it and adding features, I can push processing from server-side to client-side and vice versa with hardly more than a copy and paste of the relevant chunk of code. Say I don't really care about the security of some particular process, and I really don't want to use up any additional resources on the server for it, I can just push that load to the client browser in a couple clicks. Did I just write some feature into the client that I suddenly realize presents a security problem? With node, there's no need to change my frame of mind or rethink how to do something in a different language -- just copy and paste from client.js to server.js and do some slight cleanup.

thezilch 13y ago

Nay. You're going to need both backend (routing, security, caching, HTTP, more caching, SQL/ORM/whatever, MVC, search/document stores, etc) developers and frontend (HTML, CSS, HTML5 (Re: "the hard stuff"), AJAX/JSONP/CORS/whatever). Off the cuff, knowing another language is going to be very little of the overhead, especially when you consider one side is dealing with local services and the other is dealing with mostly DOM (or using some library / "another language" to view the DOM in another light).

ebiester 13y ago
I am a "full stack" developer. I know the ins and outs of both my front and back end stacks (Groovy in my case), and I have a pretty good sense of the patterns required in this case. However, one of the more frustrating pieces of this is that I never dive deep into one paradigm. I'm continually having to work bilingually. When I was working with node.js, I didn't feel nearly as much bilingual stress (even though I've written backends in python, ruby, java, groovy, and scala!) As such, my single person one-off and side projects will be in node.js. It's about cognitive overhead in the moment. I agree that it's a mediocre solution for larger teams and enterprise is not its sweet spot, but it's great for projects in the small.
- thezilch 13y ago
  I didn't, by any means, intend to say it is not a good setup or denigrate you. I don't think anyone is wrong for using, even big teams, and I might even use the setup myself for certain projects. Only that it is rare to find really good full-stack developers, and those developers willing to work equally on both ends of the stack. And that a majority of work is thinking about the architecture and product; only hand waving 5% of the time is going to be spent context switching languages. I'd lose most of that time not having a richer language than what JS 1.5 offers, and if backend JS ever gets 1.7+ features, I am certain the browsers are not in the same stride, at which point I lose again.
  - ebiester 13y ago
    With the new transpilers, I don't think that's as much of a problem so long as one stays to modern (IE9+) browsers. (Let's see if this really comes true, but I know a few node.js types are anticipating this.) In the domain I'm in (internal enterprise cough) I find that most people are expected to be full stack. On the other hand, these tend to be more simple UIs in general, so the front end knowledge isn't as vital (cue 'good' full stack developer comments...)

diminoten 13y ago

There's a school of thought in software dev that a developer is a developer is a developer, and should be able to do all the things a developer should do. That said, you hire "backend-focused" developers, "front-end" developers, etc., but to me that still means they should be able to do whatever tasks are necessary (Go, JS) to get their job done.