Hacker News new | ask | show | jobs
by azangru 1668 days ago
So write an application multiple times in multiple languages, package it into different packages, and distribute them through app stores? Oh, and desktop Linux users are out of luck because their market share is so tiny, and their distros are so numerous and chaotic that no-one is going to bother spending time and money on building applications for those poor sods. Is this the idea?
3 comments

How about write an application specifically designed to execute code that you give it in a safe environment. Then you only have to make that application crossplatform and everyone can target it instead. People write for the browser because it is a sandbox, store front, package manager, UI kit all rolled into one. If some smart cookie decides to forget about the web and build to that spec they could come up with a better alternative.
I've thought about this. The thing is that the current relevant browser environments (basically Safari, Chrome, and Firefox) require, what, a billion dollars a year to maintain? 2 billion? And this doesn't even count the various JavaScript frameworks, auth systems, CDNs, etc.

Any replacement technology/protocol which does the same "write once, use everywhere" thing and manages to perform better would still need to achieve wide adoption. And I feel like users would still want that to be able to play seamlessly with everything in their lives that they have online.

It would certainly be a challenge but there are examples of cross platform applications that have succeeded in the market. The Godot game engine is a good one since it does a similar thing for a different segment of the market. It's cross platform and allows you to build applications that target those platforms and more (even the web!). So these things are within the reach of a small team, or even a single dedicated individual. The important thing is to focus on what matters. Providing a safe environment to run code downloaded from strangers, a set of configurable UI elements and an API for making network and storage requests. You're basically building a VM with a UI kit and some networking. You could probably bootstrap up from something simple since it would likely be a fun platform to target for hobbyists, if you could build a community or scene around it.
Which step in that process could not be automated? What's so fucking difficult on either writing a Cross-Platform UI or using a Cross-Platform framework?

<rant>

Is it not instead the case that today's hipster developers simply want to ignore that platforms exist beside their fancy McBooks? Is it not the case that today's developers prefer a bizarre interpreted untyped language simply because that's what they learned for building websites and they don't want to put up the effort to understand what a type system is? Is it not true that the same developers pull in dependencies reflexivly and never consider long-term maintenance, let alone such weird concepts like supply chain security? And finally did not some hip leaders invent the microservice architecture to cater to these idiots? Because it's nowadays simpler to have a huge, inefficient, pile of services that hides all complexity in the communication between these services than to have one well-designed, efficient system?

</rant>

Sorry for the rant, but sometimes I feel like the industry is actually regressing because many developers are simply lazy morons that hide behind buzzwords.

Please suggest a cross platform framework that doesn't come with accessibility issues, that also allows you to create as rich ui's like what you can do in a browser, and without various licenses that restrict what you can do with your code? Something that supports Android, iOS, Linux, Windows and MacOS.
I feel that it's cheating here to include android and ios in this list, since so much stuff that is developed either:

  * is only for those two (and sometimes only one of those) platforms

  * the preferred "version" on those platforms in an app, rather than web-based 
It's clear from the scope of the mobile app market that there's a huge marketplace for a kind of application that essentially never existed on desktops. It seems a little bold to insist that the same x-platform toolkit must service mobile and desktop contexts, when so much is different between them, in particular display size and interaction style. Even more so when the evidence seems to be that not even the web has really managed to do this.
And yet HTML+CSS+JS which is so hated for making applications handles the use case of working across mobile and desktop almost perfectly. Maybe it's not just because we don't want to learn real programming like the grandparent post insinuated and instead a perfectly viable solution to the problem at hand.
If it is handled so perfectly by web tech, why do mobile apps exist?
Easier to track you.
You are probably looking for Qt.
Doesn't fit the part about licenses that restrict what you can do with your code:

"Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations." https://www.qt.io/licensing/

One of the "open source" licenses that it is under is LGPL, you can do whatever you want with your code. (Although this does not mean that you should, please avoid publishing closed source software)
It's not a bad suggestion, but it still doesn't satisfy the requirement. You can't put it all in a single executable if that is what you want
> What's so fucking difficult on either writing a Cross-Platform UI or using a Cross-Platform framework?

It's been a long time since I used a cross-platform framework so maybe things have gotten better but what used to happen was that I'd run across something in them that didn't work right and then I'd have to do one of:

1. Just not use that in my application,

2. Implement that thing outside the framework which required me to (1) know how to do that thing natively and (2) figure out how to make my implementation work with the rest of the app that was using the framework, or

3. Figure out how to fix the bug in the framework which required me to (1) dive into the framework's internals and (2) probably required me to know how to do the thing natively.

Framework internals are complicated. This complexity is expected--when you are writing a native application you only need the complexity that is inherent in doing whatever it is that application is doing whereas a framework has to be flexible and general enough to serve the needs of a wide variety of applications.

If the framework is going to make me dive into its internals to get it to work there is a good chance that the total effort of making my app run on two or three platforms via the framework will be more than writing separate native apps for those platforms.

Many developers in the industry have simply realized that the flexibility of html/css/js is simply unmatched by any other technology out there. Nothing else out there has been subjected to such extreme levels of scrutiny the web has. Nothing. Afaik, even the Dragon capsules use it for the UI layer.

But since you're such a boi genius, make something that can match and get ahead of it and i'm sure everyone will jump on your boat. Until then, your opinion will remain objectively useless.

Pyramids were also built with a lot of effort. But in the end it was a pile of stones. Architecture was created when labor and material saving technology like the arch was invented. We are in the pyramid phase with the web.
I understand what you are trying to say but you could not have picked a worst example in your analogy. I mean an arch in the end will also be a pile of stones. On top of that we have no idea how the pyramids were made, their precise dimensions and alignment would be extremely hard to replicate using modern technology.

I say we are the arch phase of the web, we understand the arch and it has served us well and it does save a little bit on materials. What we want to do is create bigger and better engineered structures like the pyramids.

Well since you know what phase we're in, and that we're in a phase even, then surely you must know what and when the revolution is. So cut the chatter and get us there. Why waste time?
Buzzwords like type system?
Or target the JVM, ship jar files, and solve the problem ~25 years ago.
We need an improvement, not a regression.
Jar files are a single file portable to all major platforms (and many minor), that can run offline and have entirely acceptable performance with modern versions and modern hardware (i.e. slower than C but perfectly good if JS in a browser is the comparison). They have inferior security vs browser sandboxing but better no worse than a native binary. Other than being "old", what exactly is the regression?
The webassembly crew is pretty much doing exactly this.

They've worked pretty closely with the folks who designed java bytecode, to try to learn from their institutional knowledge (repeating what they felt they did well, but learning from their perceived mistakes).

It hopefully will end up really nice, because it could provide us with a machine-agnostic IR that will work everywhere, have high performance, and if it becomes popular on the web, I could it leaking into the desktop space and starting to become a standard there as well.

I wish we still had applets. They sucked on dial-up, but that's not really a problem anymore.