4 ms·

Then nobody will go back to making native apps

olliej 3y ago
Yes, the problem is easy crappy apps are cheaper for developers even if they're worse for users. The alternative "single UI framework" is "everyone must run the same OS". As long as people keep buying/using crapware apps that's all that will happen. The fact that so many people are ok with that mediocrity is depressing, but that they do so while then complaining about things being slow is actively annoying.
- novagameco 3y ago
  It is totally possible to have a "runs on anything" UI framework; it simply has to have bindings for every applicable platform. SDL does this, for example, in 2D Graphics. Java has a few "run anywhere" UI frameworks, and Microsoft has .Net Maui (as well as the 3rd party avalonia UI). The problem with most native frameworks, however, is they are nowhere near as flexible as HTML and CSS (which many pre-teens taught themselves as a way to customize their tumblr and myspace pages). Other frameworks, by comparison, require programming knowledge or more setup than just a text editor (usually requiring an IDE and the rest of your toolchain). I can see native software making a comeback if it is: 1. Declarative: only software engineers like imperative UI systems 2. Flexible: some frameworks (like any of the XAML-based ones) are strongly typed and you can only combine certain XAML elements with other certain XAML elements, and will fail to compile entirely if you mess something up 3. Unopinionated: HTML, CSS, and Javascript don't require you to implement any particular paradigm for getting data on the screen; that is left up to the coder 4. Dead ass simple: the litmus test is that a 7th grader should be able to learn the basics of it on their own, and the tooling should be ideally no more complicated than a text editor 5. Totally sandboxed: You can't trust 99% of frontend devs with security The people you need to appeal to are not hardcore software engineers, but hobbyists and newbies, since they end up being the majority of frontend devs anyways. Honestly I think you could get pretty far with just adding declarative languages (read: XML) to existing native frameworks, like gtk and Win32.
  - fulladder 3y ago
    Your post is thoughtful. Why do you care so much about declarative? I tried SwiftUI last summer to see what it was about and I find the whole style rather awkward. Writing a desktop app in XML sounds even worse. And I'm not seeing the benefit to the user. With an imperative coding style, you can more directly control the user experience and give them the best one.
    - novagameco 3y ago
      With an imperative style, you need to learn a programming language before you can start making applications. With HTML, you can start making applications immediately by just writing HTML, and then you can learn the programming language (javascript) later. It's a barrier to entry for non-engineers
  - olliej 3y ago
    The problem is not putting bits onto the screen, that's all SDL does. It does not integrate at all with the host platform, to an even greater extent that chrome based crapware. 1. That's an opinion, not a fact, and most "declarative" UI frameworks have poor performance and can't do anything not explicitly models by the declarative framework. The fact that people want to just draw a UI doesn't mean that the resulting UI is either good, or works correctly, and the idea that it's "easier" simply implies lower understanding of what is being done and that you aren't considering any of the edge cases you still need to handle. 2. Not sure what to say here, as I don't know your point? it seems more about the type system of your language and not at all related to the ui toolkit 3. This is BS. html, css, and the DOM all have a very clear model for how and what a UI is, claiming it isn't means that you haven't apparently spent much time working in any other system. Much like I keep meeting people who say that they don't have an accent, everyone else does. 4. Application development is conceptually complicated unless your application is not doing anything interesting. I'm also curious what makes a browser ui more "simple" than say Cocoa? 5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are. Application development is hard, and it's not because of the UI framework you're using. The overwhelming amount of any actual application is the application logic, not the UI. Chrome based apps are all abysmal because to make an actual application using a browser engine, you need to reimplement, in html+JS, a huge amount of work the host OS would otherwise just provide for you. If all you want is a webpage, just make a webpage, don't force everyone to download a 600Mb copy of chrome.

Yes, the problem is easy crappy apps are cheaper for developers even if they're worse for users. The alternative "single UI framework" is "everyone must run the same OS". As long as people keep buying/using crapware apps that's all that will happen. The fact that so many people are ok with that mediocrity is depressing, but that they do so while then complaining about things being slow is actively annoying.

novagameco 3y ago
It is totally possible to have a "runs on anything" UI framework; it simply has to have bindings for every applicable platform. SDL does this, for example, in 2D Graphics. Java has a few "run anywhere" UI frameworks, and Microsoft has .Net Maui (as well as the 3rd party avalonia UI). The problem with most native frameworks, however, is they are nowhere near as flexible as HTML and CSS (which many pre-teens taught themselves as a way to customize their tumblr and myspace pages). Other frameworks, by comparison, require programming knowledge or more setup than just a text editor (usually requiring an IDE and the rest of your toolchain). I can see native software making a comeback if it is: 1. Declarative: only software engineers like imperative UI systems 2. Flexible: some frameworks (like any of the XAML-based ones) are strongly typed and you can only combine certain XAML elements with other certain XAML elements, and will fail to compile entirely if you mess something up 3. Unopinionated: HTML, CSS, and Javascript don't require you to implement any particular paradigm for getting data on the screen; that is left up to the coder 4. Dead ass simple: the litmus test is that a 7th grader should be able to learn the basics of it on their own, and the tooling should be ideally no more complicated than a text editor 5. Totally sandboxed: You can't trust 99% of frontend devs with security The people you need to appeal to are not hardcore software engineers, but hobbyists and newbies, since they end up being the majority of frontend devs anyways. Honestly I think you could get pretty far with just adding declarative languages (read: XML) to existing native frameworks, like gtk and Win32.
- fulladder 3y ago
  Your post is thoughtful. Why do you care so much about declarative? I tried SwiftUI last summer to see what it was about and I find the whole style rather awkward. Writing a desktop app in XML sounds even worse. And I'm not seeing the benefit to the user. With an imperative coding style, you can more directly control the user experience and give them the best one.
  - novagameco 3y ago
    With an imperative style, you need to learn a programming language before you can start making applications. With HTML, you can start making applications immediately by just writing HTML, and then you can learn the programming language (javascript) later. It's a barrier to entry for non-engineers
- olliej 3y ago
  The problem is not putting bits onto the screen, that's all SDL does. It does not integrate at all with the host platform, to an even greater extent that chrome based crapware. 1. That's an opinion, not a fact, and most "declarative" UI frameworks have poor performance and can't do anything not explicitly models by the declarative framework. The fact that people want to just draw a UI doesn't mean that the resulting UI is either good, or works correctly, and the idea that it's "easier" simply implies lower understanding of what is being done and that you aren't considering any of the edge cases you still need to handle. 2. Not sure what to say here, as I don't know your point? it seems more about the type system of your language and not at all related to the ui toolkit 3. This is BS. html, css, and the DOM all have a very clear model for how and what a UI is, claiming it isn't means that you haven't apparently spent much time working in any other system. Much like I keep meeting people who say that they don't have an accent, everyone else does. 4. Application development is conceptually complicated unless your application is not doing anything interesting. I'm also curious what makes a browser ui more "simple" than say Cocoa? 5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are. Application development is hard, and it's not because of the UI framework you're using. The overwhelming amount of any actual application is the application logic, not the UI. Chrome based apps are all abysmal because to make an actual application using a browser engine, you need to reimplement, in html+JS, a huge amount of work the host OS would otherwise just provide for you. If all you want is a webpage, just make a webpage, don't force everyone to download a 600Mb copy of chrome.