4 ms·

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 2

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.
- novagameco 3y ago
  > It does not integrate at all with the host platform SDL does in fact make system calls and have OS-specific code (DirectX implementation, Metal implementation), even if most of them don't directly manipulate OS UI controls, though it can initialize a window with a rendering context on any of its OSs. I feel like you're missing the point that performance matters less than accessibility for UI frameworks. HTML and CSS are the most popular choices because a child can learn them quickly. Native apps aren't as popular because all the frameworks out there require you to be an engineer to use them. > 1. 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. I don't see how that follows at all. HTML is declarative and powers most applications at this point. > 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 Web browsers are very forgiving with HTML errors, native UI frameworks (especially those which simply convert the markup to imperative statements) often refuse to run entirely if there's a single markup error. A native framework which seeks to become as popular as HTML would need to be as flexible as HTML > 3. 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 You're not understanding what I'm saying. You can run an ajax request and get some data, but to put that data into the UI would require you to run a query on the dom and manually set the innerHTML of the element to the new data. Some other UI frameworks will force you to bind specific variables or lists to a control in order to auto refresh when the bound variable changes. This is an opinionated framework: one which tells you how to manage updating the UI rather than allowing the developer to do it themselves. Such an opinionated framework would become more difficult for people to learn > 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? I have no experience with cocoa because I don't use a mac, but from what I can tell it requires you to know Objective C and run XCode. HTML requires, at the very least, notepad to write. It is extremely easy to get setup with HTML and start learning it as a lay person. > 5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are. You would want to make sure that programs written in this framework are sandboxed away from any resources. On Windows this means AppContainers and on Linux there are different implementations (snap, docker). But the host which runs and loads the UI should run all applications sandboxed by default (i.e: like a web browser)

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.

novagameco 3y ago
> It does not integrate at all with the host platform SDL does in fact make system calls and have OS-specific code (DirectX implementation, Metal implementation), even if most of them don't directly manipulate OS UI controls, though it can initialize a window with a rendering context on any of its OSs. I feel like you're missing the point that performance matters less than accessibility for UI frameworks. HTML and CSS are the most popular choices because a child can learn them quickly. Native apps aren't as popular because all the frameworks out there require you to be an engineer to use them. > 1. 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. I don't see how that follows at all. HTML is declarative and powers most applications at this point. > 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 Web browsers are very forgiving with HTML errors, native UI frameworks (especially those which simply convert the markup to imperative statements) often refuse to run entirely if there's a single markup error. A native framework which seeks to become as popular as HTML would need to be as flexible as HTML > 3. 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 You're not understanding what I'm saying. You can run an ajax request and get some data, but to put that data into the UI would require you to run a query on the dom and manually set the innerHTML of the element to the new data. Some other UI frameworks will force you to bind specific variables or lists to a control in order to auto refresh when the bound variable changes. This is an opinionated framework: one which tells you how to manage updating the UI rather than allowing the developer to do it themselves. Such an opinionated framework would become more difficult for people to learn > 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? I have no experience with cocoa because I don't use a mac, but from what I can tell it requires you to know Objective C and run XCode. HTML requires, at the very least, notepad to write. It is extremely easy to get setup with HTML and start learning it as a lay person. > 5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are. You would want to make sure that programs written in this framework are sandboxed away from any resources. On Windows this means AppContainers and on Linux there are different implementations (snap, docker). But the host which runs and loads the UI should run all applications sandboxed by default (i.e: like a web browser)