4 ms·

I never understood this argument. Client side javascript and server side javascript aren't really the same at all, it's not like you can re-use your client side

I never understood this argument. Client side javascript and server side javascript aren't really the same at all, it's not like you can re-use your client side javascript on the server. The only benefit I see is that you don't have to context switch between python and javascript, but the only time I can remember this affecting me is when I forget to type semi-colons.

aaronblohowiak 16y ago
"it's not like you can re-use your client side javascript on the server". The other is more appealing. The wins for client/server code share are for things like field validations and templates.
Encosia 16y ago
That's not always true. Templating is a perfect case for reusing code on both sides of the connection. In the optimal scenario, the browser can render a template based on requests for JSON data. However, if the client doesn't support JavaScript, the same template can be rendered on the server-side and fed to the browser traditionally. Great for accessibility and SEO. Input validation is another situation that's a great candidate for shared code. Another nice benefit is that server-side JavaScript brings an assortment of mature DOM selection/manipulation engines with it. I believe there was an example of using jQuery on the server-side with node.js posted here recently. Jaxer[0], which was ahead of its time, had a nice approach to sharing client/server logic with its runat="both". It's a shame that project never got much traction. [0] http://www.jaxer.org/ http://www.jaxer.org/
bootload 16y ago
"... it's not like you can re-use your client side javascript on the server. ..." nodejs and jsdom perhaps? "jsdom + jQuery in 5 lines with node.js" ~ http://news.ycombinator.com/item?id=1665999 http://news.ycombinator.com/item?id=1665999