Hi Nathan,



Glad to hear that you are still successful with your solution. Seems to be the right way for your business. 👍



But most users/developers here don't have these requirements, thousands of concurrent users. My guess would be that most have some hundred users in total but not concurrent. So you need to find the right solution for yourself. Something that gives you the features you need but is also easily maintainable. And that solution is different for everyone here.



At my site here we have only a small dev team so our focus is more on maintainability. The main language in the backend is Java ( for every new development). The batch execution time with Java is noticeable longer compared to RPG but we don't have any problems as they are still more than ok for us.



So everyone must decide for themselves which shoe fits.



My 2 cents in this exciting new year.



Mihael












Am 01.01.2025 um 06:10, Nathan Andelin <nandelin@xxxxxxxxx> schrieb:


My company develops information systems for public schools, districts, and
state offices of education, which run natively on IBM i. We've managed to
gain a niche in a market that is dominated by multi-million dollar and in
some cases multi-billion dollar publicly traded software companies. In
order to gain a foothold in the market, our applications have had to exceed
our competition in terms of user interface, functionality, performance,
cost, and stability. Otherwise, you just don't get to introduce new
applications into such a mature market. The competition is too fierce.

There are a lot of comments in this thread that provide good insights.
However, I would steer clear of all of the "tooling" mentioned here if
you're interested in deploying broadly scoped business applications that
might need to scale to tens of thousands, or hundreds of thousands of
concurrent users.

Angular is an interesting paradigm, in that the entry-point into your
applications is a single static HTML page, which after the page is
downloaded from the server, the framework makes asynchronous call-backs to
the server to fetch HTML fragments known as templates and fetch JSON data,
which is then merged with the HTML templates to update the user interface,
and by creating new DOM objects dynamically. I personally couldn't stand
using Angular because the Model-View-Controller paradigm implemented in the
framework is profoundly geeky to the point that you lose touch with
reality. Also, the idea of a client-side framework that manages locally
stored datasets and locally stored UI components is unnecessary for IBM i
developers.

Angular was created to shift more workloads to the client, to avoid the
bloated, inefficient, unscalable server interfaces that plague most server
platforms other than native IBM i interfaces. It's just a fact that
mainstream server platforms are bloated, inefficient, and poorly scaling,
relative to native IBM i interfaces. They require something like 20-100
times more compute resources to handle HTTP requests than native IBM i
interfaces. Our application interfaces handle more workload on a single IBM
i server than our competition can handle on server farms of 20+ servers.

My advice would be to meet with someone who is successfully developing
business systems on IBM i, and find out how they're doing it.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.