[StevePerkins]

EVERY language is "relatively sane" if you only "stick to the good parts". That argument is basically a tautology.

As for the logic of using a single language throughout your stack, I would argue two points:

[1] It's a myth. If you are a professional software developer, you are going to learn multiple languages... and if you're a GOOD software developer, then this excites you rather than bums you out.

So you're using JavaScript on both the client-side and server-side. Okay, how do you get information from your database without learning SQL? Just stick with MongoDB as the only datastore you will ever use? Document stores are great for the things that document stores are great for (another tautology), but suck horribly when you try to shoehorn them into situations calling for a relational database.

What about the HTML and CSS knowledge you already need to work on the client-side? Do those "not count", because a JavaScript developer usually happens to know them? Nonsense. Doing real work requires knowing multiple languages, because different ones are better suited for different domains.

[2] I would argue that the skills and considerations required to do non-trivial work on the server-side are generally different from those skills needed to do non-trivial work on the client-side. You may be smart and/or experienced enough to master both domains, but you approach design and coding issues differently in those domains.

If you take a developer who is senior on the server-side, but is so junior level on the client-side that he or she barely understands the DOM, then they will struggle at first in the other context. Vice-versa if you take a senior client-side web developer and throw them into the backend world. You're going to need to learn completely different skills, quickly. I'm not convinced that clinging to your "home" language really speeds up that process, rather than impairing it.

[daleharvey]

I agree that any language is relatively sane when sticking to the good parts, and even that is a stretch with JavaScript.

The code sharing benefits are very real, while backend developers may need to learn a bit about the dom whereas frontend developers may need to learn a bit about sockets / file handles whatever, having a shared language (and libraries) is immensely powerful.

I work on a clone of CouchDB in JavaScript, it also works as an (immature) fully functional server side clone running 90% shared code.

The most used libraries in npm are shared between client and server, it has very real benefits

[deckiedan]

Fair enough. I actually don't use node, or js on the server. :-)

I still kind of like the idea though, of having only one source for (say) object definition, which is shared somehow between the client and server code. Being able to use the same unit tests to check my client side models as server side ones.

Maybe you could do it the other way around though - having your objects from your SQL Schema (or ORM, or whatever) generate the basic JS models... I dunno.

I totally agree that you need multiple languages, and that knowing multiple languages is incredibly valuable - and a lot of fun. I wrote a basic scheme in python for fun, and have a haskell textbook on my desk in front of me right now :-) - But I also feel that there should be some way that by using one language for all of your application logic (client and server side), there could be a benefit.

Sure, DOM manipulation is it's own weird thing - as is database querying, and document styling,- but the application logic that is done clientside and server side is very similar, I find.