> The main problem is that the state of your frontend application is in the URL.
There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.
It's not a black or white, one actually has to think about what the application must achieve.
> modern UI where you might have many different zones, widgets, popups, etc.
This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day.
> React / Vue that all provide their version of a state store that can hold the state
And many times they duplicate what's already available server-side.
> There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.
> It's not a black or white, one actually has to think about what the application must achieve.
You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
> You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more.
But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.
> You don't have to do any of this in a Vue / React app
Something has to do this in an app regardless of what UI framework you're using. Deciding where a particular piece of state lives is fundamental to web development, and yes, URL/session/cookie/database are all valid options depending what kind of state you're storing.
User state is sometimes necessary, but frequently a crutch to avoid answering the real questions. Much of the time, this user-state is at the core of many performance and behavior issues as the user is burdened with unnecessary DOM reorganization. If the layout is dependent on more than just URL parameters and simple server state/cookies, then it begs the question: does this page really have a specific, well-defined purpose? If not, it's ripe for noisy UX, confused users and hard to untangle interface bugs. If so, you probably shouldn't be doing so much on-the-fly DOM configuration. You're not building an OS or window manager here.
Notably, none of this is incompatible with React/Vue where you need it.
How do you know you have the right application to open the file? I have tried at least a dozen apps to open *.stl files... some work, most don't. Some have features I need and don't work opening files. Some are sensitive to stl's that require repair and stop working... and I could go on and on for different file types. The point is; sharing isn't "guaranteed" to work across apps and is generally far, far from "it just works". You have almost zero control over the actual files because there might not be a way to save different formats from the app you are using, or the files app doesn't recognize the extension, or you can't find the folder for the other app, or it doesn't have a user accessible folder, or it will not load files from the "files app"... or <insert 50000 more "what if's here>. The whole things just sucks so, so bad.
And how do you know a Word file will work seamlessly across other word processors on a computer that are suppose to read Word files or export to Word? What modern productivity software doesn’t support using the Files app? It has been around for well over a decade.
On your computer, do you inspect the details of a file using Explorer? On the Mac do you do that with the Finder. Or do you actually open the file with an application?
Do you expect to use Windows explorer or the Finder to “convert file types”?
Using iOS 26 on my phone, I held down a file and there is an “Open With” option that gave me a choice of how to open the file.
Across applications? Applications these days save files using the File dialog, they may by default store them in a folder accesible by Files. Yes I know some apps still store their data in their own sandbox. But that’s not the case generally for standard productivity apps.
If I need to know the details of a file (eg file extension, size, location, etc) I generally use the Finder for that, yes.
I do frequently convert file types through the Finder. Bulk converting a bunch of photos, for example, is easier to do through a file browser. Even if I were opening a different app to do that, a standard file browser would be the interface I would want for that.
It’s great if more iOS applications are storing files as regular files on the filesystem now. Apple should have encouraged that in the first place. There was some goofy notion they were going to get rid of the idea of “files” with iOS, but that’s not actually a good idea.
I've used similar webview solutions before and they can break even on Windows (example: needing edge webview2 but not available on the user install). I get why people are pissed off by Electron but I also get why it's the de facto standard in its field.
I prefer working with Django ORM too by a large margin. But I think it's more opiniated than SQLAlchemy, which may be why SQLAlchemy is considered the reference (well.... this and the fact that Django ORM is not a standalone lib). It's great if your use case fits to it but if not, SQLAlchemy probably gives you more adaptability.
But yes, Django ORM any day... or just no ORM at all.
SQLAlchemy has one strongly-held opinion, that there should be a 1:1 mapping between objects in a database and in memory. So if you query the database then modify the result, the change will automatically also be made in the DB.
I strongly dislike this, since you always have to be careful not to make some unwanted change. When checking permissions, you have to check before you modify the object. You can't modify it and then run some permission checker. You also can't easily keep the old version around.
Sadly it seems most ORMs follow this style, and that Django's is the odd one out.
Last time I used it you had to commit session, so no actual change in the database is made until this. It's sill annoying that an update is scheduled though.
Pycharm has been fine. Just disable the AI stuff and you get accurate completion. It even has completion for Django ORM stuff, which is heavily dynamic.
(yes, I don't really get it either)