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

Stop Building Closed Ecosystems

buttondown.email

Post reply on HN
Print view View original

151–160 of 174 posts

Re: Stop Building Closed Ecosystems

#151

Post by PaulDavisThe1st »

scarface74 wrote: post #140
PaulDavisThe1st wrote: post #107

Earlier quoted context omitted.

Laptops are a different category. I use one, but only for travelling. Most of the time, I work on a massively multicore self-built AMD-based system which is cheap, incredibly powerful and almost silent. My power comes from the sun, and I don't have to care about battery life. My AMD system has better audio performance than any Apple system I could buy (and I can even run Mojave on it, with better $-per-cpu-cycle than…

So when will that day come? Microsoft and Apple have been the dominant desktop OS since the mid 80s. Yes I realize that Apple has hovered between 10-20% since the mid 80a

What day? I never dreamed of the "day of the Linux desktop", if that's what you mean. Couldn't really care less (other than to note that it would be nice).

Re: Stop Building Closed Ecosystems

#152

Post by PaulDavisThe1st »

culi wrote: post #142
PaulDavisThe1st wrote: post #41

Earlier quoted context omitted.

WebGPU doesn't offer any facilities relevant to GUI development except a method of putting pixels on the screen. If you're suggesting WebGPU, you're really suggesting a drawing technology, not a GUI toolkit.

No I didn't mean to imply its utilization for GUI development. I meant for it as an example of cross-platform technology that maintains good performance while being extremely cross-platform

Plenty of examples of that. I could name dozens outside the web space.

Re: Stop Building Closed Ecosystems

#153

Post by PaulDavisThe1st »

scarface74 wrote: post #145
PaulDavisThe1st wrote: post #122

Earlier quoted context omitted.

I never said anything about the backend. The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? I would bet…

> Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when…

The user clicks on a button or menu item labelled "Do Foo". To "do foo" requires further interaction with the user, and the designers opted to do that in a dedicated dialog. So the program now needs to make a dialog visible to collect information from the user. Simple enough for you?

What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platform "toolkit", albeit in-house.

Re: Stop Building Closed Ecosystems

#154

Post by kitsunesoba »

lelanthran wrote: post #105
scarface74 wrote: post #39

Earlier quoted context omitted.

Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?

> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps? Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld? Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as…

> BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals.

Hard to say without knowing what’s running in the terminals, but I’d say Chrome/Electron (and potentially, its use of non-HW-accelerated codecs in video chat) is the likely culprit here. Not the same machine, but my M1 Pro MBP 16” can pretty easily swing a full work day flipping between Xcode and Android Studio so long as I’m using Safari for browsing.

Re: Stop Building Closed Ecosystems

#155

Post by scarface74 »

PaulDavisThe1st wrote: post #149
scarface74 wrote: post #139

Earlier quoted context omitted.

So if it’s “themed” to look “native”, what happens when the vendor chooses to change the theme of the native widgets? Do the themed widgets automatically support the user’s localization and internationalization preferences? Does it support the accessibility affordances that you could get for free when you use the native toolkit? > Apple can make first party applications that abide exclusively by their HIG, and the sa…

I can only speak to the land of DAWs: The biggest DAW of the last 20 years: Ableton Live (Windows/macOS) The next biggest DAW of the last 20 years: Reaper (Windows/macOS/Linux) The most rapidly expanding DAW right now: Bitwig (Windows/macOS/Linux) The most deliriously loved DAW: FL Studio (Windows/macOS) Most widely used DAW by paid professionals: Digidesign ProTools (Windows/macOS) Other DAWs not made by Adobe or Mi…

I’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years.

Another poster cited this as far as how much “native” code is in PhotoShop

> But Russell still has MacApp to contend with — it most recently flared up during the Mac Cocoa conversion. Millions of lines of code had to be changed, and for a time the entire team was engaged on the project.

And let’s talk about ProTools. It is even in a worse position than Adobe with respect to being able to use cross platform frameworks. The backend leverages Mac and Windows specific APIs

https://www.pro-tools-expert.com/production-expert-1/is-ther...

It specifically leverages Core Audio on the Mac.

Re: Stop Building Closed Ecosystems

#156

Post by scarface74 »

LinguaBrowse wrote: post #147
PaulDavisThe1st wrote: post #137

Earlier quoted context omitted.

> or choose to use something like React Native Finally took a look, and this appears to be mobile only. Certainly covers one definition of cross-platform, but a little different than the other toolkits we've discussed.

Nope, React Native does support targeting Windows and macOS (and, though with less love, Linux) and even Web, tvOS, Android TV, and more. It’s just that iOS and Android are the only official Meta-maintained ones. The macOS and Windows implementations are solid, being maintained by Microsoft, and are even used in small corners of Microsoft Word and other flagship apps.

Are you really advocating using a cross platform framework that isn’t “maintained”?

Doesn’t that argue one of the issues with using any cross platform framework?

Re: Stop Building Closed Ecosystems

#157

Post by scarface74 »

PaulDavisThe1st wrote: post #151
scarface74 wrote: post #140

Earlier quoted context omitted.

So when will that day come? Microsoft and Apple have been the dominant desktop OS since the mid 80s. Yes I realize that Apple has hovered between 10-20% since the mid 80a

What day? I never dreamed of the "day of the Linux desktop", if that's what you mean. Couldn't really care less (other than to note that it would be nice).

I meant the day that Windows or Mac users would regret the “lock in” like farmers do with John Deere? Especially since Linux is easy to run on top of either and many of the best tools are ported.

Re: Stop Building Closed Ecosystems

#158

Post by scarface74 »

lelanthran wrote: post #105
scarface74 wrote: post #39

Earlier quoted context omitted.

Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?

> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps? Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld? Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as…

I have a (work issued) MacBook Pro 16 inch M2 Pro Mac. I charged it to 100% and it lasted two full work days on battery at a client site open most of the time running VS Code and Teams (some people were still remote) and occasionally building AWS Lambdas. The build tools let you build Lambdas within an Amazon Linux Docker container containing the appropriate runtimes when you are building on Windows or Macs.

Re: Stop Building Closed Ecosystems

#159

Post by scarface74 »

PaulDavisThe1st wrote: post #153
scarface74 wrote: post #145

Earlier quoted context omitted.

> Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when…

The user clicks on a button or menu item labelled "Do Foo". To "do foo" requires further interaction with the user, and the designers opted to do that in a dedicated dialog. So the program now needs to make a dialog visible to collect information from the user. Simple enough for you? What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platfor…

Serious question - are you a developer and what frameworks have you used?

The front end already knows the inputs that the backend needs (in this case tte engine). When you click on a menu, it usually brings up another view without ever talking to the backend. I’m sure some companies have a framework that can automatically generate a native view based on an API definition.

Even your standard CRUD app you usually have a set of API developers and they may publish their API using something like the OpenAPI specification and then your web developers, Android developers, iOS developers create interfaces to call the API.

> What is the code at the call site that opens the dialog? WinUI? Cocoa?

This is fundamentally opposite of how development is done in a GUI event driven architecture. The back end is never the “call site” that tells the front end to “bring up a dialog box” The front end calls the back end.

Even if it’s not a user generated action, the front end still defines the interfaces and subscribed to an event.

In your example:

1. The back end developer (the engine creator) writes code that is usually cross platform if that’s the aim and required certain inputs and raises events.

2. The front end developer creates menus and defines views that are shown when the menu item is selected. The view allows the user to enter the necessary information.

3. The front end then sends all of the information to the backend and probably some type of call back function that the back end should call when it’s done or in the case of error.

The back end is never the “call site” nor does it know anything about the front end.

This is a standard “onion architecture”

Re: Stop Building Closed Ecosystems

#160

Post by hsn915 »

PaulDavisThe1st wrote: post #9

The native side of this has long been addressed by cross-platform toolkits including but not limited to: Qt, GTK, FLTK, WxWidgets (note: all FLOSS, at least optionally). Alas, web development "decided" to completely reinvent the wheel for all this stuff, leading to a new generation of heading-to-native toolkits derived from browser-based technologies, such as Electron, React Native and Flutter. Unless you believe the…

> Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.

The problem is not forcing people to do this or use that.

The problem is the quality and development experience is just _so bad_ that people are resorting to other options.

Don't get me wrong, the dev experience for web is terrible, but it's still light years ahead of legacy toolkits like qt/gtk/etc.

Post reply on HN