Cornerstones of modernisation

[Zsirafovics]

First, let's agree on what the goals are.
I assume You agree that the system interface also needs to be modernized, not just the code base.
What do I mean by modernization? We need to remove deprecated parts and make the system HTML5 compliant.

As I wrote, I saw three ways to do this. In the long term and in order to maintain continuous operation, I chose a hybrid solution, which means the following.

• We are creating our own mini-layout system, which is essentially a very detailed CSS file.
• In the .pl files new components are created on div+flex basis, while the old pages remain table-based temporarily.
• In addition, we are gradually migrating the system to HTML5.

If we agree on these basics, I'll split my ideas into individual topics -as possible as- to start discussing about those.

[Tekki]

Answer Part One.

I assume You agree that the system interface also needs to be modernized, not just the code base.

Nothing can be assumed in a discussion about the goals. I would agree to ’it would be nice’, but I don’t see an absolute necessity to change it. Incidentally, the code in the bin/mozilla/ directory is still not on Perl 5.40 level.

To build a new user interface means to rewrite around 300 screens. This costs an estimated 100’000 EUR, 80’000 on your and 20’000 on my side, and creates follow-up costs of at least 5’000 EUR per year. Who will finance this?

What do I mean by modernization? We need to remove deprecated parts and make the system HTML5 compliant.

There is no depreciation in the HTML standard. Some elements like frame are considered to be obsolete, as are some attributes like <td align="…">.

Frames: The discussion about frames being a bad thing started in 1996, immediately after Netscape introduced them. Today in 2026 they are still supported by all browsers and I’m not aware of any plans to remove them (if I’m mistaken, correct me). You can assume that I’m not against a better solution, I’m just not sure about the urgency of this topic.

Tables: I agree that it is a terrible idea to create layouts with tables inside tables inside tables inside tables. There are better ways to do this. If it’s a good idea on the other hand to remove tables from spreadsheet-like reports, that’s another question.

What you don’t mention: The HTML errors that exists on most of the screens, for example elements that are opened and never closed, closed without being opened, elements at places where they don’t belong (like script blocks at the top level).

To summarize: In my opinion, a new user interface is an expensive nice-to-have, in one word a luxury. If we can afford it, no problem for me.

(Next answer will be about the second part of your description.)

[Zsirafovics]

Incidentally, the code in the bin/mozilla/ directory is still not on Perl 5.40 level.

OK. However, if I understand correctly, you launched version 4.x.x in order to continuously comply with Perl 5.40. If there are going to be changes in this regard anyway, why not replace the layout at the same time? The essence of my suggestion is that it doesn't have to be done all at once, but can be done in stages.
Personally, I'm happy to dedicate my time; it's worth it to me.

You are right, I phrased it poorly. Framesets and similar elements are not deprecated, but obsolete, yet they can still cause headaches. I do not trust developers of browsers at all. They can decide at any time to discontinue support for an obsolete feature. Since I run older versions of SQL-Ledger in production environments in several places, I want to avoid any surprises.

What you don’t mention: The HTML errors that exists on most of the screens, for example elements that are opened and never closed, closed without being opened, elements at places where they don’t belong (like script blocks at the top level).

I'm sorry, I don't quite understand what you mean. If you can give me a specific example, I'll take a look. One thing I do know. In the modifications I have made so far, I have paid special attention to ensuring that there are no warning messages even in the log.
And if you are thinking of the menu, I have solved the problem so that when a main menu is open and you click on another main menu, the open one closes.

One more brief thought.
Based on what I've wrote so far, it may seem like I only want to modernise the user interface. That's not the case at all. If I'm going to make changes, they will affect every part of the system.

[Tekki]

Answer Part Two. This is still about your first comment.

As I wrote, I saw three ways to do this.

Your three points in #95 don’t look like an evaluation of alternatives to me, rather like a justification of a predetermined answer. For the following reasons:

Mojolicious and CGI have nothing to do with the design of the user interface. You can compare them with each other, but can’t compare them with Bootstrap. And then, the discussion about CGI in Perl core dates back to 2013 and this module was removed from Perl with version 5.22 in 2015. CGI wasn’t a viable alternative even 10 years ago.

Mojolicious primarily provides an different way to run the application on the server. It’s still a phantastic tool, but considering that its development has stalled somewhere around summer of 2021, at least one alternative should appear on your list.

Our application actually runs on the web server as CGI, we just never used the Perl module with the same name, because it would have been beneath us to do so (more about that later). CGI scripts have some big disadvantages, for example they are executed anew with every request and they don’t run on servers like Nginx. This general question if they are probably not best way to serve content is missing on your list, too. You’re skipping all of that and don’t discuss any of the problems on the server side: that there is no clear distinction between logic and presentation, that we print directly to STDOUT at 2000 places (and need this ugly workaround with the UTF-8 layer), that there is redundant code over and over again — that we problably need a template system to solve this.

It all runs down to the alternative of Bootstrap and building our own framework and it remains unclear why you prefer the latter. Even if you write that «the world and user expectations have changed», you don’t ask if today’s users still want an application that works with form requests and HTML responses and updates the whole page after every interaction. Maybe they expect screens that refresh at different places in parallel, support autocomplete, live preview and similar things, who knows? For that, we would have to delegate the presentation to the client and use a framework like React, Angular or Vue.js. So that’s another question that should be addressed.

In the long term and in order to maintain continuous operation, I chose a hybrid solution,

If with hybrid solution you mean that you want to update the user interface step by step, I disagree. The old interface has to be available until the new one is finished, maybe even longer. Nothing worse for the user than an inconsistent experience. Take the ribbons in LibreOffice as an example. And there will be users who will never want to change to the new UI. As in LibreOffice, again.

• We are creating our own mini-layout system, which is essentially a very detailed CSS file.
• In the .pl files new components are created on div+flex basis, while the old pages remain table-based temporarily.
• In addition, we are gradually migrating the system to HTML5.

You don’t rewrite 300 screens with a miniature system. And you will need JavaScript in addition to CSS rather sooner than later. Don’t be fooled by a case study with just one screen, because it doesn’t scale. Did you notice by the way in what amount the lines of code increase with your updates? This is bad news for an attempt to improve the software.

First and foremost, this idea of «creating our own» is wrong and was wrong from the beginning. We don’t use CGI, but build our own Form.pm with its 100 limitations. That it can’t even process selects with a multiple attribute is just one of them. We don’t use a template system to create the PDF files, but build our own. Unfortunately it’s not even able to nest loops and conditionals. We don’t use Text::CSV, but build our own parser, a parser that can’t read valid CSV files as soon as their structure is not on the absolutely basic level. We don’t even use Perl core modules like Scalar::Util or List::Util, because we are more intelligent than the rest of the world. — This approach is the source of a big part of the problems with this software and we will not continue in this direction.

Returning to the user interface: We are neither better qualified nor do we have more capacity than the 1500 contributors to Bootstrap. Or to speak about CSS only: We are not even superior to the 44 contributors to SimpleCSS (the stylesheet I use in the HTML documentation). To build a new user interface isn’t just about using some fancy new HTML and CSS elements, it’s for example about accessibility too — a topic that, at least me, I know almost nothing about.

If we agree on these basics…

For the moment obviously we don’t. If later we agree to change the user interface, the next step will be to create an overall concept with milestones and a schedule. And still not to change the code.

(Answer to your second comment follows.)

[Zsirafovics]

I understand what you wrote, and I mostly agree with it.
You are right about CGI, and I would also like to move beyond it.
But I was looking for a simple, quick solution where the system could be used continuously while introducing the modernised parts. That is why I decided to keep CGI and convert it to HTML5 compliant.

However, based on what you wrote, I looked into the issue more thoroughly and came up with the following possible solution (outline):

• Strangler Fig Pattern - rolling development, where legacy and new code run in parallel
• PSGI/Plack base
• Mojolicious framework + Tailwind.css + Alpine.js, but decoupling the business logic from the framework (If Mojolicious is "dead" in X years, only the routing layer needs to be replaced.)
• Full CI/CD pipeline - with GitHub Actions, Docker build/deploy
• Phase-by-phase schedule

This is, of course, true if Perl remains in use.

Just a quick note about Mojolicious.
It is actively maintained. Last commit: December 9, 2025 (in the main mojo repo). Active development is ongoing - visible commit activity in 2024-2025

[Tekki]

Personally, I'm happy to dedicate my time; it's worth it to me.

You don’t answer the main question. If we take my estimation (that of course is 30 % too low, as always in IT) and you’re updating 10 screens per month, you’re going to complete work worth 2700 EUR and send me an additional 670 EUR to review your pull requests each and every month for the next two and a half years. Regardless of whether the moon is waxing or waning.

I do not trust developers of browsers at all. They can decide at any time to discontinue …

That’s a funny argument. If you are that suspicious, how can you trust the developers of the Apache webserver that they are not going to drop the support for Perl CGI, or the Perl developers that they don’t drop the whole language? And if I were to think that way, how could I trust an anonymous person that arrives here and claims, without ever having published any software, to be able to finance and complete a multi-year project? Fortunately I’m not like that and everyone gets his chance.

… looking for a simple, quick solution … That is why I decided …

I’m the one who makes the decisions here.

However, based on what you wrote, I looked into the issue more thoroughly

No. In these few hours between my comment and your reactions to it you haven’t been looking ’thoroughly’ into anything. You’ve just asked some AI or whatever for general ideas about the modernization of a Perl application. And then you posted the answer here without relation to the prior discussion. Besides that, you should have been familiar with the items on your list from the very beginning, before even starting to think about updating the user interface. With the items themselves, not with the words that name them.

I suggest that you take a break of one week from discussion and use this time to think about why you came here, if you’re serious about becoming a contributor to this project, if you’re willing to accept its rules and if you’re able to follow instructions. Then report back with your conclusions.

[Zsirafovics]

First, let's clarify how I got here:
I have been operating SQL-Ledger for several clients since 2006. Unfortunately, we are still stuck on version 2.x. Over the years, we have made a lot of custom developments to it. These include solutions that meet the special requirements of the Hungarian tax authorities.
I have been thinking about changing versions for years and looking for the possibilities. Finally, I made a decision to start customization based on Dieter's version. Unfortunately, he suddenly passed away. It looked like the person who took over the rights would continue the project, but in the end, the whole thing came to a standstill. That's when we decided to use the version you created as a starting point.

I will not respond to every comments, only briefly to a few.

Who will finance this?

Of course, we are financing the work we do out of our own pockets, and we are making it available to the public free of charge. In this case, the plan was to upload it to your repository.
I have already referred to this earlier:
#95 (comment)
"However, since I am using the version You created as a basis and I greatly appreciate what You have created, I thought it would be right to share it with You directly."

I’m the one who makes the decisions here.

I accept that you have the final say regarding this repository. However, if you are truly open to others contributing, then the least you can do is publish your ideas and expectations on the project page. If I had seen any indication of this, I would have acted accordingly. Because it's not even clear to me whether you want to keep CGI or change it while staying within the Perl ecosystem?

No. In these few hours between my comment and your reactions to it you haven’t been looking ’thoroughly’ into anything.

This implementation was conceived some time ago on our side, but we haven't started on it yet. But it seemed that CGI would remain for the time being, so I sent my contribution based on that.

...if you’re serious about becoming a contributor to this project...

As I wrote above, it is not clear to me what the goals are and what exactly the expectations are regarding contributions. (If this is due to my inattention, I apologize.)
However, I need to be clear about these things in order to make my decision.

[Tekki]

Thanks for your feedback.

When something is not clear, it’s generally better to ask questions than to make assumptions.

The goal of this project is to continue the work of Dieter and to publish a reliable open source ERP system that can be used throughout the next decades.

This software is published under GPL3. You can download it for free and do with it everything this license allows. But there are two things you can’t expect: First, that all your private code changes are going to be added to this repo. The contribution process is described in the documentation and can be considered to be rather restrictive. Second, that me or anyone else on my side is going to do free work for other companies. This includes the testing and merging of new code.

The next step in version 4 is planned to be a modification of the data model to improve the accuracy of certain numbers, especially around transactions with foreign currencies.

In principle, anything that is related to this software can be discussed in an issue. After such discussions, the documentation is regularly extended. The problem is, the longer it gets, the smaller the chances that somebody is reading it.

To the topics mentioned by you:

• New user interface: When I add all together that was said around this idea, I come to the conclusion that I don’t agree with such a project.
• Perl CGI: I rarely use it in new applications, but it’s unrealistic to change it here.
• Perl itself: To use another programming language means to write a new software. This could be an interesting challenge, but here is the wrong place to discuss it.