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

161–170 of 174 posts

Re: Stop Building Closed Ecosystems

#161

Post by PaulDavisThe1st »

scarface74 wrote: post #159
PaulDavisThe1st wrote: post #153

Earlier quoted context omitted.

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…

Wow. Just wow.

I was the 2nd employee at Amazon. For the last 23 years, I've been the lead developer of Ardour, a cross-platform DAW. I also wrote JACK, the only cross-platform inter-application audio/MIDI routing system, but since that's a system that doesn't require a GUI, it's not really relevant. It did win me an award in the early 2000s though.

What you're describing sounds to me like a process out of 1980s "application development" blended with web stuff blended with contemporary "rapid application development" aka "define the GUI with a GUI tool, and it automatically generates code".

Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.

I asked you a simple question about what the code looks like in an Adobe or Microsoft app that runs on two platforms, the code that opens a dialog to collect information from the user. Nothing in my question makes any reference to tbe backend. All I can guess is that you think that all GUIs are defined via RAD-ish tools. All I can do is to try to use your language: what is it that a front-end developer is doing when they "define views that are shown when the menu item is selected" ?

Re: Stop Building Closed Ecosystems

#162

Post by PaulDavisThe1st »

scarface74 wrote: post #155
PaulDavisThe1st wrote: post #149

Earlier quoted context omitted.

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…

> same software for Mac and PC software for over 35 years

You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so.

CoreAudio is not a "front-end" toolkit/framework/library.

You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API).

The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development).

None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.

Re: Stop Building Closed Ecosystems

#163

Post by solarkraft »

Ecosystems interest me ("how do I get my product/feature adopted in a larger landscape?"). The following are some observations everyone could make, yet I see some companies (Microsoft in particular) struggling with it, so maybe it's not that obvious.

> The lack of interest in Unimodules taught me that it’s not enough to come up with an opt-in common standard.

It's a tough sell if it offers no immediate value to the developer. If there's no immediate value for the user or a big push, they aren't going to be asking for it either. This can turn into a vicious cycle Apple keeps avoiding and Microsoft keeps falling into.

> Given it’s far too late to convince each framework to redesign their native module interfaces from the ground up for compatibility, it may be worth exploring a top-down approach instead. That is, producing tools to translate modules from one ecosystem to another “whether they like it or not”.

That's the gold standard, IMO. Once you need people to do anything for your feature to work, your work becomes a lot harder. "If everyone would adopt it you'd see the benefit!" doesn't convince many users OR developers. By removing the requirement for developer opt-in, you're suddenly avoiding a huge part of the viscous cycle (no users because no devs, no devs because no users), which is a huge part of Apple's ARM success and probably a good part of Microsoft's ARM failure.

Re: Stop Building Closed Ecosystems

#164

Post by camgunz »

hsn915 wrote: post #160
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 too…

I think they're roughly the same in terms of dev experience. Major toolkits have good bindings for dynamic languages like JS and Python so C++ isn't a barrier. I think mostly what happened was Electron's pitch of "turn your web app into a desktop app almost for free" meant that web devs could stick with React rather than learning wx or Qt. There were a lot of web devs and web companies so this meant a lot of Electron apps where once there might have been native apps.

Re: Stop Building Closed Ecosystems

#165

Post by mroche »

PaulDavisThe1st wrote: post #162
scarface74 wrote: post #155

Earlier quoted context omitted.

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…

> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You canno…

> None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.

This was the basis for my comment. It's not possible escape native APIs, but what differs will be how you consume them. You can either choose to use them directly (true native) or you can use a toolkit that abstracts the various backends. This provides you a single development layer across all platforms while the toolkit itself is what handles the access to the underlying platform native APIs. So it's not on you the vendor to keep up with what's changing at the OS layer, but the toolkit.

Obviously there are trade offs with all methods, and they can be mixed and matched as needed. For example, Qt is not a GUI toolkit like GTK, but a platform toolkit providing APIs for a whole host of functionality beyond visual representation. Does that mean you need to use Qt's multimedia package to handle video or such? Absolutely not, but for the features it provides that are shared across platforms it can make things easier to develop (this is purely for example purposes, I've never authored anything with Qt Multimedia).

Re: Stop Building Closed Ecosystems

#166

Post by scarface74 »

PaulDavisThe1st wrote: post #161
scarface74 wrote: post #159

Earlier quoted context omitted.

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…

Wow. Just wow. I was the 2nd employee at Amazon. For the last 23 years, I've been the lead developer of Ardour, a cross-platform DAW. I also wrote JACK, the only cross-platform inter-application audio/MIDI routing system, but since that's a system that doesn't require a GUI, it's not really relevant. It did win me an award in the early 2000s though. What you're describing sounds to me like a process out of 1980s "app…

> Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.

In that case, you know that the call site is never “telling the front end to bring up a dialog box”

> I was the 2nd employee at Amazon

Well I’m the millionth something employee at Amazon :). But as far as generating a view. I’m thinking of something like the home grown (publicly discussed) tools that AWS has so that when the service team introduced a new API, we have tools that can automatically generate SDKs in all of the supported languages and the CLI. Why couldn’t a custom tool create native views? Hey

Again we know for a fact that Adobe has “millions of lines of native Cocoa”. Why is it so hard for you to believe that the front end is hand coded by native developers?

Even at one 200 person company I use to work for we had dedicated web, Android, IOS and desktop developers.

But even when you aren’t using RAD tools, you are still defining your views some kind of way with XML, config files or something. BTW, I’ve been a continuous hands on ”programmer” (we didn’t call ourselves developers back then) since the mid 80s when I was a hobbyist 65C02.

Re: Stop Building Closed Ecosystems

#167

Post by throwaway290 »

Waterluvian wrote: post #85
PaulDavisThe1st wrote: post #68

Earlier quoted context omitted.

For some classes of applications, all the developers want is a 2D surface (call it a canvas if you like) to draw on and then they do everything else themselves. This leaves several notable areas of UI/UX to address: 1. menus 2. file browsers 3. text entry 4. notification/tray integration 5. window management These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platfo…

As you say, I think you’re right for many classes. But in other classes, apps are entirely widgets. I’m looking at the first Electron app in my quick bar: Spotify, and thinking about how to make it portable without being Web. It’s all widgets, no canvas. If you made it in any of the above it won’t feel Spotify it’ll feel Qt or whatnot. For Linux and FOSS types this is usually fine. It’s sure fine for me. But for the…

Downside of game engines is lacking accessibility, I think, are there any that don’t?

Re: Stop Building Closed Ecosystems

#168

Post by yw3410 »

overthrow wrote: post #31
yw3410 wrote: post #25

Earlier quoted context omitted.

Rust does well on the text-shaping and glyph rendering, but the rest of the ecosystem is still massively geared towards Windows and game development. I am rooting for Vello to succeed!

What would you say is state of the art for Rust-native text rendering on the web? I'm aware of ab_glyph, used by e.g. https://www.egui.rs/ but it looks noticeably non-native to my eyes. For one there seems to be no hinting. So text ends up blurry at 96dpi, and since a glyph stroke is thinner than a pixel the text always appears slightly faded, never able to reach fully black or white. I wish these libraries would jus…

My personal applications tend to use only monospaces fonts and stick to Latin characters so I can get away with glyph rendering and then a very simple layout algorithm so something like ab_glyph or freetype is enough and I don't need harfbuzz.

I'm aware of swash and the other libraries in that stack, but it was going through a rewrite. The Linux support was incomplete, for example, it was dependent on a piped call to fc-list and parsing the output to get the system fonts.

Also, if I were doing it via web, I'd be tempted to render to an offscreen canvas and call it a day.

Re: Stop Building Closed Ecosystems

#169

Post by scarface74 »

PaulDavisThe1st wrote: post #162
scarface74 wrote: post #155

Earlier quoted context omitted.

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…

> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You canno…

> CoreAudio is not a "front-end" toolkit/framework/library

What difference does it make? You still can’t have a “write once run anywhere”. You still have to have a dedicated team to develop each app.

Re: Stop Building Closed Ecosystems

#170

Post by mroche »

scarface74 wrote: post #169
PaulDavisThe1st wrote: post #162

Earlier quoted context omitted.

> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You canno…

> CoreAudio is not a "front-end" toolkit/framework/library What difference does it make? You still can’t have a “write once run anywhere”. You still have to have a dedicated team to develop each app.

Do web developers generally create their own audio subsystems or use platform native APIs directly? No, those aspects are handled by the browser which does the heavy lifting for them, allowing for a write-once-run-anywhere{-that's-supported} experience. The cross-platform toolkits (like Qt, JUCE, etc) do the same thing; they talk to the platform APIs on your behalf. What kind of expertise or team structure you require to build your application for various platforms really depends on what level of the stack you want to author against.
Post reply on HN