[deckiedan]

I think you're just trolling. But on the off-chance that you may actually be interested in discussion from someone who does a lot of JS, has done a lot of PHP:

No, they're different. Firstly:

- js is the only choice in browsers. for server stuff, you have an almost infinite choice.

- javascript has warts, sure. but if you stick to "the good parts", then it is possible to use in a relatively sane manner. the compile-to-js languages are trying to make it easier to use the good parts, and harder to use the bad ones.

- node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well.

[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.

[ceejayoz]

> if you stick to "the good parts", then it is possible to use in a relatively sane manner

Is there any language for which this is not true?

[deckiedan]

well, malbolge, for one. :-)

I may just be biased against PHP.

Facebook, at least, believe that it does have enough good parts to make it worth while, so my opinion is just that. My opinion.

I feel that JS has the following good points:

closures, anonymous functions & enough of the 'lisp-zen-nature' to be quite powerful. The prototypal inheritance is a bit weird, at first, and a little ugly on its own, but actually is quite powerful.

It's simple enough that any non-js programmer can pick it up pretty quickly.

PHP has all the usual well known issues, but has the following problems that JS doesn't:

a vast vast vast multi-level standard library, with many different ways of doing things (mysql, mysqli, pdo...) all of which are built in (or not, you can't tell until run-time). the various different php.ini settings which actually change how the language works (eg. 3 different 'escape to HTML' tags). although functions are 'considered bad practice' to use, there isn't a single source of truth on how to write it well. the documentation is a sea of misunderstanding and examples of how to abuse functions and do things which aren't non-obvious (the comments on each page). JS objects generally have methods attached for doing the various operations on them. php has a bit of that, but mostly external functions that you pass arrays or whatever to. That can be just a stylistic thing (being more 'c' like) but it also means you end up having to know - just to use the language at a basic level - that it's array_splice($a), sort($a), array_rand($a), strpos & string_replace, etc.

JS is really quite a small language. You can read crockford's, 'the good parts' in a day, including all the bits to avoid. PHP is a very big language. To write a 'the good parts' of it would require a much longer book, as you can't use the recommended parts without understanding pretty much of the whole language.

[slight]

ooh, ooh! Unlambda!

  ```s``s``sii`ki
    `k.*``s``s`ks
   ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
    `k``s`ksk

[mmanfrin]

Brainfuck?

[orting]

> node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well.

I don thinkt that makes any sense. Should we also use js to implement the OS for the server? If js is good for server-side use it, if not use something else.

My main issues with php is that I dont trust the language and standard libraries to behave as I expect. There are simply to many strange type conversions, silent errors and strange behaviour going on.

[adrianmalacoda]

> I don thinkt that makes any sense. Should we also use js to implement the OS for the server?

We don't normally develop the OS ourselves, so what language it was written in is irrelevant. Same goes for runtimes, libraries, etc. If we're not responsible for maintaining it, it should not matter what language it was written in. Naturally, the "same language on client and server" argument can only apply to code we develop and maintain.

[orting]

My argument was badly put.

What is the benefit of using the same language on the client and server? That the developer only needs to know one language?

The server-side code you write has to interact both with the client and the underlying OS. So you should consider how language X interacts with both client and OS, in addition to the intrinsic qualities of the language.

If we adopt a modular approach to software development, then I don't see any universal benefit to using the same language for all modules.

js might be a good server-side language, but choosing it because it works on the client is the wrong reason.