this post was submitted on 16 Feb 2026
19 points (91.3% liked)

JavaScript

2667 readers
1 users here now

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] dan@upvote.au 2 points 1 week ago (1 children)

Sites that only use vanilla JS can still be heavy, too. I think the underlying message is to do the heavy processing on the server side, and keep the client side relatively light.

This is also why frameworks/libraries like Astro and htmx are becoming more popular. Both of them focus on having minimal frontend JS. htmx effectively reverts back to a pattern that was somewhat common 20 years ago - a small amount of reusable JavaScript to handle common use cases, that hits the server and inserts its response HTML somewhere on the page. I was a web developer back then so it's been interesting to see old patterns come back.

[–] kalkulat@lemmy.world 1 points 5 days ago* (last edited 5 days ago) (1 children)

That may not be the wisest choice. For one thing, the client side can be as fast or faster than the 'server' side. Sending data to a 'server' which is 'serving' as a mainframe (reverting to a model from the past) will consume more time and bandwidth. So much for the performance goals.

That also has the potential to create securiity concerns at both ends (which were not intense in those bye-gone days of yesteryear). Furthermore, wny should the client trust the quality of the code the 'server' uses? The popularity of the 'new' frameworks aside, the cost of bandwidth and processing by the 'server' will be born by the 'client'. I'm not seeing any pluses except for thin clients, and big potential pluses for the 'serving'.

[–] dan@upvote.au 1 points 4 days ago

the client side can be as fast or faster than the ‘server’ side.

That's not the case on a lot of JS-heavy sites, though. A lot of logic runs on the main thread, which slows things down. The only way to run things off the main thread is by using web workers, but that adds extra serialization/deserialization overhead.

That also has the potential to create securiity concerns at both ends

Generally, the more logic you have on the client-side, the more likely you are to have security issues. The client is a completely untrusted environment (since they can do whatever they want with your JS code), and increasing the amount of logic on the client side increases your attack surface there.