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

211–220 of 231 posts

Re: Goodbye, Native Apps

#211

Post by cookiengineer »

jmnicolas wrote: post #179
cookiengineer wrote: post #152

Earlier quoted context omitted.

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…

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

Yes, with global css, which is literally one file for every single application, extension, gnome shell, terminal and ui windows on your whole system.

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.

Re: Goodbye, Native Apps

#212

Post by emodendroket »

pjmlp wrote: post #190
the_only_law wrote: post #129

Earlier quoted context omitted.

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.

I'm not sure the app ESR famously blew up for having a horrible UX is the example I'd point to to say it's not confusing.

Re: Goodbye, Native Apps

#213

Post by emodendroket »

mrweasel wrote: post #163
emodendroket wrote: post #146

Earlier quoted context omitted.

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.

Of all the Windows GUI frameworks WinForm has to be the easiest to develop for, for the majority of developers. Sure writing large apps is not going to be straight forward, but WinForms is super simple to get started with.

I agree and it's still pretty much the one I'll use but it's in a weird limbo where it doesn't seem like they really want you to use it

Re: Goodbye, Native Apps

#215

Post by WaltPurvis »

saagarjha wrote: post #184
WaltPurvis wrote: post #137

Earlier quoted context omitted.

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

They're not what I would call native, but they are native by the definition of the article being discussed, i.e., they're not "hybrid" apps.

Re: Goodbye, Native Apps

#217

Post by merrywhether »

Razengan wrote: post #49
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 Electro…

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.

Re: Goodbye, Native Apps

#218

Post by anthk »

qayxc wrote: post #207
anthk wrote: post #112

Earlier quoted context omitted.

Eh, BIOSes had an API-like interface under ASM assembler macros under DOS. It was relatively easy to do stuff directy with hardware. >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.

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

I was there. In 2000 the average PC was 1997 era hw... with a Pentium2, AMD k7, or a Celero overclocked to ~450MHZ? making a great alternative to a Pentium2 and a Pentium III@450.

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.

Re: Goodbye, Native Apps

#219

Post by icedchai »

russli1993 wrote: post #133
nicoburns wrote: post #97

Earlier quoted context omitted.

> 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 think the approach many is taking is just put a canvas and draw on top. Internally, you may end up creating another DOM like structure to store all your objects. The worst thing about this approach is that you lose all browser's native support like accessibility. I think Flutter is using a combination of DOM, CSS and canvas.

So we've basically reinvented Java applets - 25 years later.

Re: Goodbye, Native Apps

#220

Post by ausjke »

saagarjha wrote: post #185
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.

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)

Post reply on HN