211–220 of 371 posts
Earlier quoted context omitted.
I love nothing more than clicking “remove from cart” and having the whole page refresh and lose the info that was already typed
That can be sorted by a single jQuery or JS function. 2-3 functions in that cart page handles everything without any complication whatsoever.
Earlier quoted context omitted.
Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is {"comment": {"body: "lol"}} notably expensive than
Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.
One example is [1] Laravel livewire.
Earlier quoted context omitted.
> Why can’t we just use public CDNs is beyond my understanding. Privacy issues iirc. I think you can use the setup to introduce tracking/reveal information about your history.
It could have worked with a trusted, open broker. I'm sure there could be a compatible sustainability model. I feel like a lot of potential trust was broken by the likes of Facebook and Google.
There are 2 things that are orthogonal in current trend. This SSR buzz is not actually selling Server Side Rendering, they are selling 'one language to rule them all' (they call this dumb name "isomorphic"). Therefore, they are not solving all the problems of client-server + best UX constraints. Basically the problems we have all this time comes from: 1) There's a long physical distance between client and server 2) R…
If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…
> Isn't it also nice from a computation cost standpoint to let the client do the rendering? Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.
Either way, the measurement of Joules/page is likely to be such an astronomically small number compared to the constant cost of simply having a server at all IMO.
Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/
Can the same server side code render that fragment, regardless of whether it's part of the initial page load or a subsequent update? You need an additional route for the Ajax call, right? Just curious how this gets structured.
The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
Earlier quoted context omitted.
You don't need to wait for a response if you're sending data, or reorganizing data, or doing something that doesn't rely on data.
Yep. DOM manipulation can be done to server-rendered views to do that kind of thing, just fine. No SPA js framework required.
Earlier quoted context omitted.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…
Sounds pretty slow. At least a second before the UI responds to any action?
I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering.
It won’t be the right choice in all cases, but it’s a great option in many.