Goodbye, Native Apps
medium.com
medium.com
>In fact, writing software with C/C++ was hard because developers had to work with different operating system API(Application Programming Interface).
Seriously ? Writing C++ apps is hard because you had to use different APIs ? That's the least problematic part about C++ app development, behind say the fact that your app can segfault when dealing with strings... (and especially pre C++11) or that you could take lunch breaks during builds which kills GUI iteration.
I feel like this doesn't belong on front page and people upvoting this are doing the site a disservice by upvoting based on title alone.
If you did apps in days where C# and Java took over for C++ mobile still wasn't a thing and macos was super niche (especially in enterprise) - few people really cared about cross platform - demonstrated by C# being windows only and growing in popularity during the time.
Visual Studio dev experience was just better than anything comparable at the time (Borland stuff was dead by C# era) and C++ was just an inferior language for app development (especially pre modern C++ where you couldn't even rely on stl being implemented correctly across platforms and people regularly rolling their own containers)
1) people now expect apps to run on a million different devices and nobody has the time or resources to develop four or five native apps with feature parity between them
2) progress on UI frameworks is pretty much stalled. Just looking at .NET, because I'm familiar with it and traditionally desktop software has been a big area of concern for it, Windows Forms will work for forever but hasn't been touched in a long time, WPF has some sharp edges that make it feel unfinished but isn't being touched, and WinRT was basically stillborn because of their attempts to tie it in with the whole "new" Windows 8 ecosystem. Meanwhile, browsers are getting new capabilities constantly. It's hard to blame anyone who looks at that mess and says to hell with it and goes with a Web browser-based solution.
Can you recommend any projects to check out?
Iced is taking the "get something working now" approach, whereas Druid is taking the longer term "build it right" approach. I wouldn't recommend either of them for serious projects yet though.
I would also recommend Raph Levien's blog https://raphlinus.github.io/.
https://korban.net/posts/elm/2019-11-17-elm-ui-introduction/
I’m much more optimistic about the future of native apps, the best ideas from the web are already making their way into Rust and the recently announced .NET MAUI, and with WebAssembly I think we’ll start to see native performance on the web instead of the other way around.
I wouldn't be so sure about that. WebAssembly doesn't do anything to help the rendering bottleneck. To do that you really have to replace (or innovate in some way) the DOM.
I’ve used a lot of UI frameworks and getting to do anything complex is always much harder than doing the equivalent in HTML/CSS/etc.
I don't think it will take too long for the niceness of a sane design to outweigh the lack of features.
The only thing I'm not convinced about is that Flutter-web will ever be viable for most web pages (i.e. non-app ones). It kind of works but it's big and slow. Probably eventually people will do a native website, and then use Flutter for mobile and desktop.
It was a standard practice for some applications in the .com days.
Electron is just another example of the disease making Web == ChromeOS.
WinForms very recently got HiDPI support, better accessibility features, and was ported to .NET Core where they also fixed bugs in some controls.
WPF in the meantime has been arbitrarily declared stable and Microsoft refuses to fix anything. Everybody is supposed to switch to UWP which they already deprecated or WinUI which hasn't been released yet.
Sure writing large apps is not going to be straight forward, but WinForms is super simple to get started with.
Simple use case: Make a sidebar fade in and fade out, while changing the dimensions of the right box. Pretty close to impossible to implement in a clean manner, even within glade.
And then, try to support a mobile device in a responsive way with libhandy.
Now you throw the towel and just get on with 20 lines of CSS and literally two HTML elements.
CSS should not be underrated when it comes to layouting. It is super flexible, and UI frameworks always will lack behind due to their architectural patterns.
That is why so many apps don't work bug free with other themes. There's no way to predict how your app will behave on another system with another theme.
So personally I think the mess of overused dummy css classes in the GTK ecosystem is really a bad design. They could've gone with custom, namespaced, ui elements instead of that box.something.something shit.
They reinvented divitis. Quite literally.
It amazes me how many people went with the .NET bloatware and all that follows it. Of course, 95% of programmers out there are newer than me and don't have knowledge of this type of efficiency to compare against.
Delphi and C++ Builder are still around, but now only some lucky enterprise employees get to play with them.
.NET Native and C++/CX were finally shaping up to be Microsoft's proper version of what .NET and Visual C++ should have been all along.
However they are the most recent victims of the whole Reunion reboot, .NET Native now has uncertain future, while C++/CX got replaced by C++/WinRT with a tooling at the same level as doing C++ ATL 2.0 in 2000.
Still, there is a certain guarantee of the underlying platform and respective languages being around.
Borland mismanagement was my hard lesson to only use tools from platform vendors. Not only did they decide to leave the indie developers, they were always late providing bindings to Microsoft SDKs.
Field required: First Name
Field required: Last Name
Field required: Email
Field required: Password
Field required: Verify Password
Field required: Company
Field required: Phone
Field required: I have read the Community Edition End User License Agreement and confirm that my usage of the Community Edition version complies with its terms and conditions.
Field required: I have read, understand and agree to Embarcadero's Terms and Conditions & Privacy Statement
Field required: Yes, I would like to receive marketing communications regarding Embarcadero products, services, and events. I can unsubscribe at any time.There are, sadly, other offenders too. Microsoft is possibly the worst among them. Gone are the days of being able to use a free edition of Visual Studio to develop Windows applications with no strings attached. And good luck even figuring out what the privacy policy is, a problem that also applies with VS Code. I mean, why should desktop software even need a privacy policy?! Oh, right, telemetry, the plague of 21st century software. And then you have the mobile platforms and the offensive conditions and financial cut demanded by their gatekeepers, keeping Microsoft company in the obnoxious developer experiences department.
Meanwhile, OSS development tools and open platforms seem to be blowing away much of the proprietary stuff in administrative and business terms (as well as often in technical terms) now. Too many greedy platform owners trying to lock everyone in, not realising that Ballmer was right all along and without developers their platform is worthless anyway. And discussions like this, and the emphasis today on cloud-hosting (usually running FOSS) and web apps, are the result.
Because when one designs languages over weekends and late nighters, state of the art GC, JIT and GUI tooling are at very deep bottom of their roadmaps.
So thank you very much, but I will keep enjoying Java, .NET and C++ based tooling.
Why would someone both give up the ease of use and power of VB6 and/or Delphi / Lazarus, and want the bloat of Java, .NET, C++, etc.. that just complicate things for no good reasons?
It's like the programmers of the world went insane somewhere around 2002.
I remember Delphi adding many Windows features before Visual Studio. Windows Vista Aero support, Support for building native apps for the Microsoft Store, etc.
Delphi never shipped with bindings for 100% of the APIs, but the beauty of Delphi was I could create my own bindings with only a little code from Delphi, so it wasn't a roadblock. That is the huge difference between Delphi and non-native development tools: You aren't held back by lack of libraries or API bindings.
https://stackoverflow.com/questions/9653260/resources-for-na...
Also how come Embarcadero supports Windows features before Microsoft does?
I am a big Object Pascal/C++ Buider fan, but also acknowledge the reality of their actual support.
LOL, "lucky enterprise" my ass. The only poor souls who still work with that shitty bug ridden stone-age IDE from Embarcadero have to do that because they never managed to get rid of VCL (which might have been nice 20 years ago. Today it's just bad compared to modern frameworks).
Stay away from Embarcadero, don't become dependent on such vendor lock-in.
While I like the idea of .NET AOT, the execution left so much to be desired. The developer experience is so bad that I’m shocked that it’s still required for Store UWP apps.
With the store sandboxing Win32 apps instead.
https://github.com/dotnet/designs/blob/main/accepted/2020/fo...
https://github.com/microsoft/ProjectReunion
My biggest grip with .NET, since 2001 alphas for MSFT partners, was not being AOT like Delphi (NGEN was never meant for anything other than fast startups).
It doesn't amaze me. It's very productive to work in and the bloat just doesn't matter that much in most environments where .NET is even on the table. Now that prevailing trends are different, you can build leaner .NET Core apps.
...and a computer having 32MB of RAM was considered outrageously luxurious.
MFC with C++ was using dynamic linking by default, but you could always switch to static and see the binary bloat to several MiBs in size.
So if you do a proper comparison, there's really not much difference between them.
This is why Apple has been so hostile towards PWAs.
It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.
There will never be a viable hybrid app platform.
It may look the part but it rarely feels like it.
Something like OmniGraffle would not end up feeling the same. Even Microsoft's apps on mac feel better than their web-based counterparts in O365.
Because that is the main feature of figma. Latency of mouse issues is a good trade off from my POV.
Slick web apps are taking over the software world, whether the likes of Apple want them to or not. Looking like any specific native platform is less important, if it's even relevant at all, in an era when users are working with different web apps each with their own look-and-feel all the time anyway.
And I find it very telling that even your own comment continues the trend of over-emphasizing look over feel. I'd be happy with apps randomly launching in night mode, if they would just have all the right controls in the right places, and have the performance and memory footprint of native apps.
Also, web technologies can perform just fine the vast majority of the time. Modern JS engines have excellent performance, obviously not rivalling expertly coded C and assembly, but certainly comparable to your average native application for most purposes. Modern browsers also have good support for hardware acceleration and can render UIs that respond quickly enough to user interactions that again for most purposes there is no perceptible delay or jank. Today we're looking towards WebAssembly as a vehicle for potentially more efficient languages and runtimes, though clearly that technology is still in its infancy and its future is far from certain. Now, you can undermine all of that potential if you bloat your web site/app with tens of megabytes of junk scripts that are all competing for resources and blocking stuff and phoning home and whatever, but that's not really the fault of the web technologies, it's just bad developers and/or bad managers creating a bad application.
If nobody can get Web technologies to deliver a good experience, then I'm not sure it matters that much whether or not it's possible in theory. Delivering a theoretically great user experience won't get you anywhere unless it also translates to practice.
Applications that meet these criteria include: Thunderbird, KiCAD, VLC, Vim, tmux, Blender, evince, Handbrake, and Pidgin.
That seems like a fairly low bar to clear. Aside from the network request issue, I think every web application I've worked on for a decade or more would tick all of those boxes, from intranet tools to browser-based interfaces embedded in device firmware. I'm sure there are many others in the industry who could say the same. A lot of the things I'm thinking of are for internal use, but in terms of public examples, you can just look at most of the successful big-name business SAAS applications, and they tend to be strong on these requirements as well. Ease of use is a huge selling point for attracting customers, and no-one is winning points by being clunky in their web GUI in 2020.
Network speed and reliability is a different issue, and obviously many web applications are particularly vulnerable to problems there because they have such a strong communication element. But then the same is true of native applications that are for communication or a front-end to a client-server system like a central database.
Applications that meet these criteria include: Thunderbird, KiCAD, VLC, Vim, tmux, Blender, evince, Handbrake, and Pidgin.
That's an interesting set of examples. The other point under discussion was about whether web applications cause usability problems by deviating from native platform UI conventions. I can't help noticing that several of the native applications you mentioned there do exactly that.
For example, Blender's UI was infamous for being so unusual that anyone coming from other 3D modelling software found it hard to use, and for looking and behaving nothing like a conventional native application on a platform like Windows. Eventually, that became so much of a problem that they basically rewrote the whole UI layer to work in more conventional ways.
Handbrake has its good points, but its interface looks like a GUI from the early 2000s where the designer just threw as many different types of control onto a form layout as they could manage.
Thunderbird also has its good points, but its UI is incredibly glitchy in some areas (dragging and dropping comes to mind) and it definitely fails to meet your fast and responsive criteria at times.
That "and by extension web apps" bit is completely wrong. The long-standing conventions of how web sites work are mostly irrelevant to fancy web apps, and to the extent that they are relevant, web apps break them left and right. Just look at how many web sites/apps hijack or break scrolling or the back button or the ability to middle-click on a link and get a new tab or the ability to highlight text. Web apps are all about breaking the usability standards for web sites and replacing them with a bastardized version of the usability conventions from various native OS toolkits. But in spite of that, nobody ever really expects drag and drop or rich copy and paste or any other data exchange mechanism to work between web apps.
Hardly any? That's been a minor trend in web sites for a while, but changing scroll behaviour for no good reason is widely regarded as an antipattern by UI professionals. I don't recall ever seeing normal scrolling behaviour subverted in anything I'd call a web application.
or the back button
This is a tricky one from a usability perspective, because some users see URLs as shortcuts to particular parts of a web application and expect the back button to behave accordingly as they navigate information in the app, while others think of the whole application as being a single page and expect the back button to just leave everything. But there is a whole set of browser APIs for managing that behaviour, and it's something a well-designed application will at least present in a consistent and logical way.
or the ability to middle-click on a link and get a new tab
This sounds like you're talking more about web sites than applications again, and again it also sounds like you're talking about bad design that web UI professionals would universally disagree with. It's usually caused by newbies who read some style-over-substance tutorial and decided that making links or buttons with elements other than the designated anchor and button ones that exist for that purpose was a good idea. After the first few glaring usability problems, they'll learn better.
or the ability to highlight text.
I don't really understand this one at all. The only times you wouldn't be able to highlight text in a web application would be if the designers have actively prevented it, for example to prevent selecting UI labels along with the content of a text field. This typically works exactly the same way as any native desktop application.
But in spite of that, nobody ever really expects drag and drop or rich copy and paste or any other data exchange mechanism to work between web apps.
I don't know what you mean here, either. Dragging and dropping text between web applications typically works fine. If by "rich copy and paste" you mean other more complicated data types, what happens is obviously highly context specific, but once again, this is the same story on native desktop applications. It's not as if you can copy a selection of spreadsheet cells and paste them into a drawing package with obvious and meaningful results either.
As a final comment, the examples you're talking about here all seem very "meta". As such, they're not particularly interesting to me, because as a UI developer working on a web app you generally get the expected behaviour by default with these kinds of things. Sure, some people can and do break them. They're just bad UI designers. Some people make native applications with shocking pink skins over the normal window dressing, too, but that doesn't mean all native apps are bad.
Of course I could. I was just countering the original point that sounded that web apps are slick just because they're web apps. Making good GUI is hard (well I'd skip Hello world here).
Sorry, maybe that was written ambiguously, because that wasn't the intended point at all. The point I was trying to make was that the web applications that are slick are taking over the world. Being polished and easy to use is a big advantage, and IMHO there's been a lot more progress on this front in web development recently than in native applications.
In contrast, the mobile platforms are far too much style-over-substance and have glaring usability problems as a result.
Most desktop applications haven't really changed their basic form for decades, they just show up with flat icons and kindergarten levels of bright colours these days. That does mean here is a level of consistency and familiarity, which is valuable. However, it also means most of them aren't benefitting from decades of further experience and research in UI design and from newer UI patterns coming out of that experience that have proved to be effective in other contexts.
Part of the problem is a new twist on the old problem. I don't have to develop for Mac and Windows and Linux, I have to develop for Desktop PCs, Tablets, and Phones. My options are to create a GUI for each of them or use something like Bootstrap to build one that runs on them all, and that has limits and trade offs, but it's still pretty good.
One of the things I've done with this upgrade is provide a way for the user to store their data in the CouchDB native app running on their desktop PC. It's a "local-first" and "offline-first" web app so once it's installed it doesn't need or use an internet connection and while I have no way of making a comparison it appears to me to run pretty close to native app speeds.
When CouchDB is installed on the user's desktop PC any web app configured to use it can use it. It only requires the user fills out a simple web form to set up a user and database for the app.
Taken together, a modern web browser and CouchDB come pretty close to fully featured client side runtime environment for desktop PC web apps. It wouldn't be too hard to create a web app that looks and feels very much like a native app when running full screen on a Mac and Windows.
A client side runtime for web apps is something I've been thinking we need since I built my first web app and that was before they were even called "web apps". I'm not the guy to make that, but I think we need it. CouchDB and a web browser come pretty close.
Our users (https://usebx.com) seem to appreciate the native performance and feel of our web app.
There is nothing magical about Ui powered by compiled vs interpreted code. It is limitations in the platforms that are the roadblocks.
Ugh, no. No it's not. At least not yet.
Accessibility features alone are almost always woefully crap in web-apps, compared to what native apps have access to, at least on macOS (and SwiftUI is amazing in how it lowers the barriers in implementing accessibility in your app from the get-go.)
Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources.
Not an Android fanboy but I'm going to assume that the bigger (widely used/constantly iterating) "platform" (for a lack of a better term) has better a11y. And if there is a web framework that provides this (react?) do the majority of websites use it ? like they do native api's for native apps
(and this isn't even talking about the api's accessible to native vs web app)
There is a standard counter to that argument at this point. Developers on native platforms might be able to achieve a better experience on that platform than a web app given the same time and resources. However, if the time and resources have to be split N ways to build a native app on each of N platforms, compared to investing everything into polishing a single web application, the outcome might be very different. While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI. And since they launched their version 1 two months earlier than any of the native apps did, they even have the extra revenue in the bank to pay for those usability tests, too.
Your hypothetical scenario seems to be treating the app's UI as if it exists in a vacuum, rather than existing alongside other apps.
If there's a platform-standard UI convention that applies to a button, then UI testing in the context of that platform is probably not going to tell you to remove that button entirely—you shouldn't be surprising users by removing functionality they expect to find present. And if there is a UI convention that tells you how to position that button, you probably shouldn't A/B test the positioning of that button and should focus your usability testing on the UI elements that are not dictated by the platform's standards and conventions.
(Origin unknown)
Your arguments use the word "probably" a lot. As someone who does a lot of UI design professionally, I prefer to rely on the kind of user testing you apparently dismiss, precisely because prior expectations about what works well so often turn out to be inaccurate. Indeed, there have been plenty of native platform standards that have awful usability in recent years, which have rightly been criticised for it by professionals wielding empirical evidence.
Platform native UI conventions are very often sub-optimal, if only because they're old. But sub-optimal standards are very often preferable to unpredictable, and are definitely preferable to having to juggle multiple conflicting UI conventions at the same time when multitasking. That's why we still have QWERTY, and why all the surviving scrollbars are on the right, and why pie menus never caught on.
You say you test UI designs professionally, and claim the higher ground of having empirical evidence. But it still sounds like you're using worthless methodology by focusing only on your one app at a time and ignoring how it fits into its environment and the user's broader workflow. Is that correct, or have you actually quantified the overall productivity loss an app introduces by violating the user's expectations and habits?
The reason that junk like flat design and derivatives like Material Design are awful for usability has nothing to do with being old and everything to do with being unpredictable. Often, a user literally can't tell what parts of an interface are interactive or how they work, because affordances barely exist. It's like the old mystery meat navigation meme for web sites, except they actually did it seriously and thought it was good.
But it still sounds like you're using worthless methodology by focusing only on your one app at a time and ignoring how it fits into its environment and the user's broader workflow. Is that correct, or have you actually quantified the overall productivity loss an app introduces by violating the user's expectations and habits?
Well, firstly, a testing methodology is literally the opposite of worthless if it gives you an objective measure of the increased financial value generated by a change under consideration.
Secondly, you assert without evidence that the kind of change we're talking about does violate the user's expectations and habits, and you further imply that this causes a loss of productivity. As I have argued in earlier comments, the assumption that the user's expectations are governed primarily by their native platform's conventions is not necessarily valid any more, because users spend so much of their time inside a browser using online facilities instead of other native applications.
Moreover, the answer to your other question is yes, we have done many tests over the years that compared options including the native approach on various platforms with some other options we were considering. In the nature of such tests, the outcomes varied. In some cases, we did end up going with presentation similar to the native conventions on one or more platforms; often this coincided with cases where the native conventions across major platforms were similar as well. In other cases, we went with a completely different presentation style, as performance with the native conventions was significantly worse.
The point of all of this is still that ideally you don't want to make UI decisions based on assumptions or dogma if you could try different possibilities with real users and make your decisions based on objective evidence instead.
I'm surprised to see you mentioning the flat design trend as something you consider "old" in any way. I see it as a fad that is past its peak but still far too prevalent to regard as being in the past. And when I was talking about platform native UI conventions, I definitely had older stuff in mind than Windows 8.
> Well, firstly, a testing methodology is literally the opposite of worthless if it gives you an objective measure of the increased financial value generated by a change under consideration.
See, this is the biggest problem here. I'm talking about usability and value to the user. You're talking about optimizing the UI to exploit the users for your maximum profit. Those two motivations are obviously not well-aligned, and if you're on the side of that divide where the ad-tech stuff is, then you're not even trying to have the same conversation I'm having. Your incentives are to maximize the user's engagement with your product, so of course you don't care about how well it fits into their multitasking workflow; you want to monopolize the user's time.
I could not disagree more strongly. I have built a career built, in no small part, on a simple business model of creating software that users like because it's easy and works well, and consequently attracting and retaining happy (and paying) customers. This has absolutely nothing to do with ad-tech, which I generally regard as a toxic business model for exactly the reasons you're arguing.
Seems to me that there's less of a "apple is purposefully malicious towards PWA because of their master plan for platform lock" and more of a "apple has a very long history with being completely incompetent on the web (see: icloud as a whole, safari now slowing standards adoption, newer web endeavors like the apple music app) which in turn is slowing PWA adoption because they now own one of the most dominant mobile platforms.
[1] https://www.businessinsider.com/microsoft-xbox-game-pass-app...
[2] https://www.theverge.com/2020/9/25/21455343/amazon-luna-appl...
Desktop apps got the permission model all wrong. You run a program and that grants them access to everything.
The web's model is closer to that of mobile apps. It asks for a permission at the time that it's needed. Not all sites get this right, but browsers are starting to crack down on requests the moment you enter a site.
Google is developing cross-platform Dart/Flutter.
Apple is developing cross-platform Swift/SwiftUI.
Facebook made React and then cross-platform React Native.
Native OSs can be built to be "cross platform". For example, the OpenGL API. The same API works on different OSs, developers can code against the same API and it works on different OSs. In an ideal world, maybe there could be a standard API for presentation controls, UI drawing, animation, 2D/3D graphics, networking, filesystem access, threading and more. Each OSs would implement the same API and add additional platform specific APIs to differentiate themselves. The key is application developers would have a common core set of APIs and language to implement the 80% business logic and UI logic.
Note, this is essentially what HTML, JS and CSS is doing. But the web platform is creating a runtime that exposes APIs to do a lot of different things. A CSS transform a single API that causes the DOM to animate in specific way. There are thousands of these APIs, and the runtime implements all of them. This is why the web runtime itself heavier and it takes 100mb just to show something simple on web platform.
For flutter, the core engine is just a 2D drawing surface, the APIs it exposes is just drawing shapes. And all of the widget self contains rendering, various settings and the application pulls in the widget used in the app. This makes the runtime smaller. Flutter is more efficient because the abstraction is lower and the core runtime is trying to do less things. On the scale of level of abstraction, flutter is on one end and the web platform is on the other. For our ideal OS platform, we can select the right level of abstraction to balance between performance, standardization, and flexibility.
But in the real world, all of this require collaboration between OS vendors. Apple's business model is try to sell more IPhone, Mac, Apple Watch, IPad. They make the argument that Apple's platform has the best apps that isn't available on Google's or Microsoft's platform. And this actually works. Why is Android tablets not taking off, and IPad Pro is? People buy the IPad Pro for apps like Notability, Photoshop and more. People still buys Windows and not ChromeOS because its got native Photoshop and Matlab. These apps are coded using Apple's or Micosoft's language, frameworks and APIs. And that exactly is what is preventing these apps from appearing on Android and ChromeOS easily and reducing people's need to buy Apple and Microsoft's devices. While these vendors may not say they are actively trying to lock in developers. They definitely don't want the some developers who coded an complex application for their platform to easily move it to another platform. If this transition cost is too low, it doesn't play into their business model. Their business model pushes them to differentiate their platform against others, and as a side effect, it increases the barrier and transition cost.
This is a tug of war between application developers desire to have all platform as similar as possible, and the platform owners desire to differentiate their platform and prevent other platforms obtaining the same capabilities as my platform.
https://medium.com/javascript-scene/native-apps-are-doomed-a...
And it isn't an IDE, rather a programmer's text editor.
William Ralph Inge wrote that in 1931, but it has never been more true than when applied to modern technologies today.
TTY's date back to the Victorian era. AUX cables date back to the XIX century, too.
Most silverware design at home date back to 1800-1900.
I did this with the Eclipse Language server and my memory usage cut in half on the same project.
Think of it this way: if you have a system full of apps that conform to platform conventions, then you only need to learn the platform conventions and you’re suddenly more or less an expert in every new app you encounter.
If you need to learn every. single. apps. stupid rules and UI all over again, then sure, you can transfer skills in that one app over to another platform, but that’s it. You want an email app? Good luck learning every keyboard shortcut and ridiculous UI decision all over again.
Let’s just say this paradigm shift has not been driven by people with OCD (or good taste, for that matter).
It's essentially only using HTML and JS as the UI engine.
Even my 9 year old laptop can run VSCode just as fast as my 3 year old main machine.
Back in 1998 when Visual Studio 6.0 (actually just the second publicly released version) was released, it took ages to load and used up quite some RAM. 6 years later, when I switched to VS.NET 2003, VS6 ran super fast on my PC.
The difference was, however, that my 1998 PC was a 300MHz Pentium II with 64MB of RAM, wheras my 2003 machine was a n overclocked AMD Athlon XP at more than 2500MHz with 2GB of RAM.
Now compare that with my 2011 laptop vs. my 2017 laptop: my 2011 machine has a dual core 2.5GHz CPU with 8GB of RAM. My 2017 laptop is a dual core 3.5GHz CPU with 16GB of RAM.
22 years ago, 5 years of progress meant a 10x increase in RAM and 8x increase in CPU speed. During the past 10 years we saw a doubling in RAM (barely, TBH) and maybe 1.5x in CPU speed (at the same core count).
That's why the old software felt so fast - because we used it during a time when a major PC upgrade actually meant something. If you used a software package for five years, you could actually see more than a doubling in performance (e.g. Core2Duo E8600, 2008 vs Core i3-4350, 2013 [1]).
That's just not the case anymore and skews our perception regarding performance heavily towards "lean" vintage apps.
[1] https://www.techspot.com/article/1039-ten-years-intel-cpu-co...
I distinctly remember subsequent versions (.NET 2002, which I think had the UI re-written) being a lot slower than 6, and me still using version 6 when I could because of this.
In fact, I can remember VS 6 opening in seconds, compared to later versions being much slower.
What Electron gets mostly right is the UI, since everybody is used to browsers. What it gets wrong is insisting on shipping an entire browser rather than using the platform's native webviews, so the result is ridiculous bloat.
Interpreter written in Assembly for fast startup, if the application was never executed.
Followed by JIT compilation to native code and when the device is idle, the PGO data collected by the JIT is used to produce a binary for direct native execution.
As of Android 10 those PGO files are uploaded to the stores and then if a similar device installs the application, they will get the PGO data as well and thus achieve a relatively fast result for their initial compilation.
I know that a lot of old school code used very little memory due to everything sharing one set of libraries. I wonder if in the future, “installing an application” could be flipping a bit in a registry and your device being delivered a highly optimized monolithic system image.
I think that's pretty much what a good compiler is meant to do?
smaller binary images would be amazing though, especially when OS dependencies are required
Before starting my app, I did briefly consider going the cross-platform route, and I realize that it's possible to build a decent app that way. But personally, I could always tell when I used one. Little things like swipe gestures and drag and drop didn't quite work right. The extra polish, consistency, and speed of going native is so nice for things you use all day every day. With the shift to remote work, people might notice this extra 5-10% of polish more than they did a year ago.
In Catalina it’s crashing left, top, bottom. Moved to nvAlt which, it seems, is abandoned now as well. Author is focused on something caller nvUltra. No idea what’s that.
Besides for people who use Evernote, nv isn’t a replacement at all for them.
No sync, looks like it won’t let me put images/PDFs in, no way to collaborate with my co-writer on projects, last version is from 2011. Nope. Haven’t tried it, don’t think I will, I dunno who it’s for but it’s not for me.
In order to run such stacks we need to devote a couple of GB's of RAM for the OS and browser. Not a bad deal if you compare cost to benefits.
That said, I normally seek native apps where possible (ripcord for slack, sublime), but that's also pretty hipocrytical of me ref Kanmail!
I've started publishing Sciter.JS builds to prove that:
https://github.com/c-smile/sciter-js-sdk
Those binaries contain HTML5, CSS 2.1 + some Level 3 modules and full ES6 engine.
4-5mb of binaries is comparable with native hello-worlds of purely native Qt, wxWidgets, etc.
(See the fact that you can use it after a click, how can i do the same with paw ?)
You also need to expend several more clicks to install a browser extension to get the same level of functionality that Paw has.
What kinds of wild things could we accomplish on this hardware if we weren't bogged down in gigabytes and teraflops of bloat?
Not that many: An early 1990s PC platform could be thoroughly described in a 200 page book and you could write a boot loader for the CPU, a VGA driver, and drivers for the most common peripherals from scratch in a few weeks.
In fact, games of that era shipped with their own audio drivers, (C/E/V)GA libraries and peripheral support.
Today this would be a) impossible because many manufacturers (cough NVIDIA cough) don't even release OSS drivers and specs and b) individual programs don't own the hardware anymore - the OS does. Also the multitude of target platforms (CPU types, -core counts, and -speeds, graphics cards, peripherals, etc.) makes it virtually impossible to ship code that it optimal for each of even the most common combinations of hardware.
The final nail in the coffin of the "super lean no bloat why-not-just-unikernel-everything-for-maximum-performance" idea can be summed up in one word: cost.
Development costs would be insane if we started optimising every aspect of every program for performance (on every possible platform, no less), memory use, and (binary-) size.
And that's even ignoring the fact that it's more often than not outright impossible to optimise for binary size, runtime performance, and memory footprint all at the same time.
Plus interactions between programs (plugins, {shell-}extensions, data formats, clipboards, etc.) require "bloat" like common interfaces and "neutral" protocols.
Most of the myth of great "old software" comes from the fact that functionality was severely limited compared to modern apps and that many folks simply weren't around to actually see and feel how much some of them actually sucked.
Sure, Visual Studio 6.0 runs incredibly fast on a vintage 3.2 GHz Pentium 4 with 2GiB of RAM using Windows 2000 - but when it released in 1998 many PCs had a 60MHz Pentium 1 or a 100MHz 486DX4 with 64MiB of RAM and it ran like a three-legged dog with worms on these machines compared to the DOS-based Borland-C...
Speaking of which, remember when sometime around the 2000s all Borland Pascal program stopped working, because CPUs had become too fast (>200MHz IIRC)? That was because their runtime used a loop to determine how fast the CPU was, which caused a divide-by-zero on fast machines IIRC.
Good times indeed...
>many PCs had a 60MHz Pentium 1 or a 100MHz 486DX4 with 64MiB of RAM and it ran
By 1998 most people switched to a Pentium because of the huge performance gain. And by 2000, everyone had a Pentium2 with ~96mb of RAM.
That's a bold claim! The PII was released around 1998 and you basically just asserted that everybody buys the latest CPU as soon as its released.
The reality is that most PC users never upgrade their machine and buy a new one instead. The average age of a PC is about 5 years and no, aside from enthusiasts nobody buys the latest and greatest as soon as gets released.
Businesses in particular hold on to their assets for some years due to depreciation (which incidentally is 5 years for PC class devices).
So in 2000, the average PC was 1995-level hardware.
Windows 98 was on its peak and the Pentium MMX often was horrendously slow to start up things. Good with Windows 95, but by 2K everyone was onto 98/SE because of good additions and an easy PNP support.
W98SE was used even when XP got released and a few years more.
Also, your statement about the P4 with that huge amounts of RAM (2GB) is even more unusual than a PII in y2k.
When I had an AMD Athlon in 2003, I barely had 256MB of RAM. I stayed with that up to 2009 with Debian 4 DVD's.I tried some Fedora releases and they where a huge no-no in my machine, and Solaris was impossible.
Reminds me of the Turbo button on PCs in the 90s, which all my school mates and I at the time thought was for a speed-up.
Au contraire!
I know how to fix it for myself (I have scripts to do it automatically) but most people do not and just reboot when the system becomes too unresponsive. Not so great for 2020.
Are you sure it's not the "150 IQ I-have-20-tabs-open-at-any-given-time" usage pattern that's actually causing this? I just checked out of curiosity and Edge (for lack of an installed Chrome) used "just" ~380MiB for a rather big website.
Sure, websites (and especially ads!) taking up unnecessary amounts of memory and performance play into this, too, but the expectation that you can just leave 10 bloated websites open on a glorified netbook from 2014 is more to blame than anything else.
Sometimes yes, but;
And how are non technical users supposed to know they should not do this? A lot of people do not know how bookmarks or even ‘windows’ work so they leave open the websites they visit so they do not forget them or have to open them again... How would they know that this is bad? The browser supports it and no one told them. For them there is no correlation between tabs and computer slow. Just as many people, when you say ‘your memory is full’ start throwing away picture from their drive. I think you vastly overestimate computer users... I am ‘the computer guy’ of the village because ‘I do stuff with computers’ and I run into the strangest things all the time. There is, for instance, a large stack of perfectly fine laptops in my house because some people just bought new ones because the old one ‘was slow’ and they were fed up.
Also, what do tabs open have to do with IQ?
It's a meme.
> And how are non technical users supposed to know they should not do this?
For the same reason you need a license to legally drive a car. While I'm generally not a fan of the RTFM-attitude, I have absolutely no patience for people who are unwilling to even learn about the very basics of the complex machine they're operating.
Why on earth doesn't "the computer guy" tell them about where to learn the basics instead? Teach a man to fish an all that...
> There is, for instance, a large stack of perfectly fine laptops in my house because some people just bought new ones because the old one ‘was slow’ and they were fed up.
There's several reasons for that to happen - sometimes it starts at the point of simply buying the wrong product. Leaving the whole why-even-a-laptop-in-the-first-place aside, I have been convinced for the past 10 years now that 90% of all laptop users would be better served with a tablet (preferably an iPad).
First of all, non-technical users cannot make an informed purchase decision and way too often buy garbage products (e.g. low-tier CPU with not enough RAM) in order to save maybe 10%.
Secondly, instead of learning about the product they own and its limitations, they pile on crapware on top of bloatware and not once even manage to do basic maintenance (like disk clean-up, which is literally just a button press away).
"The computer guy" shouldn't "fix" their machines but advice them to just get an iPad instead - problem solved for both sides.
It's pretty short-sighted to blame a particular set of software packages for a whole pile of problems that stack upon each other:
• underpowered hardware
• complex operating systems that require knowledge and manual maintenance to keep them running smoothly
• increasingly bloated websites and ads (just test it yourself - HN allocates single-digit MB per tab, while a news site easily causes >200 MB allocations)
• computer illiterate users that are unwilling to learn even the very basics about their machine (Sapere aude!)
• an inability of users to judge their own needs and requirements vs their options in terms of technology (i.e. desktop PC vs laptop vs Chromebook vs tablet vs smartphone)
• the failure of the industry to communicate their target audience (i.e. you don't need a laptop to watch some Netflix, browse the web, do photo editing, etc.)
• not all operating systems are the same - sometimes all it takes is to make the switch (be that Linux or MacOS)
But no! That's way too much thinking and way too differentiated a view point! It's so much easier to just blame Chrome. Or Electron. Or JavaScript. Or Windows.
Anything but daring to actually form a complete picture...
But hey, that's basically today's Zeitgeist in a nutshell anyway I suppose.
My daily driver has 4GB of RAM, and it's possible only usable because I'm extremely frugal with my software choices. I run Debian with XFCE and pipe memory usage to my panel so I can always see whether I'm in danger of swapping. I use a Firefox extension that prevents me from opening too many tabs. I stick to the terminal for as many tasks as possible. I categorically refuse to use electron apps. And despite all that, I still ending up OOMing and having to hard reset every few days. For a normal person who doesn't know what RAM is and has an antivirus constantly running the background, the 4GB are going to be used up almost immediately, their machine will start swapping, and then they'll get the impression that their 4GB machine is "slow," despite being faster than high-end computers people used to do exactly the same things ten years ago.
'But Larry Page and Google were not interested in application software. “We like the web,” he is said to have told Lars Rasmussen, one of the Gordon’s fellow co-founders. And he set the team a deadline to get their idea working in a web browser.'
Source: https://medium.com/@lewgus/the-untold-story-about-the-foundi...
Personally, I don’t see much benefits of Electron or non native apps when they don’t mix well with the OS UI interaction model. In the end you need to implement a lots of parts twice for Windows and macOS due to the differences interaction models.
In the case just share the business logic, and write UI separately, works perfectly fine. I have written apps that run on the web, natively on Android, macOS, iOS, and Windows were the only change is the UI layer and data storage (e.g. iCloud on Mac etc)
I have about 500 applications on my Mac (465 in the Applications folder and at least a few dozen others scattered about), and I believe only two of them are hybrid apps (Visual Studio Code and Discord). There might be another two or three I'm forgetting about.
In other words, somewhere between 99% and 99.6% of all my applications are native, and I see zero reason to believe that percentage will decline very much in the next few years.
Here's a list of about 60 apps that I've used in the last month:
Activity Monitor, Adobe Digital Editions 4.5, AppCode, Bartender 3, BBEdit, BitBar, calibre 4.23, Carbon Copy Cloner, ColorSnapper2, Console, Dash, Discord, Downie 4, EtreCheckPro, Evernote, FastScripts, Firefox, Font Book, GoLand, Google Chrome, HazeOver, Highland 2, IntelliJ IDEA, iTerm, iTunes, Keyboard Maestro, KeyCue, Launchpad, Mactracker, Magnet, Messages, Microsoft Excel, Microsoft Outlook, Microsoft Word, OneDrive, Parallels Toolbox, Paste, Paw, PopChar, PopClip, Preview, Safari, Script Editor, Scrivener, shayre, SnapNDrag Pro, Snappy, SQLPro Studio, SQLPro for SQLite, Terminal, TextSoap, TG Pro, Typinator, Vienna, Visual Studio Code, VLC, WebStorm, Window Tidy, Xcode, Xojo.
So, as soon as devs realize their apps fit in 1GB or something these days where even mid range phones have 4GB of RAM, they see no reason to optimize further.
That made me laugh a bit. Yes, I tend to agree with other criticisms, although in some ways this type of increased resource usage has been going on forever, so I'm not sure it can be laid purely at the feet of hybrid programs:
That's not true. Even with "native binaries" you have the OS as an intermediary.
I recently wasted two weeks starting a new contract at a tier one multi billion dollar orginisation unable to do any work as their standard issue laptop where 8gb window machines and they had no availability of other machines. It took two weeks pointing out we can't do any work, our contractor rates they paying us to do nothing and the approaching deadline to make it way up the chain for senior execs to organise machines with 16gb.
If you need to run Docker with a few containers that's several gigs immediately unavailable to the system. Start MS Teams, another gig, visual studio code / intelij, another gig, a browser another gig or so.
Even without running developer tools on a 8gb machine which seems to be standard issue laptops at most office based companies and average non techy person off the street you very quickly hit the memory limits and swapping to disc as you have a handful of small Electron applications open.
Memory usage is extremely important to users just that most users being non technical don't know it and just think their machine is slow.
Running an application in 2020 with the ubiquitous use of Electron my desktop apps seem less responsive, i can run fewer of them, and any sign of bad internet connection my system comes to a halt as all that apps even if only sending metrics block until api requests are complete or timeout vs running them in the background and not blocking ui functionality.
of course you will need a modern browser, which is everywhere these days.
yes for corner cases Qt/Electron has their place, but I feel 95% GUI these days can be done with Browser + Backend, which is what Electron is doing basically(chromium+nodejs), I just don't want to run browser and electron in parallel, both are memory hungry, so why not just directly browser+backend(in C,golang,nodejs,or whatever)