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.
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.
> 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).
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
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.
If you can provide one, I'll yield to your point. Otherwise you're just high on nostalgia
I'm not sure what exactly you think "UI/applications from before 2000" looked like and were.
You do know that, e.g. Word, Excel, Photoshop, Logic, WinAmp, Paint, Framemaker, 3ds Max, Final Draft, Lotus Domino/Agenda, Visio, QuickBooks, Cinema 4D, Encarta, Dreamweaver, ACDSee, Real Player, Outlook, AIM, ICQ, FL Studio, Maya, WinRar, WinZip, InDesign, Quark Xpress, Cubase, and countless others, commercial and freeware, including full featured KDE and Gnome DEs were made before 2000, right?
the UI back then were fucking trivial, youre deluding yourself if you think anything else.
Lets go through your first examples one-by-one, as the theme continues i will stop at some point.
* Word: literally just 1 menu/text, 2 rows of icons. And a range picker. you can do that within ~15 minutes even as a beginner.
https://winworldpc.com/res/img/screenshots/97-98-11f3805bab5...
* Excel: same as word, with the addition of a grid in the body. the challenge is in chaining together the cells. trivial as hell -- as long as you ignore the application/domain logic, which would've been just as complicated back then. https://winworldpc.com/res/img/screenshots/57db2161e19c9e95d...
* slightly challenging for someone that hasn't encountered flex. extremely easy -- albeit time consuming just because of the quantity of buttons. still doable within <1h. https://www.webdesignmuseum.org/uploaded/old-software/graphi...
* logic: once again, the challenge is in the domain. the UI itself is just buttons in rows. trivially done by simple flex rows. https://www.muzines.co.uk/images_mag/articles/mt/MT_93_04_no...
* winamp 2.5: once again, trivial to do. creating this UI -- without the domain logic of actually playing the music etc behind it -- can be done within <1h. https://preterhuman.net/software/wp-content/uploads/2018/08/...
It goes on and on. Every single example youre citing is just rows and rows of icons. Thats extremely easy to implement with pure html and trivial css.
give any of these UIs to an experienced frontend dev and they'll provide you with a click dummy within 15 minutes to 3hours, depending on the quantity of elements on it.
I'd be pointless, precisely because nobody cares about such trivial UIs anymore... But hey, whatever floats your boat, right?
And everything I wrote here is ignoring the fact that every one of your example was the opposite of easy back in the 90s. They were developed by whole teams over years to get to that point. And duplicating this with html5 is trivial, that itself should tell you how much easier it's gotten if you just don't chase the hippest tech that's fotm right now
oooh, i see. you edited it out of your initial comment back then and i didn't notice.
I guess you realized how dumb that statement was and couldn't man up to it.
> Developers like you and I are a dying breed. We remember writing applications for operating systems that had straightforward APIs, and OS developers that worked hard to ensure any app which used those APIs would not break.
> Most "full-stack" developers I know that write web apps have literally never written a line of C++ in their life, let alone written a rich text editor using an object oriented desktop GUI API.
> They don't know it's not supposed to hurt.
HN doesn't allow editing comments outside of a very short edit window.
• Tree view controls
• Table views, with draggable, resizable and sortable headers
• Image list views
• Menu bars (something HTML will probably never have!)
• Context menus
• Embeddable file explorer views
• A rich text editor control that wasn't plagued with weird formatting and cursor movement bugs
• Embeddable Word/Excel/PowerPoint if you needed more than that
• Date/time pickers (something HTML didn't get until 2014 and I never see any real app use it)
• A calendar widget
• Tab views
• Toolbars
• Wizards/task dialogs
There's some docs here: https://learn.microsoft.com/en-us/windows/win32/controls/ind...
To get these many of these on the web you need to import large third party frameworks, because HTML5 doesn't offer them out of the box. So apps are all very inconsistent.
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.
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.
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