Live data from Hacker News

Show HN: Slint – A declarative UI toolkit for embedded and desktop

slint.dev

41–50 of 152 posts

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#42

The 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…

This is what I do:

- 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

#44

Looks 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?

Yes, I was thinking of that part, as this kind of stack would make a lot of sense for commercial application.

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

#45

Looks 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?

I always assumed "call us" pricing was to give a salesperson the opportunity to negotiate the best deal for the seller.

Re: Show HN: Slint – A declarative UI toolkit for embedded and desktop

#46

An 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?

We do have one line animations [1], we do have starter templates[2]. But not sure what you call "gorgeous".

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
Correct and complete text handling is hard. Does Slint handle (did a cursory search in the docs but couldn't find anything that hints at an answer):

* 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

#49
post #11

Nice 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.

Slint is already a viable alternative to Qt, as evidenced by users actively choosing us over Qt. While Qt is more mature in many areas with its two decades of development and large team, Slint is already good enough for some use cases. And as a young framework, we naturally strive to improve.

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

#50
There is often a criticism of Javascript, that new frameworks seem to appear every week. But it honestly feels like every week on HN there is a new Rust UI project showing up. Whether it is some new HTML/web thing, a native app thing, a TUI thing, etc.

Don'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.

Post reply on HN