4 ms·

Use Go, Dump Node

3 points by dcu 11y ago

clishem 11y ago
Misleading title.
- dcu 11y ago
  Updated to the new title from the article
jscheel 11y ago
Published with Ghost, a blogging platform built in Node :)
- xlm1717 11y ago
  The footer even hypocritically says Proudly published with Ghost.
platinumdragon 11y ago
And the entire article shoes how to take something simple and easily understandable to something that looks like complete garbage, which ends up doing the same thing.
mchahn 11y ago
Not a lot of convincing arguments there, even if his advice is good. > Javascript didn't always have this massive body of work. Let me know when GO does.
tracker1 11y ago
The foundation that JavaScript is a language for the browser isn't entirely true... it was always meant as a general purpose scripting language that happened to be heavily tied to the browser. There have been server-side browser-less implementations of the language as long as the language has existed. I wouldn't reach for node in every case, but I'm going to be honest, I would reach for it as a first choice in most cases. It's pretty easy to get going, the language is familiar, and you can do a lot with it using node + npm. I've used it to translate millions of database records from one system to another. I reach for it pretty much anytime I need to convert data... though if I knew Perl better, that might be my first choice. With the ES6 features, It's really nice... I spent a few hours the other day working on migrating the blog entries from my old blog[1] that's been in read only mode for over a year now after being compromised. It came together pretty quickly and works. Between cheerio, and js-yaml, the actual conversion was pretty simple, to say the least. XML in, yaml front-matter + post out. I don't think that doing that in go would have been nearly as easy to do. The next step will probably be to deliver a dynamic site, but may followup with a static site generator. Doing universal rendering isn't always necessary, but where it is, node is awesome... Actually, as an API server for the front end it rocks pretty hard too. With the front end in JS, and the layer it talks to in JS, it's damned easy to talk to other services from node. Getting rid of a huge amount of cognitive disconnect in the process. If I were writing a clear API-only, or system that had to process a lot more data, I might reach for go first... Most of the time, it's node/js. [1] https://github.com/tracker1/convert-blogengine-data https://github.com/tracker1/convert-blogengine-data

Use Go, Dump Node

3 points by dcu 11y ago

clishem 11y ago

Misleading title.

dcu 11y ago
Updated to the new title from the article

jscheel 11y ago

Published with Ghost, a blogging platform built in Node :)

xlm1717 11y ago
The footer even hypocritically says Proudly published with Ghost.

platinumdragon 11y ago

And the entire article shoes how to take something simple and easily understandable to something that looks like complete garbage, which ends up doing the same thing.

mchahn 11y ago

Not a lot of convincing arguments there, even if his advice is good. > Javascript didn't always have this massive body of work. Let me know when GO does.

tracker1 11y ago

The foundation that JavaScript is a language for the browser isn't entirely true... it was always meant as a general purpose scripting language that happened to be heavily tied to the browser. There have been server-side browser-less implementations of the language as long as the language has existed. I wouldn't reach for node in every case, but I'm going to be honest, I would reach for it as a first choice in most cases. It's pretty easy to get going, the language is familiar, and you can do a lot with it using node + npm. I've used it to translate millions of database records from one system to another. I reach for it pretty much anytime I need to convert data... though if I knew Perl better, that might be my first choice. With the ES6 features, It's really nice... I spent a few hours the other day working on migrating the blog entries from my old blog[1] that's been in read only mode for over a year now after being compromised. It came together pretty quickly and works. Between cheerio, and js-yaml, the actual conversion was pretty simple, to say the least. XML in, yaml front-matter + post out. I don't think that doing that in go would have been nearly as easy to do. The next step will probably be to deliver a dynamic site, but may followup with a static site generator. Doing universal rendering isn't always necessary, but where it is, node is awesome... Actually, as an API server for the front end it rocks pretty hard too. With the front end in JS, and the layer it talks to in JS, it's damned easy to talk to other services from node. Getting rid of a huge amount of cognitive disconnect in the process. If I were writing a clear API-only, or system that had to process a lot more data, I might reach for go first... Most of the time, it's node/js. [1] https://github.com/tracker1/convert-blogengine-data https://github.com/tracker1/convert-blogengine-data