[kelnos]

It's funny to see us remembering that things can be done on the server. The trend to render everything client-side has always been troubling to me. Such a waste of resources (but it's not your resources, so developers don't care). Sure, things that are truly dynamic or are different for every user is probably usefully done on the client. But a static page with code samples can easily be rendered on the server, with syntax highlighting, and then cached. You only need to do it once, rather than hundreds or thousands of times on every client device.

[Zababa]

> Such a waste of resources (but it's not your resources, so developers don't care).

I've always wondered if it wasn't intentional. Things running on the client means they don't have to run on the server, and you can save money this way.

[kevincox]

For things like syntax highlighting which is fairly cheap and done "once" I doubt resource usage is a consideration. However I won't be surprised if this is at least a consideration for bigger companies when they decide to make a relatively cheep API or a server-rendered app.

[apatheticonion]

The browser is just a generalised client implementation where the application is streamed and sandboxed. It's similar to a native app written on Kotlin/Swift or desktop application written in C#/wpf.

The same logic could be applied to those client application technologies, too.

[anoncake]

No. The browser is a document viewer, and that's what it's actually good at.

[phowat]

The browser started as a document viewer. Nowadays it is much more than that.

[anoncake]

It is not just a crappy "generalized client application".

[genericstorage3]

Css will work until a certain point. What do you do when css can't handle?

Give up, do some super hacky unmaintainable css mess, or suck it up and use js...

[setr]

The trouble generally is that JS is used despite the content being static, or independent of client behavior/usage.

That is, JS can be used to do everything but it is not optimal, or even near optimal (or even remotely close to) for many use cases. In terms of runtime or simplicity. But because it is capable and available, it has encroached into every niche (of html/css) until like any invasive species, it consumes and shreds through all available resources, collapses the whole ecosystem, and all complex creatures give way to a fresh start with new fairly rudimentary biology (wasm) trying to evolve towards and find a new stability point — hopefully one that does not invite a similar destructive species, but we’ll see how it goes

[genericstorage3]

For example you can do a drop down menu in css. Then you have some new requirements that css alone can't do it.

Even a basic thing, could be impossible in css.

All your css logic goes to trash. Or you can keep css logic and make a mess of a software

If you have done it in js, you'd be able to reuse some code.

[fwip]

What do you mean, "can't handle?"

How do you plan to style it with javascript without CSS? Rendering directly to canvas?

[tantalor]

Offloading rendering to CSS is still making the client do some work. Excessive CSS can bloat the page, hurting latency.

If you take this approach to the extreme, you should render to png on the server for display, and provide plain text for accessibility only.