[HN Gopher] Stop Building Closed Ecosystems
___________________________________________________________________
Stop Building Closed Ecosystems
Author : LinguaBrowse
Score : 138 points
Date : 2023-04-15 14:47 UTC (8 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| rafark wrote:
| Huh? Apple and Android (google) are for profit companies and are
| literally competing against each other. One of the iPhone's
| biggest selling points is iOS. Why does the author think Apple
| would want to share a single, unified interface with its
| competitor?
|
| It sounds ideal in a developer POV, but this is not open source
| territory.
| emodendroket wrote:
| A lot of these responses make me wonder how closely the
| original article was read because his critique goes beyond that
| and he's also upset about, like, code that only works with
| React.
| emodendroket wrote:
| Like everything else you have to trade off some other properties
| to prioritize this sort of "openness."
| samsquire wrote:
| What upsets me is the waste of effort building the same things
| again and again. I would like to reuse solutions to problems I
| solved and use them going forward.
|
| Imagine if we were all building upon the state of the art at all
| times and upgrades were free and things don't break between
| upgrades.
| [deleted]
| [deleted]
| thealchemistdev wrote:
| [dead]
| sfpotter wrote:
| Stop writing articles titled "Stop Doing X".
| ammarahmed6506 wrote:
| Stop adding comments starting with "Stop bla bla bla".
| znpy wrote:
| Qt is fairly open, I don't get why the author doesn't point at qt
| for a valid alternative.
| vinyl7 wrote:
| Qt is awful. Its basically the equivalent of boost but for UI
| fatneckbeard wrote:
| first rule of qt is nobody talks about qt
| LinguaBrowse wrote:
| Author here. Very confusing licence, is my main complaint (I
| speak also as the author of Svelte NodeGUI, which is built on
| top of Qt). The fact that there are hour-long seminars
| explaining the licencing
| (https://www.youtube.com/watch?v=m7etOQfrMiM) show that it's a
| real issue. I recall Qt for mobile has an even muddier story,
| with a different licencing/pricing model again.
|
| Besides that, I also personally find it horrible to program
| with, because different elements have differents way of
| managing their child nodes (unlike HTML Elements, which have
| one consistent API). And of course I'm a JS dev, though NodeGUI
| does solve that. But maybe these aren't valid gripes.
| marsven_422 wrote:
| [dead]
| asdfman123 wrote:
| Developers don't like closed ecosystems for obvious reasons. But
| companies like them because they're very profitable, if they can
| get enough users trapped in them.
|
| Having an open ecosystem can often mean you have no moat around
| your business.
| ksec wrote:
| I guess everyone goes through the stage of life thinking that
| Open System, or Cross Platform should be the norm. Java write
| once run everywhere in the 90s or earlier attempt like Smalltalk.
| But forgetting the lesson of Write Once, Debug Everywhere. Even
| if you had " _open_ " Ecosystem completely built on top of Linux
| you will still have completing OS with different parts like UX,
| UI or windowing systems / rendering engine. So what you want is a
| single OS for everything and everyone. Then you run into the
| other sets of argument which I wont name here.
|
| There is probably a reason why many working in Tech or
| specifically software is heavily leaning into certain political
| spectrum which relates to the above.
| powera wrote:
| There is no such thing as an "open ecosystem".
|
| You can only choose between having your own closed ecosystem, or
| being part of someone else's larger closed ecosystem.
| Kinrany wrote:
| An open ecosystem can be used by more than one closed
| ecosystem.
| photochemsyn wrote:
| The long-term solution seems to be to ditch iOS and Android on
| mobile devices entirely and replace them with fully featured
| operating systems based on Linux, e.g.
|
| https://itsfoss.com/open-source-alternatives-android/
| rvz wrote:
| That isn't realistic. We already gave pure 'Linux-based' mobile
| devices and desktops a chance years ago and unfortunately, they
| haven't taken off commercially.
|
| The only one that came out with a inkling of 'Linux' is
| ChromeOS and Android which both are not even fully open-source
| and will eventually be moving to Fuchsia-based OS and will
| ditch the Linux kernel.
| LinguaBrowse wrote:
| I like the idea of Ubuntu Touch (having worked with Ubuntu a
| lot), but even more so Firefox OS. As a web developer, the idea
| that "native" could simply mean "the Web platform" is really
| attractive.
| muyuu wrote:
| Attractive-for-the-developer ideas are fine but attractive-
| for-the-user dominates. That's the sad lesson since the 80s
| and 90s OS wars and the early dominance of the market over
| the committee-standards that happened repeatedly with
| databases, with web browsers, with text editors, with
| spreadsheets, etc etc.
| scarface74 wrote:
| Why is it a "sad" lesson that users have preferences that
| are not in line with developers?
| muyuu wrote:
| Personally I see the ossified bifurcation between users
| and developers as a major defeat that perhaps I won't
| live to see reversed.
|
| It was not set in stone that people would be by design
| dumbed down progressively as computing caught on, rather
| than assimilated into the computing world as 1st class
| citizens.
|
| In a parallel universe something like the Smalltalk, LISP
| or Forth machines were widely adopted and the dichotomy
| between user and developer was blurred to mean an
| incidental situation related to a specific set of code.
|
| It's hard to even convey in words how damaging it is, and
| can still be much worse, that the user was corralled
| first as a consumer and then as the product. Wholesale
| across all the industry. And the sad thing is that it
| wasn't like this, at all, as late as the 1980s.
| [deleted]
| scarface74 wrote:
| Yes and I'm sure that car mechanics are also tsk tsking
| about everyone that drives a car doesn't know how to fix
| one. I'm sure they also thing that cars have been "dumbed
| down".
|
| I've been programming for a long time (since doing
| assembly in the 80s). My second job out of college was
| for a small company where I was a developer and also had
| to manage a SAN, a dozen computers that ran jobs, mail
| servers, ftp servers, MySQL and SQL Servers, messaging
| servers (MQSeries, MSMQ) etc.
|
| Now I can just write some yaml or HCL and spin up an
| entire "server room". I don't wax poetically to juniors
| who never have to go through that and I even encourage
| them to use an even higher level of abstraction - the CDK
| that allows you to use code to create the yaml.
|
| Ob Disclaimers: yes I work at AWS now (ProServe).
|
| 2nd disclaimer: while the CDK creates CloudFormation,
| Hashicorp ported it to work with Terraform and is cross
| platform.
| muyuu wrote:
| I don't think the car mechanics analogy goes very
| far(tehe) but it could be done with some consumer
| electronics, as long as the integration and coupling of
| software and hardware has worked much more against the
| people than it has benefited them.
|
| Granted, it's not for everything. But by losing computing
| we lost a lot more, too.
| scarface74 wrote:
| How so, I think the modern iPhone works a lot better for
| most people than my old Apple //e or the first PCs I used
| ever did.
| muyuu wrote:
| i don't think you've read the above messages wholly, or
| if so you have missed the point
| [deleted]
| tannhaeuser wrote:
| It's sad for developers, I guess ;)
| satvikpendem wrote:
| I don't want to run a browser to run applications, that's
| almost as bad as running Electron apps on the desktop.
| alpaca128 wrote:
| Who says every app has to run in a separate browser
| instance like with Electron? It could be as efficient as a
| browser tab, which would be perfectly fine as long as the
| UI is built in a reasonable way. On Android it's been
| possible for a while to install webapps via the browser
| that are then displayed like normal apps on the homescreen,
| and that is nothing more than running a website in the
| single browser app instance running on the device.
| satvikpendem wrote:
| I have an Android and have done as you described but
| they're simply not as smooth as native apps, not even
| considering the lack of good native API integration.
| scarface74 wrote:
| I'm sure that will happen right after the "year of Linux on the
| desktop"
| ksec wrote:
| So we didn't actually fix cross platform ( as the article
| implies ), instead we should make all platform as one?
| rektide wrote:
| This is my main fear with Flutter CanvasKit & "Towards a Modern
| Web Stack".
| https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%...
|
| They are using canvas & webgpu, & making their own rendering
| engine (borrowing Skia) to take web apps from part of a
| participatory open ecosystem where extensions & user-agency work,
| & turning the page into a giant animated screen.
|
| The best open ecosystem we have on the planet is being body
| snatched by the closed-as-can-be native app world.
|
| The post here is a more developer-centric view of open & I think
| that's so valuable. It feels like we really used to have a more
| share-early share-by-default spirit.
|
| I think that's one thing that kind of agitated so many folks
| about webdev, is how share-centric it was.
|
| We didn't have established experts, there were no well
| established patterns, everyone was collectively figuring it out.
| Finding libraries that might work for you or doodling around with
| an idea was lead by sensibilities fit & taste. Throw it against
| the wall & see what sticks.
|
| The web today has really become a far far far more
| hyperindustrialized system, with far more popular (not enforced)
| norms & conventions. The random lead devs at a company are no
| longer necessarily intrepid explorers navigating an open sea of
| possibility. Everything is more set. And we no longer have that
| spirit of it just being us in the room, of sharing by default.
| The expectation is there's very very smart far off people
| building libraries, and we're just working on our app. The
| mindset has shifted, the culture has shifted, in a way where open
| is no longer the collective exciting happening place that we are
| all a part of.
| CharlesW wrote:
| > _They are using canvas & webgpu, & making their own rendering
| engine (borrowing Skia) to take web apps from part of a
| participatory open ecosystem where extensions & user-agency
| work, & turning the page into a giant animated screen._
|
| This is effectively what Flutter does on other deployment
| targets as well, building a framework and high-level primitives
| on top of the host's low-level primitives, and in the process
| abandoning everything good about native frameworks and
| primitives for the sake of a Google-controlled runtime.
|
| It's why Flutter apps feel so janky and awkward, and the same
| will be true of the web runtime.
| rektide wrote:
| It's going to run fine everywhere. It's going to work.
|
| As a native app strategy I think it's fine. It's immaterial,
| if it works. But on the web, it is damage. It breaks all user
| agency, wrecks all extensions, breaks accessibility
| extensions, prevents scraping. It's a closed world, and the
| web doesn't deserve this native app mistreatment.
| CharlesW wrote:
| > _But on the web, it is damage._
|
| I couldn't agree more.
|
| > _As a native app strategy I think it 's fine._
|
| It's fine in the sense that it doesn't damage open
| ecosystems in the same way that circumventing the web
| experience does.
|
| It matters if you care about the customer experience.
| Companies like McDonald's would likely see a significant
| bump in use and user satisfaction if they replaced their
| Flutter app with native apps.
| rektide wrote:
| Ok, that's reasonable. Thank you for your upfront
| starting agreement. I obviously have some real emotional
| attachment to the issue of whether users have agency or
| not, and this has been a really hard time for me, and
| hearing some recognition of the jeopardy as relevant is
| really touching, thanks.
|
| I had kind of assumed Flutter was performing fine/native-
| ish, it just didn't look native native. Different people
| will feel differently about the importance of native
| purity. I personally (with apologies) have seen native as
| a bit of a negative in general (with concerning privacy,
| dark patterns, & no observability/extensibility), and
| that's made me care a lot less about React-Native &
| Flutter & the like there. But if Flutter's really running
| bad too: that's embarrassing and not good, straight up!!
|
| However, two things. The first is a repeat: it won't
| always be bad. This team is going to make this fast.
| There aren't _real_ encumbrances to that happening & it
| will, is what my reading of the tea leaves says. Mostly
| gut feel, yes, but the plan seems solid. On the web,
| they're only just getting WebGPU booting, and still using
| older Dart VMs rather than actually compiling to wasm, so
| the web in particular is just barely getting started, but
| I'd expect the mobile situation has gobs of tuning
| potential too, and the team seems capable & smart & like
| they have the mandate to bring it. Their new Impeller
| optimizations to underlying Skia are just landing &
| already should help a lot, for ex.
|
| The other point I'd just raise is the Electron/Slack
| problem. People all assume Electron is unbelievably awful
| & slow & terrible, because they used Slack a couple of
| times & saw it responds slowly. When an app is bad,
| people tend to blame the framework. Electron is not
| without sin, but there are examples like vscode where it
| is quite snappy & fast & universes more featureful &
| expansive-in-purpose than Slack. No matter what your
| development target, it's possible to make slow & bad
| apps.
|
| I have no real insider knowledge of the Flutter app
| situation today, the lay of the land, but I'd caution too
| much against using current bad apps as an indicator of
| what to expect, caution against letting current
| experience too deeply/permenantly shape our
| belief/disposition (lest these form convictions which
| lead us astray from the truth everyone else experiences).
| More than UI, issues like Client-server data models &
| algorithmic complexity are woefully under-considered
| everywhere. Few businesses have a chain of command that
| speaks the tech language well enough to keep the ship
| from bottoming out or from not just rubbing along the
| seabed as it travels. It would be unshocking in the least
| to me to find a bunch of the big name Flutter apps are at
| Slack levels of quality internally.
|
| Then again, maybe it is partially or all Flutter's fault!
| Maybe I'm wrong and it stays terrible forever! But the
| Highest Form of Disagreement is to assume these problems
| are surmountable, and I don't see anything really
| strongly technically impeding success (if having native
| widgets isn't somehow a requirement).
| LinguaBrowse wrote:
| I think there's potential in those ideas, if only they are not
| to the detriment of the Web (which is already working just
| fine).
|
| As an alternative to iOS and Android development, I welcome
| ground-up solutions as long as they can get text editing right.
| However, I bring that up as I can't see anyone ever making a
| ground-up text view as reliable as a browser or native one
| (consider CJK, RTL, and vertical text, and IME input) without a
| dedicated team spending years of work and closely examining
| each platform's equivalent.
| nicoburns wrote:
| The Rust ecosystem (with cosmic text and parley) is well on
| the way to achieving this
| yw3410 wrote:
| 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!
| overthrow wrote:
| 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 just use native APIs on each
| platform to render text, then all these problems would
| already be solved by the OS/browser. Though I'm not sure
| if the web has good APIs for that.
|
| Maybe there's something better in Rust these days that I
| missed?
| EnergyAmy wrote:
| The worst part of flutter's web stuff is that the quality is
| absolute janky garbage. They're trying to undermine an open
| ecosystem, and they don't even offer anything useful in return.
| It's like making a deal with the devil except instead of
| getting the thing you bargained for, you just get stuck with a
| pitchfork and also you lose your soul.
| spion wrote:
| Almost every single programming language ever invented has to
| reinvent more or less the same ecosystem of libraries from
| scratch. What is the best estimate of how many hours of work that
| is per language?
| LinguaBrowse wrote:
| This short essay is a lament about how close we are to creating
| really good cross-platform solutions, but how we always fall
| short because of closing off our ecosystems to each other. I hope
| to spark a bit of conversation with this about how we can do
| better moving forwards!
| detourdog wrote:
| I see and understand the premiss. I disagree becuase the
| internet exists and any group can define or adopt a
| specification for inter-operation. The web is also part of the
| internet and has plenty of opportunity for development outside
| the norms. Let us move the conversation with out strawman
| arguments about what is holding us back. Let us move the
| conversation forward by demonstrating all the great things we
| can do right now. Almost any argument regarding constraints is
| more likely to boil down to some value dreamed up by a VC.
| Which is not a technical problem caused by proprietary tech.
| s1k3s wrote:
| I strongly disagree with most of the points in this article. Why
| does he blame small app developers for vendor lock-in? Why is
| everyone casually avoiding the fact that vendor lock-in comes
| from.. vendors? You think I want to rewrite the same app 3 times
| for it to work on Apple, Google and Microsoft systems? When is
| the last time these 3 major platform owners have done anything
| but locking you in their ecosystem?
|
| Such a weird take on this, really.
| juunpp wrote:
| I don't even know what the argument is either.
|
| Vendor lock-in on behalf of Apple, Google, and Microsoft, sure.
| But then:
|
| > but all frameworks are guilty. Electron, Capacitor, Tauri,
| Xamarin, Qt, NativeScript, the lot.
|
| Well, these all solve entirely different problems. Different
| problems, different solutions. Not sure what the "lock-in" is
| here. It's like arguing that there is "lock-in" because one
| project is written in C# and the other in Javascript. Seems
| like stretching the concept of "lock-in" too thin.
|
| > What I'd really rather see more of is standalone platform-
| agnostic modules
|
| This is a false proposition. A phone is very different from a
| desktop. "Platform-agnostic" would mean a denominator so common
| that it isn't useful for anything. Again, different
| problem/hardware, different solution.
|
| The rest of the post just devolves from there.
| Kinrany wrote:
| > It's like arguing that there is "lock-in" because one
| project is written in C# and the other in Javascript. Seems
| like stretching the concept of "lock-in" too thin.
|
| This is absolutely an instance of lock-in. An ecosystem grows
| faster when it can borrow from other ecosystems but doesn't
| allow doing the same. This is exactly the same problem: there
| is no good FFI, so we have to write M libraries times N
| languages.
| akira2501 wrote:
| The sense I get is, things should be more open, but not too
| open, because then it would be harder to sell the app. They're
| hoping that a very unnatural state becomes the default because
| it would be more profitable for _them_.
|
| It's a selfish take.
| butterfi wrote:
| Good luck with that. Developers love creating frameworks and new
| ways of doing the same things. You might as well complain about
| how movies keep using the same plots.
| rafark wrote:
| Actually I do complain about movies being very similar.
| croisillon wrote:
| There are only two plots:
|
| (1) a developer creates a framework
|
| (2) web is more convenient than apps
| ipsin wrote:
| Content streaming is one case where I wish,wish,wish they were
| non-closed ecosystems.
|
| Make your offerings available via an API. Make the actual content
| stream with whatever DRM standards you (the "platform") need to
| feel comfortable.
|
| Let me wrap all my streaming services with a single platform,
| having decent search and ability for me to do automatic price
| arbitrage. Why rent on Netflix when it's free this week on Hulu?
|
| It could be so much better, but it's not.
| brookst wrote:
| Developers care about modularity, flexibility, and reusability.
|
| Users care about unique value.
|
| Vertical integration and differentiation lend themselves to
| building something unique and valuable.
| PaulDavisThe1st wrote:
| 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 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.
|
| Does it matter if N is 10 instead of (say) 5 ? I don't know.
|
| Does it matter if the N is segmented into "derived from 90s
| widget models" versus "derived from 2010's web models" ? I don't
| know.
|
| Is there any chance of a single toolkit that covers native
| desktop environments (which continue to be important for creative
| apps, high performance apps, browsers etc.), native mobile and
| browser based apps? I don't know, but it seems ... unlikely.
| Devasta wrote:
| If quality mattered then maybe the other toolkits would have a
| chance, but no one is looking at the web for that, they are
| looking to the one advantage that the web has that the others
| cannot hope to beat: They work around bureaucrats. At least in
| the enterprise, with desktop applications you need to deal with
| IT security losers who freak out when you ask that computers
| actually have useful applications, and god help you if you need
| to get a port opened.
|
| Forget that, just shove everything down port 443 and download
| the application over and over again until the end of time.
| mardifoufs wrote:
| Even in terms of quality, the web beats most of those
| platforms. Especially now, and especially when compared to
| GTK or Wx. You'd actually have an easier time building a
| native-like app using web technology than GTK or Wx.
|
| I guess that wasn't the case a decade back when the web for
| everything trend started, so your point about ease of
| use/bypassing stupid security policies is still right about
| how the shift started, I think. But that eventually led to a
| steady improvement.
| ttttt444yeak wrote:
| How did things end up this way? I'm massively frustrated by
| the stupidity of our security team and it gets worse each
| year. And I've tried to explain this stuff about web apps
| exactly like you just did but it never quite gets through,
| and when it does it gets a response like "well, we should
| probably find a way to restrict web apps as well".
|
| I know for a fact that none of the people doing systems
| administration that install this junk endpoint management
| software actually want to install it. And it's laughable that
| corporations can simultaneously claim to be implementing zero
| trust, while at the same time giving crowdstrike software
| more trust than anything ever had before everybody decided
| they wanted to chase buzzwords. It can take weeks for me to
| get a new hire set up with WSL right now. If I didn't like
| the people I work with I would have jumped ship a long time
| ago.
|
| Security teams have managed to threaten and bully their way
| into having more power than anybody else in IT. All the big
| stories about hacking is certainly part of it, but honestly I
| don't think that fully explains it. If I was a CIO paying an
| enormous amount of money for endpoint management and then saw
| something like solar winds happen, I'd probably have fired
| everybody on the security team that advocated those sorts of
| security strategies.
|
| In my mind, security is something that should happen deep in
| the backend and be handled mostly by programmers, DBAs, and
| the admins that handle application servers. Once the data has
| left those environments with somebody it shouldn't have you
| have already lost. No hacker has ever said "I breached the
| database, but then got stopped from exfiltrating data because
| somebody made it so the USB sticks don't work".
| polynox wrote:
| Security teams don't bear the costs of reduced productivity
| from saying no, but bear all the blame if they make a wrong
| decision to approve something. So they're heavily
| incentivized to say no.
|
| Like many principal-agent problems, it requires someone
| appropriately situated to weigh the costs and benefits.
|
| If that doesn't happen, it gets borne by someone, usually
| shareholders who pay in reduced profits and eventually
| capital destruction as these companies get ossified and
| disrupted.
| ttttt444yeak wrote:
| This was very insightful, I hadn't thought of it this way
| before. Thank you for your comment.
| makeitdouble wrote:
| > "I breached the database, but then got stopped from
| exfiltrating data because somebody made it so the USB
| sticks don't work".
|
| It might be a generational thing, at some point I know
| people actually had Napster running on their work computer,
| or were torrenting porn movies. That's how the whole
| Metallica thing happened. That feels absurd to me in
| today's corporate env., for better or worse the
| work/private split has really come a long way.
|
| Malware spread by physical media was also a thing for a
| while, it's not just about the getting stuff out, a lot of
| the restriction on USB is not getting things in.
|
| PS: on the "why" of all that...I'd say Windows. Platforms
| all have their weaknesses, but Windows opened the doors
| wider than anyone else IMHO.
| Devasta wrote:
| "You cannot be blamed for bad decisions if you make no
| decisions".
|
| Far easier to say no to everything, that way either your
| manager takes the blame when they overturn your decision or
| your are blameless when Shadow IT takes over.
|
| That, and it allows you skip the troublesome business of
| userstanding user needs.
| RodgerTheGreat wrote:
| This is also one reason why users in corporate environments
| solve so many problems with Excel: it's a powerful, easy-to-
| use tool for making custom "applications" (within certain
| constraints) that is already installed on your work machine.
| No approval process, no procurement, no IT staff involvement;
| just users getting things done with what they have.
| Waterluvian wrote:
| I don't necessarily disagree with any of this. But the toolkits
| first listed are all pretty poor if you care about aesthetics
| and UX.
|
| It's like making furniture with framing lumber and OSB. It'll
| work fine and be durable. But it just always feels not great.
| They generally feel, to me, a semitone sharper than portability
| with 90s Java applications.
| PaulDavisThe1st wrote:
| > But the toolkits first listed are all pretty poor if you
| care about aesthetics and UX.
|
| You think that _this_ is pretty poor in terms of aesthetics
| and UX?
|
| https://musescore.org/en/4.0
|
| Written with Qt. For at least 3 platforms.
| bombolo wrote:
| How can they look ugly when they just use the system look by
| default and can be themed to look like anything at all?
|
| Have you ever used any of them?
| PaulDavisThe1st wrote:
| 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 platform
| controller) is really felt.
|
| Yet they have very little to do with the "interior" (in-
| window) behavior of the app at all, despite being critically
| important.
|
| If we're going to continue with the construction metaphor,
| I'd say it's more like creating a lovely house that has
| unusual door handles, windows that open in strange ways, and
| a different LED lighting temperature than you're used to.
| Waterluvian wrote:
| 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 vast majority of users it isn't.
|
| And I don't think anyone wants to write the application
| natively thrice.
|
| When it comes to "mostly canvas" applications I find myself
| thinking about using game engines. They're portable and
| basically that: a canvas with some basic UI support.
| giantrobot wrote:
| The differences aren't always surface level aesthetics. Say
| in a toolkit the text input widgets don't support pasting
| content. An app using it will behave materially different
| than any other on the system. Not only that it might look
| ok but lack functionality necessary to the user.
|
| This is not hard to imagine since various UI frameworks
| have long had issues with different paste board systems on
| Linux.
| PaulDavisThe1st wrote:
| > Say in a toolkit the text input widgets don't support
| pasting content.
|
| That's a bug.
|
| > various UI frameworks have long had issues with
| different paste board systems on Linux
|
| In my experience on *nix (37 years, going back to SunOS),
| the paste board systems for X Window are very well
| defined, and the only UI frameworks that have "long had
| issues" with them are buggy and not widely used. Are you
| thinking of something in particular?
| giantrobot wrote:
| Pasting between Xlib, GNOME, and Qt apps was a shit show
| for _years_. The situation has improved significantly
| since the advent of Freedesktop.org but there used to be
| lots of problems. It doesn 't matter if a UX problem is a
| bug or design problem. A user doesn't control if some app
| decides to use some unpopular UI framework. It's a Linux-
| on-the-desktop problem no matter the ultimate cause of
| the issue.
|
| There's still issues today on Linux with keyboard
| shortcuts. Some apps use Ctrl+Shift and others use only
| Ctrl, there's no way to know what an app uses a priori.
| You have to hope the shortcut is displayed in the menu
| and you remember it when you need to actually use it.
| Different frameworks have different default shortcuts for
| common behaviors. Accessibility for any individual app is
| still hit or miss, same with localization and theming.
| Mac and Windows users don't face anywhere near the same
| impedance mismatch between various first and third party
| applications. Those systems are far from perfect but
| they're usually much more consistent UX than a Linux
| desktop.
| scarface74 wrote:
| The native side of things has been address very badly by cross
| platform tools. I don't want lowest common denominator shitty
| cross platform apps.
| gjsman-1000 wrote:
| Then, on the other hand, you'll rarely see Linux ports.
| Lowest Common Denominator apps have been a blessing for Linux
| users - we would have never had Visual Studio Code, Slack,
| Postman, and who knows what else otherwise; and you can't
| tell me any of their developers would've done the work to
| port everything to GTK or Qt otherwise.
| scarface74 wrote:
| 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?
| klodolph wrote:
| I mean, it depends on how much time you're spending in
| great, polished native apps. For work, I spend all of my
| time in VS Code, Chrome, Slack, and the terminal. It's
| hard to justify _any_ platform as being better if those
| are the apps you use, since they basically work the same
| on any platform.
|
| And then there are the people who spend day in, day out
| in programs like Photoshop, InDesign, Pro Tools, etc.
| PaulDavisThe1st wrote:
| At least two of the final three you mentioned run on
| Windows and macOS, meaning that somewhere there's a
| cross-platform layer for the GUI. And yet apparently,
| that works.
|
| There's a lesson there, though I'm not sure what it is.
| klodolph wrote:
| The lesson is that you can get great cross-platform UX if
| you have a massive budget. There's some cross-platform UI
| code, sure, there's also duplicated work.
|
| Photoshop was originally written using MacApp, so it must
| have gone through some extensive, extensive changes to
| get its first Windows version.
| scarface74 wrote:
| Adobe and Microsoft both have spent 30 years optimizing
| their development around supporting both Macs and
| Windows.
|
| But how much of the GUI is actually cross platform? Adobe
| famously used Apple's Carbon API and was very upset that
| it wasn't ported to 64 bit. There is a lot of Cocoa in
| both products.
|
| Microsoft use to brag that they had more Mac developers
| than Apple did.
| PaulDavisThe1st wrote:
| > But how much of the GUI is actually cross platform
|
| I find the idea that when Photoshop or Protools wants to
| open a dialog with a button, the developer creates two
| functions, one for Windows and one for macOS, completely
| unbelievable.
|
| There is almost without doubt some level of in-house
| cross-platform toolkit in place. It may not go as far as,
| say, Qt tries to, and it may differ in design philosophy
| from other similar toolkits, but they are not writing
| twice the code every time they have do something in the
| GUI.
|
| If I'm wrong, HN is the place to find out.
| scarface74 wrote:
| That's kind of backwards isn't it? If I am writing a
| banking app for both the web and mobile. My GUI
| development is going to be different. But I'm calling the
| same set of APIs. The backend isn't "opening a dialog
| box" to the front end. The developers would be designing
| a native dialog and calling backend shared codex
| PaulDavisThe1st wrote:
| 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 that they do not. Adobe has wrapped "dialog
| creation" (along with hundreds of other GUI abstractions)
| in their own cross-platform layer, and their GUI code
| calls that. This is the same thing done by pretty much
| any company developing for more than one platform.
|
| The approaches can differ a lot. For example, consider
| Reaper (another DAW). Its lead developer picked a tiny
| subset of the win32 API that he wanted to be able to use,
| and implemented that for macOS and Linux/X Window. Then
| he uses the (partial) win32 API for the entire GUI (with
| higher level stuff built on top of it).
| scarface74 wrote:
| True.
|
| But even then the reason I prefer my Mac is that it
| integrates with my personal hardware. I do log in to my
| personal account on my work Mac But I am careful about
| what gets synced.
| [deleted]
| lelanthran wrote:
| > 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 useful as a mid-range Windows /Linux laptop.
|
| If you're going to insist on using only non-xplatform
| native apps when on Mac, you're in a niche
| (image/video/sound editing, maybe?)
|
| 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.
|
| In over a year of using a Mac as a daily driver, I've yet
| to use _one_ non-xplatform native Mac application. so I
| am curious about what you non-xplatform native Mac app
| you are using.
| PaulDavisThe1st wrote:
| So what do you want?
|
| "Highest common denominator" doesn't make much sense in this
| context - it's functionally equivalent to lowest common
| denominator.
|
| You want N different implementations, 1 per platform?
|
| You think the cross-platform toolkits could be better? Do you
| have an explanation for why they are not?
| scarface74 wrote:
| I want native apps on my platform of choice that leverage
| the native capabilities of that platform. That's the entire
| reason I chose one platform over the other. Mac users
| complained about Word 6 forever ago when MS tried to use a
| cross platform toolkit and Apple's Windows app were just as
| bad.
| PaulDavisThe1st wrote:
| So you don't actually want cross-platform apps at all,
| but either single-platform apps, or apps developed
| independently for both platforms (because otherwise
| you're just talking about some in-house cross-platform
| toolkit).
| scarface74 wrote:
| Why do I as a Mac user care about cross platform apps?
| Even as a long time Windows user, why would I care about
| cross platform apps?
|
| I chose a platform because the platform and the apps meet
| my set of priorities.
|
| As far as how that affects Linux users, even if I did
| prefer Linux as a developer platform, why make it my
| daily driver instead of running it in a VM or with
| something like WSL2?
| bombolo wrote:
| > Why do I as a Mac user care about cross platform apps?
|
| Because there aren't enough macs in the world for people
| to make apps just for you, it seems.
|
| > why make it my daily driver instead of running it in a
| VM or with something like WSL2?
|
| Why run a fast OS when I can run the same fast OS within
| a slow VM and a bunch of other limitations?
| PaulDavisThe1st wrote:
| Well, you're obviously welcome to do whatever you want,
| but I personally regard this as backwards. I believe in
| libre software, because I believe it is ultimately going
| to be better for users (over what timescale, I can't say
| for sure, but longer rather than shorter), and better for
| developers and better for technology. So I want to work
| on a libre platform, to some extent regardless of the
| applications I need/want to use, and thus I pick Linux
| first and apps second.
|
| When the app is not there (e.g. a DAW), I merely choose
| to spend a few decades of my life developing it, thus
| destroying my ability to do what I originally wanted to
| :)
|
| As for why would you prefer Linux as the daily driver,
| that would depend a lot on what you were doing/needed. It
| is a technically superior in almost every respect (not
| every, but close). It has better audio latency
| performance, should that matter, better bandwidth for
| most things, is generally more customizable to your own
| preferences (though obviously other platforms may be
| customizable _enough_ ). Upgrades and maintainance is
| generally simpler and smoother. I like being in control
| of my technology in a way that Microsoft and Apple
| increasingly do not allow me to be.
|
| I'm not saying that you have to care about any of that. I
| do, that's all.
| scarface74 wrote:
| So you regard it as backwards that Apple and Microsoft
| give users what they prefer including a better user
| experience? Do you seriously wonder why the "the year of
| the Linux desktop" never came?
|
| And what good is this supposed "technical superiority" if
| it doesn't have any end use benefit? Does it integrate
| with my other hardware seamlessly like my headphones that
| switch automatically between my phone, computer and
| watch? I can start an SMS message thread on my phone and
| finish on my computer or if I'm sitting at my computer
| and my phone rings, I answer it from my computer? Does it
| give me 16 hours of battery life?
|
| And the Mac is kind of known to be great for audio
| editing if you're not aware and has first rate software.
|
| I haven't heard anyone say that the ARM based Mac are
| poor performers
|
| > I like being in control of my technology in a way that
| Microsoft and Apple increasingly do not allow me to be.
|
| Would I rather be "in control" of hardware that sounds
| like a 747 when you do something even mildly intensive
| with piss poor battery life by modern standards or have a
| laptop that I can actually work with on my lap and have
| 16 hour battery life?
| PaulDavisThe1st wrote:
| 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 anything Apple would sell
| me), despite Apple systems indeed having great audio
| subsystems.
|
| I rarely use headphones, but when I do they are studio
| quality ones that do not use bluetooth, and are fed via
| my studio gear, not random consumer devices.
|
| Look, I get that different users have different needs.
| I'm not trying to persuade you not to use Apple products.
| I just happen to think that the focus on "how good is
| this for my day to day needs" can obscure a more
| important long term truth. Farmers have been discovering
| this with John Deere for the last few years, another
| company that makes incredibly great hardware that is
| totally what their users need. It just turns out the
| Deere's model of buyer lock-in via repair control is now
| causing conflicts for those same users.
| scarface74 wrote:
| 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
| schrectacular wrote:
| It sounds like you are largely in agreement with GP, who
| says:
|
| "I chose a platform because the platform and the apps
| meet my set of priorities."
|
| You listed a wonderful set of priorities which put the
| philosophy and a certain kind of usability at the top. GP
| seems to value day-to-day UI/UX within the desktop.
|
| So question for you, with regards to cross-platform,
| insofar as you value it as a goal, is that to help spread
| the user base of libre software?
| PaulDavisThe1st wrote:
| > So question for you, with regards to cross-platform,
| insofar as you value it as a goal, is that to help spread
| the user base of libre software?
|
| Essentially, yes. As a developer, I'd like my work to be
| available to as many people as possible, and I'm not
| dogmatic enough to insist that they choose to use Linux
| or another libre OS as their platform. If I want users of
| other platforms to be able to use my work, I need to
| somehow do cross-platform development. That means either
| creating my own cross-platform toolkit, or using an
| existing one.
|
| As a side note, I'd also say that cross-platform
| development turns out to be great for finding bugs and
| design flaws in your software. Exposing it to other
| compilers, linkers and UI/UX design models has always
| been a positive experiences, even if often frustrating.
| dvdkon wrote:
| I suppose you don't, at least not as a user. But behind
| app availability, which _is_ a concern for you, is this
| whole debate about cross-platform apps. It 's likely that
| the only way you get to continue using your preferred
| platform and some new app/piece of hardware is if the
| developers use a cross-platform toolkit.
|
| When releasing software, macOS is a small tertiary
| concern for me at best, behind Linux (for myself),
| Windows and mobile platforms. So if you care about app
| availability, you indirectly care about cross-platform
| toolkits.
| PeterisP wrote:
| That's a false dichotomy, someone can want a cross-
| platform app that has shared code but the outcome is
| "native-like" on each of the platforms. If a cross-
| platform toolkit can't do that and people consider that
| its result is a bad fit to some of the platforms, it
| doesn't mean that these people don't want a cross-
| platform app, all it means is that this toolkit is not
| good enough.
| klodolph wrote:
| There are multiple explanations for why cross-platform
| toolkits are kind of awful. I'm treating "cross-platform
| toolkits are kind of awful" as an observation here, because
| I've used them, I've worked with them. And my measurement
| for awful is poor UX, relative to native apps.
|
| Different platforms are just slightly too different from
| each other to make it work well. So you end up with a bunch
| of cross-platform apps which are built on things like
| Electron. You more or less reject platform expectations for
| how apps should work, how they should look, or how they
| interact with other apps / other parts of the system.
|
| You end up with stuff like Spotify or Discord.
|
| Thing is--if I'm getting work done with this app, if I get
| paid for working with it, I'm going to pay for a better
| experience. Instead of using GIMP, I'll use Procreate,
| Photoshop, Pixelmator, whatever. Maybe I'll use Notepad++
| or BBEdit. Maybe I'll buy Pro Tools despite its cost, or
| maybe I'll buy a Mac just so I can use Logic.
|
| It is costly to just reimplement your UI for multiple
| platforms, but that's where the "closed ecosystems" come
| in. React Native is kind of a compromise between the Qt-
| style approach (cross-platform UX) and the native approach.
| You're given a framework which works with multiple native
| toolkits, and you can have a mix of cross-platform UI code
| and platform-specific UI code.
| PaulDavisThe1st wrote:
| > It is costly to just reimplement your UI for multiple
| platforms, but that's where the "closed ecosystems" come
| in. React Native is kind of a compromise between the Qt-
| style approach (cross-platform UX) and the native
| approach. You're given a framework which works with
| multiple native toolkits, and you can have a mix of
| cross-platform UI code and platform-specific UI code.
|
| I don't understand this claim at all. Qt (or GTK) let's
| you "escape out" to the "native" toolkit on Windows or
| macOS as needed.
|
| There are not multiple "native toolkits" on Windows or
| macOS.
|
| > Different platforms are just slightly too different
| from each other to make it work well.
|
| So basically, you're denying that it's possible to do
| excellent cross-platform apps at all. OK. I'm not sure I
| agree with that, but it's a position.
| Macha wrote:
| > There are not multiple "native toolkits" on Windows or
| macOS.
|
| This is just not true on Windows. What is native Windows
| these days? Win32? WPF? WinUI? Even if your view is that
| Win32 is the one true native toolkit, MS alone produces
| multiple abstractions over Win32 like Windows Forms or
| MFC.
| [deleted]
| Multicomp wrote:
| Honestly, if someone produced a book that said how to
| write win32 applications in a way portable enough that
| current distributions of wine would not have to do any
| special work to make them work, I would very strongly
| consider that option.
| PaulDavisThe1st wrote:
| My definition works like this:
|
| is there an API layer on which (a) everything else is
| based and (b) people sometimes use directly for app
| development? macOS: Cocoa/Quartz - yes
| and yes windows: win32 - yes and yes
| linux: X Window - yes, no (though of course Wayland is
| changing the "yes" a bit) GTK, Qt, WxWidgets,
| FLTK etc - no, yes
| Macha wrote:
| But that's my point, WPF (the Vista-7 era primary
| toolkit), is not based on Win32. Neither is WinUI (the
| 8-11 era primary toolkit) calling Win32 or WPF.
|
| Win32 is mostly used for legacy apps, you'll find some
| random usages still like pre-Win11 notepad or the
| services configuration menu.
|
| WPF is the primary UI framework of Windows Vista/7 and
| still the framework which the majority of the OS is in
| for Windows 8/8.1. It doesn't call Win32, it implements
| its own widgets, something that would most often be
| exposed in differences in high-dpi support. These do
| generally try to align with the Win32 widgets from that
| Windows version visually, but there's plenty of
| discrepencies.
|
| WinUI is the new framework which isn't even shipped with
| the OS as of the latest versions, but even if you're
| using the built in verison it's not calling Win32 widgets
| or WPF widgets, it's once again implemented a new set.
| The lower level APIs share some similarities with WPF as
| it basically started as a fork of WPF modified to
| implement Windows 8 UI patterns, but neither WinUI or WPF
| are implemented in terms of the other.
| PaulDavisThe1st wrote:
| Thank you for a brief update on the situation on Windows.
| I didn't know all that, and now I know a bit of it.
| catiopatio wrote:
| > So basically, you're denying that it's possible to do
| excellent cross-platform apps at all. OK. I'm not sure I
| agree with that, but it's a position.
|
| Can you name a single cross-platform application that is
| indistinguishable from a native application?
| PaulDavisThe1st wrote:
| I don't even know that this question means.
|
| Is Photoshop a cross-platform application? Protools?
| Chrome?
| scarface74 wrote:
| Photoshop has a shit ton of Cocoa and before that Carbon
| on the Mac. While the processing engine may be cross
| platform. The UI is mostly "native".
|
| And do you really want to bring up the battery killing
| Chrome as a great cross platform app?
|
| Safari is much more efficient and ironically from
| reports, so is Microsoft's Chromium based browser.
| PaulDavisThe1st wrote:
| I wasn't trying to name "great" cross-platform apps. The
| question was "what _is_ a cross platform app ".
|
| Is Chrome or Firefox a cross-platform app or not,
| regardless of how they shitty they may or may not be?
|
| > Photoshop has a shit ton of Cocoa and before that
| Carbon on the Mac. While the processing engine may be
| cross platform. The UI is mostly "native".
|
| Every GUI application that runs on macOS has a "shit ton
| of Cocoa" inside it. There's essentially no other way to
| create a GUI app for macOS, regardless of the toolkit you
| use. There's a separate question like "are the buttons
| drawn by Cocoa, or app-specific, or toolkit specific?"
| but I regard that as a separate question.
| scarface74 wrote:
| The discussion is about cross platform "frameworks"
| versus writing apps using the native frameworks.
|
| Adobe and Microsoft basically use native frameworks for
| most of their apps.
|
| It's the difference between most of Office and Teams and
| VSCode.
| mroche wrote:
| On the flip side, nearly all groups in the VFX industry
| author their apps with Qt and deliver across Linux,
| macOS, and Windows. The "native" side of things is where
| people usually end up having the most debate, typically
| around appearance. VFX and creative apps tend to choose
| to look and behave consistently across platforms within
| their own context, rather than trying to utilize the
| human interface guidelines (HIG) of each respective
| platform. The standard place where this differs is
| usually on the file picker component.
|
| That being said, even with these toolkits you can make
| applications that are themed and behave similar enough to
| the native runtimes that most users wouldn't notice. But
| that's a developer's choice to do so, or to completely
| customize the app for themselves and the UX they're
| looking to deliver.
|
| To me the concept of cross-platform desktop applications
| is pretty interesting, as when you include the Linux
| ecosystem into the fray it's not macOS, Windows, and
| Linux (Qt/GTK), but rather macOS, Windows, GNOME
| (libadwaita), KDE (KDE Frameworks), etc etc. And that is
| _significantly_ more difficult to support "native" for,
| even if the latter are using GTK and Qt under the hood of
| their respective platforms. Apple can make first party
| applications that abide exclusively by their HIG, and the
| same with Microsoft, but asking vendors targetting
| multiple platforms to do so and essentially support
| multiple versions of their apps to achieve "true native"
| when "seemingly" or "close-to" native via the toolkits
| widgets, built in theming capabilities, and backend
| abstractions are available can be a bit of a tall ask.
| scarface74 wrote:
| 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 same with Microsoft,
| but asking vendors targetting multiple platforms to do so
| and essentially support multiple versions of their apps
| to achieve "true native" when "seemingly" or "close-to"
| native via the toolkits widgets, built in theming
| capabilities, and backend abstractions are available can
| be a bit of a tall ask.
|
| And could that be part of the reason that Microsoft and
| Adobe - both with a multi decade history of writing cross
| platform apps that use the native frameworks of the
| target platform are really the only two software
| companies that are really still successful making desktop
| consumer/prosumer software?
| klodolph wrote:
| > I don't understand this claim at all. Qt (or GTK) let's
| you "escape out" to the "native" toolkit on Windows or
| macOS as needed.
|
| You're kind of fighting against Qt or GTK when you do
| that. Qt and GTK have their own widgets. React Native is
| more of a framework that uses native toolkits to begin
| with, so it starts out with much better alignment with
| platform expectations, and has better interoperability
| with platform features.
|
| > There are not multiple "native toolkits" on Windows or
| macOS.
|
| I'm confused by this comment. I don't know what kind of
| point you are trying to make here, or what you are
| responding to.
|
| > So basically, you're denying that it's possible to do
| excellent cross-platform apps at all. OK. I'm not sure I
| agree with that, but it's a position.
|
| Yeah, let's dial the "it's a position" condescension back
| one or two notches.
|
| When I said, "Different platforms are just slightly too
| different from each other to make it work well," the "it"
| refers to cross-platform toolkits like GTK and Qt, which
| provide their own widgets. This explains why so many
| people use Electron and just embed a web browser (let's
| say "fuck it" and make one UI inside a big window), or
| choose to use something like React Native. Maybe I'm
| drawing too fine a line here--I think of Qt and GTK as
| cross-platform toolkits, I think of React Native as a
| framework without the toolkit parts, and I think of
| Electron as some kind of cross-platform box that you can
| something inside. I'd rather not talk about the
| definition of "toolkit" or "framework" because the
| definitions are not material.
|
| Qt is a big honking mess, and GTK is worse. Speaking as
| someone who has written apps using both, and fixed UI
| problems in people's open-source Qt and GTK projects.
| PaulDavisThe1st wrote:
| > 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.
| PaulDavisThe1st wrote:
| > This explains why so many people use Electron and just
| embed a web browser
|
| I would wager there are 100x the number of Qt/GTK apps
| than there are electron apps. That number could go up or
| down by an order of magnitude, and the older widget-based
| toolkits would still be ahead. So ... I don't think that
| citing numbers of developers doing X or Y is helpful
| here.
|
| > React Native is more of a framework that uses native
| toolkits to begin with, so it starts out with much better
| alignment with platform expectations
|
| More similar to WxWidgets then, which uses native widgets
| but wraps them in lowest common denominator API. For one
| reason or another WxWidgets hasn't been as successful as
| one might expect.
|
| Anyway, as I've noted elsewhere in this thread, the
| majority of creative apps (including Logic) barely use
| any of the native toolkit within their main windows.
| Almost all DAWs, drawing programs and image editors just
| treat their windows as a big 2D drawing surface, and do
| their thing without regard for UI/UX widgets or rules
| designed around productivity/business/system utility
| apps. The "native" aspect kicks in only when they
| interact with the rest of the desktop environment, and
| they vary quite a bit in how native they go (they also
| keep changing this; Logic has gone back and forth with
| using the native file browser vs. an app-specific one
| several times over its life, and in different contexts
| within the app).
|
| This also has implications for the extent to which
| Qt/GTK/etc. toolkits impact the UX. If someone writes a
| widget-heavy app, then the toolkit design &
| implementation will have a strong impact. If the widgets
| are limited to some toolbar at the top, it doesn't really
| make a lot of difference as long as the devs get system
| tray/notification right, and don't screw with window
| management.
| klodolph wrote:
| > I would wager there are 100x the number of Qt/GTK apps
| than there are electron apps. That number could go up or
| down by an order of magnitude, and the older widget-based
| toolkits would still be ahead. So ... I don't think that
| citing numbers of developers doing X or Y is helpful
| here.
|
| If making the comparison is not helpful, then why make
| the comparison in the first place? I was just observing
| that "many" developers made the choice to use Electron; I
| am not trying to compare numbers of developers here.
|
| > More similar to WxWidgets then, which uses native
| widgets but wraps them in lowest common denominator API.
| For one reason or another WxWidgets hasn't been as
| successful as one might expect.
|
| Yeah, although I think WxWidgets abstracts too much.
|
| Maybe I can frame it this way--I'm not really against
| cross-platform toolkits in the first place, and I'm not
| complaining about cross-platform toolkits on a conceptual
| level. I do think that apps made with cross-platform
| toolkits _often_ have UX problems and I think part of the
| reason is because the underlying platforms are too
| different. Those differences are both (edit: fix)
| technical differences and differences of conventions /
| expectations.
|
| React Native seems to have less abstraction. Maybe that's
| just my subjective thoughts on it.
|
| > Anyway, as I've noted elsewhere in this thread, the
| majority of creative apps (including Logic) barely use
| any of the native toolkit within their main windows.
|
| Sure, if you focus narrowly on the main content of the
| main window, you'll see less of the native toolkit being
| used. But that's only one part of the app, and it's still
| built to match platform expectations, in a way that is
| not easily abstracted out by cross-platform toolkits.
|
| Logic is a bit of a funny example because Apple has a
| separate set of "pro" widgets they use for their creative
| apps, like Logic and Final Cut. You can see that, for
| example, Logic has a decent number of .nib files, which
| means that it's making use of the native toolkit, even if
| it's not everywhere.
| Macha wrote:
| Is Photoshop a native application? It sure doesn't act or
| feel like one on Windows. It seems to be just using an
| Adobe in-house cross-platform abstraction. Maybe you like
| that abstraction's output more than web platforms, but
| that's a different matter.
| CharlesW wrote:
| https://www.theverge.com/2013/2/13/3959868/photoshop-is-
| a-ci...
|
| _" Somewhere, deep down under the streets of Photoshop,
| down where the mole people live, is a little framework
| called "MacApp." It's a remnant from the very first
| versions, a fragment of foundation. MacApp originally let
| Photoshop communicate with the underlying operating
| system, which was then Mac OS 6.0.3."_
| culi wrote:
| Look at WebGPU. Still a WIP, but it shows that you really
| CAN provide a performant cross-platform... platform if
| you're really thoughtful about performance
| PaulDavisThe1st wrote:
| 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.
| scarface74 wrote:
| And will it look and act like a native app? Will it
| support all of Apple's built in accessibility affordances
| that a developer can get for free by using Apple's native
| toolkits (and Microsoft's)?
| PaulDavisThe1st wrote:
| a11y is definitely a critical and often overlooked issue.
| And this is one area where I find myself in 110%
| agreement with the title of TFA: Stop Building Closed
| Ecosystems.
|
| If the Apple and MS a11y frameworks were not so distinct
| from one another, wrapping them in a cross-platform layer
| would be much easier. But they couldn't be bothered,
| largely because they both have enough users whose
| priorities match your own: are the apps on the platform
| good enough for them. The incentives to standardize a11y
| at the API level across OS platforms is a tiny fraction
| of the incentive to standardize e.g. WebGPU.
| k__ wrote:
| Every now and then I meet a Qt dev who's whining about how
| Electron stole their lunch.
|
| If something like Electron stole your lunch, Qt obviously had
| serious problems.
| spion wrote:
| There is still an opportunity for Qt to win in this area -
| they should make it really easy to create (well documented)
| bindings for new languages (that integrate with their
| runtimes)
| bombolo wrote:
| Do you also meet chefs complain about how mcdonald takes work
| away?
| dasil003 wrote:
| This is utopian thinking that disregards how software ecosystems
| actually work in practice. Take the opening sentence:
|
| > _In the world of mobile development (though likely also
| elsewhere), we sink so much engineering talent into making tools
| that are great within-ecosystem, but as we don't bother making
| them available to other ecosystems, everyone ends up reinventing
| the wheel._
|
| I get the frustration with software churn and substandard tooling
| when you have to code for multiple platforms, but this is a very
| hand-wavy admonishment. Leaving aside who "we" are and what our
| cross-platform responsibilities are for the moment, how would
| this even work? Different platforms have different capabilities.
| Cross-platform tooling will therefore always be more complex and
| less capable than platform-specific tooling.
|
| One could then argue that we should consolidate platforms, which
| generally will be more efficient, but who will be responsible for
| this platform? Whether closed or open, you are now in a situation
| where one platform has to be all things to all people, and that
| means there will be tradeoffs that hurt someone. I'm a happy iOS
| user, but I'm sure glad Android exists because diversity is
| healthy.
|
| Technology will always trend towards consolidation because bits
| are cheap and easy to move, and there's always an incentive to
| harness economies of scale. The problem is mono-cultures are
| brittle. Some amount of "reinventing the wheel" is just the cost
| of a healthy and diverse software ecosystem. The OA should be
| careful what he wishes for.
| detourdog wrote:
| I feel these complaints are misguided. If anybody thinks an Apple
| II was the good old days should lose their mind with this
| computer.
|
| https://www.analog.com/en/products/max78000.html#product-ove...
|
| This has all the freedom one could need and amazing computing
| power. If one needs a non-propriety way to reach iOS users use a
| webpage.
|
| Nobody is stopping anyone from making the next big thing.
| hammyhavoc wrote:
| People invoke corps when discussing this problem, but fail to
| realize that publicly traded stocks only care about monetary
| value; that's why they're there. Any notion of bettering humanity
| or doing something sensible in terms of software is purely
| secondary. They're a business.
|
| Is it any surprise that tech is the way it is with this in mind?
| Is it frustrating? Absolutely. Is it as expected? Yup.
| apsurd wrote:
| The main problem is who gets to decide on the one anointed
| approach. Diversity ends up being a good thing, and also makes
| everything more messy and more complex.
|
| Take your example of the Open Web. I wouldn't be in software
| without the Open Web. I hand-write HTML and CSS to this day! But
| many people hate the web stack. They hate the ergonomics and
| enjoy better ecosystem for nearly every possible thing
| implemented in the web. I think ultimately, that's ok and it's
| "worth" having competing standards, because the alternative is -
| pardon the dramatics - authoritarian.
|
| edits:
|
| > #2) Check for prior art first. The problem may have been solved
| before...
|
| I generally take issue with the statement "this is a solved
| problem". It ends up killing critical thought on the vine. I
| think everyone is better served thinking critically, and yes
| maybe something off the shelf is the right choice. But think
| critically, and freely, first.
|
| > #3) "be opened-minded to other approaches"
|
| contradicts the idea of building one-thing all-together no?
| LinguaBrowse wrote:
| I think the point is that the decisions on direction shouldn't
| be made behind entirely closed doors by insiders. Outside input
| should be taken seriously, with invitation to dialogue, rather
| than chasing some narrowly-supported vision.
|
| As a web developer myself, I too am baffled by the folks who
| don't like the Web stack, but fine.
|
| And good points, I guess I wasn't too concrete on "unify on one
| approach" vs. "consider all options". So to solidify my
| thoughts, I do think diversity in approaches is a good thing.
| It would just be great if any parts could be shared so that
| others could iterate on the same idea.
|
| For an example of a missed opportunity for diversity, if only
| React Native had originally architected itself as Reactless
| Native + React, we could've had equivalents for each different
| renderer by now (e.g. Vue Native, Angular Native) based on that
| Reactless Native base.
|
| For an example of the merits of unifying on one approach, see
| Yoga Layout. Flexbox has proven to be an agreeable layout
| model, and because it's so solid (apart from where it varies
| from the spec, which I do grumble about) various different
| cross-platform projects have benefitted from unifying around it
| as a reliable building block.
|
| I guess my grumbles with Yoga's spec deviations echo your
| distaste for the "it's a solved problem" sentiment, too. Even
| established solutions should be open to improvement and
| evolution, and I had that partially in mind when talking about
| being open-minded.
| culi wrote:
| > I hand-write HTML and CSS to this day!
|
| Yeah but... for your job? I'm sure we all do those side
| projects, but hard to imagine being able to do that on a
| complex multiple-member team project
| Mezzie wrote:
| Not everybody who's coding is doing it in a tech company on a
| complex multiple-person team project. I'm a software
| mechanic: I do really small scale tweaks for small businesses
| (I mean SMALL - my current project is for a business with one
| owner and 2 employees), non-profits, libraries, etc.
|
| In those use cases, there can be good business reasons to do
| things this way: Part of my current project is building
| something where odds are there won't be another tech person
| around regularly and it needs to last for several years (the
| information is evergreen). For something I want to run for 8+
| years with minimum fuss that doesn't require storing user
| data and that may need to be ported from LMS to LMS or
| eCommerce platform to eCommerce platform/won't be broken by
| updates (because again, no regular dev to maintain it and
| check compatibility), using basic HTML, CSS, and even vanilla
| JS can make sense. I can write something in HTML/CSS/vanilla
| JS and it will probably run in browsers until the heat death
| of the universe.
| apsurd wrote:
| I count writing JSX as hand-written as the child comment
| mentions. Also HAML in rails. I realize this perhaps is a
| fuzzy definition as we move along the spectrum of automation
| and abstraction.
|
| What I mean to say is I still have a more-or-less 1:1
| relationship with both HTML and CSS APIs to affect user
| interfaces. Like how do make round corners I need to know
| `border-radius: 100%`, or `borderRadius: 1rem`, etc
|
| (And you're right, in all projects where "I have my way"
| meaning it's personal or in a small-group, I have the freedom
| to choose low-level vanilla primitives. Less so at work in
| large teams where everything is a build pipeline.)
| klodolph wrote:
| I think writing a React component using JSX counts as "hand-
| written" HTML and CSS. Definitely when you're writing the
| low-level components that other stuff is built on.
| mvuksano wrote:
| I think about these frameworks as products. They are meant to
| solve specific problem for specific audience. I also think we
| need to start differentiating between different classes of
| developers. I think a good analogy is car mechanic vs mechanical
| engineer. when a car is made there will be a lot of need for
| mechanical engineering. Once it's on the road and needs to be
| fixed is when car mechanic comes into play. You need to decide
| whether you want to be mechanical engineering or a mechanic -
| skillet is very different.
___________________________________________________________________
(page generated 2023-04-15 23:01 UTC)