Creating a native Windows app to mimic the Electron Slack client would not be a trivial task.
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?
As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.
Huh? Okay, maybe Swing doesn't support native-looking widgets (I have less experience with it), but I can personally attest that Qt and Tk (or more precisely Ttk) apps nowadays use a platform-native look-and-feel on Windows, macOS, and Linux alike, by default (i.e. with zero effort on the part of the app developer). It might not be absolutely pixel perfect, but it's way closer than an Electron app.
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
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.
"But I already know Javascript, it's too hard to figure out something else"
It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.
Later, at a different job, the UI was Electron based, but designers no longer worked in HTML, they used some other tools and it had become the job of engineers to write the HTML and CSS to match.
These trends seem to be driven partly by conventional wisdom about the lowest common denominator among young people in the workforce, e.g. javascript and html are so much easier, let's build everything on those, and next thing you know those have become a given and the next crop of kids will use something new on top of that. Or maybe something like QT will win and native code will become a first class citizen again with secondary support inside browsers via WebAssembly?
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.
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.
Still Java feels speedy, I think because it is compiled and doesn't need wacked workarounds like not having non-floating point numbers.
Update: ah, Microsoft released their own port in 1997: https://www.cnet.com/news/ie-gets-java-for-windows-3-1/ - I wonder how long they maintained that for.
which is funny when you see that Qt runs on microcontrollers now.
Even at an absolute worst case it still beats the pants off Slack.
An earlier blog post shows this http://yeokhengmeng.com/2016/09/windows-for-workgroups-3-11-...
Wikipedia says "However, no single process can use more than 16 MB.". Not sure where is the source of that though.
It’s a limitation from the 286 Protected Mode.
You don't call the raspi an SoC, and it's debatable that you'd call a prototyping platform like Arduino an MCU. The MCU is the main Atmel AVR, Microchip PIC, or similar part that drives such a board.
If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No one needs to be convinced that a native Slack client for each platform would be much better, I wish they would build those clients. The problem is most companies can’t reasonably justify the costs of building multiple native clients when a single cross platform one is good enough.
Lazarus can use the Windows API on Windows, gtk/qt on Linux, and carbon/cocoa on Mac.
There is also a custom drawn mode that draws the GUI directly rather than using platform apis. That also runs on Android, but it not maintained anymore, so only up to Android 5 or something
Delphi is supposed to run on Android and iOS.
And Delphi 1 ran on Windows 3.1, so you could have used the same GUI since then
Shhh! Ixnay on the Lazarusay. If people find out, I'll lose my magical secret weapon for blasting out little windows gui apps.
Seriously though, if you ever find yourself needing a few buttons on a windows desktop that do simple things, Lazarus is amazing for whipping that up in a few minutes and still looking professional.
Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019.
> GTK+ can be programmed in Vala
Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can easily cost weeks to fix.
Have you seen the state of Javascript 'ecosystem' and job market?? Both statements are false.
The real reason is that C++ toolkits don't have platform and device independence. HTML and CSS are really good and powerful design tools, especially compared to composing raw pixels like you'd (essentially) be forced to do with Qt and GTK.
Let me correct: GTK+ is not C++, it's C. Qt is very cross-platform: it supports about 10 platforms, including Linux, Windows, and macOS. You are not doing anything close to compositing raw pixels in Qt or GTK+. They have layout managers that are specifically made for typical application UIs, and they have lots of ready-made widgets. Qt also has QML, which is a declarative UI descriptions language kind of like HTML/CSS but much more productive because (gasp) it's actually designed from the ground up for applications, not websites.
Which one would you recommend?
Cross-platform story is complicated, though. I have good experience creating a custom GUI framework for embedded Linux: drm/kms, gles, NanoVG, [DllImport], everything on top is custom C# code in .NET core 2.2. But that approach is not for everyone. I only needed 10-15 screens with simple GUI on them, it’s a 5” touchscreen with no other user-facing devices. Creating more advanced UX this way would consume too much time.
There’re Avalonia and Xamarin. Didn’t used them at that time because I needed full-screen GUI for a single-application Linux, without any desktop environments or user mode OS components. For desktops and especially mobile apps they might work OK.
It’s unpopular opinion here, but I think Electron is not that bad for GUI, esp. when writing TypeScript instead of JS. I think it’s similar story to Unity3D or PHP: low entry barrier attracted inexperienced programmers, then the whole ecosystem is judged based on the output of these inexperienced people.
Qt, as well as Windows, macOS and Linux actually can do Android [0] and iOS [1], and Web is halfway there [2].
[0] https://doc.qt.io/qt-5/android.html
You know all of the arguments against Electron that people trot out about how it's not real native, and it doesn't follow the right UX conventions or paradigms? Qt on the web is exactly like Electron on native, except way worse and without any sign that it's going to improve, because fundamentally Qt is structured around the idea that it should be able to spit out a binary blob of pixels instead of hooking into web-native primitives like the DOM.
Look into something that's showing more promise, like .NET and Razor. The Rust community is also doing some good work here, although I don't know that they have any UI frameworks that are mature enough to be reliable in an enterprise setting.
These aren't true cross-platform efforts yet, since they're still forcing you to think about HTML. But if I was going to bet on any project ending up with a real cross-platform solution that felt good on the web, some kind of export option from an Open Source Windows Forms or similar is probably what I would bet on. Either Microsoft or (possibly) the Rust community are the two parties that I think are most likely to end up producing a true native UI toolkit that can actually export to the web in a usable, acceptable way.
[0] http://www.beeware.org [1] https://dan.yeaw.me/posts/gui-widget-for-beeware/
[0] https://github.com/otya128/winevdm
It would have been relatively straightforward for Microsoft to support 16-bit on 64-bit, but they decided not to. I can't help but feel that that is just more evidence that whoever is running Windows development these days hates everything that used to make it a good desktop.
Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64. They figured, rightly, that by the time x64 became widespread, 16-bit would be obsolete.
Don't believe I said otherwise.
> This has nothing to do with "whoever is running Windows development these days"
> Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64.
These two statements are at odds. Microsoft used to take compatibility extremely seriously. It would have been relatively trivial to allow 16-bit applications to run, and obviously there is desire to do so since WineVDM exists, they just arbitrarily decided not to.
I suspect this is because they've become infected with developers who use Linux a lot and think nothing of breaking compatibility every release, let alone in cases like this.
It didn't exactly run 16-bit installers. https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27...
> Write your apps in Python and release them on iOS, Android, Windows, MacOS, Linux, Web, and tvOS using rich, native user interfaces. Multiple apps, one codebase, with a fully native user experience on every platform.
I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.
I'm still trying to figure out if there's a GUI that supports different text with mixed colors and features out of the box, and that's not horribly broken in OS X
I was actually thinking of giving it a go, but the idea of a Python backend and a Delphi frontend is as attractive as recoding everything in ASM.
Slack calls don't work reliably in Chrome/Electron on linux anyway, so no loss here.
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
That's the biggest lie ever, with these newfangled "cross-platform" solutions.
I want to watch the guy who has to sit down and port electron to a platform it doesn't run on yet. It's just a few lines of code, right?
Java had the same problem, everyone who ran Linux in early 2000s remembers. It's still not something I would want to port, but at least it runs on more systems ootb than electron.
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.
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 someone who is experienced in making UIs say that electron saves them so much time, it is always people assuming it takes an army of C++ people to do what one person can do with electron, which is bizarre, especially over the course of something that is more than a prototype.
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.
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.
> false sweeping statements
OK.
In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-)
More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality. I'm a long-time Win32 programmer who started in the tail-end of the Win16 days and one of the things I've wanted to write if I had the time and need was a Win32 native Slack client, to show that it can be done with far less resources, but you've gone even further with Win16. Win32 has native TLS support (via SChannel library, not well-documented but examples exist) and you'd be able to even use it practically (32-bit applications will run on all current versions of Windows, both 32 and 64-bit.)
Note that C89 only prevents declarations of variables in the middle of a scope; you can simply create an inner scope with new variable declarations at its start. Like so...
Another small tip: if you make it a dialog-based application, you won't have to bother with WM_PAINT and drawing text yourself --- you can just make the "statusText" and "settingsText" edit controls, and use SetWindowText (or SetDlgItemText) to set their content. They will paint themselves automatically just like the listboxes that you used for the chat contents and userlist. At least you'll save some of those 676 bytes that way...