Web interfaces are extremely clunky to use when trying to do things via only-keyboard (which is the only way to have muscle-memory help you zip through forms) methods.

They are slow to update and in some cases, the Web browser's UI is fighting with you, such as offering to replace your input with the previous data you put in a form field of the same name, etc. In certain cases the tab method of navigation between fields gets broken or something else that interrupts the person's flow happens.

Having worked in a case where the ticketing system and related interfaces were half-Web and half-Java-application-on-Windows - even the Java application was better to use via the keyboard.

If you are paying people on a regular basis, whether hourly or per-shift, and the UI slows people down by 5% , what is the cost over the (perhaps) 3 years of that application's life?

Even 4 users at $50k/year each in the USA (with healthcare and other business expenses etc. that means a $20/hour full time job) means $10K/year (5% * 200K salaries) in extra expense.

You surely have noticed how employees speed hack away on the keyboard with those old terminal style TUI apps.

Modern UX is almost all about looking sleek to the procurer, not usable for the end luser.

You can use tab and hotkeys, add hints for auto fill (or just straight disabling them for a page).

Normal UIs are fast enough.

I'm not necessarily advocating for only web but I don't think your arguments holding up with reality

I went through this transition in the late 2000’s, moving grid and form heavy delphi windows screens to webpages, using ExtJS, the only framework at the time which kind of sort of could do this.

The process made me realise two things:

1. if you try to map information-dense UI’s like that to the web, it will cost more to develop and the UX will be worse. (we saw double the dev cost and a slower and more cumbersome ui)

2. in most cases information-dense UI like that is bad design and should be avoided. I couldn’t see it back then how things could be done differently to make screens less dense, but looking back there were plenty of ways.

We do auto-expand a lot of groups, ie for company name and address fields we might just show name and org. number until you enter the company name field, at which point we show with the full name and address set. Once you leave the group it collapses again.

Still, the information-dense UI is what our users like, as far as I can determine. They want to take one look at an order or invoice and get the info they need, not having to flip through several tabs or pages.

Part of this is also driven by gov't requirements. That is, users are officially responsible for the data they submit, so they must be able to see all the data they submit.

Yeah i’ve built single page apps with more input fields than this and grid tables all in a single view. Are you sure this cant be easily done?

Coincidentally that was first 15 years ago with extjs, second time with react 3 years ago - the latter being a slower process but still pretty much doable.

No, I'm no web expert. We've not found a way so far, and I've not seen something like this on the web, but I'd be happy to be proven wrong.

edit: to clarify, I don't doubt one can get 150 fields in a view on the web. But can one dev do it in one day and have it look great?

And I've seen Delphi apps; I recently worked on one. In my experience they don't look great. Maybe you've done a lot of work to theme the controls; if so, wonderful. But what I'm familiar with just brought up Windows dialogs, and ... well, that's functional but I wouldn't say it looks great.

But here are a few examples of ways you could create 150 fields in a day on a web app and have them look great:

Arrays of control types: https://formik.org/docs/examples/field-arrays for simplicity of creating the controls plus something like https://chakra-ui.com/docs/components/input to make them pretty.

Spreadsheet look (with spreadsheet functionality!) in one control: https://www.npmjs.com/package/react-spreadsheet

Want to build the form by hand and customize it? https://www.form.io/

Form should follow a database schema and automatically display database records? https://marmelab.com/react-admin/ (I used this approach to bring up an admin panel for more than 150 fields, though spread over a couple dozen pages, because of course that looks better than trying to bring up 150 fields on one page.)

The standard way to create a large form (or any data table on a page) today is to iterate over the fields you want and add them to a page. There are frameworks like Chakra that can help you make everything look attractive--and you can theme the result in whatever color scheme or styles you like.

I really don't want to have to touch Delphi ever again; it felt like I'd fallen back into the 1990s in code development terms, and I missed all of the modern features I'd grown accustomed to. If it's what you like, and it pays the bills, then enjoy. But know that people who have used more recent tools like myself consider it to be anachronistic.

But that doesn't mean I want to work on it.

Simple is beautiful.

> And it's a utility that really doesn't need to look fancy, so it's fine for what it is.

"Fancy" sucks.

> It doesn't seem to have a dark theme, which is a bummer, but otherwise it does the job.

"Dark theme" is moronic: Having your app use only standard Windows controls meant it automatically used whatever "theme" the user had set Windows-wide, so it always adapted to their preferences. No per-application "dark theme" or "purple theme" needed.

Until Microsoft themselves sabotaged all that, starting late in the lifespan of Windows 7. Assholes.

Delphi has almost none, while most tech I have seen on web has a lot of it.

Edit: However, my challenge is on wether it can be done or not. Delphi is cool, and tbh any tool you are an expert in will let you do something quicker than a tool thats new for you. It will probably take me a while to achieve the same goal in delphi.

Win32 is bedrock, the web is quicksand. Look at "HTTPS everywhere" and "you don't need FTP any more", which did little in terms of actual security, but broke almost everything in some small way.

The web doesn't value legacy. It's a petulant 22 year old, that thinks it knows everything, and does stuff deliberately against the advice of those with more experience.

Is the web as stable as Win32? No, of course it's not. But a page with 150 inputs isn't anything that requires cutting-edge web technologies. It'll work just as well today as it'll work in 5 years.

Sticking a bunch of inputs in a HTML page is indeed not complex, but it has to look decent (labels and corresponding inputs line up vertically etc) and be functional (ie with sensible tab order etc).

To get a sense of what we've got in Delphi, here's a demo video[1] illustrating making a simple input box. This is a "entry level" demo, but it's representative (though we don't use the runtime customization).

I'd really appreciate input on something which could allow us similar decent looking UI with similar effort on the web.

Like, note how "Last Name" lines up with "Product ID" below, even though they're in different groups. Things like that.

[1]: https://www.youtube.com/watch?v=PiKmYwB__YE

How do you handle the transition at 2:04 where "Last Name" is moved from its own row to sharing a row with "First Name"? Keep in mind I might want to add a third element in that row afterwards.

IIRC with tables you'd have to modify the column spans of all the other rows which is way too much effort. How does it work with the CSS grid layout?

This is pretty simple with CSS grid -- literally takes a couple of seconds. I am a fan of Delphi, and used it myself in the late 90s, but I think you just might just give it more credit due to familiarity.

There are benefits to a web-app these days, due to the onerous requirements and demands of different operating systems and platforms.

Fair enough. I've tried searching for these things but it's very hard to find good resources. So far I've not found a way to do this with similar ease, but from this thread it seems it might be possible after all.

Some concrete examples or resources would be much appreciated.

> There are benefits to a web-app these days

Sure, I definitely see the positive sides of a web application, especially for our smaller customers.

Ok. I am not sure of your current front-end experience level, so I will give pointers as if you are not experienced with CSS grid, forgive me if this is incorrect.

The key CSS items in this case would be:

display: grid;

... which will allow for CSS grid layout, and then for the particular item you discussed, the following two CSS values would do the trick.

grid-template-areas .... for the layout container itself in a pseudo-visual way, and grid-area for the items to be laid out.

Here[1] is a simple example, but if you are a visual-type person would get the idea across.

[1]https://developer.mozilla.org/en-US/docs/Web/CSS/grid-templa...

The demo at the top of the page is interactive and you can see how easy it is to move around items. Of course these items would already be styled themselves to maintain label positioning and alignment so simply moving the letters in the grid-template-areas value would be sufficient to completely change the layout.

This does not let you drag and drop as in your demo, but it is equally fast and gives instant visual feedback in the browser.

As a side note, I morn daily the continuing loss of desktop applications, which is where I cut my teeth in development. But the explosion of platforms and continued aggression from OS manufactures in the name of "safety" is basically forcing the hands of people to move to web apps. I agree that, in general, they are not as snappy or as light-weight as a well-designed desktop application (a "real" one, not an electron app), but if you know what you are doing you can get close and get all the benefits that do come with web apps.

And, from someone that has done both desktop and web app development, web apps can be laid out very quickly if you have experience. I almost can not think of a single-page (non-animated) application that I can't layout in a single day. This is especially true if you are using an existing UI framework or you have built-up one of your own over time. The time-consuming parts tend to be testing on multiple platforms/screen-sizes for compatibility (iOS being the worst) and the business logic.

Let me know if that is not the type of info you were looking for, and I will be happy to point you in a direction to get the info you are looking for.

Will definitely take another stab using this. I'm assuming the grids compose, so I can work on one group (say name-address set) and it'll be well behaved when added into a larger layout grid.

The WYSIWYG drag and drop is nice, but if the results are predictable enough a manual "edit-and-run" cycle should suffice.

> Of course these items would already be styled themselves to maintain label positioning and alignment

So I guess this is the only thing I'd still be struggling with. Concretely, consider a grid layout like this:

    a b
    c c
    d e

I'll have to see if it's easier with the grid layout.

Yes. That will work as expected.

>Here the labels and inputs in a and d, as well as b and e, should automatically line up vertically, including if say b's label changes due to a dynamic event.

This is where not rolling your own UI elements are faster. They will have been tested and any serious problems would have been addressed. But, even if you do roll your own, you can expect to be able to line up labels and fields both vertically and horizontally, even if the labels dynamically change (although watch for line wrapping if that is a possibility).

But, generally, your idea would work. I typically use flexbox unless I have a reason to use grid. For example if the entire flow of a page design changes between desktop and mobile, I normally use grid or if I need things consistently centered both vertically and horizontally, I use grid.

For laying out form UI elements, there are tons of examples that you can easily find online to fit the look and feel you are looking for.

If you have not settled on a stack yet, Svelte and Solid will offer the snappiness you are used to with desktop apps (due to no duplicate/virtual DOM). The drawback being that plugin elements are more readily available for more popular frameworks like React, however imho the plugins for Svelte or Solid tend to be better written.

I'm... not sure this is true. There are plenty of ways of designing non-trivial UIs on the web.

I'm kind of curious now.

Delphi claims you can "Build Native Apps 5x Faster With One Codebase For Windows, Android, iOS, macOS, and Linux" the biggest corollary I can think of there is Election, and we all know how we feel about Electron apps here.

We've yet to receive a HiDPI bug report, but we do get reports when we forget some customers still run 800x600 screens...