0

Hypothetically, consider a social photo platform - each pic gets its own url, this page contains the image, text about the image, buttons for the user to click, related pics, and some user-specific elements (maybe notifications, etc.). There are different ways of going about the frontend. In each case, elements specific to the logged-in-user and the related images get fetched via api calls and are rendered client side.

For rendering the rest of the page, couple of distinct possibilities -

  1. Everything is rendered client side - one can use a single page application to handle the routing. The page structure stays the same, and new image uri's and the associated content are fetched via api calls.

SEO is a priority, so pure client side rendering is suboptimal.

  1. Server side rendering for each page with NextJS or even Express is another option.

  2. Another way is to do a static export in something like NextJS - which will generate separate html files for each image.

  3. Now my thought is to skip all of that and go old school with sed/awk. We'll have a template file with all the styling elements and placeholders for the image uri and its description, etc. Then a script iterates through a list of values (queried from a database) specific to each image (img source URIs, description text, etc.) and uses sed to replace the placeholders in the template file and output a separate html file.

Each file has the same javascript to load the user-specific components.

Every time someone adds a new image, the script runs with the uri of the image and the description, etc. as the variables passed to it, and adds a new html file in a flat file structure.

These "variables" are stored in a database. So whenever we change the "design" of the page, we repeat the same process again - regenerate each html file.

The flat file structure will run into limitations, which is solvable with a directory structure. Nginx remains performant with large numbers of files.

Right now, we use NextJS with a mix of server side rendering and static pages, so it is all good. But I have been wondering about achieving something similar with more rudimentary (and performant) tools.

There's not too much additional work involved - templatizing the html file is straightforward, and this won't be difficult to script.

What's good and bad about this?

2
  • 1
    What actual, specific problem with your current system are you trying to solve? Jul 17 at 21:17
  • 1
    think it through. How are you going to make a template thats both sed-able and works for multiple users? you are going to have a whole lot of serverside rendering to get a specific to user template which you then awk/sed. Just server side render the page, cache or render it to a static file if performance is an issue
    – Ewan
    Jul 17 at 22:09

1 Answer 1

3

Yes, you can do that. No, it is not a good idea.

This is roughly how some websites worked in the 90s. That these approaches are problematic has nothing to do with their age, and everything to do with the difficulty of creating a secure website this way.

In particular, real template engines support some degree of auto-escaping. Sed and awk do not. It is also challenging to express all but the most trivial business logic in those languages. For example, how will you query the database? Sed can't do that.

In contrast, generating static sites can be a very good idea – serving static files is very fast, it scales well, and there is a fantastic ecosystem of static site generators. So it's perfectly OK to run some script to generate static HTML files if that is what you want. Just use a real template engine for this, please.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.