Hacker News Reader

Comment by fnid2 | Hacker News Reader

For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front.

It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.

View on HN

I run into this all the time. The most common case is form validation. If you want to do some validation on the client side, why are you forced to repeat yourself by writing it once in Java/Ruby/Python/Perl/PHP on the server and then write it again on the client using Javascript/Underscore/JQuery/whatever?

http://github.com/raganwald/homoiconic/blob/master/2010/02/d...

A concern might be that you expose your server side code. Though many os projects do this by design.

Not necessarily, you can make a really high-level DSL to express validation rules, that encompasses both client-side and server-side logic, and then you generate the client-side-only validations from this model while not including the server-side, "secret" validation code.

Could it be that your form validation example is merely a symptom of not working at a high enough level of abstraction?

In the rails world, for example, if you've done your validates_* declarations on an ActiveRecord model, it shouldn't be too difficult to generate the javascript required for client-side validation.

Actually found a project that goes a long way towards achieving just that: http://github.com/grimen/validatious-on-rails

But I guess you're referring to complex validations, expressed as code instead of validates_* declarations. It seems like you would prefer either an all-JS approach or an automated translation to JS, as per the blog post you linked. To me, it boils down to whether such a complicated validation is really appropriate for client-side validation and whether it blurs the lines between form validation and business logic to such an extent that it's better off just living on the server.

But I'd love to hear your further thoughts on the matter.

Innocent question: Won't the server and client side code tend to be so different, they'll appear to be mutually exclusive? I understand that you're referring to basic concepts and syntax, but surely a lot of server side code simply won't execute in a browser's sandbox, correct?

When writing code for both client and server, it's difficult to mentally "switch". E.g. after writing some code in client, I'm starting placing curly braces in python's code :)

It would be nice to write both client and server in one language.

Someone once gave an example of a 'preview' feature on the client side (like preview the formatting of blog comments) -- then the same code is used on the server to generate the actual view.

I think this was briancarper.net where - since he's using clojure on the server - ended up running a javascript interpreter (rhino) on the server so that the same formatting code could run on the client and server.

Reply on news.ycombinator.com