Goodbye, Native Apps

https://medium.com/the-innovation/goodbye-native-apps-2ffcbd2773e7

by delvin0 • 6 years ago

101 230 6 years ago

juststeve3• 6 years ago

Or native apps will go through a revival due to new languages, compiler optimizations and access to intrinsics and C libraries.

karmakaze• 6 years ago

Technology still matters. It's not native vs not-native, there are many points along this scale. An app written in Swift on an iPhone should run faster than a similar app in Java on Android. If they run about the same, remember that the iPhone can do it with less memory and battery consumption. The Java Android app is more native than a React-Native app executing js.

juststeve3• 6 years ago

yep, so the goal should be to compile everything down to light binary images the first time, and not require mobile devices work it all out at runtime.

peatmoss2• 6 years ago

As an avowed skeptic of all things deep learning, I do wonder if there is a role for AI generated native code from some form of psuedocode.

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.

juststeve3• 6 years ago

I do wonder if there is a role for AI generated native code from some form of psuedocode.

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

njhaveri• 6 years ago

As a developer of a native Mac email client, I sincerely hope that this is true. At least in the Apple ecosystem, there are new technologies like SwiftUI and Mac Catalyst that should make this easier, particularly for the army of iOS developers looking to bring apps to the Mac.

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.

emodendroket15• 6 years ago

It's a double-edged sword. I like that no matter what OS I'm using I can set up IntelliJ to work exactly the same, down to non-native keymaps.

saagarjha3• 6 years ago

I am unsure we're going to see a performance increase there; nobody has really made the highest performance languages faster by more than an order of magnitude in the last couple decades.

mikewarot2• 6 years ago

I have Lazarus up and running... it's currently taking 32 Megabytes of RAM. It compiles in the blink of an eye, has one of the best possible 2 way GUI builders in the open source world, and I can reach back 30 years into the libraries I wrote in the days of Turbo Pascal 7/MS-DOS and pretty much use them intact.

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.

pjmlp16• 6 years ago

You have to thank Borland's management for that.

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.

vintagedave• 6 years ago

At least there is a free Community Edition now. It is one release behind (so doesn't have the latest goodness, eg the LSP server for code completion), but it does let you build apps for non-commercial use or pre-income startups for free, using Delphi/C++, the VCL, etc. Ie, if you want to encourage people to use tools like Delphi, it is much more open to indie devs than it used to be.

Link: https://www.embarcadero.com/products/delphi/starter

TheJimMcKeeth• 6 years ago

always late providing bindings to Microsoft SDKs

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.

tonyedgecombe• 6 years ago

Borland dragging their feet on 64 bit support helped me win quite a few customers from one of my competitors.

jackewiehose• 6 years ago

but now only some lucky enterprise employees get to play with them.

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.

ripley12• 6 years ago

.NET Native is an absolute nightmare in practice. Glacial compile times (I’ve heard many people complain that their Azure DevOps CI times out after an hour), and so many bugs that you only discover at runtime. I gave up on .NET Native after discovering that it can’t even handle the ultra-popular Dapper ORM.

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.

emodendroket15• 6 years ago

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.

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.

userbinator• 6 years ago

It's funny to see this comment, because Delphi and such were actually considered rather bloated back in the day --- a basic windowed app with not much in it (like a "Hello World") taking up several hundred KB was not unusual, compared to tens of KB for the MFC equivalent, and a few KB for pure Win32.

...and a computer having 32MB of RAM was considered outrageously luxurious.

scaladev• 6 years ago

They were using static linking by default though. You could always switch the linker to dynamic linking and get those sweet 20-something KiB binaries.

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.

lostmsu3• 6 years ago

I did Delphi 7 back in the days, but not sure I understand your complaint: .NET desktop apps do compile and launch in seconds.

Fizzadar• 6 years ago

I don't think it's impossible to have (relatively) lightweight hybrid apps. The article focuses entirely on electron, which ships a whole browser. There are other options, such as pywebview, that use the system native browser. Still means the underlying JS bundle has to perform, which goes the same for websites too.

That said, I normally seek native apps where possible (ripcord for slack, sublime), but that's also pretty hipocrytical of me ref Kanmail!

c-smile• 6 years ago

Well, HTML/CSS/JS apps can fit into 5mb size even they contain HTML/CSS/JS engine linked in.

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.

mike_ivanov• 6 years ago

Unfortunately, Sciter is not opensource. Qt and wxWidgets are.

wademealing• 6 years ago

I feel like writing a 'goodbye goodbyes' medium piece which talks about never listening to a 'goodbye' article again.

thotsBgone• 6 years ago

Can you find an example of a tech goodbye article which has been wrong?

kerbs• 6 years ago

I still hold this one close to my heart

https://medium.com/javascript-scene/native-apps-are-doomed-a...

schwartzworld• 6 years ago

VSCode is a poor example. Its a fully featured IDE, and sure it would be lighter without electron, but it still wouldn't be a lightweight piece of software. I use JetBrains which is not Electron, but also uses it's fair share of ram.

danmur• 6 years ago

I haven't compared ram usage but vscode feels (subjectively obviously) very slow by comparison to me. Intellij is a beast of an application in terms of features also.

pjmlp16• 6 years ago

Nope is a very quite good example, because one can compare it to Emacs, vim, Sublime Text loaded with a similar set of plugins.

And it isn't an IDE, rather a programmer's text editor.

gumby2• 6 years ago

For decades people complained that Emacs was huge, bloated, etc. Now there are bigger web pages

deviantfero• 6 years ago

I use emacs exclusively but VScode is way snappier when dealing with JSX syntax at least

nbrempel• 6 years ago

To be fair, JetBrains runs on the JVM which arguably has the same problems.

vips7L• 6 years ago

I wonder if forcing IntelliJ to run with ZGC would help since it releases unused memory back to the OS after some time.

I did this with the Eclipse Language server and my memory usage cut in half on the same project.

emodendroket15• 6 years ago

Yeah but if it didn't, would I be able to run it with no differences on Linux, OS X, and Windows?

jarjoura• 6 years ago

Most of the core functionality of VSCode is powered by native extensions written in C++.

It's essentially only using HTML and JS as the UI engine.

Tyriar• 6 years ago

This is false. A very small amount of the core functionality of vscode is powered by native code, for example: find in files shells out to ripgrep, the majority of the other usages are mainly just exposing various native apis to js (like ptys, fast process trees, windows specific apis not surfaced by electron, etc.). The regex engine used for parsing textmate grammars is a special case that uses wasm.

bitwize2• 6 years ago

Visual Studio -- itself a fully featured IDE, even back in the early 2000s -- used to run on machines with less than 1 GiB of RAM.

qayxc6• 6 years ago

It also didn't support as many languages/features and was super slow on contemporary hardware.

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...

ablekh2• 6 years ago

In my opinion, VS Code is not a "fully featured IDE". In fact, I would argue that it is even not an IDE. Simply because, "I" ("Integrated") in IDE implies lack of external dependencies or, in other words, self-sufficiency. Install PyCharm, Rider or any other real IDE, for that matter, and you have a truly fully featured development environment (yes, you can install some optional plugins, but it is largely not needed). Install bare-bones (i.e., without any extensions) VS Code and you have just a nice development-focused editor, but definitely not an IDE.

IggleSniggle2• 6 years ago

Interesting that you mention pycharm. VSCode has a superb integrated experience for TypeScript ootb with language, refactoring, IntelliSense support, etc, no plugins or additional language servers needed.

twodave2• 6 years ago

I like to joke/not really joke that (insert JetBrains product)’s main feature is converting laptop battery charge into heat and fan noise ;)

bdcravens• 6 years ago

Around 1997 I was able to carry around a copy of Homesite on a floppy and run it in many places, on machines in the neighborhood of 32MB of RAM. It understood multiple languages, you could define additional ones and your own tag fillers using a custom XML syntax, connect to a database to inspect schemas, etc. Not as full featured as VSCode, but it had an amazing amount of functionality.

allo372• 6 years ago

The cheapest laptop I could find on walmart.com right now has 4GB of RAM. "Low-end" isn't what it used to be! Only techies care about things like how much RAM a program is using. End users, from my experience at least, don't really care - as long as it works.

possiblerobot• 6 years ago

You might be right with respect to non-techie users. But, it's not about whether it merely works. It's about what we could be doing with modern hardware if we used it as efficiently as old software had to use its hardware.

What kinds of wild things could we accomplish on this hardware if we weren't bogged down in gigabytes and teraflops of bloat?

qayxc6• 6 years ago

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...

emodendroket15• 6 years ago

Probably fewer because we'd be spending more time pulling our hair out on trying to make cross-platform C++ apps work instead.

tluyben22• 6 years ago

As a techie I mostly do not care as long as it works either, if I am not writing it myself (and sometimes even then but I care more now than years ago). However; things do not work a lot of the times; my wife is a writer, almost all my friends are non technical and they complain a lot about how crap everything is. And when I check the culprit is always lack of memory and it is always chrome (the browser and in Electron) that is eating all of it. It is miserable imho; techies can pretend the enduser does not care; maybe they should ask.

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.

MattGaiser• 6 years ago

Does the end user care enough to switch? As if all you are doing is complaining but it does not alter behaviour (specifically usage or purchasing behaviour) then for all business purposes they do not care.

qayxc6• 6 years ago

And when I check the culprit is always lack of memory and it is always chrome (the browser and in Electron) that is eating all of it.

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.

fuball63• 6 years ago

They may not care about how much RAM it is using, but the blatant disregard for resource usage manifests in other ways. Most people I know are just resigned to believe their 4GB RAM laptop will be obsolete in a few years. When things "get slow" it means chuck the whole computer. I do think that the recklessness to which we use our virtual resources contributes to e-waste, which is a physical problem.

allo372• 6 years ago

Sure, but why can't I replace the battery in my phone easily? Why does the computer that controls my fridge cost as much as a new fridge to replace (if you can even get one)? Why is a cheap printer about the same price as the cartridges? Our throwaway, built-in-obsolescence approach to product development is definitely a problem, but I think it's pretty obvious that the causes reach far beyond the use of resource-intensive UI frameworks.

pgcj_poster2• 6 years ago

Normal users don't care how much RAM their programs use, because they don't know what RAM is. They think that computer hardware has a single one-dimensional property called "speed" and that if their software performs badly, it's because their computer is too slow, not because the software is bloated.

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.

the_only_law3• 6 years ago

Any tips on getting stuff to run fine on low end machines. I'm currently running Lubuntu on a very cheap laptop and while its usable, most applications are get pretty irresponsive. I've also tried running some BSD's on it whith very bare bones wm's (i.e. ctwm) and that became unusable quickly. Although, I think the issue there was lack of proper graphics drivers and being stuck with the framebuffer driver.

mekster• 6 years ago

To be fair, writing apps that tries to throttle the use of memory is harder as you might have to let go of unused data onto disk instead of read and forget or process data little by little instead of all at once.

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.

burtonator• 6 years ago

Here's the thing. Apple, Google, etc are trying to lock developers into specific platforms.

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.

athenot• 6 years ago

It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.

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.

giantDinosaur2• 6 years ago

OmniGraffle could be fine; hasn't Figma shown us the way?

wtallis7• 6 years ago

Yeah, proponents of cross-platform frameworks love to ignore the second half of "look and feel". It's ridiculous to claim that a web app can behave like a native app when even Qt apps still tend to have obvious tells.

jiofih• 6 years ago

You should try Figma. Will open your eyes a bit.

osrec• 6 years ago

I think that can often be due to a lack implementation skill.

Our users (https://usebx.com) seem to appreciate the native performance and feel of our web app.

emodendroket15• 6 years ago

The fact you can just run it without installing anything makes up for a lot of faults (doubly so when the vendor isn't Microsoft but somebody nobody's ever heard of).

kgin• 6 years ago

It easily could feel like it, given a very reasonable amount of support by platform owners.

There is nothing magical about Ui powered by compiled vs interpreted code. It is limitations in the platforms that are the roadblocks.

Razengan• 6 years ago

It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.

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.

candiddevmike• 6 years ago

You really think accessibility for native apps will always be better than a web app that follows a11y?

Silhouette14• 6 years ago

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.

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.

merrywhether• 6 years ago

PWAs are extremely user friendly in one dimension: they frequently take 1-2 orders of magnitude less space. This is very relevant for low end devices, and has been one of their biggest selling pints since inception.

choathedolls• 6 years ago

Isn't that curious then, that Apple is forcing some developers to turn to web-based solutions [1,2] instead of encouraging them to actually create native locked in experiences?

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...

jjtheblunt• 6 years ago

Are you suggesting Javascript has access to all hardware functionality exposed to C/ObjC/Swift?

impassionedrule• 6 years ago

I've heard of Ionic/Cordova which gives JS apps the ability to access native APIs, but haven't used it to see if it's truly capable of all functionality

SquareWheel• 6 years ago

With a proper permission system in place, sure.

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.

fastball• 6 years ago

Doesn't really pass the smell test.

Google is developing cross-platform Dart/Flutter.

Apple is developing cross-platform Swift/SwiftUI.

Facebook made React and then cross-platform React Native.

russli19932• 6 years ago

Apple is definitely not developing cross platform. Swift the language is cross platform. But the SwiftUI is only "cross platform" within apple's different devices. A true cross platform is when a SwiftUI app would work on Android.

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.

intellix• 6 years ago

This is why Apple should be forced to allow multiple web browser rendering engines on iPhone. Cause they're so damn anti-competitive and being forced to develop for Safari makes developing web apps horrible

barnaclejive2• 6 years ago

If it were so easy, why is Postman pure garbage compared to Paw on mac?

pjmlp16• 6 years ago

There are many local markets across the globe where Apple devices are irrelevant, so trying to block PWAs won't work as much as they would like to.

egypturnash2• 6 years ago

I hate this trend so much. I just dug around in Time Machine for the old version of Evernote, after being frustrated by the Electron trash they are calling version 10. It's missing so many little touches that just magically happen when you make a real application instead of having to fake everything from inside a browser.

jamesu• 6 years ago

I’ve been tempted to do a native clone of an early version of evernote for a long while now. Learning it’s turned into electron trash might just push me over the edge and actually do it.

ksherlock• 6 years ago

Have you tried Notational Velocity?

crossroadsguy• 6 years ago

It’s been abandoned for almost a decade now. It survived changes until now.

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.

egypturnash2• 6 years ago

searches

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.

z3t4• 6 years ago

There are also "chromeless" apps which are just web apps (no Electron) and runs in the default browser, but without the address, tab bar etc. You can run the "app" by for example adding the "--app" flag for chrome, or -k for iexplore. Then there is also "add to home screen" (A2HS).

emodendroket15• 6 years ago

As much as anything else the growth of hybrid apps is a symptom of a couple of things:

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.

nicoburns4• 6 years ago

Indeed, my prediction is that native apps will make a comeback when the UI toolkits catch up. Flutter is in this vein. And some of the Rust UI ecosystem looks promising (although very early stage).

heavyset_go• 6 years ago

And some of the Rust UI ecosystem looks promising (although very early stage).

Can you recommend any projects to check out?

ronanyeah• 6 years ago

Check out elm-ui.

https://korban.net/posts/elm/2019-11-17-elm-ui-introduction/

jordwest• 6 years ago

Agreed, I think the web was simply first in being a highly versatile, capable, and relatively cheap to develop with cross platform UI toolkit.

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.

thrashh• 6 years ago

Can they catch up? I feel the reason why web apps took off is because so much money has been spent on the underlying technologies (HTML, CSS, etc.) that makes them extremely powerful.

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.

brightball• 6 years ago

As a Linux user, I love this though. Brings me a lot more.

benrbray• 6 years ago

Agreed. As the developer of an Electron app, I would jump ship in a heartbeat if a viable alternative emerges. Until then, I'd rather use my time to add new features rather than wrangle multiple implementations of the same app. The core app logic is the same on every operating system, so why on earth should I have to rewrite it three or more times?

beached_whale3• 6 years ago

I know of people doing C++ backend as an Electron extension. The C++ can be compiled on almost any OS does the non GUI stuff.

foepys2• 6 years ago

Windows Forms will work for forever but hasn't been touched in a long time

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.

emodendroket15• 6 years ago

Windows Forms remains supported, yeah, but there are no marquee feature to make it easier to develop for really. That seems like it's more focused on getting people to bring their existing WinForms work to .NET Core.

pjmlp16• 6 years ago

UWP and WinUI are marketing terms for the same technology stack that keeps being developed.

cookiengineer2• 6 years ago

If you take a look at the GTK+ ecosystem...it's kinda broken, too.

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.

jmnicolas• 6 years ago

I never coded GTK apps, but isn't the theming done with CSS since GTK 3?

tehabe• 6 years ago

I wonder if there is really a big difference between using an Electron based application or a progressive web application (PWA). My current guess is, that the biggest advantage of PWA's is, that you use the same browser for several applications. But I never really tested my guess.

IggleSniggle2• 6 years ago

An advantage/risk of Electron is inheriting the users filesystem and device privileges.

r-w• 6 years ago

Hence, there were no intermediate layers like run-times in order to execute native applications; just binary content was there.

That's not true. Even with "native binaries" you have the OS as an intermediary.

zuhayeer• 6 years ago

This is why building for web first is underrated – let people access everything within their browser, it's naturally cross-platform

'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...

ericmcer• 6 years ago

Memory usage is not that important to users. They would way rather have feature parity and familiar UI across all devices. That’s kinda why the browser is cool...

tiew9Vii• 6 years ago

Memory usage is important to users!

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.

gcanyon• 6 years ago

As an example I haven't seen elsewhere of why web apps suck (maybe this could be coded around?): I can receive a notice from Slack of a new message, with who it's from and a snippet preview, as I'm leaving my office's WiFi, and then the actual Slack app won't show me the actual message until I return to WiFi :-(

twodave2• 6 years ago

Sounds more like an implementation detail to me. The notification doesn’t contain the entire message (it goes through a different channel altogether). By the time the app tries to poll to retrieve the message (I assume here that it’ll wait until you try and view it) there’s no connection.

reader_mode3• 6 years ago

How is this getting uovoted ? Is nobody reading the article ? A few paragraphs in and I can see the author has terrible writing skills and doesn't know what he's talking about

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.

bluedino• 6 years ago

It is a shit article.

sudobash1• 6 years ago

I agree the article in of itself doesn't deserve front page placement, but the discussion that it is generating does. Sometimes I upvote or favorite mainly because I found the comments engaging and informative.

reader_mode3• 6 years ago

I mean this is a dead horse beaten over and over weekly, but even if it wasn't I don't expect to read blog spam when I click on front page stuff on HN - if this becomes the norm the site will lose value for me.

baxtr• 6 years ago

"Goodbye, Medium articles". That's the article I want to see trending...

gabereiser• 6 years ago

I’ll upvote that

thaumasiotes• 6 years ago

Hey, Jeff Bezos' article was pretty good.

Entalpi• 6 years ago

It was a bit hard to read honestly. A bit of rehash but that is most of the content on the internet anyways. Felt like someone writing for a school assignment.

axegon_• 6 years ago

My thoughts exactly. The one problem with native apps is the resources and time you need to develop the same app for several platforms. That's all.

Thorrez• 6 years ago

That seems to me to be what the Medium author was saying.

reader_mode3• 6 years ago

That's really a modern problem that happened after mobile became mainstream - but by the time that happened nobody was pushing C++ for app development anymore - Android was Java only for frontend and iOS was objc.

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)

darthrupert• 6 years ago

This should tell you something about the quality of patrons on this site.

perryizgr8• 6 years ago

It reads like something generated by GPT3.

ineedasername2• 6 years ago

"Older native software used resources in a well organized manner"

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:

ineedasername2• 6 years ago

I think the basic principle at work here is that new programs will only ever be optimized enough to be functional on a typical (< 5 years old) computer.

cwyers• 6 years ago

I mean, that Pentium III he shows up top probably cost $900, and even with inflation, a Windows laptop with 4gb of RAM costs $250 off Amazon.com right now. The "low-end PCs" that the author complains are being left out by Electron apps... a lot more people have PCs capable of running VS Code than had PCs that could run the old Borland IDEs back then. Computing is more accessible now, not less.

dreamcompiler• 6 years ago

Electron is only the latest in a long line of almost good enough cross-platform solutions. Java for example was supposed to solve this problem but the widgets never looked quite right and Microsoft threw a wrench in the works so Java-on-the-desktop never quite caught on.

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.

ausjke4• 6 years ago

why not just golang+http in one binary as backend and browser for the GUI frontend, that seems can solve all the GUI problems.

of course you will need a modern browser, which is everywhere these days.

hu3• 6 years ago

https://github.com/webview/webview

ausjke4• 6 years ago

aware of that and yes that's an interesting project

saagarjha3• 6 years ago

It doesn't solve the GUI problems of the web in general.

ausjke4• 6 years ago

what is it missing then? more specifically, what can't be done this way comparing to electron ,or Qt5 style GUI.

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)

WaltPurvis3• 6 years ago

The thesis that native apps are being supplanted by hybrid apps seems wildly overstated.

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.

mushufasa• 6 years ago

how do you have so many applications? Do you just accrue them over time? How many have you used in the last 6 months?

WaltPurvis3• 6 years ago

I was honestly shocked just now when I checked the number. Quite a lot of them are small utilities and menu bar apps. Many others were acquired via bundles (e.g., BundleHunt, Paddle, etc.) and a fair number of those I've probably never used.

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.

bikamonki• 6 years ago

The browser is the new OS. For most users, a Chromebook-like PC is all they'll ever need. On mobile, most native apps should be web apps or PWAs. Native code is now unnecessary in terms of hw/os features accessibility and performance.

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.

fareesh• 6 years ago

This is really poorly written and argued. The topic isn't exactly novel either. I'm wondering if these upvotes are organic

barnaclejive2• 6 years ago

Paw is a far better app than Postman, on a Mac, for no other reason than it is native and behaves as you would expect.

lucasverra2• 6 years ago

Last time i checked this app felt native https://hoppscotch.io/

(See the fact that you can use it after a click, how can i do the same with paw ?)

jamesgeck0• 6 years ago

It feels like a browser app. It’s snappy, but not as snappy as native.

You also need to expend several more clicks to install a browser extension to get the same level of functionality that Paw has.

mr_vile• 6 years ago

What a confusing title.

gorbypark• 6 years ago

I know the article is talking about "truly" native apps, but React Native is quite an interesting project. Microsoft has been heavily investing into React Native for Windows and macOS, so combined with RNWeb (which is still a work in progress, but quite usable), a developer can target iOS, Android, Windows, macOS and web with the same code base and have a native UI for each platform. It's pretty magical when it all works.

wdb2• 6 years ago

My main grievance with solutions like Electron the app doesn’t adapt to the platform.

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)

trzeci• 6 years ago

No company that tries to have the biggest possible user base will drop old devices that are running Android 4.2 or iPhone 4. Author lives in a dream 10 years from now.

Goodbye, Native Apps

Related Stories