Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yeokhengmeng.com

Post reply on HN
Print view View original

161–170 of 248 posts

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

#161

Post by BubRoss »

rvanmil wrote: post #148
BubRoss wrote: post #137

Earlier quoted context omitted.

You are being downvoted because the idea that electron is the only way to get cross platform GUIs is absurd and comes from inexperience and a lack of research. FLTK, Juce and Qt are just some of the options for creating cross platform UIs that end up being much smaller and MUCH faster than electron. Electron is popular because people learn javascript and don't want to learn C++. I can't completely fault this mentalit…

> toy programs > false sweeping statements OK.

I think misunderstood what I said - I can understand not learning C++ for toy programs, but at some point making thousands of users use an electron program is pretty silly.

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

#162

Post by laurent123456 »

BubRoss wrote: post #137
rvanmil wrote: post #127

Earlier quoted context omitted.

It was more or less a rethorical question (I guess that’s why I’m being downvoted), because there is no competitor. If there was, then Electron wouldn’t be so extremely popular in the first place, and we’d see a lot more popular apps made with all the tools mentioned in the other replies to my post.

You are being downvoted because the idea that electron is the only way to get cross platform GUIs is absurd and comes from inexperience and a lack of research. FLTK, Juce and Qt are just some of the options for creating cross platform UIs that end up being much smaller and MUCH faster than electron. Electron is popular because people learn javascript and don't want to learn C++. I can't completely fault this mentalit…

It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy.

The truth is, everybody knows about Qt, GTK and so on, and everybody knows Electron is heavy but you have to be realistic. As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, or do you go for the solution which, while not ideal, allows you to develop a cross platform app in a much shorter time?

These days many people run Electron apps without even knowing it, showing that it's an ok solution.

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

#163

Post by tjpnz »

Snetry wrote: post #151
harshitaneja wrote: post #149

Earlier quoted context omitted.

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.

Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected

>Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution

They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.

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

#164

Post by itronitron »

rvanmil wrote: post #127
itronitron wrote: post #69

Earlier quoted context omitted.

What are your criteria for something being an Electron competitor?

It was more or less a rethorical question (I guess that’s why I’m being downvoted), because there is no competitor. If there was, then Electron wouldn’t be so extremely popular in the first place, and we’d see a lot more popular apps made with all the tools mentioned in the other replies to my post.

Thanks, I'm assuming there is some core application capability that people are getting from Electron. In terms of 'write once run anywhere' Java has that covered but doesn't offer a means to spec UIs with HTML/CSS, so if that is the deal killer then it would be nice if Java added that capability for applications.

Edit >> looks like JavaFX WebView is a thing now, plus the jxbrowser embeds chromium in a Java App... not sure of the performance of either of these implementations

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

#165

Post by artificial »

archi42 wrote: post #125
scarface74 wrote: post #118

Earlier quoted context omitted.

Yes, because Slack is one man shop that can’t afford to hire one or two Windows, Mac, and Linux developers.

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.

Here’s a free lightweight native Mac client (with dark mode oooOooo) https://www.sblack.online/

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

#166

Post by nottorp »

fortran77 wrote: post #154
bluedino wrote: post #143

Earlier quoted context omitted.

MSDN was a gold standard in the 90's. Now you have tragedies like social.technet.com

The low quality of the technet "answers" are mind-boggling. Why doesn't Microsoft pull the plug on this? Also, what's the purpose of the people who will answer nearly any question with a very low-quality (but wordy) answer? What are they getting from this effort?

There must be some reputation game there.

You see it on SO too, people answering basic questions 2 seconds after they're postedd with long pastes from documentation that are sorta related to the original question.

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

#167

Post by theandrewbailey »

> Also, we can’t write our code directly on the Windows 2000 VM as it has limited software support for modern IDEs like Visual Studio Code not to mention security issues.

I'm guessing that Visual C++ 1.52 has no code editing capabilities like Visual Studio?

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

#168

Post by bawolff »

shakna wrote: post #156
cesarb wrote: post #103

Earlier quoted context omitted.

From what I recall of that era, it's the exact opposite: invalid elements (like ) are simply ignored, and their contents shown. That's how works: newer browsers which understand JavaScript know the element and ignore its contents; older browsers which do not understand JavaScript don't know the element so its contents are shown. The same trick is used for : browsers like Netscape which understand frames don't show th…

XHTML came after HTML 4.0, so it had its advent around the rise of JavaScript's popularity. However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me. From RFC 1866: > markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization.…

If that was true, why did tags have that horrible hack where the contents started with <!-- to hide from old browsers?

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

#169

Post by yeokm1 »

ufmace wrote: 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.

If someone has got a working TLS 1.2 on such an old OS, I'll like to know too. Because I certainly haven't saw any example.

I think the work to get TLS 1.2 working will certainly dwarf the work on this Slack app.

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

#170

Post by shakna »

bawolff wrote: post #168
shakna wrote: post #156

Earlier quoted context omitted.

XHTML came after HTML 4.0, so it had its advent around the rise of JavaScript's popularity. However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me. From RFC 1866: > markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization.…

If that was true, why did tags have that horrible hack where the contents started with <!-- to hide from old browsers?

Note that in the example code I gave the enclosing tag vanished, but the internal tags did not. That's why.
Post reply on HN