Comment by imagist | Hacker News Reader

Comment by imagist | Hacker News Reader

Parent Full thread

> he biggest advantage of Node.js is that you can reuse the same code on the client and server, and thus it's ideal for creating universal single-page web apps. Being able to reuse the same code on the client and server is a massive advantage that can't be understated.

This advantage is totally overblown, and in fact I am not sure it even is an advantage. It definitely makes things easier in the short run, but it always comes around to bite you in the ass. The fact is, objects on the server and objects on the client are different things, and while you write less code up-front because the differences aren't always immediately obvious, you end up writing a lot more code later because you didn't think about the very important differences. Representing them as the same thing enables shoddy programmers to not think about the context of where their code will be run.

> "There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup

"[A] quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business." -- A. A. Milne

I think this is right on. They are completely different environments and I can't imagine very many instances where you'll be able to write a generic function you really want on both front and back end. I certainly haven't run into any in real life

I think a good example of a function you'd want in the front and back end is one that takes data and outputs a template.

sigh I'm afraid to hear your answer, but I'm going to ask anyway: what would compel you to output the same template on both the client and server sides?

Possible, possibly dubious: search engine optimization.

I'd argue that this points to a poor design. If something is static enough to be crawled by a search engine, then it doesn't make sense to be generating it dynamically every time on the client side. It's static, generate it statically, and then all you have to do is serve it up (caches are a variant of this approach, but not the only one).

I'm currently working on an unofficial interface for Readability because they aren't working on it anymore and their Android app is really broken.

The webpage needs to work offline (whole point of the project) but should be able to work without js if need be.

I create templates server-side and serve them to the client,

If js is available, it takes over and renders any further client-side interactions.

Does this sound like poor design or a valid reason to be able to render on the server and client?

It sounds like a poor design.

Webpages don't work offline. All the user has to do to break everything is hit "refresh". What your business users wanted was an app, and you gave them a webpage instead.

I also don't understand why you would do rendering both server and client side. That's an overcomplicated architecture that doesn't buy you anything. If you chose one, you'd have a simpler architecture.

And before you claim "optimization"--did you profile?

You're pretty opinionated for someone who doesn't seem to understand a lot of things ;)

1. Hitting refresh doesn't break everything. It resets your current state to the default. I default to the url combined with locally stored state, so you will lose text in an input field, but not much else.

2. I want a website not an app, thank you very much. I'm really just displaying text. I don't need to download an app for that when I have a perfectly good browser on every device I'd like to read from.

3. Maybe it's over complicated to you, but the same function that renders on the server is what I use to render on the client. Zero difference. It's not a choice I have to make so I can use either when I feel it's appropriate.

> 1. Hitting refresh doesn't break everything. It resets your current state to the default. I default to the url combined with locally stored state, so you will lose text in an input field, but not much else.

Really?

1. Go to your website.

2. Disconnect from the internet.

3. Hit Ctrl+Shift+R.

How's that app you wrote as a website working for you?

Works well, actually.

It's called appcache. Works in most browsers. You should look it up ;)

I'm guessing you've never written a universal/isomorphic single-page application?

If you try to write one without Node.js, you're going to be writing a lot of the same code twice - once in Javascript to run on the client-side, and twice to run the same exact logic on the server-side (eg. fetching data on the server to pre-render a page and parsing that data, making an AJAX call for the same data on the client and parsing that data in JS).

One codebase is easier to maintain than two codebases in two different languages.

> I'm guessing you've never written a universal/isomorphic single-page application?

You guessed wrong.

> If you try to write one without Node.js, you're going to be writing a lot of the same code twice - once in Javascript to run on the client-side, and twice to run the same exact logic on the server-side (eg. fetching data on the server to pre-render a page and parsing that data, making an AJAX call for the same data on the client and parsing that data in JS).

> One codebase is easier to maintain than two codebases in two different languages.

Sure, until you realize that they aren't the same objects, because context matters. But then it's too late because you've so fundamentally coupled the front-end to the back-end that they're inseparable. So you throw in ifs and switches to handle the difference, and eventually your code becomes an unmaintainable mess, and you can't get time from your boss to clean it up because deadlines.

So you quit and get a new job and starting that new project with Node is so easy, and you don't see the problem because you never stick around to actually maintain your code. Your previous business will go out of business when they try to rewrite the app because development has ground to a halt, but that's not your problem, now is it?

In my experience, having to write the same code twice in two different languages is a hell of a lot more work both from a creation and maintenance perspective than just writing it once. I haven't really had to deal with many of those edge cases you're talking about.

So what do you prefer to Node.js for universal single-page apps then?

> In my experience, having to write the same code twice in two different languages is a hell of a lot more work both from a creation and maintenance perspective than just writing it once. I haven't really had to deal with many of those edge cases you're talking about.

Cool, I hope for your sake that your luck continues.

> So what do you prefer to Node.js for universal single-page apps then?

To be honest, I prefer not to write single-page apps, as they break some fundamental ways the internet works, with no real benefit. I have started using React for in-page responsive components, which are composable and reusable independent of the app.

I prefer Flask for the backend, although I've used Django w/ Django Rest Framework and that has also been a good experience.

Reply on news.ycombinator.com