In most production cases, there is no luxury of debugger.
In my current $job, all we get is logs from 70+ node cluster and that too in a shared-nothing architecture. You have to stitch together varied datapoints (job logs on multiple nodes, netstat o/p, job logs of other services, http access logs, tcpdump, etc) to even prove that problem is on the customer side and not ours.
You have to know what key to use to decrypt the timestamp bits of the token. If you change keys regularly you have the problem of keeping lots of keys, as well as somehow determining the right key
I am backend dev and dipping my toes in frontend dev for my side hustle.
It is a typical CRUD app (like most of them). I like the idea behind HTMX or datastar. I built a prototype in it as well. But then I pivoted to solidjs.
Some reasons for this:
1. Single backend API for web, mobile and any other platform
2. Some UI patterns which are suited for JSON REST APIs [#patterns]
3. Ability to support partial functionality offline.
#patterns
1. Showing a subset of columns in a table but have an option to view & edit each record in detail. In my case a dialog opens with editable checkbox. So it doubles-up as "view" and "edit". These actions render just another view of existing data. A round-trip to server is not desirable IMO.
2. Filtering, sorting on columns. HTML based solution becomes tedious if some of the cells are not plain text but instead a complex component like a <div>. Sorting json and rendering is much better experience IMO.
Edit: About solidjs & datastar
1. It has fine-grained reactivity which I find it appealing and it uses signals which hopefully will be standardized.
2. The compiled bundle size is much smaller than I expected. I have 24KB compressed js which is serves quite a lot of views, pages.
3. Datastar is amazing and I have added it in my toolbox.
I felt like these song as rings tones went well with the optimism around technology at that time which I feel has just been crushed by internet giants and the rise of surveillance capitalism and social media.
There was something great about early phone based digital photography and it being offline, so convenient yet completely "yours" (for example).
Definitely don't feel as if it's all bad, but that optimism doesn't exist anymore in my opinion.
I remember being extremely envious of the "Alienware theme" that you could only get with an actual Alienware machine.
That was surprisingly short-lived though, such custom experiences are uncommon these days. Seems like nobody is theming Windows- they just fill it with crapware.
I remember those themes - the sleek "glowing" blue accents on shiny silver and black UI elements looked so fancy back then. There was a Windows Media Player skin too if I recall correctly.
Why theme it? For many people, it has three main functions: starting a game, starting Chrome, and starting MSO. All three kinds have their own custom look, or theme support. The native UI is barely visible, unless you're a heavy Explorer user.
More games ran on it (mostly thanks to higher DirectX version).
From developer perspective, XP was the first version of Windows with registration-free COM and side-by-side assemblies, which (if used properly by app devs) fully solved the "DLL hell" problem.
IIRC it was almost always the video card driver; I ran W2K for quite a few years into the XP era before moving to XP with 2K theme. Everything was happy except the video card drivers, which were often "XP-only" but actually worked fine with 2k.
Lots of relatively small UI improvements that all added up. I honestly never noticed them until years later when I had to use a slightly older machine and had an "oh wow" moment.
Win2K did multiple users more or less the same, the only difference I remember from XP is the login screen that would list all accounts so you didn't have to type the username.
As for UI, it was very easy to switch to classic mode.
Cookies are more appropriate for whole-site or whole-session data. There's no natural segregation of "this cookie belongs to this instance of this form". You could figure that out, but the additional moving parts cut down on the appeal.
> He just put the sessionId in the form data instead of a cookie.
This does not have the benefit of being usable across different tabs or even closing and re-opening the page.
Besides, (a minor point) shoving all the state in the cookie makes code simple i.e. don't have use URL params.
Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction.
I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?
If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?
It appears to be a SSE channel for each event stream returned, not one channel for all subsequent updates. So a PHP backend for instance could batch all the updates from one request, would open a new SSE channel, send the updates over that, then close it. With an in-process server like swoole or most things not PHP, you could presumably reuse the channel across requests in whatever framework-specific way makes that happen. Would probably need sticky sessions in any scaled-out deployment.
This is just what I can glean from the docs, I've never actually used datastar myself.
With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database.
So when opened on a different tab, the backend would do authentication and render the page depending on the store state.
In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.
DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.
In DS, with SSE you can paint different parts of the page with ease. So in this case, it can update <form> and <label> separately. So instead of one update the backend fires 2. There is not separate marker or indicator for OOB.
I think it is best seen in examples on DS website.
HTMX also has the option of using SSE with an extension [0]. I've used this to update the notifications tray for example. You could probably do it for OPs example too.
Shouldn't the OS kernel innovate in this area instead of different languages in userland attempting to solve it?