Ask HN: Looking for a lightweight and simple engine for dynamic page rendering | Hacker News Reader

Ask HN: Looking for a lightweight and simple engine for dynamic page rendering

4 pointslukcybrain6 comments

I want to implement a website similar to HN, but I don't want to/not familiar with the front end(it's ok but debugging is too slow).

the basic requirements are link tags,forms,lists, and simple styles.

The key point is that data needs to be dynamically rendered through a small server side,not static documents I thought about the Markdown document rendering engine.

Compared to HTML,I prefer the Markdown syntax, but it seems there is not way to submission or data exchange with the server.[Perhaps it can be achieved by extending the syntax?]

Or there might be some technologies that I haven't learned about yet that can achieve this?

View on HN

Sounds like a web 1.0 http server with a pug-like html templater and some popular css framework.

> I want to implement a website similar to HN, but I don't want to/not familiar with the front end

OP, it was a bit unclear from your post: What technologies are you already familiar with? Does this mean you can already comfortably make the backend (DB, API, etc.), or is that part unfamiliar too?

> The key point is that data needs to be dynamically rendered through a small server side,not static documents

That's fine, but that doesn't really narrow it down by much. You can use any sort of backend stack that can output HTML, but there's a million of them to choose from, and probably a dozen good & popular ones.

Even if you had a heavy and partially static frontend, you would still need a backend (or serverless) to persist data in anyway. Persistent data lives on the server and the rendering will always happen on the client because HTML is ultimately rendered by the browser. What's different is where application logic happens (clientside in JS, or sent as data to the backend for some other language to process). Even if you had a partially static site, normally parts of it would still be dynamic and update from AJAX calls. Ultimately the frontend and backend will always work together, but where you want to draw the particular lines is entirely up to you.

> Compared to HTML,I prefer the Markdown syntax

Me too, but unfortunately Markdown just isn't expressive enough for something like this. It doesn't have logical functions or network functions.

If you want interactivity, you need some sort of scripting language on top of a document markup language (which is all Markdown is). These are often called templating engines, and were really popular in the past (90s-2010s) before the JS frameworks took over everything... the folks that used to use them now use React/Vue/Svelte/etc.

There are also in-between systems, like HTMX + Alpine that's popular on HN.

If you want to go the more traditional route and do the logic on the server, PHP is the most obvious serverside system for something like this (maybe with Laravel & Blade or Symfony & Twig), or people build their own too (like Shopify did with Liquid: https://shopify.dev/docs/api/liquid#what_is_a_template_langu...), Django for Python, etc. There are probably similar ones for Java, Go, Rust, and whatever other language you prefer to work in. But ultimately you need something that can process both content markup/styling and also logic, which Markdown can't do on its own. You don't necessarily need to do everything on the frontend, but it's helpful for the user to be able to do certain things (like upvoting) via AJAX without having to redownload a whole new page from your server. So it's worth thinking about what logic should vs shouldn't live on the frontend.

Whatever you do, you might wanna take a look at other HN clones to see how other people have made similar software: https://www.google.com/search?q=github+HN+clones&ie=UTF-8

--------------

If you don't wanna do any of this yourself, you can also just consider running a Discourse system (or pay for a hosted one) and add a voting plugin... might be similar enough.

> OP, it was a bit unclear from your post: What technologies are you already familiar with? Does this mean you can already comfortably make the backend (DB, API, etc.), or is that part unfamiliar too?

You're right,I didn't notice that.I had a 4-year enterprise working experience which was more focused on the back end. I'm familiar with using object-oriented programming languages such as Java, Python Js to create DBs, APIs, etc. But I rarely dealt with front-end interaction. So it's diffcult for me now.

This is rather contradictory. Currently, my main time and enegy are spent using NLP to filter high-quality content in the field of technology [or others],

and dynamic rendering of page data is required [but not realtime], whether on the client side or the server side. At present, the front end has become a weakness.

I've been trying to move towards a static architecture, like static site generator. but it doesn't seem to work..LOL..like:

1.The NLP system will update the data frequently, and the data needs to be displayed in a list,and how to deal with pagination staticlly?

2.Form data needs to be enterd manually.Interaction adn persistence are also required.

3.Like HN item, if it is statically genereated, whether several pages are generated for each comment?

I think it will encounter this situation again in the future.There are two ways:

One is to pick up HTML, CSS, React etc again.

The other possibility(laziness) is to find other technologies (perhaps some that I'm not aware of) to replace the first one. Since interface interaction doesn't need to be fancy. I know about Gradio,Streamlit, etc. They dont seem very flexible. For Instance, embedding a database or implementing a login system is troublesome,etc.

Sorry, I'm not familiar enough about the Python world (Gradio, Streamlit, etc.) to know if those will work for you.

But I don't know that your situation is necessarily about static vs dynamic rendering, but just basic web architecture (API design, caching, etc.). You can do all of it serverside and render the HTML dynamically on every load, or you can cache some of it, or you can statically bake it into HTML and use patterns like ISR (incremental static regeneration) or SWR (stale while revalidate) to re-build when they change, etc., or you can render some or all of it dynamically on the frontend after fetching from your APIs... those are performance optimizations, IMO, but none of them are necessarily more difficult than the others.

I don't think this is really a frontend-specific question, but like web dev in general (meaning all the in-between parts too, like HTTP and CDNs and such). If you want the backend to spit out all the pages dynamically you can do that, but you still have to be able to write basic HTML (doesn't have to be anything fancy, or you can use systems like Tailwind/Bootstrap to make it simpler but somewhat modern looking). But if you can't make a functional HTML webpage from your existing backend knowledge, you'll have to either fill that gap or yeah, find something that can auto-generate that for you.

> The other possibility(laziness) is to find other technologies (perhaps some that I'm not aware of) to replace the first one.

Is this for a commercial project? Can I suggest possibly partnering up with a frontender or hiring a freelancer, at least for the initial implementation? You can sit down and hash out the API endpoints needed, how to deal with pagination and caching, where to host all of this, etc. And then with that basic architecture up and running, maintaining it or adding new features in the future might be something you can do on your own with less effort.

Or if it's an open source kinda thing, maybe put up what you have now, explain what it does and what you need the UI to do more specifically, and maybe people can provide more concrete specifics? It's all still kinda vague beyond "there is some data and some of it comes from NLP algorithms and it needs to update every so often". Sorry that I couldn't be more helpful.

> Is this for a commercial project? Or if it's an open source kinda thing,

It's very far from business.I don't think it's like an open source project,I don't know. It's just a thought that has been in my head all the time.

The idea is to aggregate information in a field, such as the IT field, but the quality of most of information on the Internet is uneven, so I decided to embed NLP/ML algorithms to filter the data, preferably to filter out "real, useful,interesting" information rather than searching for it myself.

Compared to search engines, I prefer interesting things to appear in front of me rather than me searching with a certain keyword in the search engine.

In fact, many things that I think are interesting or useful to me were things I hadn't known or realized before, and I couldn't express them either, also unexpected. [kinda like ] I hope to be pushed some things I didn't know before. If I want to study in depth, I can focus throught the search engine. This is my ideal idea.

> Sorry that I couldn't be more helpful.

You did mention some things that I'm not familiar with, I'm glad to hear that.

To be honest, I don't have a very clear or better way to achieve it now. I've been trying.

The prototype of the interface refers to the HN. It can link to the data source and users can comment. Just plain text, keep it as simple as possible.I don't konw about HN's voting, sorting algorithms.

Or I should ask: What would you do if you wanted to statically make all the items of HN [articles and comments] static (generate static pages) without affecting user to submit comments and of articles?

Reply on news.ycombinator.com