I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser.
Not only will this be more secure, it'll also be 10s or 100s of times more performant.
Not only will this be more secure, it'll also be 10s or 100s of times more performant.
There have also been plenty of exploits in applications written entirely with native code.
However, to say that browsers are secure is pure nonsense. Browsers get exploited all of the time, I'd argue that this is not as big of an issue as it could be because browser vendors respond to new vulnerabilities very quickly. WebGL, for instance, is still a massive mess in terms of security.
This has lead to some pretty bad hacks. I'm not sure what more you could want really, a vulnerability where people can be punched in the face over the internet?
That sounds like a mild form of swatting, which is already a thing.
For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on.
Yes, it takes some initial effort, but it only needs to be done once.
Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc...
Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept of "files" like iOS or up to recently Android (at least in what is normally exposed to the user)
Roll in various versions of each OS and you are up to needing 10+ ways of doing most things. How are you supposed to create anything even remotely complicated?
Not sure I agree here. There are a great many browser features (e.g. web speech api for recognition and tts, webrtc, etc) that are just not lowest common denominator. Even if we stick with UI only, features like cross platform vector graphics are not trivial. Of course some libs like qt abstract it, but you're back to your same complaint except it's qml, css, and js (or often times worse, c++ if using widgets)
Most of it actually written in Assembly.
Magnitudes easier to shim and support multiple architectures.
It is all about design a good application architecture from the get go.
If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.
Cursors and styluses are accurate, but fingers are not. So, if you make buttons sized for fingers, they feel awkwardly large (takes large hand movements to change between UI components, and the spacing means more scrolling or pages of UI), but if you size them for cursors/styluses, they are frustratingly small targets for touchscreens.
You can probably assume that most devices in portrait orientation are that way so they can be held in one hand leaving the other free to work a touchscreen, so you only need to handle three of the four combinations for a comfortable user experience in those regards.
However, there's more to it than that. Desktop users often run apps windowed, while phones tend to omit that option entirely. Mac puts the menu bar at the screen edge regardless of the window size/position, but other desktop/laptop OSs usually put the menu bar within the window border. You can remove the menu bar entirely and draw a hamburger button into your UI, but desktop users have the expectation of a menu bar and the change in convention will make the app feel like an outsider.
A desktop/laptop user will never try a long press and don't have a menu button, both of which have been used to hide extra functionality on phones, but they often do have a keyboard, and there is a massive list of keyboard shortcuts that they will automatically use. Desktop UIs have a logical tab order and that selection can be moved with the arrow keys. Cut, copy, and paste function as expected. On windows, F2 almost always means "rename selected item", F1 for help, alt-enter to toggle full screen, and so on. What about the multitude of multi-finger phone/tablet gestures? You have two very different modes on input, and users' muscle memory expects your app to fully support whichever one they are using. As an anecdote, I tried writing something in an Electron app's text box, then went for ctrl-left to jump back a word, but instead it caused a page navigation and lost the entire message I was typing. That was a frustrating "this app is an outsider on desktop" experience to me.
Your decision is effectively mediocre everywhere or customized to fit the conventions for each platform.
https://books.google.co.uk/books?id=vPvhzDqZlaAC&pg=PA174&lp... (Spolsky)
See the Office related talks at CppCon 2015 about how to write portable code using what Microsoft calls the hamburger model, as part of their migration to a common codebase.
Basic a shim layer for low level OS APIs, the middle layer with the majority of code and another shim layer for UI APIs.
Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.
It needs to be redone for each platform every few years as apis and visual styles change. Cross platform libraries are notoriously hard and usually end up in the uncanny valley (qt, swing etc).
Platform vendors of course any devs to buy into just one platform, they want and need the lock-in. Using web UI is a way to sidestep that.
Most applications are really crude in their design, and do not target large international hip demographics.
If you didn’t even take the effort to get your interface with your user (read: customer) right, how lazy did you get with the parts of the app I can’t see ?
1) Most users don't actually give a crap about "UX guidelines". I promise.
2) "UX guidelines" are, in my opinion, why our user interfaces continue to suck.
A bad UI is a huge smell. In my experience there is a 1:1 relationship between the quality of the UI and the quality of the software as a whole.
Great idea! Now show me an application that can be extended in the same way Atom can, that didn't have 30-40 development behind it...
You couldn't be further from the truth. Have you seen the Blizzard app (Qt) [0]? The JetBrains Toolbox app(Qt) [1]?
Also, here's a small app I wrote in kotlin and swing for my GF who wanted to download music from youtube without installing crapware downloaders [2]. You'll notice it has a custom window frame, support for drag and drop, and fully customized table and buttons. I spent about 5 hours styling the UI, and half a weekend writing the entire app.
Yes, I agree, dowloading music from youtube is immoral and illegal, but I'm showcasing the UI so please ignore the underlying purpose of the app.
[0] http://l3.yimg.com/ny/api/res/1.2/v.xvnI7eUsLskyHopY6Kkg--/Y...
[1] https://www.jetbrains.com/help/img/idea/2017.2/rm_py_toolbox...
That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs.
Not to mention the irony of complaining about performance, when the promoted alternative is electron...
Well, it wasn't about being "better", it was about not looking like shit.
> The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.
Well, Visual Studio Code used to drain battery life for blinking the cursor in the background. But again, it was never about performance. My original argument was that newer 'native' applications written using Qt or swing can look just as good as web based UIs
What you did say is that Qt or Swing apps looking bad cannot be further from the truth. If that were the case, you should be able to rattle off dozens of beloved, beautiful, complex Qt or Swing apps. Most cross-platform UIs (including those based on Electron) look and behaves poopily. The few that don't are the result of exceptional effort and focus.
Unless someone puts in the extra effort to style the application, nothing will look consistent cross platform.
And if you want "native, consistent, desktop applications" (for the current platform), Qt has that out of the box and Swing had a native look and feel that looked pretty consistent on Windows 7 at least.
To be fair, I did change it a bit later to use Open Sans .
It is neither! Enjoy your music :)
WxWidgets [0], bindings in: Python, Perl, Ruby, Lua, C++, C#, and others.
Qt [1], bindings in: JS, Python, C++, and others. Also has QML to make things easier.
Tk [2], bindings in just about everything. Included in most Python distributions.
Kivy [3], Python only.
Java/FX [4] Java and other JVM languages.
If your main problem is the duplication effort between the web and an application: Qt is the simple path. Qt includes WebKit. Everything Electron can do, Qt can do, but faster and smaller.
[4] https://docs.oracle.com/javafx/2/overview/jfxpub-overview.ht...