> If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives.
But it's not, is it? The state lives in the server. If I open a page, and let it open for 2 hours, then there's no guarantee it actually represents the current state.
You are conflating all state into a big undifferentiated soup.
I reason about state differently, Here are my axioms:
1. There is no such thing as "state".` There is user/ui state, there is cache state, there is db cursor state, etc. trying to manage all of that as big undifferentiated ball is not proper separation of concerns.
2. what I call User State is the user's exceptions that they will find things "as they left them". If as a user, I do a pager refresh, I expect that my user preferences for colors and fonts will still be there. that the sorting on the table I was looking at will still still be there, that the filters I had applied to the table are still there. That is I was editing a record but had not saved, I will still be editing that record without data loss on screen but still not saved to the db (unless the app is explicitly autosave). In a word: the user state is what the user can see.
3. Ideally my User State has a single source of truth, the user can always confirm it by looking at it, and is therefore IN the front end.
4. Most, if not all, other state is stored on the server. things like the user's auth state is a -backend- concern, and should NOT be stored in the frontend.
5. class-oriented programming is extremely difficult to manage: as I like to say, every class is a petri dish for state corruption. I prefer pure functions on the backend for the reason I outline ion the dataos.software blog articles.
Pure functions are mostly deterministic (especially if you avoid floats). So you can not only count on getting the same results for the same query, you can cache them too. And you can test them trivially. Integration test? What's that?
When you capture the User State from the DOM (using a manifest so that you do not need to capture the whole DOM) and send it to the pure function on the back end, you have a perfect event source pattern. Not only can I tell you exactly who and what triggered a particular piece of html being sent o the screen, I can rewind and reply like a tape recorder.
BTW, I have no hate for React. There are some things I think it does better than any other option. I was a core member of the React Studio team (expired cert on the site but safe to visit for archeological purposes).
It feels like the worst of both worlds, what am I missing?
I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive.
I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint.
This seems like a worst-of-both-worlds paradigm, where the backend needs to be intimately aware of the frontend context. Am I not getting it or is there a massive implicit coupling?
Now if I need to display the same "user" data twice, in different formats, on my website. Say, as a table in "My account", and as a dropdown in the menu bar. Do I need to write two endpoints in the backend, returning the same data in two different formats?
You need to get out of the mentality that there have be two states.
Ultimately the frontend state cannot exist without the backend, where data is persisted. Most apps don't need the frontend state, all it really gives you is maybe a better UX? But in most cases the tradeoff in complexity isn't worth it.
This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state.
I don't see how it's any simpler to shift partial presentation duties to the backend. Consider this example:
The backend is supposed to respond with the rows to fill a table. You have an extremely tight coupling between the two. Something as simple as changing the order of the columns would require three releases:
- A new version of the backend endpoint
- A frontend change to consume the new endpoint
- A version to delete the old endpoint
I'm not trying to be obtuse, but I fail to see how this makes any sense.
Consider something as simple as an action updating content in multiple places. It happens all the time: changing your name and also updating the "Hello $name" in the header, cancelling an order that updates the order list but also the order count ...
There's _four_ ways to do it in HTMX. Each "more sophisticated" than the previous one. Which is one really wants, sophistication, isn't it?
I really struggle to decide which example is worse. Not only the backend needs to be aware of the immediate frontend context, it also needs to be aware of the entire markup.
In example two, a seemingly innocuous renaming of the id of the table would break the feature, because the backend uses it (!) to update the view "out of band".
I'm really trying to be charitable here, but I really wonder what niche this is useful for. It doesn't seem good for anything complex, and if you can only use it for simple things, what value does it bring over plain javascript?
> This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state.
No, there's two states here: the frontend state, and the backend state.
The name example is trivial, but in real applications, your state is complex and diverges. You need to constantly sync it, constantly validate it, and you need to do that forever. Most of your bugs will be here. The frontend will say the name is name, but actually it's new_name. How do you do fix that? Query the backend every so often? Maybe have the backend send push updates over a websocket? These are hard problems.
Ultimately, there is only one "true" state, the backend state, but this isn't the state your users see. You can see this in every web app today, even multi-billion dollars ones. I put in some search criteria, maybe a check a few boxes. Refresh? All gone. 90% of the time I'm not even on the same page. Push the back button? Your guess is as good as mine where I go. The backend thinks I'm one place, but the frontend clearly disagrees.
SSR was so simple because it FORCES the sync points. It makes them explicit and unavoidable. With a SPA, YOU have to make the sync points. And keep them in sync and perfect forever. Otherwise your app will just be buggy, and they usually are.
I fail to see how HTMX helps. I fail to see how SSR necessarily helps too. You could be serving a page for an order that's been cancelled by the time the user sees it.
> I put in some search criteria, maybe a check a few boxes. Refresh? All gone
You could see that 20 years ago too, unless you manually stored the state of the form somewhere. Again, what does it have to do with HTMX, or Rect, or SSR?
HTMX helps enhance UX by not having to reload/render the entire page. IME it should be used sparingly.
For your name example, you could use hx-swap-oob to update multiple elements. However if you're submitting a form element, I would just re-render the page.
> You could see that 20 years ago too, unless you manually stored the state of the form somewhere
See, that's my point - it's NOT manual, it's explicit. There's a difference. A form submission and page refresh is just that. It's very clear WHEN the sync happens and WHAT we are syncing.
With a SPA, you throw that all away and you have to do it yourself. And it's almost always done poorly and inconsistently.
> Something as simple as changing the order of the columns would require three releases
Just change that example to just return the entire table element on /search. You could even add/remove columns with a single route response change, vs the multiple changes required to sync the front/backend with a JS framework.
Splitting application API and generic data API is orthogonal to HTMX. You still have issues compared to plain JSON, don't you?
Imagine you need firstName/email in once place, firstName/email in another, and firstName/D.O.B in another.
In a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. My understanding is with HTMX, I'd have to craft (and maintain/test) three different endpoints, one per component.
I feel like you would quickly end up in a combinatorial explosion for anything but the simplest page. I really don't get the appeal at all. Of course everything can be very simple and lightweight if you hide the complexity under the bed!
any factoring you do on the front end you can do on the back end too, there's nothing magic about it and you don't need different end points: that can be a query parameter or whatever (if it's even a request, in most hypermedia-based apps you'd just render what you need when you need it inline with a larger request)
it's a different way of organizing things, but there are plenty of tools for organizing hypermedia on the server well, you just need to learn and use them
> n a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it.
The main problem is that this is extremely, extremely expensive in practice. You end up in Big Webapp hell where you're returning 4mb of data to display a 10 byte string on the top right of the screen with the user's name. And then you need to do this for ALL objects.
What happens if a very simple page needs tiny bits of data from numerous objects? It's slow as all hell, and now your page takes 10 seconds to load on mobile. If you just rendered it server-side, all the data is in reach and you just... use what you need.
And that's not even taking into account the complexity. Everything becomes much more complex because the backend returns everything. You need X + 1, but you have to deal with X + 1,000.
And then simple optimization techniques just fall flat on their face, too. What if we want to do a batch update? Tsk tsk, that's not RESTful. No, instead send out 100 requests.
What about long running tasks? Maybe report generation? Tsk tsk, that's not RESTful. No, generate the report on the frontend using a bajillion different objects from god knows where across the backend. Does it even make sense with the state and constraints of the data? Probably not, that's done at a DB level and you're just throwing all that away to return JSON.
I mean, consider such a simple problem. I have a User object, the user has a key which identifies their orders, and each order has a key which identifies the products in that order. Backend-driven? Just throw that in HTML, boom, 100 lines of code.
RESTful design? First query for the User object. Then, extract their orders. Then, query for the order object. For each of those, query for their products. Now, reconstruct the relationship on the frontend, being careful to match the semantics of the data. If you don't, then your frontend is lying and you will try to persist something you can't, or display things in a way they aren't stored.
The backend went from one query to multiple endpoints, multiple queries, and 10x the amount of code. The frontend ballooned, too, and we're now essentially doing poor man's SQL in JS. But does the frontend team gets the bliss of not dealing with the backend? No, actually - because they need to check the database and backend code to make sure their semantics match the real application semantics.
> What happens if a very simple page needs tiny bits of data from numerous objects? It's slow as all hell, and now your page takes 10 seconds to load on mobile. If you just rendered it server-side, all the data is in reach and you just... use what you need.
You went on a long tirade against REST, which nobody mentioned. Just ... write an endpoint returning the data you need, as JSON? But write it once, instead of once per view variant?
> Just throw that in HTML, boom, 100 lines of code.
Now you need the exact same data but displayed differently. Boom, another 100 lines of code? Multiply by the number of times you need that same data? Boom indeed, it just blew up.
> Now you need the exact same data but displayed differently. Boom, another 100 lines of code? Multiply by the number of times you need that same data? Boom indeed, it just blew up.
It isn't 2004 anymore - all of the server-side frameworks have components.
Except, now instead of using serialization and JSON, it's a real API. In code. I can click and go to definition.
> Just ... write an endpoint returning the data you need, as JSON? But write it once, instead of once per view variant?
What you just said directly contradicts itself.
If each view variant needs slightly different data, or ordering, or whatever, we now need to make N APIs. Or we don't. And now we're back at square one and everything I said is valid.
The more modular and reusable your API is, the less performant it will be and the more bugs it will introduce. I'm all for the God API that has 1 million endpoints each doing one specific thing. But it seems nobody else is, so instead we get the fucked ass RESTful APIs that are so bad and lead to such overly complex code were pushed to write critical CVEs to avoid them (looking at you, NEXT)
via 3 different rendering logic, (such as JSX templates) same as the server
> if you hide the complexity under the bed!
which is what you just did by dismissing the reality that client-side requires the same 3 renderers that server-side requires! (plus serialization and deserialization logic - not a big deal with your simple example but can be a major bottleneck with complex, nested, native objects)
This isn't about the number of rendering logics. You'll have as many as you have variants, that's tautological. This is about where they happen.
In a classic app, there's one entity that keeps the state (the server), and one entity that keeps how it is rendered. This is very easy to reason about, and the contract is very clear. If I want to understand what happens, then I can open my frontend app and see "Hello <b>{{name}}</b>".
In HTMX, the logic is spread. What I see is a construct that says "Replace this with the mystery meat from the backend, whatever that is".
Assume there's a styling issue. The name looks too big. Is it because the frontend is adding a style that cascades, or is it because the backend returns markup with a class? Now any issue has an extra level of indirection, because you've spread your rendering logic into two places.
> which is what you just did by dismissing the reality that client-side requires the same 3 renderers that server-side requires!
But what's complex isn't the number of renderers, it's where the logic happens. The HTMX website is full of examples where the header of a table is rendered in the frontend, and the body is rendered in the backend. How's that considered sane when changing the order of the columns turns into a real ordeal?
> If I want to understand what happens, then I can open my frontend app and see "Hello <b>{{name}}</b>".
> In HTMX, the logic is spread
I disagree... with React, by definition, the logic is spread. Persistent data, and usually, business logic, is in some data store accessible via the app backend. And then a totally different entity, the front-end, renders that data (often implementing additional business logic) and manages state (which is often not yet recorded in the data store until various updates can be performed).
HTMX helps keep everything aligned. All the rendering logic is right there along with the data and the business logic. If I'm looking for a renderer, not only is it easy to find the template that produced "Hello <b>{{name}}</b>" but it is also easy to find the source of {{name}}. Which also makes it easy to alter {{name}}, say, from Smith, John to Mr. John Smith - because the data store and business logic are right there, it is low effort to switch the order and to begin including the salutation.
Your "front-end" is still all in one place, except it's on the server, and typically rendered via templates instead of React components. But the templates can often access native objects (including their properties and functions) instead of solely relying on JSON objects.
This comment is already long but regarding data tables... yea, highly dynamic pure data-based UI's such as charts and tables aren't HTMX's forte. But even then there are ways... the data- attribute is very useful, and since you are already using JS to handle sorting, filtering, re-ordering, showing tooltips, etc, it's very possible to render valid HTML fragments that can be properly rendered via that same JS (or contain data which can be).
Not a problem with Jinja (or any server-side templating). Both the table and dropdown render from the same context variable in one template pass. One endpoint, one data fetch, two presentation formats.
The "two endpoints" concern assumes you're fetching fragments independently. If you're composing a full page server-side, the data is already there
So now you have presentation logic, tightly coupled, spread over two places. You need to jump between two codebases to even have a clue about what is rendering on the page.
There's an example on their website where the header of a table is defined in the frontend, and the body is returned by the backend. If I wanted something as simple as switching the order of the columns, I'd actually need to create a new version of my backend endpoint, release it, change the frontend to use the new endpoint, then delete the old one. That sounds crazy to me.
So what if you have presentation logic in two places, if it isn't necessary, remove the second instance?
There are so many gains by not using a frontend. You've greatly reduced your site size, removed duplicated logic, a shitload of JS dependencies, and an unnecessary build step.
I use nested templates the same way React uses nested components. The key is cascading the context (like props) down the hierarchy. Column order change? One edit in the table template; everything that includes it gets the update.
The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice.
When they eventually roll it out (And they will, they always do), everyone will have had plenty of time to run the numbers and either come up with a plan, or just swallow the pill.
If you still complain in a few months then that's on you, because you've been warned.
Humans respect the rules because if they don't, then they lose their jobs, can't pay their mortgages, and become homeless. That's quite a powerful incentive not to fudge the numbers too much.
Why would the AI care? The agent builder is still asking a non-deterministic black box with no skin in the game to behave a certain way, they have no guarantees.
Yes, in fact I've heard people argue the opposite point, that EU benefits Germany more than the rest of the EU countries. The argument starts from Germany being more competitive than most EU countries. Protection from external trade is usually needed so that an industry can home brew and reach competitive or almost-competitive state, and trade barriers are then removed to keep improving against competition. But with competition in place you can't go from zero to one in established industries. The result, the argument goes, is that Germany ends up owning entire industries within the EU.
But some people cannot conceive that some arrangements can be win-win.
And 88 million people signaled they were fine with either candidate, by not voting. 165 million people out of 264 millions eligible voters supported this.
as someone who has never voted, i am absolutely okay with this characterization. i often hold my tongue when it comes to complaining about political stuff because i dont really feel like i have the right to. i mean, of course i HAVE the right, but the hypocrisy isn’t. to be clear: this is not the same thing as being animated about general gov. malfeasance, which is something that everyone is in the right to complain about, as the operation of the government isn’t a politics-specific issue in a lot of cases.
> don't think one can blame them, not voting can be a legit option for many reasons,
With the exception of people who have religious beliefs prohibiting voting, it’s saying that you don’t feel strongly enough about the differences between the two candidates to pick one. There are some people who can plead various hardships, but most people don’t have that excuse: it really did come down to thinking their life would be fine either way.
No, in the US electoral formula, not every vote for President will make a difference. Seven out of 50 states are close, so in 43 states it’s only a protest vote.
It still matters for the popular vote and all of the downstream candidates. People who stay home inevitably complain about local changes which also were on the ballot.
I strongly support national electoral vote reform but it’s important to remember that every election really does matter.
In a healthy democracy there are more ways than just voting to influence the countrys political affairs. Democracy has a price, voting every four years is not enough.
This sounds horrible. Onboarding should ideally be marginally about the "what". After all, we already have a very precise and non ambiguous system to tell what the system does: the code.
What I want to know when I join a company is "why" the system does what it does. Sure, give me pointers, some overview of how the code is structured, that always helps, but if you don't tell me why how am I supposed to work?
$currentCompany has the best documentation I've seen in my career. It's been spun off from a larger company, from people collaborating asynchronously and remotely whenever they had some capacity.
No matter how diligent we've been, as soon as the company started in earnest and we got people fully dedicated to it, there's been a ton of small decisions that happened during a quick call, or on a slack thread, or as a comment on a figma design.
This is the sort of "you had to be there" context the onboarding should aim to explain, and I don't see how LLMs help with that.
But it's not, is it? The state lives in the server. If I open a page, and let it open for 2 hours, then there's no guarantee it actually represents the current state.
reply