Great to see competition in this space; I'm sure they'll all benefit in the long run.
Show HN: Slint – A declarative UI toolkit for embedded and desktop
41–50 of 152 posts
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#42The comparison sections are very confusing. It says you will compare your UI toolkit with, for example, Flutter and then there is no comparison there at all. I thought the site is broken on mobile, I tried different browsers, etc, because the comparison was just not there. If you don't have any real content there because you don't want to start a flame war, you could try something like what the Flutter team did, they…
- Write the backend in Rust
- Write the UI in Flutter
- Tie them together using gRPC. You get an API and ability to run client and server on different machines as well
I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#43Well done! This is exactly what we should be better at, ship less bloat and set a higher standard.
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#44Looks nice, but actually the per/appliance pricing could be a bit clearer, I hate the Call Us type pricing pages, that is usually where I rather look for the competition... (Just had some hardship with finally getting an atrociously expensive quote after spending workdays of providing the needed inputs to a HW vendor)
Disclaimer: I work for Slint I suppose you are referring to the "Embedded Add-on per application" pricing? At least the non-commercial use is hopefully clear :) Yes, we need find a better way to show the pricing there since it's dependent on 2 variables - volume and type of embedded system. Maybe some sort of a online calculator?
Just made an appliance using a Web technology for the frontend, as the licensing situation was a nobrainer, and we could focus on delivering value instantly, using proven technology, instead of wasting time on negotiating on terms for something this basic element of the project. I mean if I need an LCD screen or a CPU, I don't negotiate, just go to a retailer, and check their prices and availability, and order&pay. No multiple round interactive sales process needed for something that is just a stock item, no customization needed, etc. Also the per-customer pricing seems potentially a bit discriminatory to me.
So an online calculator would be great, it would instantly let me know if your product suits outr business.
For example with the relatively low volume electric part I have mentioned above I had to make several hoops, provide lot of redundant paperwork, and nag the salespeople for weeks to provide me at least a quote the vendor could have already put on their site, as their competitors do. (This vendor has some niche differentiator aspects which made us focus on them first, not on larger volume ones). They wasted a lot of our time and our project was stalled until we got responses from them, and the prices seemed irrationally high, feeling almost as if they didn't want to sell that piece to us from the start. This is what I feel whenever I see Call Us for a quote, as this was not a unique occasion.
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#45Looks nice, but actually the per/appliance pricing could be a bit clearer, I hate the Call Us type pricing pages, that is usually where I rather look for the competition... (Just had some hardship with finally getting an atrociously expensive quote after spending workdays of providing the needed inputs to a HW vendor)
Disclaimer: I work for Slint I suppose you are referring to the "Embedded Add-on per application" pricing? At least the non-commercial use is hopefully clear :) Yes, we need find a better way to show the pricing there since it's dependent on 2 variables - volume and type of embedded system. Maybe some sort of a online calculator?
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#46An UI framework in 2023 needs two things: one line animations and a gorgeous starter template. The inconvenient truth is that there are way more good coders than there are good designers so coders need all the help they can get to sell their product and make good ux choices. Any comments on how it compares on those fronts?
I 100% agree with the need of good designers.
[1] https://slint.dev/docs/slint/src/reference/animations [2] https://github.com/slint-ui/?q=template&type=all&language=&s...
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#47* multi-line text
* languages that use non-Latin characters, as well as mixing them in the same control
* RTL and maybe vertical layout
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#48Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#49Nice to see that Qt finally gets some competition! The pricing alone is a no-brainer. Now the only thing I'm missing from the demos is smooth scrolling :)
Not to diminish Slint authors work, but it is still far from being Qt competition, given the current state of accessibility, IDE integration, or graphical tooling for UI/UX designers.
By the way, when it comes to IDE integration, our VSCode extension and LSP server, which includes live preview, put us on par with Qt's.
Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop
#50Don't get me wrong, I think that is the sign of a very healthy ecosystem. I am just curious how the Rust evangelists will spin this. Somehow this constant churn on the Javascript side is worthy of snide, satire and ridicule.
IMO, UI development is deceptively hard. Rendering scalable graphics efficiently is hard enough. Creating a good layout engine and a set of reliable basic controls is even more difficult. But managing interfaces seems to scale quadratically with the number of controls, views, states, etc. I see programmers, over and over, underestimate how difficult of a task managing that complexity can be. This complexity leads to difficult to use libraries/framework/platforms. It also leads naive and ambitious developers to believe they can do better. This leads to more and more new libraries/frameworks/platforms.