I agree. Using Electron on all of these desktop application "frameworks" keeps seeming like throwing a supertanker at a job when someone asked for a tugboat. I feel like this will only continue to bloat so many applications further, and will make writing (and refactoring) GUI applications more difficult.
You'll be sad to known a ton of OS X and Windows applications these days are just running in web views. Heck, even a lot of iOS apps are partially/mostly UIWebViews.
Slack's desktop app is a web view. The iOS app is native.
I think the wells fargo banking app on the phone is not native. The At&t one doesn't feel like it. Usually there's something different about the controls and interactions that make it not feel native. Sometimes there's a dead giveaway like being able to double tap and accidentally zoom in just like in mobile Safari.
Yep! A common pattern is for the navigation to be written in the native language to take advantage of faster/smoother animations and all dynamic content is inside of web views.
Spotify on Linux: clicking on things often feels slightly janky and laggy. How fitting!
And the spacebar will 80% of the time page down rather than pause the music, something which sounds minor but which makes the user experience 50% more annoying for me. Do most people even use spacebar to page down in normal webpages!?
The colloquial definition of a native desktop application is an application that runs from a binary on your system. So yes, most people DO think of these as native applications.
A native app is one you download and execute on your computer. In reality it doesn't matter much what gui toolkit you write it in, there is nearly always going to be some xml and styling involved - GTK is native on Ubuntu (I hope you will grant me that), but programs written in it typically uses glade files to design the gui and load and bind event handlers at runtime. Glade is XML.
.net uses the native win32 gui toolkit - but you typically build it WPF, which is XML, styled with XML.
On mac? plists - which is you guess it XML (I have no idea what, if anything, you style a mac app with).
So basically the three biggest platforms use XML to bind their guis with - and there isn't much difference between XML and HTML. Granted when you design XML for guis it tends to be nicer than if you wrangle HTML into that role but this is a programmer, not a user, issue.
That's a nonsense argument. There's a world of difference between using the platform's native framework and controls (which may be instantiated from an XML file) versus a single WebView which contains the entire app.
Saying "HTML is nearly XML, therefore HTML is native" is akin to saying "Vietnamese is written using the Latin alphabet, hence it's basically the same as English".
The "native" part of native app doesn't mean machine code. It means that it is native to, i.e. feels like it naturally came from, the host operating system. It uses its APIs, conventions, UI components, event queues, etc.
as JayVanguard already pointed out native means another thing. but putting that aside.
You are confusing what HTML and XML are if you think they are similar. XML is a way to encode data, validate it conforms to a schema, query it, etc. HTML is more than the surface syntax. It includes an schema and semantics (the DOM, the CSS OM, the boxing model, etc). Using XML as a declarative layer on top of their UI, as android does, does not make it similar to writing HTML because of the completely different semantics associated with it.
Android takes all the xml layouts and compile them and expose them through the R(esource) class.
I see more than one person on this thread who thinks native means "runs native machine code" and more than one person who thinks it means "looks like it was built with the native GUI library" so the term is ambiguous. Before iOS app store, I think it was more common to mean the former, so it may be related to that.
The browser is native code, the app is compiled to native machine code. There are no virtual machines involved, except the JS VM on the browser (and this doesn't need JS).
Right, when people say native, they talk about connecting directly with the OS-specific UI fundamentals. An application is "native" not by virtue of its execution environment, but by virtue of the UI primitives. That's why people talk about "native look and feel".
