7 ms·

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 p

by fnid2 17y ago

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.

qjz 17y ago
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?
- Esspe 17y ago
  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.
- nimrody 17y ago
  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.
raganwald 17y ago
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/difficult_distraction.md http://github.com/raganwald/homoiconic/blob/master/2010/02/d...
- planettrash 17y ago
  A concern might be that you expose your server side code. Though many os projects do this by design.
  - Hexstream 17y ago
    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.
- daveungerer 17y ago
  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 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.

by fnid2 17y ago

qjz 17y ago

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?

Esspe 17y ago
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.
nimrody 17y ago
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.

raganwald 17y ago

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/difficult_distraction.md http://github.com/raganwald/homoiconic/blob/master/2010/02/d...

planettrash 17y ago
A concern might be that you expose your server side code. Though many os projects do this by design.
- Hexstream 17y ago
  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.
daveungerer 17y ago
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 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.