Hacker News new | ask | show | jobs
by brut 3299 days ago
I don't have a specific answer to your question. What I think would be much more sensible is to design your website without JS, and then sprinkle it here and there.

Ex: Make a request to an API upon page load. Populate tables or whatever you want. Then if JS is enabled, load a script that makes AJAX calls to the API to update the data every x seconds. That way your site gets "enhanced" by JS and is completely usable without it.

1 comments

Yes, the issue is then that you have to write two pieces of DOM rendering code (some view code in erb/jinja/whatever to populate a template on the server, and a piece of JS to update the table afterwards).

And if you want to allow JS-enabled browsers to transition between views (and different data subscriptions) without having to reload the entire page, then you'll have to write two pieces of routing code (one route in Rails/Django/whatever and another in JS).

And if you want to allow JS-enabled browsers to post form data back to your server and make minor changes to the page (e.g. edit one field in a table) without reloading the entire DOM, then you'll have to write two different routes on your server -- one that processes the form data and returns the HTML for a newly rendered page, and one that processes the same form data and returns only what's changed.

You could, of course, use server-side-rendering JS to DRY things up for issue one. I'm more curious if anything reduces the boilerplate for issues two and three.