Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

Post reply on HN
Print view View original

21–30 of 130 posts

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

#21

Post by Retric »

encoderer wrote: post #16
virmundi wrote: 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 duplicati…

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine.

The problem is JS frameworks make development easier but have high real world costs that are often ignored.

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

#22

Post by rictic »

crooked-v wrote: post #13
osrec wrote: 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.

The service worker spec was deliberately designed to give the browser, not the site, control over resource consumption. The browser is permitted and encouraged to keep them on a tight leash on behalf of the user's experience. See e.g. https://github.com/w3c/ServiceWorker/blob/master/implementat...

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

#23

Post by ianamartin »

idlewords wrote: post #15

It's 2017. It's shameful that our expectations for web speed should be this low.

I was going to say this but wanted to read the comments first to see if anyone else did.

The constraints on global technology sever for this budget. But I have a personal standard of 200ms for TTI on my projects, and I push hard against any requirements or suggested libs or UI features that broach this.

5 secs? You can get away with that if you’re a global brand that people are already hooked into, I guess. The amazon iOS app is infuriating on a brand new iPhone 8 on gigabit WiFi. And that’s an app where every second of load time is lost revenue. They do not, apparently have any kind of budget concept.

Facebook is similarly awful. They can afford to blow their load budgets because users are already locked into the network. Or at least they think they can.

When I’m bringing a new app to market, speed is my highest priority feature. And the feature backlog is organized by cost of speed, not by difficulty or time to market.

And like another poster said above, most of this is completely unnecessary. Be a dinosaur. Write “MVC” apps with server side rendering and deal with Ajax where you have to for as long as you can. Write the very little bit of js you need, and rock on.

It’s not hip, and it’s not always fun. But it’s fucking fast.

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

#24

Post by megaman22 »

crooked-v wrote: post #18
justin_d wrote: 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.

Next year, in Jerusalem

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

#25

Post by briantakita »

megaman22 wrote: post #24
crooked-v wrote: post #18

Earlier quoted context omitted.

Tree shaking should help... eventually.

Next year, in Jerusalem

You can have tree-shaking right now, with rollup.js. You can also have purely transpiled isomorphic component library (no runtime download) running at near vanillajs speeds with svelte.js.

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

#26

Post by andrewstuart2 »

Retric wrote: post #21
encoderer wrote: post #16

Earlier quoted context omitted.

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 duplicati…

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.

Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.

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

#27

Post by iamthepieman »

virmundi wrote: 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 agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application that we are having to purposefully keep features out of, not because they are slowing the page down, or increasing TTI, but because we risk offending our business partners by building a one for one replacement of their multi-thousand dollar per seat desktop software. There's just no getting around the MB of JavaScript we need for this app. And for this type of application, we are much more concerned about the speed of individual actions on the page than page load. The site still loads faster than the desktop application opens.

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

#28

Post by feelin_googley »

virmundi wrote: 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…

"Do we need all this JS?"

I know at least one user who is asking this same question. He does not believe it is needed.

Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers?

Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript.

The tactic leveraged against users is to tell them they need javascript for some thing to work. Then users want it. But I think really they just want the thing to work. They have no particular affection for javascript, let alone any knowledge of why they need it.

One thing I have observed over the years the web has existed early 1990's to today is that users can adapt to anything. Whether it was learning keyboard shortcuts on the console and using text-only programs like Pine, or running www searches that took minutes to finish, or communicating with 140 characters or less, or working with tiny touchscreens and horribly slow web pages and mobile apps. Many more examples if I gave it some more thought. From what I have seen, users accept what they are given and find a way to make it work.

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

#29

Post by jrs95 »

virmundi wrote: 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…

Even the full page loads aren't necessary with Turbolinks or PJAX. If I had a choice, thats definitely what I'd be using for what I'm working on now at an ecommerce company. But the boss insists on microservices, and the once the advantages that come with a monolith are gone the SPA is just a better approach imo

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

#30

Post by sanderjd »

jrs95 wrote: post #29
virmundi wrote: 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…

Even the full page loads aren't necessary with Turbolinks or PJAX. If I had a choice, thats definitely what I'd be using for what I'm working on now at an ecommerce company. But the boss insists on microservices, and the once the advantages that come with a monolith are gone the SPA is just a better approach imo

Correct me if I'm wrong, but don't Turbolinks and PJAX work through JS as well?
Post reply on HN