Why would you not want a toolkit that makes rich application experiences across multiple platforms easy and standard?
I get that performance is a problem with the tooling in its current form (arguably...) but that's not a reason to ignore the problem electron is solving: creating complex UIs using things like WinForms, QT, GTK, Cocoa, etc SUCKS.
It requires learning vendor specific toolchains, different builds for different platforms, and an incredible amount of wasted time that could be spent developing your business logic instead.
I get that Electron brings benefits: it's dirt-easy to build something that'll run on Windows, MacOS, and Linux, without having to know a bunch of platform-specific details, and if you already have a webapp, you can leverage a lot of that work, but in the end it just feels to me like people cutting corners. You get a sub-standard app, but you don't have to pay developers to build for each platform plus the web. Which I think is a perfectly reasonable business trade off to make; I'm just not happy with the result as a user.
Animations are an important tool for showing transitions between states.
Pasquale D'Silva has a bunch of good blog posts explaining how they can help an interface:
- https://medium.com/@pasql/transitional-interfaces-926eb80d64...
- https://medium.com/elepath-exports/spatial-interfaces-886bcc...
Apart from being resource hogs Electron apps are usually delightful. And usability (for non programmers!) is what for a large part decides the value of your app. You want users to use your program, right? What they see is the UI. Making it easy to develop good UIs is important for a GUI tool (obviously!).
I think that this depends on your background. Personally, I would rather do a UI in QT than Javascript. I like that Qt supports high level components such as trees:
https://doc.qt.io/qt-5/qtwidgets-itemviews-simpletreemodel-example.html
It annoys me when people say something sucks without taking the time to understand it.
That is only true in the sense that your Python 2.x experience didn't translate into your Python 3.x experience. That is, I think the overlap is similar on a language level. The difference lies in the libs/frameworks.
Even jQuery is still helpful if you think of how it's accessing the DOM rather than just a set of magic functions to make things happen.
If you know Javascript you can learn Angular or React or Vue fairly quickly.
For the purpose of this discussion — carrying learned knowledge forward — it was minor.
Obsolete does not mean you cannot use your knowledge anymore. It means that community are shifting interested into new thing, maybe for better or for worse.
In this case, I do not think stick with JQuery or old framework for 5 years is productive for programming. If that happen to any community I would say that is a downside, not an upside.
Except for that fact that community and newly graduated junior developer are ahead of me in something. I can live with that
This has nothing to do with Javascript. It's much easier to do complicated UI using a web browser's layout engine than it is using one of the above frameworks. For really simple stuff, yes it's about the same, maybe even easier with native UI, but if you ever need to do something outside of buttons and lists, things will get ugly fast. On a browser on the other hand, you can very quickly implement any component you can think of using well-documented CSS rules.
Because way more often than not the "rich" stuff are all fluff with no meat, end up taking wasting system resources and work badly with the rest of the system.
Accessibility is another big one.
† The flip side is if you use the same app on different operating systems often. There are some apps that fall into that category for me personally, but I think your average user probably only uses two operating systems regularly: one on their mobile device(s) and another on their "real" computer(s).
Ignoring the snark, "Modern" is better should not be the default, either. Performance is a valid reason to ignore Electron.
The Slack desktop app is the prime example for how bad Electron apps are. Its literally notorious for it.
Seriously, open the desktop app, then open the web app. They're identical. Precisely because they chose to use a toolkit that let them easily handle cross platform issues with UI in a sane and repeatable manner.
Yes. So why would I run essentially a second web browser instance to run the same code in a different place?
Beyond that, I had with weird screen refresh issues with the desktop app, where scrolling or even just typing in the text box would cause parts of the main HTML view to just disappear to the point where it'd be unusable. Often images wouldn't load, or would load, but then have the same disappearing issue. Restarting or refreshing the UI wouldn't help. I'd have to restart the app every couple days anyway due to ballooning memory usage. Hell, even the font rendering was weird and didn't match what I'd see by opening a regular Chrome window. I reported the issues to Slack, but never heard back, and after waiting through several releases for a fix, over a period of months, I gave up.
> ... let them use a toolkit that let them easily handle cross platform issues with UI in a sane and repeatable manner.
That's not what I want. I want apps that fit in with my desktop, not apps that look the same across OSes, ignoring platform idioms and style/placement standards.
I installed the Netflix chrome app on my Windows PC. It's basically the Netflix webpage on a separate application window that doesn't have tabs or a search bar.
https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
A single Gitter tab uses 20MB RAM. I'm sure it would use at least 250MB for the same functionality if I used the electron version.
This is such an obvious problem. Why haven't they fixed it already by trimming down the web browser?
Now that Desktop apps compete with web apps those toolkit’s are falling short. They are falling short in ease of development, cross compatibility, lack of trained developers (relative to web), and lack of good looking UIs and UI patterns.
I have developed some larger Qt applications and in each case there are at most a couple dozen of lines with platform-specific code. Qt abstracts away most of the platform differences.
For me ‘good looking UIs and UI patterns’ means: well integrated in the platform and accessible. Electron apps fail miserably in both departments.
Delphi/Qt Designer look way worse than any HTML/CSS/JS GUI builder, too - along with having interfaces equivalent to what GIMP's is to Photoshop.
I have a feeling that you do not have any actual experience with Qt Designer or RAD tools? Designing a user interface quickly is many times easier in Qt, Delphi, etc. than in HTML/CSS. It start with the basic fact that Qt has many useful widgets that are not available in plain HTML, nor many CSS/Javascript frameworks. From there it is just drag and drop, adding a few spacers here and there and you are done.
Plus, with HTML/CSS, you can work manually on your project, without any special tool besides your browser,
Why would I develop in such an arcane manner if I already have great development tools for more than two decades?
Again, I recommend anyone who only has HTML/CSS experience to look beyond their bubble. We had RAD tools with Delphi 1.0 in 1995, where you could build a user interface using drag and drop and associate code with event by simply double clicking a widget in the interface builder. I built GUI applications in Delphi as a 13-year old because it was trivial, even without an internet connection, StackOverflow, etc.
Not only did it take something like two orders of magnitude more man-hours to develop, but it takes users twice as long to get anything done, too.
I have a fair bit, albeit less than the average user of said programs, of experience with Qt Designer and, admittedly to a lesser extent, Delphi. They're infinitely more complicated than, say, Adobe Muse. Muse has plenty of widgets, too; even if it's not 1:1 on pure quantity. BlueGriffon is quite nice, too.
Why would I develop in such an arcane manner if I already have great development tools for more than two decades?
Modern web browsers* have more or less functional IDEs within their devtools.
*Except Firefox, of which has devtools half a mile behind most other browsers, at least in my opinion.
Of course, I'm speaking from the point of view of someone who's a much worse programmer than designer.
I can understand the cross-platform angle, but not ease of development (unless you are limiting yourself to the very, well, limiting subset of interactions and controls that are easy to do in HTML). Nor, for that matter, the quality of the end-product.
Don't get me wrong, I love native applications—but saying that they're easier to develop than something in HTML/CSS is, generally speaking, not true.
Granted, I'm far worse of a programmer than a designer, so I might be missing out on what's good about Delphi because of it.
For a designer, yes, I can see your point -- it's easy to use markup to make something that looks good (or at least this month's fashion for web pages good) quickly. It's when you want to add any kind of sophisticated behavior and non-standard UI (i.e. exactly why you would want to have a desktop app instead of just using a browser in the first place) where even old Delphi would be far superior. And the result would actually look like a native app, too.
Discord's a highly admirable, semi-complicated web application, that extremely benefits by not looking native, in my opinion. The interface of it is miles ahead of any native desktop VOIP/Text client I know of, and I don't think it'd have been done without Electron.
Of course, I'll agree that generally nothing more complicated than that should be anything but native.
Discord seems to be a nice app (never used it, though) but it has the exact same generic look of, say, Microsoft Teams (another Electron app). Nice, but I would not say that it has any better interface than even classic Skype. Much better than the new monstrosity that is Skype 8, but then Skype 87 also drops proper native interface.
Of course you can get native application to look like nothing else quite easily, but by default they at least agree with the host OS conventions, which is a good thing IMHO.
Also, the Discord interface looks entirely different than Microsoft Teams.
Microsoft Teams: https://www.windowscentral.com/sites/wpcentral.com/files/sty...
Discord: https://support.discordapp.com/hc/en-us/article_attachments/...
Discord also allows advanced users to theme it with ease, which is another good thing about it.
Now, just double-checked a few apps (Firefox, mIRC, Visual Studio) between Windows 7 and latest insider buld of Windows 10. They look exactly the same. Office? Looks the same, too. Can you reference some app that does look different between them?
Still not seeing any sinificanmt difference between Teams and Discord either. From left to right: - Narrow column with icons - Wider column with list of somethings - Even wider colunm with another list - Less wide column with more icons and text.
Seriously, if you swap icons between the two, would you be even able to tell the difference? Sure, some content in some of those colunms is different -- these are different apps, after all, but saying that one interface looks entrirely different seems to me to be an exaggeration. From a designers' POV maybe, colors re different, and icons are in slightly different locations. From a users view, they are basically identical. For that matter, Slack seems to look exactly the same, too. At least based on what they show on their site. Except, of course, that being an Electron app and not following even what little Windows has for UI standards, they have to start the description form saying that to find settings you need to go a Workspace menu. Which, of course, doesn't look like a menu to begin with.
Honestly, I do not see how this is an improvement. Cheaper for the manufacturer, sure.
Can you please provide an example of such tool?
Doing UI development since Windows 3.x days, and I am yet to find such a tool for HTML/CSS/JS development.
Oh and in the process it would be nice to know about a least one comparable component library for such tool.
import sys
from PyQt5.QtWidgets import QApplication, QWidget
if __name__ == '__main__':
app = QApplication(sys.argv)
w = QWidget()
w.setWindowTitle('Hello, world!')
w.show()
With PyQt, he needs to download and install PyQt. When ready to ship, he needs to figure out how to build it into an app that can be delivered to clients.
With web technologies, he knows how to get deliver code in ways it can be loaded in a web browser, and how he can deliver code to end users.
Though to use that web code with Electron, he needs to download and install electron and figure out how to build it into an app that can be delivered to clients.
The web has a lot of great advantages for sure, but native applications have advantages and can do things that are unwieldy and inefficient via the web.
i'm just trying to act as if people do when i suggest them learn new programming languages :) or any things which they aren't used to for that matter.
{ "name": "helloworld", "main": "index.html" }
And index.html is just whatever HTML web page you want, like "<html><herd><title>Hello World</title></herd><body>Hello World</body></html>". You could also use a javascript file as your "main" file if you want.
Even when you screw up the HTML it will still load, which won't happen if you get your underscores wrong in your example.
Edit: removed erroneous formatting
And this is why we have the wasteland of browser incompatibility that we're (still!) in. If something is wrong, it shoudn't work. Why are our standards so low that mistyping "head" as "herd" is considered something that heuristics should fix, rather than causing an error?
I mean, really, though, any decent IDE should flag that error for you in-line, anyway.
> Edit: removed erroneous formatting
This is beautiful!
You don't need to override ::paint because the authors of the class already included support for rich text.
Javascript is "libraries" the language, for better or worse. You're comparing a language which is the de-facto language of front-end design and increasingly popular on the back-end to UI toolkits that have been around forever and still have virtually no mindshare by comparison.
HTML and javascript are the time and energy wise choice for any sort of front end design. It's just that we have shit like electron that is beyond suboptimal at tackling the issue of "native" applications (although I'd argue still a sensible choice!). Ideally we have something like react-native for the desktop, or built in html/js runtimes with platform specific bindings.
Furthermore, most people do not care about this, and the value of marketing with a sleek design vastly outweighs any benefit of conforming to system components UI.
If literally every Electron app fixed memory issues and correctly placed OK/Cancel dialog buttons, I'd be fine with it for the rest of my life - and I write native code for a living. ;P
No, they aren't.
"MacOS UI consistency is a mess."
Not really. Most small developer programs I use follow these. It makes it really easy to know what to do to accomplish something.
"Furthermore, most people do not care about this"
[Citation Needed]. I think most people would prefer to not have to learn a new UI from scratch everytime they want to use a different app.
"and the value of marketing with a sleek design vastly outweighs any benefit of conforming to system components UI."
What is this "value"? How does that help me accomplish my tasks?
"If literally every Electron app fixed memory issues and correctly placed OK/Cancel dialog buttons, I'd be fine with it for the rest of my life"
You mean, if every Electron app stopped being Electron?
I'm not going to bother listing out the litany of odd UI issues present in macOS, because you can Google it and find this within a few seconds. It comes up every. single. macOS. release.
Nobody cares about learning a new UI because most of the tools they use are webapps nowadays anyway, which require this.
The value isn't yours, if that wasn't apparent. For the vast majority of people who use apps with easier to implement design/UI/UX features, it's easier for them to get things done. These apps wouldn't have caught on without that.
And lastly, you've opted to be incredibly pedantic in an attempt to be snarky (I'm guessing, otherwise I've no clue why you'd do this). Electron is more than memory issues and this isn't even a debate.
To be fair, these are different problems from what the grandparent was discussing.
Licensing is a problem a business really shouldn't have: Qt is LGPL and PyQt licenses are cheap even for ramen-eating startups.
Lack of mobile support is a Python problem, I agree there. I can assure you everyone in the Python world is sorely aware of it. Unfortunately, nothing will change until someone does what Google did for Java with Android. But it's a problem that electron apps have too, because "html apps" are still pretty bad on mobile (and terrible on desktop).
Similarly, packaging a PyQt app is not much more of a problem than packaging any app that is not among the "blessed" mobile languages (Java/Kotlin and Objective-C/Swift).
I don't want a good looking UI, I want to have a fast and _usable_ UI!
This fad in the UI and JS world that absolutely everything has to be "beautiful" needs to go away.
Good looking UI is a major part of user experience.
https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/
Your eye will probably be more attracted by the good design of the electron website.
I'm not saying an app should be only good looking, but it's clearly a major part.
[1] http://ixd.prattsi.org/2015/04/response-time-is-speed-the-ul...
It drives engineers batty, because it's often irrational.
Just because something is irrational doesn't mean it doesn't have a huge impact on something like adoption.
If we didn't care how things looked, we might all be wearing google glass.
Edit: the snark... removed.
There are ways around that. For example, DOtherSide is a C library to bind to QML, and binary releases for Windows and Linux are made available on the GitHub page, so in principal you could try out QML without needing to directly use a C/C++ compiler:
https://github.com/filcuc/DOtherSide
There are also a few other languages with QML bindings, such as Rust (the Rust binding is based on DOtherSide):
https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-g...
You'll need to dip into clang or whatnot for really hardcore perf either way
I still develop 100% in QWidgets, which probably makes me a dinosaur but at least I know what I'm getting out of it.
Meanwhile, there have never been anything but Single Page Applications in the native world.
And sure, Qt is now more than 20 years old, it's from a time strongly rooted in "widget" based UI systems that have somewhat fallen out of favor. That is what QML is for, which similarly to WPF that started this trend, allows for GPU accelerated vector composition of anything you could ever want, with sane provided defaults so not every project is reinventing grids.
What Electron apps are good examples of ones that look very good? Slack and VS Code both look fairly bland, and Spotify is a bit of an over-energetic mess, at the moment.
It's ironic that people bang the drum about REST and decoupling... and then at the first hint of actual serious frontend/backend decoupling, everyone runs for the hills.
[1] http://doc.qt.io/archives/qt-4.8/richtext-html-subset.html