3 ms·

I wish they were a dying breed, but no, you're not. You're just looking at the past with extremely rose tinted glasses. It's way,way easier to implement a UI

by ffsm8 2y ago

I wish they were a dying breed, but no, you're not. You're just looking at the past with extremely rose tinted glasses. It's way,way easier to implement a UI like in the 90s with hmtl5. You're just trying to make a modern UI with all it's bells in whistles and now complain how complicated it is. The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s

coldtea 2y ago
>You're just looking at the past with extremely rose tinted glasses Dude, some of us still write 90s style code, even Delphi style stuff (FreePascal and Lazarus), and can still compare it everyday to modern web dev. It was better without any "rose tinted glasses" needed. Same for 00s C#/.NET or even "classic" Visual Basic - dead easy to make even an elaborate UI going. >It's way,way easier to implement a UI like in the 90s with hmtl5. No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that. >The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s Not even close to being right. Most web apps including Electron apps are dead simple and primitive functionality wise compared to the 90s (including not having all the functionality one got for free via integration with the OS), but their codebases and dev platforms are still over-engineered and haphazardly-engineered monstrocities. And then there's the resource consumption.
- ffsm8 2y ago
  You're putting words into my mouth I didn't say: The "modern web stack" has an incredibly high ceiling wrt how complicated it can be. It's floor isn't particularly complicated however, and definitely not higher then the equivalent software with the native APIs from the 90s. You had buttons, inputs, text boxes. Pre-2k UI APIs were extremely limited. Did we even have hover in windows 95/98 or MacOS 9.0? The first time I've seen that was more towards 2010 then 2000 - windows XP/Vista and MacOSX, but it's been a long time since then > No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that. Please provide an example then. I sure as hell can't think of one and googling didn't provide me with anything but that.
  - ale42 2y ago
    > Did we even have hover in windows 95/98? Hover how? Changing the appearance of a control when the mouse passes over it? Or having a tooltip appearing? Both can definitely be implemented quite easily. For the tooltip, I just checked on Delphi 2 (which I was using on Win95 ages ago) and it had the Hint and ShowHint properties (as the current VCL/LCL). > Pre-2k UI APIs were extremely limited. But that was largely enough for most GUIs. Nowadays people are putting a full browser (Electron) to create an interface with a few buttons and a progress bar. I'm thinking of an actual application, a relatively famous SD card writing program which weighs something like 200 MB. Make it with native GUI controls and it takes 50 kB (maybe even less) and will not eat the RAM and CPU of the users. Moreover, people are doing fancy GUIs, with the result that no two application look the same, totally confusing some users (Windows itself is a mess, since Windows 8).
    - ffsm8 2y ago
      The tooltip hover is equivalent with the title attribute in hmtl5, so that once again as trivial as you can get. The original comment made it sound like they wanted something else to happen. The resource inefficency is a completely different argument. That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false. Completely off topic, but... If you're on windows , use Rufus instead if balena etcher. And if you're on Linux/MacOS... dd works great, just make an alias with tab completion for devices/image
      - coldtea 2y ago
        >That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false. That's like your opinion, man. First, it's not the invidual APIs themselves, it's several layers of APIs, and combinations thereof. In traditional desktop UIs you just placed widgets together in a form/panel, hooked events, and wrote your application - normally all in the same language and with a single bundle of APIs from your lib (e.g. the Delphi API, the QT API, MS's API). In web dev (I do both), it's an endless layer upon layer of cruft. Even just the browser UI base layer alone has HTML, CSS, JS, the DOM, SVG, Web Components and shadow DOMs, and several other items besides. Then there are the differences and incompatibilities between engines, between desktop and mobile, and so on. Then there's the pre-processing of all those, JS (or typescript), bundlers stuff like Webpack, minimization and map files, then there are Frameworks like Next/React/Angular/Vue, and different varieties. We haven't even touched the backend of those, written in the same (Node) or different languages, and with its own layers added.
adastra22 2y ago
I right rich/native applications right now, using OS-provided APIs. It's a little bit of a pain point because I've chosen to transition to writing in Rust, and the Rust interfaces always have some friction. But the native APIs themselves? Smooth as butter and a joy to work with. It ain't complicated at all.
kaba0 2y ago
Well, the web (most common frameworks) doesn’t really have drag’n’drop UI editors. Writing complex widgets for the web had a long list of issues for a long time and only recently became feasible without hacks (they couldn’t be reasonably encapsulated from the rest of the website before shadow DOMs, and better js encapsulation). As an example, there is no standard, no-one-gets-fired-for choosing complex table widget that can sort, filter, paginate, re-order, etc its rows/columns. Many of them fall just shy of a prod-ready implementation.
foul 2y ago
>The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s It was (it still is) SHIT (there are technically valid reasons), but being shit from moment 1 it was absolutely necessary to create a builder for that. While simple UI in HTML5/js/css is wonderful to make, any user-contribution system (drag and drop builders, editors and what-have-you) is hell to manage and develop, breaks a lot more than you may think, has bold performance issues. The stack is shareware as a service, it's crazy, it's laughable thinking that probably the multi-billion system required for A-grade GPTs is more cost-efficient than living like we are accustomed to in big web development.

by ffsm8 2y ago

coldtea 2y ago

>You're just looking at the past with extremely rose tinted glasses Dude, some of us still write 90s style code, even Delphi style stuff (FreePascal and Lazarus), and can still compare it everyday to modern web dev. It was better without any "rose tinted glasses" needed. Same for 00s C#/.NET or even "classic" Visual Basic - dead easy to make even an elaborate UI going. >It's way,way easier to implement a UI like in the 90s with hmtl5. No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that. >The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s Not even close to being right. Most web apps including Electron apps are dead simple and primitive functionality wise compared to the 90s (including not having all the functionality one got for free via integration with the OS), but their codebases and dev platforms are still over-engineered and haphazardly-engineered monstrocities. And then there's the resource consumption.

ffsm8 2y ago
You're putting words into my mouth I didn't say: The "modern web stack" has an incredibly high ceiling wrt how complicated it can be. It's floor isn't particularly complicated however, and definitely not higher then the equivalent software with the native APIs from the 90s. You had buttons, inputs, text boxes. Pre-2k UI APIs were extremely limited. Did we even have hover in windows 95/98 or MacOS 9.0? The first time I've seen that was more towards 2010 then 2000 - windows XP/Vista and MacOSX, but it's been a long time since then > No, it really is not. What you're describing is some simple form, as if 90s UIs were constrained to that. Please provide an example then. I sure as hell can't think of one and googling didn't provide me with anything but that.
- ale42 2y ago
  > Did we even have hover in windows 95/98? Hover how? Changing the appearance of a control when the mouse passes over it? Or having a tooltip appearing? Both can definitely be implemented quite easily. For the tooltip, I just checked on Delphi 2 (which I was using on Win95 ages ago) and it had the Hint and ShowHint properties (as the current VCL/LCL). > Pre-2k UI APIs were extremely limited. But that was largely enough for most GUIs. Nowadays people are putting a full browser (Electron) to create an interface with a few buttons and a progress bar. I'm thinking of an actual application, a relatively famous SD card writing program which weighs something like 200 MB. Make it with native GUI controls and it takes 50 kB (maybe even less) and will not eat the RAM and CPU of the users. Moreover, people are doing fancy GUIs, with the result that no two application look the same, totally confusing some users (Windows itself is a mess, since Windows 8).
  - ffsm8 2y ago
    The tooltip hover is equivalent with the title attribute in hmtl5, so that once again as trivial as you can get. The original comment made it sound like they wanted something else to happen. The resource inefficency is a completely different argument. That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false. Completely off topic, but... If you're on windows , use Rufus instead if balena etcher. And if you're on Linux/MacOS... dd works great, just make an alias with tab completion for devices/image
    - coldtea 2y ago
      >That's true, but has no bearing on how complicated the APIs supposedly are. Same with the coherence between applications. That's an issue entirely unrelated to the original claim which was just false. That's like your opinion, man. First, it's not the invidual APIs themselves, it's several layers of APIs, and combinations thereof. In traditional desktop UIs you just placed widgets together in a form/panel, hooked events, and wrote your application - normally all in the same language and with a single bundle of APIs from your lib (e.g. the Delphi API, the QT API, MS's API). In web dev (I do both), it's an endless layer upon layer of cruft. Even just the browser UI base layer alone has HTML, CSS, JS, the DOM, SVG, Web Components and shadow DOMs, and several other items besides. Then there are the differences and incompatibilities between engines, between desktop and mobile, and so on. Then there's the pre-processing of all those, JS (or typescript), bundlers stuff like Webpack, minimization and map files, then there are Frameworks like Next/React/Angular/Vue, and different varieties. We haven't even touched the backend of those, written in the same (Node) or different languages, and with its own layers added.

adastra22 2y ago

I right rich/native applications right now, using OS-provided APIs. It's a little bit of a pain point because I've chosen to transition to writing in Rust, and the Rust interfaces always have some friction. But the native APIs themselves? Smooth as butter and a joy to work with. It ain't complicated at all.

kaba0 2y ago

Well, the web (most common frameworks) doesn’t really have drag’n’drop UI editors. Writing complex widgets for the web had a long list of issues for a long time and only recently became feasible without hacks (they couldn’t be reasonably encapsulated from the rest of the website before shadow DOMs, and better js encapsulation). As an example, there is no standard, no-one-gets-fired-for choosing complex table widget that can sort, filter, paginate, re-order, etc its rows/columns. Many of them fall just shy of a prod-ready implementation.

foul 2y ago

>The tech ain't any more complicated. The software you're imagining has a waaaay more complicated UI then what you did in the 90s It was (it still is) SHIT (there are technically valid reasons), but being shit from moment 1 it was absolutely necessary to create a builder for that. While simple UI in HTML5/js/css is wonderful to make, any user-contribution system (drag and drop builders, editors and what-have-you) is hell to manage and develop, breaks a lot more than you may think, has bold performance issues. The stack is shareware as a service, it's crazy, it's laughable thinking that probably the multi-billion system required for A-grade GPTs is more cost-efficient than living like we are accustomed to in big web development.