Live data from Hacker News

I'm done making desktop applications (2009)

kalzumeus.com

61–70 of 88 posts

Re: I'm done making desktop applications (2009)

#61
post #32

Earlier quoted context omitted.

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…

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 th…

>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.

Re: I'm done making desktop applications (2009)

#62

Every time I take a stab at a web gui app, I’m daunted. The toolkits, the apparently billions of dependencies, the vastly complicated build processes. I tried again recently. HTML file and a separate JS file. Some SVG elements with a click handler. I had mouse in and mouse out logic, and that worked great. But for some reason the click handler did not. I tried it in Safari, Chrome, and Firefox. It worked in Firefox.…

> The toolkits, the apparently billions of dependencies, the vastly complicated build processes... Except instead of a 50 line experiment, it’s a gazillion lines of God knows what 87 levels removed from whatever code I actually wrote.

Instead start with pure HTML, SVG, CSS and JavaScript. Use MDN for documentation. Pick one browser to develop on (any one will do).

Why? Most importantly you are learning how the low level browser code works, and you are building your own taste about using the core languages. Just like learning machine code helps with your C++ development.

You don't need build processes unless you are developing commercially. The frameworks provide opinionated APIs, but they are often too abstract and are providing complex enterprisey features.

There is not that much difference between browsers now. And jQuery is bollocks (it was mostly golden for adding code to HTML pages that were served from a back end).

If you want to get a webdev job then maybe do some thinking on what framework and tools you want on your resume, and learn that framework/tooling after you have mastered non-framework browser development. But my guess is that webdev is likely not a good fit if you like engineering your software.

My experience is now outdated, but I wrote my own framework which morphed over time as we supported other browsers and newer versions of browsers. I started my career on embedded software, so perhaps I am more cynical than most! My framework was far better engineered than most (for the reliability we needed). Other frameworks delivered on other goals that were not aligned with our needs.

It is a very frustrating road writing pages for browsers because everything feels arbitrary and you have very little control over the engineering and you are at the mercy of browser quirks: you are often forced to come up with shitty expedient solutions that work if you are dong commercial work, and I very rarely felt clean. There is no beauty to web development: it is dirty work that I would try and do the best I could to achieve the outcomes we needed. Compromising constantly...

Re: I'm done making desktop applications (2009)

#63

Now that websites can use the File System Access API to load and save files, the Desktop is "solved" for me. Everybody can use my software simply by opening the url in their browser. The new challenge is phones. Mobile browsers do not support the File System Access API. What is a solution to this? Is there a reputable service that converts a web page into an Android/iOS app so that it can load and save files?

>The new challenge is phones. Mobile browsers do not support the File System Access API.

Phones are an old challenge for now. Their OS is made upfront to coerce the user in having their data dealt by someone or something else out of the phone, somewhere through an Internet connection.

Re: I'm done making desktop applications (2009)

#64
post #56
post #52

Earlier quoted context omitted.

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…

> 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 enou…

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

Re: I'm done making desktop applications (2009)

#65

Earlier quoted context omitted.

File system access API is a chromium feature.

File System API is a baseline feature supported across all major vendors. https://developer.mozilla.org/en-US/docs/Web/API/File_System...

Ya, it's odd to say it's not on other browsers when they all have it just to variable degrees... it's almost as if there are comment bots here that are trained on outdated data ;)

Re: I'm done making desktop applications (2009)

#66
post #64
post #56

Earlier quoted context omitted.

> 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 enou…

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 orig…

>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.

Re: I'm done making desktop applications (2009)

#67
post #66
post #64

Earlier quoted context omitted.

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 orig…

> 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 e…

I don't think it's possible to end this debate unless one of you finally names an example. Please provide a screenshot or at least a name of an UI/application from before 2000 that's not braindead easy to implement with pure html/trivial css and simple click handlers.

If you can provide one, I'll yield to your point. Otherwise you're just high on nostalgia and comparing today's complexities caused by a vastly bigger scope to yesteryears simple realities, where multi-platform, i18n, animations, dynamic rerendering, etc pretty much wasn't a thing... entirely

If you remove all these features, you end with a simple html file with inline css. And that's easier then it was in the 90s.

Re: I'm done making desktop applications (2009)

#68

Every time I take a stab at a web gui app, I’m daunted. The toolkits, the apparently billions of dependencies, the vastly complicated build processes. I tried again recently. HTML file and a separate JS file. Some SVG elements with a click handler. I had mouse in and mouse out logic, and that worked great. But for some reason the click handler did not. I tried it in Safari, Chrome, and Firefox. It worked in Firefox.…

It hurts, but it's not supposed to. The web stack is now pure hell, almost completely devoid of what makes programming software enjoyable in the same way as making furniture or machining a tool, which it used to be and still is in places. The web ecosystem has raced to the bottom with the goal of enabling less and less talented/experienced developers to be productive. That goal is good, but the changes didn't have to be so bad - however, the nature of the web means that it's almost completely nonviable to make large breaking changes to the foundations, which are they kinds of changes that actually improve things and benefit everybody. So instead we build up layers. It's so disappointing considering what it could have been like.

Re: I'm done making desktop applications (2009)

#69
post #67
post #66

Earlier quoted context omitted.

> 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 e…

I don't think it's possible to end this debate unless one of you finally names an example. Please provide a screenshot or at least a name of an UI/application from before 2000 that's not braindead easy to implement with pure html/trivial css and simple click handlers. If you can provide one, I'll yield to your point. Otherwise you're just high on nostalgia and comparing today's complexities caused by a vastly bigger…

>Please provide a screenshot or at least a name of an UI/application from before 2000 that's not braindead easy to implement with pure html/trivial css and simple click handlers.

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?

Re: I'm done making desktop applications (2009)

#70
post #62

Every time I take a stab at a web gui app, I’m daunted. The toolkits, the apparently billions of dependencies, the vastly complicated build processes. I tried again recently. HTML file and a separate JS file. Some SVG elements with a click handler. I had mouse in and mouse out logic, and that worked great. But for some reason the click handler did not. I tried it in Safari, Chrome, and Firefox. It worked in Firefox.…

> The toolkits, the apparently billions of dependencies, the vastly complicated build processes... Except instead of a 50 line experiment, it’s a gazillion lines of God knows what 87 levels removed from whatever code I actually wrote. Instead start with pure HTML, SVG, CSS and JavaScript. Use MDN for documentation. Pick one browser to develop on (any one will do). Why? Most importantly you are learning how the low le…

>There is no beauty to web development

Thanks for this pithy summary. Beauty is the perfect one-word difference between what programming can be and what the web stack is.

Post reply on HN