Hacker News Reader

Comment by tiborsaas | Hacker News Reader

Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at.

I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy end result and blame the technologies, but this is superficial.

It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".

View on HN

SPAs are the worst, because companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer".

Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA applications cause the opposite — companies move everything to client-side in order to reduce Amazon bills, and don't care if those client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.

Clearly, there should be a heavy tax on single page apps. They are

1) addictive — by making more Javascript devs, who in turn write more Javascript websites

2) act as luxurious goods ("Look guys — we have created a new version of our website. It looks so cooool (but loads a bit slow)!")

3) have ugly externalities, completely ignored by most of their creators

> companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer"

SPA-s are much-much harder to develop if more teams are working on it. So your first sentence makes little sense.

> companies move everything to client-side in order to reduce Amazon bills

This is never the reason why it happens. Seriously? The cost are not saved, just moved around. SPA-s are developed because they could provide a much better UX. As a side benefit, server side development becomes simpler by providing some REST or GraphQL API. You don't want to be in a place where tens of thousands of lines are generated backend side by backend developers.

> client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.

I appreciate your sense of humor :D

Yes, but equally so, replying to this email comments with "but page loads are slow" is not helpful.

CSS doesn’t require javascript, and allows for nearly all the features of a SPA.

Like plotting an equation to canvas? Editing video? Handling drag and drop events?

I've seen that blog post where a guy demonstrated that many UI elements can be done with CSS, I like that. I try to do that myself as much as I can, but let's not pretend that CSS is a programming language and it can replace ANY JavaScript.

It is debatable that CSS is or isn’t Turing complete, but as long as the task isn’t totally automated without user input, CSS could replace most Javascript.

Reply on news.ycombinator.com