... and off by one errors!

Dammit, wrong joke.

Let's talk about javascript

PHP: the good parts  From /r/lolphp

From /sub/lolphp

Coming from a Java background, having worked with JavaScript on the frontend, I have to ask: Why would you want to use JavaScript on the backend?

I've played with nodejs a little bit, I guess I'm still missing the point though.

I own both of these books. The primary difference is that The Good Parts ignores web browsers.

Kidding aside, JavaScript has come a long way. I'm impressed daily by the things we can do in it now (looking at you, nodejs)

Why would anyone use JavaScript in the browser?

I don't really get it either. I always assume it's front end or designers making life easier for themselves.

Well, there's a reason for that...

bunch of people who only know JS can now do backend development.

And that's #1 reason to never ever let them.


This. Having familiarity writing server side code with Java, JS, C#, C++, and Python, it seems to me that most of the appeal of JS on the backend is that a bunch of people who only know JS can now do backend development.

JS isn't Hitler. But given the possibilities, I'd way rather write server side code in anything other than JS.

I've been so disappointed at the lack of a follow-up talk about other languages. I suspect you could find similar things in Python or Go.

I went to a talk Douglas Crockford gave once. My co-worker brought a copy of "JavaScript: The Good Parts" and got him to sign it.

He wrote "Use spaces, not tabs" with his autograph. Sigh.

Well, most of that is due to type coercion, which neither Python nor Go have.


Things like this done with javascript only

Javascript has pretty good support for anonymous first order functions, and node is a asynchronous io framework.

On the one hand it's funny, on the other that's exactly the point of the second book. The author explicitly states that the book is about the small subset of the language he thinks should be used.

Or it could be people who, despite knowing plenty of backend languages, would like to minimize the amount of mental context-switching needed when they jump between frontend and backend.

If there's actually a hard line between frontend and backend developers, then it doesn't matter. If you mostly have backend code, so your frontend is mostly just ad-hoc scripts rather than a full-blown application, then you could focus on better languages than JavaScript most of the time.

But if I was starting a project today, Node would be a serious contender, because so many modern apps seem to be dumb CRUD-style backends and increasingly-rich frontends. (But I might also tend towards something like Dart rather than pure JS.)

Node is pretty damn awesome.

People keep saying this, and I can never tell if it's regurgitated or genuinely has a point. What is it about Go that makes it useful on the web like Node is, and so much better than Node?

People complain about Python. People use Python.

But they aren't necessarily the same people.

And Python!

... I'll see myself out.


Having read both, definitive is better.

Or at least as old as Javascript: The Good Parts

There are two questions you could be asking, so I'll answer both.

The reason I personally use it is twofold. Firstly, because I'm familiar and comfortable with JavaScript, and despite its warts I think it's a language you can make nice programs with. Secondly, it has a fantastic ecosystem - a big, largely well-designed standard library, a great package manager and a wonderful community around it.

The reason I'm glad Node exists is because it's the first big-hitting platform I'm aware of that pushes for non-blocking methods as the main tool for flow control. Lots of other languages (C# springs to mind) have patterns for it, but always allow you write software either way. Node is the first (again, that I'm aware of) to say "if you want IO, it has to be non-blocking." Being an environment for JavaScript isn't the objective, and reducing Node to "JS on the server side" is somewhat missing the point.

Never trust a language that doesn't support integer types.