Live data from Hacker News

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

11–20 of 130 posts

Re: Can You Afford It? Real-World Web Performance Budgets

#11
post #7
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.

Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.

Re: Can You Afford It? Real-World Web Performance Budgets

#12
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

It's probably predicated on a lot of other assumptions. Full refresh might be really annoying if your site is slow and bandwidth heavy. But, for example, squirrelmail is so fast I don't notice the full refreshes.

Re: Can You Afford It? Real-World Web Performance Budgets

#13
post #2

I think the article makes some valid points, but it's important to remember that PWAs are just getting going. The existing SPA frameworks are still a little crude at the moment, but there is definite progress. For my own app ( https://usebx.com ), I eventually ended up writing my own front end framework, as existing frameworks at the time felt rather bloated. Now, however, things are starting to look better with the…

Given how much iOS restricts any kind of background thread and how service workers require being run independent of a specific page context, I would be really shocked if iOS literally ever provides support for them.

Re: Can You Afford It? Real-World Web Performance Budgets

#14
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

MVC + Turbolinks. I still barely use any JS except frontend libs for fancy utils.

Re: Can You Afford It? Real-World Web Performance Budgets

#16
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

Multi page flows are fine for many data entry style apps which covers a lot of the web.

But for more nuanced software, responsive and rich ui is very important to user uptake.

Examples: Gmail, Facebook, Maps, Slack, SoundCloud, every autocomplete search box everywhere.

If you accept that parts of the page should be interactive then you need to consider the benefit of an isomorphic approach to eliminate code duplication. Usually it's not just a single interactive component.

Re: Can You Afford It? Real-World Web Performance Budgets

#17
post #2

I think the article makes some valid points, but it's important to remember that PWAs are just getting going. The existing SPA frameworks are still a little crude at the moment, but there is definite progress. For my own app ( https://usebx.com ), I eventually ended up writing my own front end framework, as existing frameworks at the time felt rather bloated. Now, however, things are starting to look better with the…

Given how much iOS restricts any kind of background thread and how service workers require being run independent of a specific page context, I would be really shocked if iOS literally ever provides support for them.

It's in development, so we know it's on the cards (https://webkit.org/status/#?search=servi&status=in development)

Re: Can You Afford It? Real-World Web Performance Budgets

#18
post #3

It's remarkable how much js gets loaded onto a page (mainly due to libraries) vs. how much of its functions are needed for what the web developer is trying to do. There just is not a whole lot of use cases for the big libraries unless you're doing something really intensive like a drawing app.

Tree shaking should help... eventually.

Re: Can You Afford It? Real-World Web Performance Budgets

#19
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

It's not a thing of the past. The majority of websites still use this capable and pragmatic approach.

I haven't got any information to support it, but I suspect it was mostly cargo culting from big vendors with big platforms that has made JS Single Page App style sites seem ubiquitous, because everyone in the spotlight is talking about the cool stuff they are doing with it. But in reality they still make up a minority of the web.

Re: Can You Afford It? Real-World Web Performance Budgets

#20
post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

Most sites can do with very little JS. Many do well with just a bit, like hacker news, which uses JS for little stuff like voting.

Appier sites, like video, music, games, maps, etc are gonna need a lot more client-side logic to be pleasant to use.

Post reply on HN