Lessons learned from 15 years of SumatraPDF, an open source Windows app (2021) - https://news.ycombinator.com/item?id=35065785 - Mar 2023 (173 comments)
Seems like the author didn't look at cross-platform toolkits since 90s.
Sure, but not accessibility or UX design. There's more to a good UI than looking pleasant. Far more. I wish we hadn't unlearned that in the past decade, because Flutter and browser-based UI kits throw all of that out the window.
Discarding it out of hand by "qt is bloated" just feels disingenuous to me. You can add to that the fact that qml on the desktop if finally maturing into a viable alternative for widgets, and UI development with qml is such a breath of fresh air.
From a user perspective I remember that being a big thing some time ago when people didn't have anything already using Qt install did an “apt install” or “yum install” on something that did and saw the small tool they were wanting was going to drag half a desktop environment in with them as dependencies. The same could likely be said for GTK in reverse, I'm not sure what their relative sizes for similar features are these days.
Some use bloated to mean the memory footprint. IIRC GTK has more of a reputation for eating RAM than Qt, but again maybe people notice a single Qt app using a lot of resource (that would be shared if running multiple apps against the same libs) when it is the only one they run.
As you suggest, just stating that “<whatever> is bloated” without reference to some details of what is meant by that, sounds a bit like someone parroting old information and/or group-think rather than having looked into it recently.
Having said that the author has a minimal dependency stance in order to try to maintain a small footprint for the app (“I avoid unnecessary abstractions.” in the section about keeping things small) so any framework that isn't little more than a cosmetic wrapper could legitimately be called more bloated than using nothing at all and talking more directly to the standard OS libs. Also in context (discussing why the product is not cross-platform and is never likely to be) this is not the only reason being given and probably not the most significant one (there may be significant selection of cross-platform issues beyond the UI framework).
The key to a lot of what is in that document is the “It’s my project and I act like it” part. All too often we forget this very important side of things, especially with one-man or small-team projects, and people comment on project decisions as if using the product gives some automatic expectation that the creator will mould it around the needs/wants of a given user or someone's idea of “the community”. For an open source project the community has the option of forking the project or offering to fund the changes they want that aren't otherwise on the creator's roadmap (though obviously the larger the project, the less practical these options may be)…
That said, has there been any fundamentally groundbreaking crossplatform classic UI toolkits released since the 90s? (IMGui is the only one that has seemed interesting but that's specialized and not a general one really)
I'm pretty sure that something based on IMGui could be more or less isomorphous to React style rendering, it'd be up to someone to implement it though (and it'd probably be worth it since building applications at scale you win back a lot of time by not fiddling with state manually all over the place).
Using Chromium however is explicitly not where we should want to go (it's basically a kitchen sink in itself), but we go there anyhow (me included often) because it's just so much more quick thanks to progress in dev experience in the webdev area.
That's fair in the sense that I did not look closely at latest Gtk or Qt or WxWidgets.
That being said they certainly did not get lighter.
Last I checked Qt was over 10 MB of libraries). Sumatra is 12 MB and I'm guessing over 8 MB is fonts needed to render PDF documents.
So just Gtk or Qt code would be more than the whole app.
Latest Gtk4 does seem to look nice so maybe calling it ugly was uncalled for.
Edit: I just checked and Acrobat Reader requires 450/900/380 MB for Win32/Win64/Mac respectively [1]. One might argue that it does more than just read PDFs. But in many cases, reading PDFs is all that I need.
> And yet I do know that you can write complex, relatively bug free code without tests, because I did it.
> I do know that you can write complex, relatively bug free code without anyone looking over your code, because I did it.
> If no one uses your app then who cares if it crashes.
> If many people use your app and it crashes, they’ll tell you and then you’ll fix it.
Those four statements are contradictory. What they're saying is not that you don't need testing or code reviews, but that you can get your users to test for you.
I figure the author probably does test their code (everybody tests, even if that just means running the app), but not rigorously or in a way that you could say gives one the security of regression tests.
No-one worth discussing the issue with claims that it's impossible to write complex code without automated testing. I'm a huge proponent of automated testing, and I wrote a relatively large, cross-platform renderer without a single automated test back in the late 90s/early 00s ... it just took a long time, and I became increasingly terrified of making changes.
Edited for formatting.
What I was trying to say is: there's dogma about tests and code reviews.
At Google you would get fired for suggesting skipping code review.
Even at smaller Silicon Valley companies (smaller == less than 10 devs) it's unthinkable to not do code reviews. I haven't worked outside SV so it might be different.
That's the dogma.
My point is that maybe we should apply a bit of common sense on top of that.
I'm not saying Google should stop doing code reviews - the cost (to Google) of google search breaking is so high that you do 100x more than just code reviews.
But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.
There's a good rule of testing top level behaviors described in this talk [1]
For code reviews, it's about knowledge handoff. No one disputes you can write great code alone. The problem is that singular geniuses writing functional but unmaintainable code only they understand and then getting hit by a bus or changing jobs is a real issue.
It's a mess. We've been paying them serious money for a product. We've never been warned that their product isn't finished yet or that we're the beta testers for the product they'll sell to other clients. Or that we have to invest our own personal and their time to fix their problems and talk to their useless support.
This has become a pattern and I'm done with it. We are slowly moving back to older and larger companies who actually do their work properly before they roll out products and updates.
I know CGM from medico...their KIS is a nightmare. We have to communicate with it in hospitals. What an ugly monster and somehow no hospital IT is able to admin it properly.
Which of their products are you considering?
What Data Warehouse software do you write for RIS? Maybe I can use it :D
...and yeah Radiology communities are rare. I'm still looking for one...if I have time.
The DWH software writes snapshots of db_direct into a temporal DB (implemented in Postgres using multiranges) and then uses dbt to transform the data into usable tables. Right now, I use Power BI for visualisation and reporting.
However it's good for usual Doctors offices. It's terrible for Radiology Planning. Also many institutions just put a link to their homepage or phone number in there. This way they're on DL but don't have to deal with the calendar.
...
> But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.
It's not dogma, it's just the necessities of large groups of people working together. A small organization can use common sense, a function that scales up to (20? 50?). 10,000 people can't operate on common sense; they need another function: rules.
Much of our professional habits are part of the corporate chains which is optimised to deliver and squeeze as much as possible.
Software developed in the wild does not have those corporate obligations and the sole purpose is to enjoy the process, the sheer joy of creating something. Of programming as a creative medium.
You don't get your paintings code reviewed. It's just that artistry. You like it, then you like it, end of the story, you're not playing for the gallery.
Corporate enslavement works differently. It has moved and distributed the part of the factory shift in charge to the dude sitting next to you, cleverly. Many are just complaining to make sure they're considered the quality sensitive cooperate loyals.
You two might like different pigments for the grass and he'll strike down your painting with a red ballpoint if not to his taste.
Happens to all of us and if not, wait for it.
Declaring a single boolean flag in a corporate environment might cost more then an hour to get to a consensus because one I-am-dffierent-I-care-too-much guy has some objection about some ambiguity in the flag name in some far future and has now swayed roughly half the team on his side.
That doesn't exist in open source. Open source is all about anti status quo. It is pure rebillion. It started that way, it is about hippies and naysayers. The very root of the GNU toolchain, Herd etc are probably there.
EDIT: Typos + corporate software development environment.
That's the main value of automated tests.
seek forgiveness rather than permission - gets you launched - gets you better