Live data from Hacker News

Building a new Windows 3.1 app in 2019: A Slack Client

yeokhengmeng.com

211–220 of 248 posts

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#211

Earlier quoted context omitted.

> It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy. I don't think I said all that > As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, This I think is a big assumption. Making a GUI isn't really that difficult. Most of the time in a program doesn't go into making the actual UI. I never hear some…

> I don't think I said all that Kind of: "inexperience", "lack of research", "don't want to learn C++" > Making a GUI isn't really that difficult. Also a big assumption, especially for cross-platform GUIs.

If you don't know the difference between "inexperience and a lack of research" and "ignorant, incompetent and lazy" then I don't know what to tell you. It seems like you are hallucinating some sort of persecution.

It is not a big assumption, I've done it many times. What is it that you think electron gives you that cross platform GUIs don't have? Making the actual UI is usually pretty trivial, it isn't even logic, just data through function calls.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#212
post #40
post #10

Reading this article and others by the same author on his travails of getting Windows 3.11 to install and then bridging it to modern(-ish) tech was like being transported back to the 90s when I was first learning about computers. Seeing those screenshots of the unmistakable Win 3.1-style dialogs was a real nostalgia hit. What a treat. 10 points (well, an upvote, I guess) for anyone who knows why the Windows DOS-mode…

Are you asking why it’s F3 as opposed to some other key? Because that would be from the IBM CUA standard: https://en.wikipedia.org/wiki/IBM_Common_User_Access .

Yep, that's what I was thinking of. F5 for refresh is another artifact from that time.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#213

Earlier quoted context omitted.

It isn't like Qt is some bizarre arcane wizardry. You give a web developer a few days and they can productively be contributing to a Qt app.

Yeah but then the dev has to investigate how to solve certain patterns in Qt's ways which they already know how to solve in the web frameworks, and just like with natural languages, sometimes there are no straightforward ports for concepts, and it requires a ton of extra work that you couldn't foresee until getting halfway through the whole project. Adopting new tech is not without serious costs and risks. Also, no G…

Sorry, but if the way forward really is that every desktop application of the future has to ship with a full copy of Chrome, come with all the bloat and baggage of the web platform and continue its questionable UI conventions - all just because companies are too cheap to offer some training - then I really don't see how that is a desirable future.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#214
post #140

Earlier quoted context omitted.

His point is that this bare bones get/post app in Electron will be much, much "larger".

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron.

In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration.

If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#215
post #160

After the first few paragraphs, I was most eager to see how he managed to handle modern TLS on Win3.1. Last time I wrangled with vintage stuff near that timeframe, that was the toughest part. Alas, he "cheated" for it with a proxy app. Can't say I blame him, since it's probably about as much work over again to get modern TLS 1.2 working on such an old Windows.

IMHO the fact that it's hard to get TLS 1.2 (or indeed any form of "pure" cryptography) working at all on an obscure platform says a lot about the state of commonly available crypto libraries --- as those who are against regulating it like to say, it's "just math"; and math that any computer should theoretically be able to do. OpenSSL is one of the more portable ones, yet I'm not sure how it would be able to handle the 64K segmented model. It would need at least 32KB (maximum TLS record size, multiplied by both directions) and a little bit more per TLS connection. That said, a 2048-bit RSA key is "only" 256 bytes, and ECDH ones are smaller, so I think a TLS 1.2 (or even 1.3) implementation on the platform is definitely in the area of "feasible, but not trivial". A lot of IoT stuff has similar constraints (minus the segmented addressing).

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#216
post #44

Earlier quoted context omitted.

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

Before Electron people had the arguments about bloated apps when it came to WPF and Qt. And Java apps, like WPF (and most Qt apps I’ve used lately) lacks true integration with native OS widgets so as a user I get an uncanny-valley feeling. At least with Electron you’re essentially forced to style everything - and ever since Windows 8 (or Windows Vista) Microsoft has been actively uglifying native widgets.

I did consider Java as I was writing it, but at the same time Java is actually pretty fast, but there is no doubt that it doesn't use native components most of the time (there is a gnome toolkit bindings for Java, so it is possible).

Still Java feels speedy, I think because it is compiled and doesn't need wacked workarounds like not having non-floating point numbers.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#217
post #44

Earlier quoted context omitted.

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries. Designers by the dozens would be hired, then get fed up with these limitations and quit, complaining that they wanted to have the freedom to make UIs in HTML and CSS, and that users are used to interacting with Web UIs so everything should look like…

Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries.

That's funny, because it's exactly the type of job I'd love doing --- and I have been working on stuff like that (native code, mostly Win32, with some hardware/drivers/embedded stuff) for a long time; if you haven't guessed already, I try to stay very far away from the web stuff, even though I know HTML/CSS/JS and can use it if needed.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#218
post #44

Earlier quoted context omitted.

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries. Designers by the dozens would be hired, then get fed up with these limitations and quit, complaining that they wanted to have the freedom to make UIs in HTML and CSS, and that users are used to interacting with Web UIs so everything should look like…

I mean I am not a fan of C++ (though I don't hate it either), and I love how easy and well libraries for e.g Python works together and how easy they are to find and install, but I don't think it is necessary to go all the way to native code -- Java/Kotlin on the JVM performs pretty well (and you can always outsource the heavy parts to C).

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#220
post #128

Earlier quoted context omitted.

Actually, s/Slack/Tidal/ if you want to add insult to injury. Electron app for Windows and Mac (but well, nice features overall). However, no Linux build.

Slack does have (very-long-time-beta) Linux build[0], though I personally prefer to just use Slack through my browser instead of suffering through an Electron app. [0] https://slack.com/downloads/linux

The web version work also well in Firefox, so you don't need to give all your RAM.

Slack calls don't work reliably in Chrome/Electron on linux anyway, so no loss here.

Post reply on HN