Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

I don't see a lot of merit to the "sharing code" idea as the purpose of server side code and client side code are completely different. There are 2 possible exceptions where I can see some use:

1) Utility libraries. I have a clone method I use a lot, an would work equally well in both environments. I'm sure math libraries would be the same way.

2) Models. Maybe. Personally, my server side models contain get and save methods which make database calls. I don't want or need those on the client side. If for no reason other than wasted bandwidth.

* note: I'm a node user, but I don't share any code between server and browser.

View on HN

Since I compile all my CoffeeScripts into JavaScripts at node program start, code sharing is a breeze. For each file, I make a client version and a server version and use simple preprocessor lines:

#if client

#if server

#endif

for the pieces that only apply to the client side or the server side, with shared pieces staying outside these "tags". I won't go back. This is especially cool as I have a templating system that can run on the server or on the client. So for JS-enabled browsers, all HTML template rendering is done on the client by building all HTML tags out of very small simple JSON structs. For non-JS clients (spiders, bots, paranoid non-JS enterprise legacy browsers) the "pages" get fully rendered old-school by the server-side -- both sharing the same rather simple custom-made JSON-driven templating functions and producing essentially almost the same HTML output. Of course there are some added complexities going on with things like scripted onclicks, but you get the general idea. (This is mostly done for indexing spiders and human non-JS clients just simply have to put up with a limited, degraded, basic experience.)

I do it similarly. And it's the way to go ...

Sharing the utility libraries are a huge win though and should not be underestimated. For example on one project alone:

- Input Validation

- Asynchronous loop patterns

- Promise pattern implementations

- markup logic & output

- A* pathfinding

More and more use cases will pop up over time, and it's really unique to the node.js environment. This alone would not make me pick node.js over another solution but I feel it is still an advantage.

I spend about 50% of my dev time on writing / working with utility libraries as writing these libraries takes far more effort than writing handlers, models, etc.

Ian Bicking does a great job of debunking the many of the alleged advantages of code sharing: http://blog.ianbicking.org/2011/03/30/js-on-server-and-clien...

    Validation on the client is primarily a user experience concern,
    where you focus on bringing attention to problems with a form, and
    helping the user resolve those problems.
    
    Once the form is submitted, if you’ve done thorough client-side
    validation you can also avoid friendly server-side validation. Of
    course all your client-side validation could be avoided through a
    malicious client, but you don’t need to give a friendly error
    message in that case, you can simply bail out with a simple 400 Bad
    Request error.
    
    At that point there’s not much in common between these two kinds of
    validation — the client is all user experience, and the server is all
    data integrity.

That's some nice theory, and it's obvious the author hasn't had much experience implementing real applications where sharing code is possible.

With the right abstractions the code for validating on the client and for validating on the server can be identical. For example take a look at Luna/Lunascript.

This is not easy by just using Node, and it's not necessary that the language you use is Javascript. A better approach IMO is that you have a language X that is nicer than Javascript, and compiles both to server side code and client side Javascript.

For the case of validation here is a hypothetical language (ignore the bad regex):

    <form action="/foo/bar">
      <input type="text" name="email" />
      <%= if not email ~ "[a-z]+@[a-z]+.[a-z]+": invalid("Email is not valid") %>
      <submit>
    </form>

From this code you could generate real time JS validation and server side validation.

Example: You are building an editable list. The client insert and delete items from the list, which is then synchronized with the database. Now you need the HTML generating code on both the client and the server.

Another example: validation. You want to validate on the client for responsiveness, but on the server for integrity.

Being able to reuse content generating code can be especially useful when you don't realise that you will need it on both the client and server when you write it, or you have to move it from one to the other.

Code sharing really only becomes a compelling argument if you're building browser games or something similarly interactive (i.e., really bloody interactive). In this case, you need to run the same logic on the client (to reduce latency) and on the server (to validate and actually update game state).

Otherwise, you really have no excuse for putting logic on the client. Even with something like validation, I think its much more sensible to have your renderers pump out generic validation event handlers than to reconstruct the whole model class on the client.

I definitely am in the same camp on the "sharing code" argument, but could see careful structuring make models sort-of work. Obviously the basic persistence behavior needs to change, but if you reduce validation and some of the business logic to something more composable/interchangeable you could share it between the two.

Obviously then you'd need some way of distinguishing validation that is only important to one of the two ends from that which is meaningful to both, but I can see it being possible.

That said, I'm still not convinced it's worth it. Especially when you look at the state of libraries in node compared to something like Python/Ruby.

IMHO, the merit of sharing code really shines with templates. You can have full-featured Haml-js templates that are rendered on the server and the client. This means your client can make RESTful calls to your JSON api and has full rendering capability in the client.

I do that by using RDFa as the "templating language". This way the same templating information is usable on both client and server, and also external tools like search engines can benefit from it

Could you explain? Right now I'm using Jade on the server and Jquery Templates on the client. I'd love to use the same templates on both.

Do you want me to explain Haml-JS shared across both or the parent of your comment to explain RDFa? If you email me - aaron.blohowiak@gmail.com - I'll write up a tutorial and send it to you when its ready.

Most of templating is relatively simple rules: put attribute foo of object bar inside this div, repeat members of collection baz here.

These can just as easily be described using RDFa as using TAL or Jade or whatever. The benefit of RDFa is that the templating information stays with the page, so client-side can also utilize it.

The library I made for this is https://github.com/bergie/VIE

The way I've heard it argued is that as more and more things happen in the client, you want some level of data validation there. But as we all know, it's not enough to just validate the data in the client - you need to do it on the server too. So hence code duplication.

Reply on news.ycombinator.com