The website is an entirely static website, and the frameworks main pitch is how good it is with reactive websites. This website could be entirely the same with html and css.
in case you don't understand what GP is suggesting: your website does not actually describe what you're providing. A "next generation Rust UI library powered by fine-grained reactivity." could mean a UI for native apps - something like egui or Dioxys - or it could mean a way to use rust to output HTML, CSS, and javascript. Or a bunch of other things. And, regardless, there's no way to look at your website and determine how to get that output using sycamore. I can inspect and see your HTML or your CSS, but there's no Rust code for me to compare that against without going and looking it up somewhere.
To be more succinct: you don't even have an image of your UI running on your websites landing page. Not one single image of the library which is, again, a UI library. People have an interest in knowing "does this look and feel like I want it to?" as well as "can I use this in the projects I'm working on?". Both of those questions should be answered by your landing page. For me, at least, it doesn't do that.
There are also plenty of other examples as mentioned in the comment above. Also many other projects using Sycamore which you can see by looking at GitHub’s reverse dependency page.
I have a desktop computer that I use for gaming so it had windows forever. Lately it started running laggy. Occasional frame drops and stuff. Reinstall, bios update etc nothing helped.
For debugging I installed Bazzite (Linux gaming distro) assuming compatibility would be shit but I can at least test native linux builds of some games to see if there is a hardware issue. The thing runs perfectly. I've been playing propert windows games on Proton with higher / more consistent FPS. It is kind of funny at this point. Granted I do not play any competitive / multiplayer games.
I guess Valve did a great job on the Steam Deck sw.
I've been running Fedora (or a flavor) on my gaming PC for two years. All my games work. I understand some competitive games with intrusive anti cheat are incompatible, but with the success of the steam deck I don't think the gaming argument is holding much water these days.
I switched from Windows 10 to Fedora recently. Most of the games I play work without issue but I know there are some which categorically refuse to work (mainly some specific anti-cheating software reasons).
I was playing RE9 at 4K on my Debian 13 last weekend. The vast majority of games work, even some live service games. 5 years ago you would face significant issues, today that simply isn't the case.
We are using it for our apps, but I can see why people do not use it for new projects:
1. The state of C++ is not great. Few developers, C++ footguns, complicated build systems, and generally slow progress, see my https://arewemodulesyet.org/
2. How Qt presents and licenses itself. Either you go LGPL or you have to pay big money for a commercial license, which will then infect all other apps as well. For example, when you have two Qt apps that talk to each other you must license _both_ commercially.
3. The split of Widgets and QML makes the ecosystem fragmented, because Widgets will never die. Even the Qt devs themselves are split about this. You can see this when example code for a new feature uses Widgets. QtCreator is also a nice example, where they reverted some new QML code quite a while ago and have not substantially added any new QML code since then.
4. Tooling: We use QML for everything and the tooling is not great. The language server is still super flaky and breaks, and developer tooling like the Chrome Dev Tools is virtually nonexistent.
5. Packaging is still also not great but has gotten better in the last few versions where Qt creates a deployment cmake script for you, but you still need logic for your own (vcpkg) packages.
Those are not native (on desktop) in any sense of the word. They don't use native controls. For that, you want WX or SWT, but those come with their own sets of problems.
On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI).
I'm personally a fan of AppKit and Win32, but those are "dated" apparently.
I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though.
IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one.
Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.
gp was using a more restrictive definition of "native controls". I.e. "o/s builtin UI controls" vs "framework canvas painted elements".
For Windows, "native" would be the classic Win32 UI "common control" elements from "Comctl32.dll"[0] that is directly used by older GUI frameworks such as Windows Forms. Those map to classic Win32 API CreateWindow(L"BUTTON", ...). In contrast, the newer frameworks of WPF and Xamarin Forms and Qt Quick "paints controls on a canvas" which are not "native" and makes every app UI look different instead of standardized "look & feel" of common controls.
But others include custom-canvas painting UI objects as "native" -- as long as it's not Electron.
It's worth noting that some cross-platform toolkits are non-native in the strict sense, but mimic each platform's native controls.
This is harder to get right than one might think; small differences in text rendering look very much alien to me, and user input handling that isn't exactly the same as the platform's native conventions will make me stumble every time I perform common operations.
In my experience, Qt does an excellent job with this. It's not technically native (except on KDE and other Qt-based desktops), but it looks and feels right, or so close that I find it comfortable and well integrated with the rest of each platform I've tried. I haven't found any other cross-platform toolkit to match Qt in this area, so that's what I use for now.
Some day, I hope we'll see an alternative that accomplishes this at least as well as Qt, while being more flexible to license, easier to bind to other languages, and better at memory safety. (It's written in C++.) There seems to be renewed interest in GUI toolkit development lately, perhaps fueled by the excitement for newer languages like Zig and Rust, so perhaps I'll get my wish.
As far as I can tell, Qt Quick doesn't have anything like the same set of
polished widgets that integrate nicely into the target platform. It's been
this way for years, they just don't seem interested in implementing them.
I wouldn't exactly call Flutter native. It uses its own rendering engine and doesn't necessarily behave like operating system native controls. It is not really different from using electron.
Using electron at least uses some UI primitives from chromium. Flutter has thrown away all the usability and robustness of existing components and just reimplemented everything. It absolutely is different from electron
"Native" seems to mean different things to different people. I'm mostly with you on this, but the tides are turning. In any case, the other 3 do use real native widgets.
Of course, there's no need for them to be. But this conversation started out with "why do people use web based UI solutions?" and "because there is no proper UI library that does cross platform as well as the web".
I haven't put any effort into any kind of snapshotting capabilities yet, since I won't want the scope to be too large and there's often ways of designing your system in ways where replaying isn't a big issue (the db scans are fast, designing aggregates to have a smaller scope/less overall events, etc).
But with increased resources, I can see some solutions being considered around snapshotting. For now the goal is heavily unix philosophy inspired: a really fast and purpose built event sourcing database
Working with 3 intersecting stacks is more complex than a single stack. Go toolchain is batteries included and coherent. Author admits to not using it bc of legacy (and preference).
author here. as i mentioned in post i said we choose frankenphp since it's already supported by php foundation and in some cases we might use Go php extensions. i know writing extensions in any language add a bit complexitiy but i believe if the extensions selected wisely they will be somehow fire and forget. for instance creating pdf files would be faster in Go than php. you can create an pdf creator extension and that extension would probebly work for a long time without any adding much effort to maintenance.
reply