Yup, sure sounds like a game developer. That's kind of why most of these 3rd party pluging schemes are either done on the quick and on the cheap, or open source projects done on the side as a...
Whats the pricing and licensing model like
Look, we're going to level with you. We really don't know. We have two overriding priorities:
First, we want to put PanGui into the hands of as many people as possible and make it as accessible as possible. Second, we would prefer not to starve to death.
Yup, sure sounds like a game developer. That's kind of why most of these 3rd party pluging schemes are either done on the quick and on the cheap, or open source projects done on the side as a grassroots. You're simply not going to make a living wage on anything at first, which includes dev tooling.
It's really hard to advise a pricing model when starting out in such an environment. In the long term with several projects using it there's may ways to charge fees or cuts. But until that critical mass hits, no one trusts it. Which means you kinda need to at least give the API away at the very least, but that can also be tricky.
It's not that I don't understand why they're doing this but it means Electron will continue winning simply by virtue of its corporate backing making it permissively licensed…
It's not that I don't understand why they're doing this but it means Electron will continue winning simply by virtue of its corporate backing making it permissively licensed…
Not really. Tauri uses the system web UI when it exists, which means the initial install doesn't need to include a whole fresh web browser, but it's still using the same underlying concepts, and...
Not really. Tauri uses the system web UI when it exists, which means the initial install doesn't need to include a whole fresh web browser, but it's still using the same underlying concepts, and it's still using a fully-featured browser.
A different approach might to be create a stripped-down browser exclusively for developing applications in. It wouldn't need to support everything that a real browser supports, and you don't need the scripting language to be Javascript or to worry to the same degree about security. I know there's a couple of projects going in this direction, but they're mostly either small or experimental.
JS is relatively efficient. I don’t think that’s what would need to go. Cutting down the runtime sounds good. A smaller install size would be great. Providing developers with a small but capable...
JS is relatively efficient. I don’t think that’s what would need to go. Cutting down the runtime sounds good. A smaller install size would be great. Providing developers with a small but capable standard library would go a long way as well. You’d get less npm bloat. Maybe requiring an alternative package manager would help. If you can’t just npm install a bunch of BS and have to write your own leftPad you’ll get a smaller app size.
Javascript uses a lot of memory, and browser sandboxing makes it even heavier, as each browser tab/window/frame needs its own interpreter. I've seen estimates suggesting Javascript accounts for...
Javascript uses a lot of memory, and browser sandboxing makes it even heavier, as each browser tab/window/frame needs its own interpreter. I've seen estimates suggesting Javascript accounts for about 35% of browser memory usage, which is a lot considering how difficult rendering is. If you could control the DOM natively (i.e. not just with Wasm, but directly compiled code), you would need a lot less of that. It would be way less secure (i.e. no sandboxing), but that's less important for applications that are essentially insecure by design. You can also remove a bunch of browser features that only make sense in the context of the web, like networking, storage, devices, etc.
NPM and package management is mostly a red herring here. In general, you're only going to be paying for what you're using, at runtime at least, which means whether a function comes from an NPM library or from a built-in browser API, it'll still use up roughly the same amount of memory. The more stuff that gets bundled in the browser, the less needs to be shipped as additional packages — but the more needs to get shipped in the browser in the first place. I think there's a lot to criticise about NPM, but it's irrelevant to this particular issue.
Basically, I suspect the future is probably tools like Dioxus' Blitz engine, which is basically just an HTML/CSS renderer which can be embedded in other applications. Essentially, take the bits of the browser focused on rendering things, and make them usable in other contexts as well.
Isn't that just a virtual machine then? The whole point of electron is that it enabled developers who were used to developing web apps in JavaScript to develop desktop apps. If we're no longer...
Isn't that just a virtual machine then?
The whole point of electron is that it enabled developers who were used to developing web apps in JavaScript to develop desktop apps. If we're no longer fully implementing a browser engine, and we're no longer using JavaScript, we've just come full circle and reinvented the JVM.
Not really, a virtual machine is a program that executes code in a particular way, it doesn't have anything to do with GUIs. The benefit of electron and friends is partly that it enables...
Not really, a virtual machine is a program that executes code in a particular way, it doesn't have anything to do with GUIs.
The benefit of electron and friends is partly that it enables Javascript developers to do develop desktop apps, but it's mainly that the web platform is surprisingly nice to develop for. CSS is a good language for describing how UI should be laid out, and HTML includes almost all of the most necessary controls, as well as making it fairly easy to create new controls out of the existing primitives. It's also far more cross-platform than most existing solutions, and allows a much higher degree of styling and branding.
So the goal would be to take as many of the benefits of that (cross-platform, UI elements, etc) while removing anything that doesn't need to be there. For example, sandboxing is a big part of the browser, but it's completely unnecessary for desktop applications, because those typically aren't sandboxed at all.
What makes the web stack so nice to work with is that trillion dollar companies pour billions of dollars into web tooling and frameworks. If this hypothetical UI engine severs that link, it loses...
What makes the web stack so nice to work with is that trillion dollar companies pour billions of dollars into web tooling and frameworks. If this hypothetical UI engine severs that link, it loses much of its value.
It depends how much it can retain. For example, the Blitz system being explored by Dioxus uses parts of the Firefox/Servo browser under the hood (for example, Stylo), which means they can...
It depends how much it can retain. For example, the Blitz system being explored by Dioxus uses parts of the Firefox/Servo browser under the hood (for example, Stylo), which means they can piggyback off existing tooling. In general, HTML and CSS will largely stay the same.
On the surface this looks very cool, the focus on efficiency is great, the implementation and ease of use looks good. But as you bring up, there are no licensing details, which means no one in...
On the surface this looks very cool, the focus on efficiency is great, the implementation and ease of use looks good.
But as you bring up, there are no licensing details, which means no one in their right mind would use it for a real project. I guess the release is really just a call for beta testers?
As of this moment, we think PanGui is very likely to be some sort of open source, and hopefully the vast majority of people using it will never have to pay a dime. If we can make that work, we will.
If it does indeed end up being open source I can see it catching on in a big way.
The cynical side of me says that it's unlikely to really catch on even if it's completely free under MIT or something because I just don't think there are really that many projects that are in the...
The cynical side of me says that it's unlikely to really catch on even if it's completely free under MIT or something because I just don't think there are really that many projects that are in the market for another UI layout library. I'm sure the number is non-zero, but I doubt it's particularly huge. And if it costs more than zero it'll probably go nowhere at all.
I don't see any tip jars on the page, but it might be a worthwhile suggestion to setup. Though historically, no-incentive donations tend to be pitiful. But who knows? This is definitely the time...
I don't see any tip jars on the page, but it might be a worthwhile suggestion to setup. Though historically, no-incentive donations tend to be pitiful.
But who knows? This is definitely the time for the most principled data-oriented folks to truly prove there's demand for such talent and tools.
I assume raze means that when donations are solicited without offering anything in return (rewards, "perks", etc), people very rarely if ever donate. They're just not a viable means of...
I assume raze means that when donations are solicited without offering anything in return (rewards, "perks", etc), people very rarely if ever donate. They're just not a viable means of monetization in most cases, despite being frequently suggested in lieu of charging for work.
Consider every time you've used an OSS tool, or game mod, or NPM package. There's often donate buttons, but we (collectively) almost never click them. The most successful donations are those that provide some value to the donor, and would be more accurately described as "selling features or services".
For example, game servers may offer priority queues, companies may provide tiered support, or tools may unlock unique features (eg. Cryptomator unlocking dark mode for supporters). Alternatively, they may just provide some special recognition of having donated - a gold star publicly beside your name, or some other display of virtue.
I've always found it a little dishonest to sell features and call it a donation, but I recognize the reality that no-incentive donations are also extremely ineffective.
Okay, but why do we do that? People sort of imply this, but they don't actually say it. People don't donate anything because it's inconvenient to do so. You don't have a donation shortcut, you...
Consider every time you've used an OSS tool, or game mod, or NPM package. There's often donate buttons, but we (collectively) almost never click them. The most successful donations are those that provide some value to the donor, and would be more accurately described as "selling features or services".
Okay, but why do we do that? People sort of imply this, but they don't actually say it.
People don't donate anything because it's inconvenient to do so. You don't have a donation shortcut, you don't have any system that keeps track of the most helpful open-source projects and collates a nice list of recommendations, you don't have a nice app that centralizes your donations so you can sort it out via filters and one-click payments.
Or to rephrase: if donation-driven open-source is a business, open-source projects spend almost no effort on turning users into customers.
I'm not blaming this on any one open-source project, BTW. Ideally this would be a service/daemon/app basically built into Debian (et al).
Sorry, I meant "pitiful" in the amount offered. I'm talking some decently known FOSS getting maybe a few hundred a year. I'll see if I can find some soft numbers Rallying for fundraising is a job...
Sorry, I meant "pitiful" in the amount offered. I'm talking some decently known FOSS getting maybe a few hundred a year. I'll see if I can find some soft numbers
Rallying for fundraising is a job in and of itself. And it only works by spending money to advocate (especially towards corporate donations), or if you have some incentive for the "donation".
I wonder if it would be possible to mandate that tools like this and e.g. Godot be offered as an add-on when purchasing a product built with it. For instance if a game used this library they could...
I wonder if it would be possible to mandate that tools like this and e.g. Godot be offered as an add-on when purchasing a product built with it. For instance if a game used this library they could allow that to be done for free as long as one of the purchase options for the game was X% more expensive where X% goes to the maker of the tools. Tool makers could possibly bundle in some value adds to increase the likelihood of people picking this option. The increased exposure could bring in some additional cash...
No one would use it then. Pricing display is extremely sensitive for businesses. People spent millions of dollars to optimize the way their prices are displayed. Having that kind of FUD “wtf is...
No one would use it then. Pricing display is extremely sensitive for businesses. People spent millions of dollars to optimize the way their prices are displayed.
Having that kind of FUD “wtf is godot? I’m buying XYZ, not godot. Huh? And it’s more expensive? Is it dlc? Huh?” Is the last thing anyone would want.
Not sure. Looking at Space Marine 2 on Steam I currently have 3 purchase options; standard, gold and ultimate edition. It is not immediately apparent what's included in each. Arguably this could...
Not sure. Looking at Space Marine 2 on Steam I currently have 3 purchase options; standard, gold and ultimate edition. It is not immediately apparent what's included in each. Arguably this could be done in a similar way. You do have a point that this introduces some friction at the point of purchase, but evidently there is some games that do add this friction for some reason.
The difference is that they get more money if you buy the more premium options. They get nothing if you donate money to godot. There is no reward and a lot of downside if it spooks people.
The difference is that they get more money if you buy the more premium options. They get nothing if you donate money to godot. There is no reward and a lot of downside if it spooks people.
Intriguing, and I appreciate that the demo app is something both complex and pretty rather than the typical flat design todo app that could’ve been written on a Mac Plus. It looks like it’s...
Intriguing, and I appreciate that the demo app is something both complex and pretty rather than the typical flat design todo app that could’ve been written on a Mac Plus.
It looks like it’s probably one of those UI libraries that renders to an accessibility-invisible canvas, though, and I’d need to see what widgets it comes with out of the box to be able to judge it. Building everything from scratch doesn’t sound great.
I scrolled quickly and was getting skeptical about the lack of sample code, but they're demo sound app is pretty darned impressive for ~1,500 of code and comments. I'll have to look into this more...
I scrolled quickly and was getting skeptical about the lack of sample code, but they're demo sound app is pretty darned impressive for ~1,500 of code and comments. I'll have to look into this more closely.
One immediate thought is that the more concise and expensive the language is, the better it will be adapted for AI assisted development.
As an F# dev i'm always keeping my eyes on decent UI libraries. I would love to NEVER have to touch javascript, which leaves me in a limited space, and things like HTMX worry me in case I ever...
As an F# dev i'm always keeping my eyes on decent UI libraries. I would love to NEVER have to touch javascript, which leaves me in a limited space, and things like HTMX worry me in case I ever need to scale. For hobby projects especially this seems interesting.
Yup, sure sounds like a game developer. That's kind of why most of these 3rd party pluging schemes are either done on the quick and on the cheap, or open source projects done on the side as a grassroots. You're simply not going to make a living wage on anything at first, which includes dev tooling.
It's really hard to advise a pricing model when starting out in such an environment. In the long term with several projects using it there's may ways to charge fees or cuts. But until that critical mass hits, no one trusts it. Which means you kinda need to at least give the API away at the very least, but that can also be tricky.
It's not that I don't understand why they're doing this but it means Electron will continue winning simply by virtue of its corporate backing making it permissively licensed…
Maybe we should worry about making electron more efficient then.
Isn’t that just Tauri, then? They use web technologies in a more lightweight frame/runtime than Electron offers, as far as I know.
Not really. Tauri uses the system web UI when it exists, which means the initial install doesn't need to include a whole fresh web browser, but it's still using the same underlying concepts, and it's still using a fully-featured browser.
A different approach might to be create a stripped-down browser exclusively for developing applications in. It wouldn't need to support everything that a real browser supports, and you don't need the scripting language to be Javascript or to worry to the same degree about security. I know there's a couple of projects going in this direction, but they're mostly either small or experimental.
JS is relatively efficient. I don’t think that’s what would need to go. Cutting down the runtime sounds good. A smaller install size would be great. Providing developers with a small but capable standard library would go a long way as well. You’d get less npm bloat. Maybe requiring an alternative package manager would help. If you can’t just npm install a bunch of BS and have to write your own leftPad you’ll get a smaller app size.
Javascript uses a lot of memory, and browser sandboxing makes it even heavier, as each browser tab/window/frame needs its own interpreter. I've seen estimates suggesting Javascript accounts for about 35% of browser memory usage, which is a lot considering how difficult rendering is. If you could control the DOM natively (i.e. not just with Wasm, but directly compiled code), you would need a lot less of that. It would be way less secure (i.e. no sandboxing), but that's less important for applications that are essentially insecure by design. You can also remove a bunch of browser features that only make sense in the context of the web, like networking, storage, devices, etc.
NPM and package management is mostly a red herring here. In general, you're only going to be paying for what you're using, at runtime at least, which means whether a function comes from an NPM library or from a built-in browser API, it'll still use up roughly the same amount of memory. The more stuff that gets bundled in the browser, the less needs to be shipped as additional packages — but the more needs to get shipped in the browser in the first place. I think there's a lot to criticise about NPM, but it's irrelevant to this particular issue.
Basically, I suspect the future is probably tools like Dioxus' Blitz engine, which is basically just an HTML/CSS renderer which can be embedded in other applications. Essentially, take the bits of the browser focused on rendering things, and make them usable in other contexts as well.
Blitz seems nice. I think an upgraded rsx macro with XML-like syntax would help it gain popularity.
Isn't that just a virtual machine then?
The whole point of electron is that it enabled developers who were used to developing web apps in JavaScript to develop desktop apps. If we're no longer fully implementing a browser engine, and we're no longer using JavaScript, we've just come full circle and reinvented the JVM.
Not really, a virtual machine is a program that executes code in a particular way, it doesn't have anything to do with GUIs.
The benefit of electron and friends is partly that it enables Javascript developers to do develop desktop apps, but it's mainly that the web platform is surprisingly nice to develop for. CSS is a good language for describing how UI should be laid out, and HTML includes almost all of the most necessary controls, as well as making it fairly easy to create new controls out of the existing primitives. It's also far more cross-platform than most existing solutions, and allows a much higher degree of styling and branding.
So the goal would be to take as many of the benefits of that (cross-platform, UI elements, etc) while removing anything that doesn't need to be there. For example, sandboxing is a big part of the browser, but it's completely unnecessary for desktop applications, because those typically aren't sandboxed at all.
What makes the web stack so nice to work with is that trillion dollar companies pour billions of dollars into web tooling and frameworks. If this hypothetical UI engine severs that link, it loses much of its value.
It depends how much it can retain. For example, the Blitz system being explored by Dioxus uses parts of the Firefox/Servo browser under the hood (for example, Stylo), which means they can piggyback off existing tooling. In general, HTML and CSS will largely stay the same.
On the surface this looks very cool, the focus on efficiency is great, the implementation and ease of use looks good.
But as you bring up, there are no licensing details, which means no one in their right mind would use it for a real project. I guess the release is really just a call for beta testers?
If it does indeed end up being open source I can see it catching on in a big way.
The cynical side of me says that it's unlikely to really catch on even if it's completely free under MIT or something because I just don't think there are really that many projects that are in the market for another UI layout library. I'm sure the number is non-zero, but I doubt it's particularly huge. And if it costs more than zero it'll probably go nowhere at all.
A similar-ish project was posted a few months ago: https://tildes.net/~comp/1l32/introducing_clay_high_performance_ui_layout_in_c. Fascinatingly even though that has a public implementation and a permissive license it got no discussion even though they seem to share a similar design.
Do they take donations? Seems like those could help fund it to reduce the price.
I don't see any tip jars on the page, but it might be a worthwhile suggestion to setup. Though historically, no-incentive donations tend to be pitiful.
But who knows? This is definitely the time for the most principled data-oriented folks to truly prove there's demand for such talent and tools.
Could you please expand or clarity? I'm not quite sure what you mean by this, why are no-incentive donations considered pitiful?
I assume raze means that when donations are solicited without offering anything in return (rewards, "perks", etc), people very rarely if ever donate. They're just not a viable means of monetization in most cases, despite being frequently suggested in lieu of charging for work.
Consider every time you've used an OSS tool, or game mod, or NPM package. There's often donate buttons, but we (collectively) almost never click them. The most successful donations are those that provide some value to the donor, and would be more accurately described as "selling features or services".
For example, game servers may offer priority queues, companies may provide tiered support, or tools may unlock unique features (eg. Cryptomator unlocking dark mode for supporters). Alternatively, they may just provide some special recognition of having donated - a gold star publicly beside your name, or some other display of virtue.
I've always found it a little dishonest to sell features and call it a donation, but I recognize the reality that no-incentive donations are also extremely ineffective.
Okay, but why do we do that? People sort of imply this, but they don't actually say it.
People don't donate anything because it's inconvenient to do so. You don't have a donation shortcut, you don't have any system that keeps track of the most helpful open-source projects and collates a nice list of recommendations, you don't have a nice app that centralizes your donations so you can sort it out via filters and one-click payments.
Or to rephrase: if donation-driven open-source is a business, open-source projects spend almost no effort on turning users into customers.
I'm not blaming this on any one open-source project, BTW. Ideally this would be a service/daemon/app basically built into Debian (et al).
Sorry, I meant "pitiful" in the amount offered. I'm talking some decently known FOSS getting maybe a few hundred a year. I'll see if I can find some soft numbers
Rallying for fundraising is a job in and of itself. And it only works by spending money to advocate (especially towards corporate donations), or if you have some incentive for the "donation".
I wonder if it would be possible to mandate that tools like this and e.g. Godot be offered as an add-on when purchasing a product built with it. For instance if a game used this library they could allow that to be done for free as long as one of the purchase options for the game was X% more expensive where X% goes to the maker of the tools. Tool makers could possibly bundle in some value adds to increase the likelihood of people picking this option. The increased exposure could bring in some additional cash...
No one would use it then. Pricing display is extremely sensitive for businesses. People spent millions of dollars to optimize the way their prices are displayed.
Having that kind of FUD “wtf is godot? I’m buying XYZ, not godot. Huh? And it’s more expensive? Is it dlc? Huh?” Is the last thing anyone would want.
Not sure. Looking at Space Marine 2 on Steam I currently have 3 purchase options; standard, gold and ultimate edition. It is not immediately apparent what's included in each. Arguably this could be done in a similar way. You do have a point that this introduces some friction at the point of purchase, but evidently there is some games that do add this friction for some reason.
The difference is that they get more money if you buy the more premium options. They get nothing if you donate money to godot. There is no reward and a lot of downside if it spooks people.
Intriguing, and I appreciate that the demo app is something both complex and pretty rather than the typical flat design todo app that could’ve been written on a Mac Plus.
It looks like it’s probably one of those UI libraries that renders to an accessibility-invisible canvas, though, and I’d need to see what widgets it comes with out of the box to be able to judge it. Building everything from scratch doesn’t sound great.
I scrolled quickly and was getting skeptical about the lack of sample code, but they're demo sound app is pretty darned impressive for ~1,500 of code and comments. I'll have to look into this more closely.
One immediate thought is that the more concise and expensive the language is, the better it will be adapted for AI assisted development.
As an F# dev i'm always keeping my eyes on decent UI libraries. I would love to NEVER have to touch javascript, which leaves me in a limited space, and things like HTMX worry me in case I ever need to scale. For hobby projects especially this seems interesting.