Never do at run-time that which can be done at serve-time. Never do at serve-time that which can be done at build-time. #programming #webDev #webDevelopment #software #softwareDevelopment

@schizanon

I can't agree. I frequently do real time data visualization, using XML or JSON for getting data and client JS to paint graphics and do updates. Should I do this using full page reloads, and paint everything on the backend? Seems like a terrible experience and a wasteful way to do it.

@jgg if you can't do it at serve-time, then do it at run-time; that's what I said

Follow

@schizanon

I think your rule is good for most of public sites, where nearly all can be cached, but doesn't fit for very personalized or dynamic content, internal applications, or when there are concerns about server load. Some users have metered connections, and doing most of the work client side is much cheaper for them.

So, even if you can do something server-side, sometimes you shouldn't.

We are generally abusing client side, that's true. Your rule is perfect for most news sites, blogs, or static content pages.

A good example is an online XML formatter: should it be client side or not? I see it as a perfect fit for a PWA: code would be cached, you would be able to use it with no network, and it would be much faster, with no server load. Can it be done server side? Of course. Should it?

@jgg if your XML can be formatted on the server then you can support devices with JavaScript turned off, and you can save your users' batteries; so my point stands.

@schizanon

My applications usually require JS because they have some features that can't be done server side. If I have to require it, I may as well use it.

Using JS not always leads to more battery use. Network connections drain power too; and reloading a page to show some detail can be awfully wasteful when you already have all the data client side. And I'm not giving a worse service to 99% of users to help 1%.

Users that disable JS (I do it myself as user sometimes to avoid ads and mobile data charges, so I get the point) should be treated as blind users: we must give them the best functionality we can, but we should not harm nearly all of our users for their sake.

Disclaimer: I have clients who require us to disable the page if JS is not enabled. And they don't even want to discuss it; it is a hard prerequisite.

Sign in to participate in the conversation
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.