Goodbye, Native Apps • Hacker News Board

Re: Goodbye, Native Apps

#181

Post by pjmlp » Sun, Nov 01, 2020, 9:43 AM UTC

ripley12 wrote: post #147

pjmlp wrote: post #8

Earlier quoted context omitted.

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 r…

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

Well, if you have been following up on blogs, community videos and github issues, most likely by the time .NET 6 comes out, the stack will look like Windows 7 development model never went away and the only improvement was replacing COM with the improvements brought by UWP.

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

Re: Goodbye, Native Apps

#182

Post by perryizgr8 » Sun, Nov 01, 2020, 9:48 AM UTC

reader_mode wrote: post #96

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…

It reads like something generated by GPT3.

Re: Goodbye, Native Apps

#183

Post by saagarjha » Sun, Nov 01, 2020, 9:57 AM UTC

juststeve wrote: post #2

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

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.

Re: Goodbye, Native Apps

#184

Post by saagarjha » Sun, Nov 01, 2020, 9:59 AM UTC

WaltPurvis wrote: post #137

mushufasa wrote: post #119

Earlier quoted context omitted.

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

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 Clo…

To be fair, calling the JetBrains IDEs "native" might be going a bit too far ;)

Re: Goodbye, Native Apps

#185

Post by saagarjha » Sun, Nov 01, 2020, 10:00 AM UTC

ausjke wrote: post #115

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.

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

Re: Goodbye, Native Apps

#186

Post by pjmlp » Sun, Nov 01, 2020, 10:12 AM UTC

Silhouette wrote: post #78

capableweb wrote: post #30

Earlier quoted context omitted.

They are making it easy to get started with when there is a whole bunch of information I have to give them in order to download even a trial/community edition. Contrast that to most other programming languages / development environments, where you usually can just download and run it. Field required: First Name Field required: Last Name Field required: Email Field required: Password Field required: Verify Password Fi…

Contrast that to most other programming languages / development environments, where you usually can just download and run it. 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 ap…

While bringing developers to the stone age before RAD tooling was a thing.

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.

Re: Goodbye, Native Apps

#187

Post by pjmlp » Sun, Nov 01, 2020, 10:20 AM UTC

IshKebab wrote: post #178

thrashh wrote: post #151

Earlier quoted context omitted.

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.

I think so. Web has the advantage of already catering to literally every layout & style use case (grid, multiple columns, floats, inline elements, etc. etc. etc.). But Flutter has the advantage of being designed from scratch so it can avoid all the idiotic mistakes the CSS made (e.g. box-sizing, the insane difficulty of centering things, etc.). I don't think it will take too long for the niceness of a sane design to…

Something that one can easily do even with Motif and Windows Forms, just learn the layout APIs to start with.

Re: Goodbye, Native Apps

#188

Post by pjmlp » Sun, Nov 01, 2020, 10:22 AM UTC

ausjke wrote: post #114

beached_whale wrote: post #107

Earlier quoted context omitted.

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.

then why still use Electron? why not just c++-backend with an embedded http server for frontend that uses the browser

That is the proper way of doing, but then some lazy devs rather code with Chrome APIs instead of Webs standards.

Re: Goodbye, Native Apps

#189

Post by pjmlp » Sun, Nov 01, 2020, 10:23 AM UTC

akritrime wrote: post #128

ausjke wrote: post #114

Earlier quoted context omitted.

then why still use Electron? why not just c++-backend with an embedded http server for frontend that uses the browser

For many users that can be an alien experience. For most non-technical people, browser is still primarily for accessing contents on the web and switching them to a user experience where you have to start a backend server locally and then access it via the web browser can just feel hacky and even a bit off-putting.

You can do that perfectly transparent, the executable just starts the user standard browser.

It was a standard practice for some applications in the .com days.

Electron is just another example of the disease making Web == ChromeOS.

Re: Goodbye, Native Apps

#190

Post by pjmlp » Sun, Nov 01, 2020, 10:25 AM UTC

the_only_law wrote: post #129

ausjke wrote: post #114

Earlier quoted context omitted.

then why still use Electron? why not just c++-backend with an embedded http server for frontend that uses the browser

I would assume for the same reason that they don't just use a normal web app. They want the packaging of a native app.

Package as native app, it starts the user browser pointing it to localhost into its builtin server, plenty of examples during the 90's, e.g. CUPS printer management tools.