It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
I'm using EGUI for a all-in-one molecular viewer / CAD. It's like PyMol, Coot, GROMACS and VMD in one. If this is trivial, I would like to see what you consider to be non-trivial!
There are parts of the rust ecosystem that are only built for trivial apps (And demos, blog posts etc), but GUI is not one.
Look, your application is certainly impressive, but it's extremely basic from the perspective of a UI toolkit.
- It's not multi-window, so it doesn't have to integrate with a bunch of the OS window management affordances.
- It doesn't have any complicated typesetting or rich text editing, so you get to pretty much ignore that whole mess.
- Since it's a very visual tool that doesn't make much sense for blind folks, you haven't invested much in accessibility support.
- And so on...
This is a great use case for EGUI, and EGUI works great in this sort of UI-lite scenario. Whereas I wouldn't want to use it to implement something on the complexity of VSCode/Excel/FireFox.
And quite amazing work, so thank you for sharing. This will be fun to dive into. I'm generally liking egui but have just recently been using it, so I'm still new at it.
The most popular language by far used for writing UI is JavaScript, and the go to framework this day (React) doesn't use that though.
From the various experiments that popped up over the years, it's pretty clear that the React way works pretty well for Rust, but it's also too slow to be desirable for Rust (what's the point of using Rust for UI if you're going to have web-like performance).
And then again, making a half decent UI framework is a gigantic task, there's just not a whole lot of languages with a decent UI story at all, no matter what's the paradigm of the programming language. (And if you want a
language for cross-platform UI, I'd argue that the only one that ticks the box is JS with React in Electron and React Native, and it's not even truly a single framework).
The view part would be fine, the problem is updating the state. In a language which discourages shared mutability, most of the solutions are not terribly ergonomic.
You either end up needing to:
- handle all your state via interior mutability (i.e. Arc<RefCell<_>>)
- use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)
- or invert the relationship between state and view (i.e. immediate-mode) which comes with it's own implementation challenges (caching immediate mode views is hard)
SEEKING WORK | Berlin, Germany | Remote or on-site | Full-stack Web Developer
Hey, I'm Ricardo, a full-stack web developer specialised in interactive experiences, with more than 10 years of experience in building creative and business applications.
> If everything is highlighted, nothing is highlighted.
This is very true, but not in the way the author thinks. Highlighting is the wrong term here after everything is colored. As long as you keep using the same color definitions, you should be able to blur your vision and still get a sense of what is described in the source code at the "infra-structure" level
Depends on people, but for most it's mainly because Stallman says so.
You still have ethics ground if you think it the same way as repairability, actively blocking ways to repairs things you bought yourself is questionable, and keeping things closed source can be seen as a way to artificially prolonge a strict dependance on your vendor by impairing your ability to resolve issues by yourself.
Not disclosing the ingredients is illegal large part of the world, and people can die if you don’t do that, so the answer is clearly yes in some sense. This is also true for some cooking techniques, like heat treatment of raw meat. I think your analogy is not the best.
Not disclosing ingredients is more like not disclosing dependencies because I am very confident that you can't go into a shop, buy a random food and then construct recipe from list of ingredients.
It does however play a hugely important role in a recipe, in a way than the choice of language doesn't play in a program (especially considering turing completeness). So the analogy is broken.
Besides nobody made the point that list of ingredients makes a recipe.
Just that it's important to know the list of ingredients for a food you're gonna eat, and that it's even illegal to not disclose them (either to the public or a regulatory body) if you sell food.
As someone who also believes closed source software is unethical (though full of nuance), I don't appreciate the abrasive and combative (and frankly rude) way you are engaging on this. You're so epitomizing the rabid stereotype that part of me thinks you are just trolling and don't actually believe what you are saying.
If you actually care about this, stop alienating potential allies, and ideally start making arguments to support your case instead of telling people to RTFM (which in this case is even worse because "the manual" isn't as much of an authoritative mic drop as you seem to think it is).
This is the first paragraph after the initial quote defining "free software".
> We campaign for these freedoms because everyone deserves them. With these freedoms, the users (both individually and collectively) control the program and what it does for them. When users don't control the program, we call it a “nonfree” or “proprietary” program. The nonfree program controls the users, and the developer controls the program; this makes the program an instrument of unjust power.
It seems safe to say the author thinks that one creating "an instrument of unjust power" for oneself is unethical. Though, perhaps if the commenter in question pulled that quote out of the article, it could have helped their point.
You don't have to agree with it, but I think it's fair to parrot a take from people who have invested a lot of time and effort into considering why free software is good.
The linked page has a clear explanation for why one might consider nonfree software to be unethical.
Sometimes people take the time to read and understand something and conclude that this is the best way to express it, better than they themselves can paraphrase.
And sometimes they just collect opinions and follow suit, instead of forming their own ones. How do you know which one happened here, are you a mind reader?
> How do you know which one happened here, are you a mind reader?
If you admit that they could be doing one of two things ("And sometimes ...") but you assume it's actually one of them in particular ("I think they asked for your take, not GNU's."), then this question could similarly be asked of you.
A bigger problem with my model is that it's a false dilemma. These are both just characterizations. Both can be true at the same time just fine, and so can neither.
It even does my own sentiment poorly. My actual issue with this whole exchange was not that their thoughts are unoriginal (although I'd be surprised), but that this way of responding I find extremely lazy and disrespectful, as well as generally unreasonable. They were asked for their opinion. It doesn't have to be good, it doesn't have to be rigorous, it just has to be theirs.
Linking out to some reading material and adding nothing else of substance fails even this most basic expectation. It's a discussion thread, not a newsletter. But then just like in the other subthread where the person above found me from, I'm sure they'd argue that this is just, like, my opinion. And that it sure is.
Could ask the same from you really, but then you followed me here out of spite from the other subthread to just loosely regurgitate another person's reply [0], along with your lackey [1], trying to make it a touch more hostile on the way, so I think I do know the answer to that one...
> If you're not interested at all, why did you even join the conversation?
Or was this a genuine question? I don't think you do those though. Are you then maybe getting tripped up on your own dumb headcanon? Cause honestly, given that this would be the third time in this thread that you're conjuring up a strawman and twisting words, you have to appreciate I have a hard time believing anything coming out of your mouth (keyboard?) at this point. It's almost as if there was a reason I went off about what I did, and it's coming back to bite you in the ass now...
To you, is a suggestion for someone to explain their own thoughts in their own words, rather than link to someone else's, a sign of no interest at all? Did I really say that I wasn't interested in what their take was, or did I say that I wasn't interested in receiving another barrage of GNU links? Careful, the latter one doesn't even require thinking, only bare minimum intellectual honesty, seemingly your Achilles heel.
> When I asked Kiro to fix a small bug (it was the same one I used in the past to try Codex), it quickly became clear that the workflow was like using a sledgehammer to crack a nut. The requirements document turned this small bug into 4 “user stories” with a total of 16 acceptance criteria, including gems like “User story: As a developer, I want the transformation function to handle edge cases gracefully, so that the system remains robust when new category formats are introduced.”
If there is only one thing you take from my post, then look up "NextJS middleware auth bypass" or something along those lines. Have fun reading about that and then never touch NextJS or anything Vercel ever again.
I won't repeat what the sibling poster said, but I can tell you, I've been using NextJS from v12-v15 and in that time we've had:
- The catastrophic (and, at the time, UNDOCUMENTED) "aggressive, opt-out caching of all fetch calls", which confused the living daylights out of everyone who suddenly couldn't retrieve updated data from their servers. Like, don't override a native JS function that's supposed to work in an expected way, with black-box magic that adds caching behaviour that then needs to be overriden _per route_ with directives on each route. Cache headers can be added to fetch calls and are easy to configure globally via axios if needed. If you're going to do black magic, call it "nextfetch" or something
- The app router / page router transition was shockingly badly handled, with so much missing documentation around dynamic routes
- I don't know how many different ways of fetching / setting metadata / <head>-related techniques I've had to learn by now. It seems to change all the time. BUT, that isn't the worst part....the worst part was / is:
- You couldn't, for the longest time, fetch metadata for a page without duplicating fetch requests. I think this is where their fetch-deduping thing came from. But again, black-box magic on a native JS function with very inconsistent behaviour, so for a while, all pages in our app just had to make two fetch calls per page that needed specific metadata added to the <head>
- Vercel as a platform not allowing to set billing limits (have fun with your DDoS that they don't recognise as such)
- Middleware is one file. That's what you get. No chaining, nothing. One god-function for everything. Just think about the anti-pattern that is
- I don't know whether it's clever or terrible, but if you want to add a sitemap, you do so by defining a route by creating a folder called sitemap.xml (yes, a directory), where you then put your route.ts which is in keeping with the way the new router should work. But somehow it just doesn't sit right with me. Folders with file extensions. But it also adds a lot of ability to make the sitemap highly customisable and dynamic, so maybe it's ok
- You suddenly needed to start awaiting url params, cookies, etc. which is sort of fine, but was a huge change causing warnings all over the compiler for months and months
Anyway, those are just a few things off the top off my head. I already find React to be quite counter-intuitive and non-deterministic, but NextJS just adds a layer of pain on top with very, very few advantages.
I am dying to get my hands on an alternative, but also don't want to rebuild all of the apps I built when I was still optimistic about NextJS.
As a mostly-backend dev I stumbled across the "metadata in <head>" issue in my first hour of using NextJS for a toy project.
I kept wondering if there's something wrong with me or if a framework recommended in so many places can really be this shitty, until I read your comment.
- fragile under load and very difficult to debug SSR issues
- inconsistent behavior between hosted and self hosted versions of the same code
- horrible build times, like laughably bad multi-minute builds for trivial code bases
- crappy directory based routing system with lots of weird gotchas
- schizo identity JAMstack -> serverless -> ssr -> now its microvms + ai
- multiple hilariously long running GH issues where the dev team is thrashing around trying to debug their own black box framework
- "framework" that barely provides any of the primitives necessary to build web apps
- major breaking changes around core features like routing that require painful migrations
- general sloppiness, churn, and insecurity that comes from being part of the nodejs ecosystem
Thats not even getting into all of the shady patterns vercel uses to lock you into their overpriced hosting.
I've been a part of multiple teams that decided to build apps using NextJS, and while the FE is not my responsibility I typically got pulled in to help troubleshoot random issues. It was a complete waste of time in almost every case, and in one case resulted in the entire FE team being let go because they were unable to ship anything on time.
Yeah matches my experience. It’s just so much complexity just to get SSR. I’ve worked at places that used it for b2b SaaS apps with no public web part, so the SSR is just a big liability… whyyyyy
I use it for my web site where SSR is critical for SEO. For app development I don’t use Nextjs. I think it is designed for web sites (as opposed to web apps) and it is great for this purpose
I think Meteor is finally starting to fully overcome the tech debt from the second half of the last decade. They're in a recent Node.js release, and the next version will integrate a modern bundler (Rspack) in its tooling.
Lots of apps are still stuck in Meteor 2.x hell because of the dependency on Fibers though.
I was pretty involved in their stack back in the day, it was a good alternative to Django at the time for simple plug and play admin apps, and to this day i think they had the simplest OAuth setup of any framework I've used.
The real issues were the super tight coupling with MongoDB and their decision to roll their own package ecosystem instead of just using npm from day one.
Not to mention their braindead decision to aggressively cache everything as much as possible, which they're now trying to undo, but still haven't shipped.
Used Astro for a pro bono project. Found it fantastic, well documented, provides solutions for the hard parts, gets out of the way for the easy parts. Documentation is well written, but I find I don't need it much because mostly it works how I would expect.
You lost me at React SSR. That is part of the complexity bs. React is a lib for mapping state to the DOM. There's no DOM on the server. So React on the server is 95% useless for that purpose and hence, overengineered to create a bit of HTML and send it down the wire.
I like the simplicity of Hono and use their html helper to write good old HTML that is send to the client.
Hono is a server-side framework like Express. So same way like you handle application state in most server-side multi-page web apps: You just fetch whatever you need from the DB per request.
"State management" really isn't that much of an issue on the server. Only on clients, when you need to map state changes to DOM updates.
I've heard good things, what would you say is the killer reasons to justify being the nodejs ecosystem vs something more purpose built for ssr like php?
"The Wall Street Journal reported last week that before OpenAI released Sora 2, the company told talent agencies and studios if they didn’t want their copyrighted material replicated by the video generator, they would have to opt out"
I hope they get sued to death for copyright infringement.
Doesn't even refute it... Warhols fame came from claiming any absurdities of capitalism and the art market as his working material. He was a "Business artist".
