I have been held back for years because of the sad state of desktop UI frameworks. I have recently embarked up creating my own, if only for my own purposes. It's a nightmare.
One of the primary issues is that there is no foundational cross-platform support. For creating windows, GLFW is the best bet. I should give kudos here. GLFW works and is well-documented, a rarity indeed. The forum is also pleasant. For graphics, Skia is probably the best solution, but it has problems. For example, it is 2D only, has support on a Google Group with not much traffic, and is complicated to build.
The binding for it on .NET is currently not actively maintained, despite being effectively owned by Microsoft. You also give up performance. For example, Direct2D is much faster than Skia on Windows, and Direct2D can seamlessly interact with Direct3D in the same window. But SharpDX (the .NET bindings) is no longer maintained and DirectX is of course Windows only. Then you have macOS which is completely antagonistic. It is locked to an extremely old OpenGL version, and Apple may remove it at any indeterminate time. So you either build against OpenGL or start jumping through hoops in GLFW and Skia to use Vulkan and Molten to talk to Metal on macOS. Also, macOS is the only OS that forces the window management on the main thread. All window management on all OSs is on a single thread, but on Windows, for example, that thread can be any thread. Then there's Linux and the umpteen million distros and the two window managers in X11 and Wayland. There is no cross-platform accessibility library that I know of.
On top of all this, all pf these solutions have limited to no support. Most projects are ran by just a couple of people, if that. This is not a complaint against them in any way, as it is simply an observation of the reality in that support is highly, highly limited. There's also the issue that many of the issues encountered are complex and often reach across several stacks. For example, is it a bug in Skia, GLFW, the bindings to these, the OS, the graphics drivers, or from the interaction of these.
There are also very few resources and references for stuff like this.
If I read your post correctly, you might be interested in reading the readme and maybe the code of this library I've been working on (even though it's only 2D, and (purposely) not advanced 2D):
https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
> For example, Direct2D is much faster than Skia on Windows
Much faster? I’m not necessarily doubting this but you have some evidence? Isn’t Skia even used by Edge? And everybody here is basically claiming that the only UI frameworks that matter are web based - so if it’s good enough for that…
Also Qt Quick - seems to cover all the platforms mentioned. Of course it has a ton of resources poured into it, but it’s there.
Qt is pretty damn easy I would say. And some Web UIs are easy too.
In any case this article is talking about the features that are unique to Rust that make it especially hard to write GUIs.
Though weirdly it focuses on lack of inheritance which is definitely not that big of a deal (Rust does have trait inheritance - you can even get full implementation inheritance using macros if you really want but I doubt it is needed). The biggest issue by far is state management because of the single ownership rules.
You can of course Rc-RefCell everything but that gets very ugly.
I never fully understood why we couldn't have the VB/Winform model of building GUI on the web. Is it because we need the designer skinnable GUI? With WebAssembly and CSS grid layout, could we finally get a modernize VB/Winform?
Because they used to produce dubious code leading to poor rendering result.
I would like to say the Web was poorly designed but that would be too generous. The Web wasn’t designed at all. It’s a hodgepodge of poorly thought out technologies hastily cobbled together. It’s a piece of technology designed to display static textual content horribly contorted to make applications.
It took decades for JS and CSS to reach a state I consider barely useable and the best we could do is apparently flexbox.
Ten/Twelve years ago me and a colleague would build random desktop apps using WinForms and C#, they were deployed using a network share and ClickOnce. They weren't the most elegant pieces of software ever developed, but it sure was easy to slap together a small tool for the warehouse manager or someone in sales.
You can still do all that, on Windows. As I get older and have more experience, I have come to the conclusion that some people are more interested in the technology and less so in solving actual problems. While I'm pretty happy with my career, if I were to do it all over: Windows, Visual Studio, C++ and WinForms would have been the tools that I'd have picked. We're coming up on 25 years of a fairly stable, actively developed platform with pretty good backwards compatibility.
Maybe I missed some opportunities but with my later experience and in my line of work I got pushed towards webapps and these days PowerBI. I can make those work but I feel that as a beginner with VB6 I could build forms faster than I can do now in a browser.
Also, I remember not being completely precise: I maintained a hacked together GUI build in Access VBA. It had its warts but its web-based replacement didn't blow it out of the water and took longer to develop.
React Native is a lot faster for building out prototypes but slows down when you start building more complex screens and can be very brittle to maintain over time.
I always boggle a bit when somebody measures development velocity "by the screen"
It's smoke above pinched fingers creating a bottleneck. Whether the fingers belong to bureaucracy or dev capability requires more info than I have. My bias says look at whoever has the biggest ego and the strongest opinions. They're the anchor.
SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it.
IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working to better support this type of thing more directly/natively.
In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"?
Frankly, it didn't seemed you had a point to make other than parroting cliches.
Your comment sounds a bit dismissive though. They all provide plenty value individually. A lot of this stuff needs to be used IRL for the community to understand the limits and there will always be junior devs and cowboys willing to risk it.
Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect.
The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
The signal is to avoid new technologies with marketing engines behind them for at least a few years. And anyone who is gullible enough to believe them, which are more likely the new people learning to code and yelling about the new shiny libraries they found than full time developers that are actually productive rather than bored.
Being too eager to dismiss a technology and move on is just as much of a bandwagon-jump as being too eager to adopt it in the first place.
The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'.
The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology.
The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche.
> The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche.
I keep thinking of the tower of babel.
> God was concerned that humans had blasphemed by building the tower to avoid a second flood so God brought into existence multiple languages. Thus, humans were divided into linguistic groups, unable to understand one another.
In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo
Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs.
No wonder it feels like a clunky extra glue layer if it’s being used as one.
> and no one can delete anything because you have no idea what it'll break.
This is a problem with GraphQL, but you can monitor if anyone is requesting that data.
Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful.
It depends if you're in that situation or not, or what parts of your domain are in those situations.
> Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar.
A lot of them also support deep relationships this way too.
For example, the Directus REST API is completely feature compatible with the GraphQL API.
Again, as an example, Directus supports doing everything you just said over both REST and GraphQL.
There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever.
You may also want to take a look at HATEOAS and JSON:API and similar.
REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something?
I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard.
GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
> is it just "we don't like GraphQL" or something?
Yes.
But not without reason.
GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs.
You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc...
This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that.
With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design.
GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport.
Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1].
Why do I hear so much about htmx and so little about unpolly, which seems everything htmx promise but with additional high level primitives for the common task?
Unpoly dev is german nobody cares about abd doesnt go on podcasts vs htmx author is american that does marketing well. Same goes for alpine js where the author is “famous” dev.
Pretty typical with open source projects tbh. Many of them win thanks to marketing more than anything else.
Don't why you have been downvoted, while there are famous dev outside of the US, american identity and marketting does sell better than the german one.
A long time since I was a Research Associate at a UK university (salaried short term contract) and trying to finish a PhD and I remember someone from outside of academia describing me as "hyper cynical" - that was after 5 years or so.
I left, co-founded a startup and never regretted leaving academia.
Edit: That comment didn't make me leave but it does rather reflect my state of mind at the time - which was pretty bitter....
If you're in a teaching position and students' evaluation depends on you remember that you won't see all that much genuine interactions, as many will try to appear at their best
It absolutely will be the end of 'turn the crank and out comes a mediocre film we can put into a red box and make a few million off of'
It's unlikely it will produce works that are doing new things and creating new styles because currently all AI has one thing in common - it's very good at replicating existing ideas and performing style transfer to blend those ideas. It's going to get better at those things but there's no reason to think that it will be truly creative in the sense of creating something that isn't a style transfer in the near future.
What it will do is create an incredibly low entry barrier to making truely creative work with a human in the toolchain at the highest levels of abstraction. You won't need to pay a team of actors and stage hands and audio people and editors etc. You'll be able to make world class cinema with a desktop PC and an AWS account. It'll probably result in a massive explosion of content (both good and terrible).
Once we create an AI that can be truly creative in the way specified above, I think it's about time for biological humanity to accept that our time as the most advanced intelligence in our little corner of the universe is over.
Sounds like TikTok or am I missing something? I'm not on social media (I guess I'm here on occasion), but it just sounds like a feed of shit to consume... Would it really be that much better than what we've got now?
You don't need it to be fair, you need it to be fun. Most video games play with randomness so that the distribution serves the gameplay, sometimes bypassing completely the RNG to balance frustration/satisfaction.
GPT can learn do to that: not providing true randomness, but the illusion of it to serve the game.
Players will detect drama being injected into their randomness (unless it is very gently and rarely done), and over time they will start to be able to predict dice rolls [edit: or even learn to shape their responses to trick the model into generating the rolls they want.] That will ruin the game.
So that's not removing randomness, it's just grade inflation. I suppose it's also secret range narrowing, since an 3% improvement from 92% to 95% is actually no improvement at all at 1.1 * (random) capped at 100%.
When you think of the content of the books in Baldur's Gate and the sheer amount of human hours poured into something just to give background to the game, this is going to save indeed a lot of time.
But on the other hand, just like open world was a terrible curse with hundred of games feeling empty, I'm afraid we will see a wave of games with a lot of generated but eventually uninteresting content because this is so easy to do.
After all, good content is coherent, and filtered. It's not just about producing a lot, it's what you don't put in the game, and what you do to glue things together.
I sure GPT will eventually be better at it than humans, but for now, having a human veto is necessary to have a good noise/signal ratio and because GPT is "good enough", being lazy is tempting.
But yeah, I can confirm GPT4 is already quite good at it and will only improve from this point.
This is going to be very interesting years.
Edit: I just made it write a full video game scenario, using BG as a competitor for basis. At first it was average, but with directions, it refined it and became quite good. Some kind of steam punk guild called the Navigators reading the wind, living in floating islands and a girl rediscovering the earth bellow the clouds and rebuilding old aliances with lost civilizations, plus a politician leader trying to prevent that and even a mentor to help her. Not bad.
I would play this, and even read it.
You can see the inspiration from "The Pillars of the Earth", "Gunnm", "Baldur's Gate" and "nausica" proving again it's mostly assembling known stuff.
But a cake is mostly assembling known stuff and it's still good. The "last of us" is just a good take on something that has been done a thousand times.
What's missing is overt structure. More or less the same reason as to why AI can't draw hands - there is no "understanding" of the fact that a hand is a rectangle with five sticks coming out of it in a specific arrangement. For a human, that is all that's needed to recognise a hand, i.e.
This is a (very crude) hand. This registers as a hand for you, because it has the structure of a hand. This is less similar to a photorealistic hand than a 6-fingered AI hand, objectively, however it fits the human understanding of what a hand is supposed to be, because it has the right kind of shapes in the right relations to one another. In the same vein, if we could get the AI to understand the structure of a story, it should be able to DM session by session, starting from a high level abstract idea and refining it based on player actions, incorporating player input into the game. I'm not sure if hierarchical abstract reasoning should be forcibly added to the model, or if it can be emergent in a specific configuration, but if we figure out how to build an AI with that, then it should be able to produce something a lot more sensible.
I had a fun conversation with GPT-4 about your ASCII hand. You're absolutely right, it had a very difficult time and thought it was a city skyline, game or puzzle diagram, and a scale, but after a few hints, it got it:
"Considering the hint that the image is part of a human being and the diagonal line is similar to the vertical lines, it appears that the image might represent a hand, specifically an open hand with fingers splayed out. The vertical lines represent the fingers, and the diagonal line represents the thumb, which is extending out at an angle from the square (representing the palm of the hand). The image is a 2D, stylized representation of a human hand.
With the provided hints and context, the interpretation of the ASCII art as a hand seems more plausible. If you have more hints or information, please share them, and I'll be happy to refine the interpretation further if necessary."
This technology appears to show great promise, but is clearly still in its infancy.
