181–190 of 371 posts
Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
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.…
Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.
Earlier quoted context omitted.
There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
Things only work because it's not people that create it.
I love Deno, I hope it succeeds, but I'm disappointed to see them so confidently publishing a broad assertion like this that's very weakly argued, and heavily biased towards promoting their own position in the stack > Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser. Excuse my bluntness, but this is complete nonsense. Bro…
There are some pretty crappy bloated client-side apps but when it's done well and it is appropriate for the app in question, it's amazing.
I've been playing novelai.net text generation and I think their app is mostly client-side. It's one of the most responsive and fast UIs I've seen.
Also, the article has this sentence: "Performant frameworks that care about user experience will send exactly what's needed to the client, and nothing more. " Ironically, a mostly client-side app that's only loaded once, cached, and is careful about when to request something from the server, might be more bandwidth friendly than a mostly server-side app.
Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
How much is the additional compute cost? $10 a month? $1000 a month?
How much more productive are your developers? Does it offset the cost?
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/
So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
It's not suitable to everything, but it works really well. I'm not advocating switching to it right now, but it's looking very promising.
Earlier quoted context omitted.
> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need t…
I love nothing more than clicking “remove from cart” and having the whole page refresh and lose the info that was already typed
Earlier quoted context omitted.
There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
Earlier quoted context omitted.
So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
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…