12 ms·

Stop Building Closed Ecosystems

158 points by LinguaBrowse 4y ago

LinguaBrowse 4y ago
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 4y ago
  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.
brookst 4y ago
Developers care about modularity, flexibility, and reusability. Users care about unique value. Vertical integration and differentiation lend themselves to building something unique and valuable.
apsurd 4y ago
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 4y ago
  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 4y ago
  > 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
  - klodolph 4y ago
    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.
  - apsurd 4y ago
    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.)
photochemsyn 4y ago
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/ https://itsfoss.com/open-source-alternatives-android/
- LinguaBrowse 4y ago
  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 4y ago
    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 4y ago
      Why is it a “sad” lesson that users have preferences that are not in line with developers?
      - tannhaeuser 4y ago
        It's sad for developers, I guess ;)
      - muyuu 4y ago
        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.
rektide 4y ago
This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%22&sort=byDate&type=all 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.
- LinguaBrowse 4y ago
  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 4y ago
    The Rust ecosystem (with cosmic text and parley) is well on the way to achieving this
PaulDavisThe1st 4y ago
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.
- scarface74 4y ago
  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.
  - PaulDavisThe1st 4y ago
    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 4y ago
      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.
detourdog 4y ago
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-overview 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.
znpy 4y ago
Qt is fairly open, I don’t get why the author doesn’t point at qt for a valid alternative.
- fatneckbeard 4y ago
  first rule of qt is nobody talks about qt
- LinguaBrowse 4y ago
  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 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.
- vinyl7 4y ago
  Qt is awful. Its basically the equivalent of boost but for UI
- marsven_422 4y ago
  [dead]
asdfman123 4y ago
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 4y ago
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 4y ago
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 4y ago
  An open ecosystem can be used by more than one closed ecosystem.
mvuksano 4y ago
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.
thealchemistdev 4y ago
Whatever Jamie. (Nice blog name) Move out of the technician role and into either stake holder or owner, then run your mouth. ;)
s1k3s 4y ago
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 4y ago
  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 4y ago
    > 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.
    - juunpp 3y ago
      I agree that M libraries x N languages is an absurd reality (and why I still write C), but "lock-in" to me suggests intent, and the situation you describe is more accidental, at least if you exclude corporate languages like .NET and such.
butterfi 4y ago
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.
- croisillon 4y ago
  There are only two plots: (1) a developer creates a framework (2) web is more convenient than apps
- rafark 4y ago
  Actually I do complain about movies being very similar.
hammyhavoc 4y ago
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.
rafark 4y ago
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 4y ago
  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 4y ago
Like everything else you have to trade off some other properties to prioritize this sort of “openness.”
samsquire 4y ago
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.
sfpotter 4y ago
Stop writing articles titled "Stop Doing X".
- ammarahmed6506 4y ago
  Stop adding comments starting with "Stop bla bla bla".
ipsin 4y ago
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.
spion 4y ago
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?
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
dasil003 4y ago
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.
solarkraft 4y ago
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.

158 points by LinguaBrowse 4y ago

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 4y ago
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.

brookst 4y ago

Developers care about modularity, flexibility, and reusability. Users care about unique value. Vertical integration and differentiation lend themselves to building something unique and valuable.

apsurd 4y ago

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 4y ago
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 4y ago
> 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
- klodolph 4y ago
  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.
- apsurd 4y ago
  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.)

photochemsyn 4y ago

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/ https://itsfoss.com/open-source-alternatives-android/

LinguaBrowse 4y ago
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 4y ago
  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 4y ago
    Why is it a “sad” lesson that users have preferences that are not in line with developers?
    - tannhaeuser 4y ago
      It's sad for developers, I guess ;)
    - muyuu 4y ago
      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.

rektide 4y ago

This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%22&sort=byDate&type=all 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.

LinguaBrowse 4y ago
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 4y ago
  The Rust ecosystem (with cosmic text and parley) is well on the way to achieving this

PaulDavisThe1st 4y ago

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.

scarface74 4y ago
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.
- PaulDavisThe1st 4y ago
  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 4y ago
    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.

detourdog 4y ago

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

znpy 4y ago

Qt is fairly open, I don’t get why the author doesn’t point at qt for a valid alternative.

fatneckbeard 4y ago
first rule of qt is nobody talks about qt
LinguaBrowse 4y ago
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 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.
vinyl7 4y ago
Qt is awful. Its basically the equivalent of boost but for UI
marsven_422 4y ago
[dead]

asdfman123 4y ago

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 4y ago

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 4y ago

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 4y ago
An open ecosystem can be used by more than one closed ecosystem.

mvuksano 4y ago

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.

thealchemistdev 4y ago

Whatever Jamie. (Nice blog name) Move out of the technician role and into either stake holder or owner, then run your mouth. ;)

s1k3s 4y ago

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 4y ago
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 4y ago
  > 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.
  - juunpp 3y ago
    I agree that M libraries x N languages is an absurd reality (and why I still write C), but "lock-in" to me suggests intent, and the situation you describe is more accidental, at least if you exclude corporate languages like .NET and such.

butterfi 4y ago

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.

croisillon 4y ago
There are only two plots: (1) a developer creates a framework (2) web is more convenient than apps
rafark 4y ago
Actually I do complain about movies being very similar.

hammyhavoc 4y ago

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.

rafark 4y ago

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 4y ago
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 4y ago

Like everything else you have to trade off some other properties to prioritize this sort of “openness.”

samsquire 4y ago

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.

sfpotter 4y ago

Stop writing articles titled "Stop Doing X".

ammarahmed6506 4y ago
Stop adding comments starting with "Stop bla bla bla".

ipsin 4y ago

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.

spion 4y ago

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?

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

dasil003 4y ago

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.

solarkraft 4y ago

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.