Back in the day, around 1998/1999, Oracle had tools to develop Web-applications served directly from the database.
To produce HTML one would use a variety of PL/SQL functions, one function for each HTML tag that was available at the time.
The result was that each time I had to correct a spelling error, or change a portion of the page, I had find in the code where the change was to be applied, change the code, recompile the package, and then restart the service to have the changes come into effect.
Combine it with the fact that the code written was always much more verbose that writing straigth HTML, it got really old, really fast.
In the end, I created a micro-CMS where I put the HTML code as snippets in the database that I then combined in PL/SQL to form a page that could be served to a browser.
Changes appeared on the fly as I updated the HTML snippets, and the service had no downtime due to restarts.
Not long after, we moved to using Zope to develop more advaced solutions, but thats another story.
Now, this was a long time and 2 jobs ago :), but I am curious as to why in 2025, one would prefer to go to return these types of solutions.
I like this approach. We did something similar, but for a position as support engineer, where coding ability was one of the requirements, though not the only one.
They were given a piece of code on a toy, easy to read, english-like pseudo-language, and were asked to examine it and explain what the output to a specific input would be.
They were told that we would answer any question, except what the answer was or what the code was doing, and encouraged them to explain their reasoning as they went ahead.
We wanted to asses the candidates ability to problem solve, communicate, how would they react under preassure, and how they approached the issue.
We were not necessarily looking for perfect answers, we rather rated the candidates willingness to ask for help when stuck, how well they communicated while doing the task, whether they tried different approaches, their ability to grasp what an unknown piece of code was doing and so on... all important properties for a role supporting mission critical solutions with near to zero down-time requirements.
Our reasoning was that technical knowledge is easy to acquire over time, but problem solving skills, how candidates tackle difficult and unknown challanges were more important for the role.
In my current role I try to design interview questions like that, looking both for the candidates current skills as well as their future potential.
Not easy, but IMHO more rewarding for us and them in the long run.
I agree and I don't fully understand the why of it.
I remember coding PL/SQL to emmit HTML in Oracle around 1999 or 2000 and using functions to code the various elements.
That got old and repetitive very quickly - for instance, everytime I had to correct a spelling error, I had to recompile the code.
To get around it I used one or two tables to hold html snippets to decouple the business/backend logic from the frontend, and stopped using the PL/SQL functions completely.
My speed of developmet skyrocketed, and separating and abstracting the frontend from the backend made so much sense.
A few years later, I was doing web developemt with Python using the Zope framework (not many people know about it tiday, I think).
It uses a specialised serverside templating language called TAL (Template Attribute Language)[1] that basically builds the front end dynamically, and then you feed it data from the backend.
Very neat and allowed me to build reusable compoments as well as collections of a schema definition (basically a dict), html template(s) and the code to validate that the input matched the schema and could be rendered.
Or something like that - its been 2 employers and almost 20 years since I worked with that :)
I did build a small extension for Wordpress using a PHP implementation[2] of TAL a few years ago, and TAL still works like a charm :)
My point is that I still believe there is value in keeping python out of the html-templating, and in keeping the front end logic apart from the backend logic.
There is something I am not understanding about the renewal of mixing HTML/GUI template with code, but I haven't fully found it yet.
To produce HTML one would use a variety of PL/SQL functions, one function for each HTML tag that was available at the time.
The result was that each time I had to correct a spelling error, or change a portion of the page, I had find in the code where the change was to be applied, change the code, recompile the package, and then restart the service to have the changes come into effect.
Combine it with the fact that the code written was always much more verbose that writing straigth HTML, it got really old, really fast.
In the end, I created a micro-CMS where I put the HTML code as snippets in the database that I then combined in PL/SQL to form a page that could be served to a browser.
Changes appeared on the fly as I updated the HTML snippets, and the service had no downtime due to restarts.
Not long after, we moved to using Zope to develop more advaced solutions, but thats another story.
Now, this was a long time and 2 jobs ago :), but I am curious as to why in 2025, one would prefer to go to return these types of solutions.