841–850 of 875 posts
I remember fetching HTML from the server with AJAX and updating innerHTML before it was called AJAX. Is HTMX repackaging that or am I missing some exciting breakthrough here?
It is like that yes but more abstract because it uses some special HTML tags to make the JS calls. There is a big downside though: weak error handling. It just assumes that your call will get a response.
Earlier quoted context omitted.
> by a single server maintaining all the states HTTP is stateless. This is the whole point of the hypermedia paradigm. If you have a page with many partial UI page changes over htmx, then yes, this paradigm puts increased load on the server, but your DB will almost certainly be your bottleneck before this will be, just as in the SPA case.
I'm not talking about network state, but app state. Yes, in HTMX the server is handling client app state, even things as little as whether a todo is in read or edit state. That just seems absurd to me, let the client take care of that.
Earlier quoted context omitted.
I maintains a side project in Django since 5+ years now. The scope has been reduce to almost nothing. I have spend like 20h on it in 2022. But it still being used. Django helps by how boring and solid it feels. A similar project in node would probably not build anymore
I know of a 15 years django project that runs on 2.7 that is still making money. It got reinstalled this month on brand new Ubuntu servers out of a rubbish requirements.txt, and it worked. So much for saying python packaging sucks.
Django can also serve a boatload of concurrent users, way more than one would think. It is a boring, old-fashioned, but stable and very functional framework.
Earlier quoted context omitted.
I'm not sure what you're getting at. I'm not talking about bandwidth usage at all . I'm talking about CPU, memory and IO (as in disk, not client server transfer) usage.
I'd wager all of those things are still lower on their "low bandwidth" option. Now, I will grant that it does less. Probably lacking a lot of the "presence detection" that is done in the thick client. Certainly lacking a lot of the newer ad stuff they are pushing at. But the rest could be offset by a very basic N-tier application where the "envelope" of the client HTML is rather cheaply added to any outgoing message.…
I would argue that Google has thrown a bunch of engineering talent at it to optimize the problem as much as it can be for a web interface, and that Gmail is a bad example of a a SPA mail client, as it's more a combined mail client and IMAP server (really a custom designed mail store) all rolled into one. Whether Gmail itself really uses more or not is somewhat irrelevant to whether a mail client in general leans into the benefits a SPA provides. This is what I was talking about here.[1]
That said, whether it uses less resources is a tricky question. Sometimes there's algorithmic wins that overall reduce the total work done, and I don't doubt Gmail leverages some of those, but it's also just a huge amount of caching, whether in the browser or in a layer underneath. The benefit of a SPA is that you can customize the caching to a degree for the application in the client without having to have an entire architectural level underneath designed to support the application. For anything at scale, having that layer underneath is obviously better (it's custom fit for the needs of the application and isn't susceptible to client limitations), but it's also very engineering intensive.
My guess is that Gmail puts a very large amount of cache behind most requests, and is just very, very good about cache invalidation. Or they've got the data split across many locations so they can mapreduce it quickly and efficiently (but tracking where those places are will necessitate some additional resource usage).
In the end, you need caching somewhere. You can do it on the server side so that you have full control over it but you have to pay for the resources, or you can do it on the client side with some limits on control and availability, but you don't use your own resources. SPAs make client side caching more reliable in easier to deal with in some cases, because the working state of the client isn't reset (or mostly reset) on every request.
Earlier quoted context omitted.
Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is se…
A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer . If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in…
Did you mean “receiving mail intended for people that gave my email address”? Because that's how I usually notice that they did.
Earlier quoted context omitted.
A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer . If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in…
You missed my point, I'm afraid. I meant that it very much depends on the business-case (and hence laws and regulations) what exactly you'll have to verify, and therefore where you verify and validate it. Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Then it probably only has to be guaranteed unique. Do…
Pretty humongous dick move to use someone else's email address as one's own login for some website, wouldn't you agree? What if it's a popular website, and the owner of the address would like to use it for their id; why should anyone else be able to deprive them of that?
And thus it's also a dick move from the site operator to allow those dicks to do that. So no, it doesn't depend: Just don't accept untested email addresses for anything.
Earlier quoted context omitted.
> Yes. I’m generally against specialization and splitting teams. This of course depends on what type of organization you have and how complex the frontend is. iOS and Android is usually complex as it is so they are typically specialized but I would still keep them in the team. Right why have someone _good_ at a particular domain who can lead design on a team when you can have a bunch of folks who are just ok at it, a…
You are comparing apples with oranges. I'm talking about organization, you about individual developers. I can have fullstack that is better than a specialist. Specialist only means that they have specialized in one part of the architecture, that doesn't necessarily mean that they solve problems particular well, that depends on the skill of the developer. And the point is that even if they do have more skill within th…
Are. En developer is, flera developers are.
> Most ORMs, especially if they are of type active record, just misses that mark entirely
Miss. En ORM misses, flera ORMs miss. (Du fixade ju "are"!)
> Performance is generally bad, thus most ORMs has
Have. En ORM has, flera ORMs have.
Kom igen, så jävla svårt är det inte.
Earlier quoted context omitted.
I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…
> felt they had to switch to Angular about the same time and they never regained their footing in the Angular age And in this case what actually happened is exactly what we had expected would happen: tons of badly-written Angular apps than need to be maintained for foreseeable future because at this point nobody wants to rewrite them so they become Frankensteins nobody wants to deal with.
Earlier quoted context omitted.
You missed my point, I'm afraid. I meant that it very much depends on the business-case (and hence laws and regulations) what exactly you'll have to verify, and therefore where you verify and validate it. Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Then it probably only has to be guaranteed unique. Do…
> Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Pretty humongous dick move to use someone else's email address as one's own login for some website, wouldn't you agree? What if it's a popular website, and the owner of the address would like to use it for their id; why should anyone else be able to depriv…
Not all web-applications with a login are open for registration. Not all are public. Not all are "landgrab". Not all have thousands of users or hundreds of registrations a week. Not all are web applications and not all require email validation.
Some do. But, like your niche example proves: the business-case and constraints matter. There's no one size fits all.
Earlier quoted context omitted.
> do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/
One great thing about your docs is the anticipation to concerns.
Must be why they're called “Recursive Doubts”.