Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Native Apps

medium.com

Post reply on HN
Print view View original

41–50 of 231 posts

Re: Goodbye, Native Apps

#41

Post by jackewiehose »

pjmlp wrote: post #8
mikewarot wrote: post #3

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

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…

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

Re: Goodbye, Native Apps

#43

Post by Tyriar »

jarjoura wrote: post #13
schwartzworld wrote: post #6

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.

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.

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.

Re: Goodbye, Native Apps

#44

Post by qayxc »

bitwize wrote: post #18
schwartzworld wrote: post #6

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.

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.

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

Re: Goodbye, Native Apps

#45

Post by wtallis »

athenot wrote: post #35
burtonator wrote: post #32

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.

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

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.

Re: Goodbye, Native Apps

#46

Post by jamesu »

egypturnash wrote: post #34

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.

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.

Re: Goodbye, Native Apps

#47

Post by ablekh »

schwartzworld wrote: post #6

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.

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.

Re: Goodbye, Native Apps

#48

Post by z3t4 »

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

Re: Goodbye, Native Apps

#49

Post by Razengan »

burtonator wrote: post #32

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.

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

Re: Goodbye, Native Apps

#50

Post by choathedolls »

burtonator wrote: post #32

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.

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

Post reply on HN