News for hackers. Stuff that matters.
Re:To boldly go where Node man has gone before by tomjen3 on Wednesday May 16, 2012 @03:19PM (#3983555)
For small apps, no.

For complex ones yes. The actual code shared may not be that much, but consider the advantages in sharing validation code between the client and server -- you never accidentally forget one requirement on the server side, leaving you vulnerable to an attack.

Re:To boldly go where Node man has gone before by moe on Wednesday May 16, 2012 @08:13PM (#3984742)
consider the advantages in sharing validation code between the client and server

Is there a mature implementation of this yet?

One that is not tied to an entire immature framework (meteor) or programming pattern (nowjs)?

Code-reuse was the big promise of node. Yet in reality I've never seen it executed beyond brittle experiments.

Where is the form_for_model() function that emits code for both the client and the server?

Re:To boldly go where Node man has gone before by reissbaker on Thursday May 17, 2012 @02:38AM (#3985770)
Template compilation being able to happen on either the client or the server is a huge win for anyone writing webapps, and it's trivial to write view code that can be compiled in both Node and browsers even without a framework.

In other languages, even if you write completely logicless views in a templating language that can compile in the browser like Mustache, you'll end up duplicating your presenter code if you don't use a language that browsers can understand.

Re:To boldly go where Node man has gone before by moe on Thursday May 17, 2012 @07:45AM (#3986499)
and it's trivial to write view code that can be compiled in both Node and browsers even without a framework.

Nonsense. It's far from trivial to have the same code get binding and validation right on both sides. That's why it needs to be wrapped in a thin abstraction, which apparently nobody in the node-community has been capable of writing.

Instead we see dozens of rails-clones (oh, exciting..), and a handful of very half-baked full-stack universes that are nowhere near production ready.

Re:To boldly go where Node man has gone before by jsprinkles on Wednesday May 16, 2012 @03:21PM (#3983566)
Alternatively, there's an argument that one should not validate on the client to avoid this exact scenario (split-brain validation).
Re:To boldly go where Node man has gone before by sim0n on Wednesday May 16, 2012 @03:27PM (#3983599)
Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.
Re:To boldly go where Node man has gone before by jsprinkles on Wednesday May 16, 2012 @03:32PM (#3983619)
To avoid a split-brain validation scenario.

Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX).

Since it's a pain in the ass to remember to update two places when you make a change, you're seeing people make ridiculous leaps of programming ingenuity by choosing a server-side language that allows them to not have to update two places at once, and Javascript absolutely sucks for server programming. Every time I have to do any client-side Javascript I, quite literally, hate my life. People that love Javascript and want to apply it to everything have arguments about the stupidest things, like using semicolons, which is telling about how awful of a programming environment it can be.

Easier: Just don't validate on the client, and make a round trip. If you're doing mobile or on a high-latency link, there's an argument for doing client-side validation but then you just need the discipline to update both sides at once, which hopefully integration tests should help with.

Re:To boldly go where Node man has gone before by anatoli on Wednesday May 16, 2012 @04:26PM (#3983855)
That's a straw man if I ever saw one. This isn't a debate as to whether JS should be a server-side language or not. The fact is that if you're using Node and you're validating data, you can reuse the code to validate both on the front-end and the back-end. Front-end validation will likely improve the way your users perceive the app.
Re:To boldly go where Node man has gone before by vectorpush on Wednesday May 16, 2012 @04:54PM (#3983967)
Proper unit testing makes split-brain validation a non-issue. Client-side validation does feel more responsive, it also saves bandwidth, and prevents impatient users from spamming the server with invalid requests.
Re:To boldly go where Node man has gone before by vshade on Wednesday May 16, 2012 @04:27PM (#3983864)
That is why the guy is using the same code to do both validations.