It blows my mind.. really it does, how did we not fix this shitshow? We have automated test on top of automated test on top of automated tests but web is so messed up we still can't have shit working reliably.
It blows my mind.. really it does, how did we not fix this shitshow? We have automated test on top of automated test on top of automated tests but web is so messed up we still can't have shit working reliably.
How many are
a) highly nontrivial with hundreds of windows/screens, many with with multiple searchable grids, custom lookups, per-screen user-definable tab-stop order etc etc
b) reliable enough that the users can enter all the data they need without looking at the application (ie no missed keypresses or focus changes etc)
c) being developed, maintained and operated by a team of <10 devs?
Honest question, if you know then do tell! I'd love to hear how they're doing it.
Like, this year changes to gov't systems means we'll have to implement about a dozen new complex windows/screens, along with all the backend logic. We get the specs about 6-9 months before go-live, so it's not like we have a full year either.
I'm also using a language from the 90s, but one even more niche than Delhi. We have desktop systems, and Web systems, and while they share a lot of source code, the UI procedures are different.
The Ide is still maintained an updated, but of course falls well behind visual studio now.
So for you to switch to this makes even less sense than staying on Delphi. We're under similar pressures to "rewrite in something more modern" but fortunately (for us) the business doesn't have the pockets that sort of project would consume.
Technically there's little reason to change, Functionally the language let's us program anything we want, so apart from the perceived "long term security" of rebuilding from scratch in c# there's not much upside.
For what it's worth we've built the system mostly with 1 developer, although on occasion as many as 3. The primary developer has changed once, and that was a smooth process so it can be done again if necessary.
I write all this to encourage you. If what you have is the best option, then stick with it, swapping bits out slowly as you need to. Make a transition organic, not one giant project. Code is just code. Customers don't care about the language, they don't care about the code, they only care about the solution to their pain.
I have my job because I love technology.
There is joy and fun in using modern systems.
Good tooling like ide, security tools, linting, Testing Frameworks etc requires modern supported languages.
Languages evolve.
I've been doing this a while, and I've been around the IDE bush, and the editor Bush and so on lots of times.
There are many disadvantages to using things that will never be popular, that are niche, but lack of joy is not one of them.
For me it's not in some shiny new language, or toolset, or whatever. The joy is in what you create, not the tooling. It's in creating solutions that make people's lives better. It's in putting good on the family table. It's in employing others and watch them do the same.
The things you talk about are language agnostic. What doesn't exist, we create.
I completely disagree.
I also don't enjoy creating systems which calculate car payment or a registration flow.
By "web" you mean "professional standards". There's no excuse for not being able to put out something that doesn't result in a blank page in Safari. The Web has not gotten more difficult to publish for. It's not an SDK that forces you to rev your codebase from time to time if you want things to keep working*; the stuff that worked last year and 10 years before that would still work today. The developers chose to make these changes, and the client chose to accept it.
* barring some pathological circumstances like previously having decided to depend on undefined/non-standard behavior, but that's (a) gonna be a problem anywhere and not unique to the Web, and (b) not remotely essential for publishing working stuff that you want to show up in a Web browser