Ask HN: Where is my server-side rendering?

Here's my approach - I think it will work for you, but you can use different tooling:

-Django server framework to handle templates, auth, routing, DB etc

- HTML templates and CSS (inline for one-offs, and CSS files for multi-use and defaults)

- Targeted JS without dependencies for UI manipulation and fetching data from the server as required.

I think you'll find the improvements in modern JS and CSS very nice. Flex, Grid, JS DOM apis etc. Ignore the bloated frontend frameworks etc.

If this is a personal project and if you are not very JS fluent, you can absolutely stay away from all the SPA bruhaha. Rails is still very well alive and kicking, same thing going on for Django, Symphony and so on.

I say "if this is a personal project" because in the case of a professional engagement there are possibly other considerations.

You could remove the first 14 words and the entire last sentence and this would be even more accurate.

I preferred to err on the side of caution, just in case.

PHP , jquery with maybe bootstrap for the mobile compatibility and some mysql. It all works as it always had and you won't have to learn a lot of new stuff you won't use again.

Nothing's stopping you from generating HTML with plain old strings. If you like Python, Bottle [1] is a great example of how simple it can be. This isn't actually what I use these days (I'm a victim of the fancy client-side JS libraries) but it's much easier to get running from zero than any other setup.

[1] http://bottlepy.org/docs/dev/tutorial.html#tutorial-template...

Rails + bootstrap ui. The fastest lane to up & running website.

It's been only 6 months since I made a quick and dirty DBMS web explorer, with for-loop tables and columns with sensible user-actions, dropdown menus what have you, depending on data types and requirements reported by the database. All server-side generated.

Stack that solved my problem:

- Python Flask, with the bundled Jinja templating,

- Spectre CSS.

This setup could produce some seriously large, functional and attractive tables. PHP is also an option, with Twig templating (which is a Jinja copycat).

> Where went the quick and dirty results of server-side generation of HTML tables and such?

Still here in the 20 years old technology you know, only changed in some paradigm, words, tools, but the core is always the same hyper text metaphor.

> How can old-timers quickly and easily get a modern-feeling but simple-to-make UI?

There are a lot of frameworks available todays, but if you have been ibernated for 20 years, I bet you'll like to try do it by yourself.

Depends on the stack you are sitting on or familiar with. Plenty of ways to still create a server side rendered site.

PHP has been around for quite the long time and is a quick and easy way to do it if you are familiar (or even if you aren't usually). Sure people shit on PHP all the time, but it can be a quick way to do it. Node also has template systems for server side. .NET & Python too.

Try looking harder? Basically every webserver framework comes with server side rendering out of the box and as de facto.

Check out https://hotwire.dev

Use React and keep all state in MobX, find one widget set you like, stick with it and don't get hung up on fine requirements of how it looks and behaves.

PHP: Symfony/Laravel Blade Templates

Python: Django/Flask/Jinja Templates

Ruby: Rails ?

NodeJS: Express ?

Basically a popular framework for a popular language. Almost all are server side by default.

I'd add Liquid? It's used by shopify and there are various implementations. I use liquidjs: https://liquidjs.com

May I ask what’s wrong with vanilla PHP?

With Node.js and Express, you can generate HTML as a string in response to HTTP requests, as barebones as it gets.

Ruby on Rails.

Plotly dash is the modern version of what you describe

https://plotly.com/dash/

Django templates will be your fastest option

Rails and PHP are a nightmare and legacy. Don't even bother

Next.js is pretty good

Can you please explain your opinion?

I am curious of two things:

1. How come Django is not legacy but Rails is?

2. How come Rails in itself it legacy for SSR?

I am curious and I think it worth explaining as it might be that people read the comments here and do not understand what criteria did you considered when deciding which is which.

Django uses a modern language and is simple

Rails is not sanely organized, very complicated, and ruby is just a crazy language

This is your purely subjective opinion.

I've worked with both profesionally, and my also purely subjective opinion is that while Ruby is better than Python, Rails is thousands of miles ahead of Django.

On the Ruby side, the standard library is a lot more consistent, the language itself is more powerful, the tooling is better (bundler + gems + rake vs pip..oh, wait its poetry.. or was it pipenv), puma is objetively better than uWSGI (no releases in years) and gunicorn (can't serve static files! wtf!).

Rails provides an opinionated and clear way to do frontend too (better templates, stimulus, hotwire, etc) and a way to do websockets, an official one. Translations in rails are a lot better too, based on keys instead of on 80's gettext funkyness. Routing is a lot easier too, just map urls to controllers... in django do you do function views? or class based views? now that's a mess. The "asyncification" going on in django is CRAZY, the complexity they're adding is React level insane.

Also, ruby didn't break the ecosystem and f*d half the community like python did from 2->3 (that's when I gave up on it) and nor is doing it with all the async madness in python splitting again the ecosystem on things that support it vs things that don't.

The only thing I miss from django is the migrations system, which I think are better than in rails, and maybe django-rest-framework.

So, there you go... your subjective opinion vs mine, everyone has one.

> HTML was a language that was obvious and easy to generate

It was never so. This attitude in fact is the cause of many bugs and security vulnerabilities, most popularly XSS. There's a reason infrastructure was built around these technologies, one of which is that they are not really safe.

There's nothing unsafe about HTML as a language. You'll never get an XSS issue from pure HTML. All of those "bugs" and "security vulnerabilities" come from mis-configured frameworks not properly sanitizing external data, or from (mostly PHP) ad-hoc code written by people unaware of the issue. But even then, any mainstream templating language escapes by default.

The parent comment was specifically about generating HTML, which by definition is not pure. And the templating languages are part of the complexity people are talking about.