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

31–40 of 130 posts

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

#31

Post by aaron-lebo »

feelin_googley wrote: post #28
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 kno…

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer.

Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it.

Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.

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

#32

Post by swyx »

i cut my personal site's TTI by 62% after reading this. I just was lazy about performance when there were some real easy wins. i do wish for more guidance on how to do PRPL in React (without necessarily doing full Next.js which is too opinionated for some of the stuff I want to do)

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

#33

Post by swyx »

ianamartin wrote: post #23
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 amazo…

sorry, but 200ms for TTI on the web? are you measuring the same way that he is? he includes 1600ms just for dns lookup and tls handshake

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

#35

Post by jaggederest »

aaron-lebo wrote: post #31
feelin_googley wrote: post #28

Earlier quoted context omitted.

"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 kno…

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well.…

> How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)?

Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem.

If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.

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

#36

Post by jaggederest »

raverbashing wrote: post #34

Meanwhile, HN loads like a charm and time to interactive seems to be less than 0.5s Seems like that's what happens when you are too deep in the js bog, and you forget what is below the thick js cover

And works largely the same without Javascript enabled, last I checked. Edit: Yup, can still view pages, up/down/flag in essentially the same flows.

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

#37

Post by aaron-lebo »

jaggederest wrote: post #35
aaron-lebo wrote: post #31

Earlier quoted context omitted.

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well.…

> How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5…

You're glamorizing old web. Old web had the same quality issues, most form submissions were not taking 100 ms and JS validation does not (have to) take 100 ms today.

If you exaggerate the numbers, you can't make any useful comparisons.

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

#38

Post by samsonradu »

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…

Regarding full refreshes, I was thinking the other day why do browser vendors not implement them more graciously, as in Pjax style, but a clean reload. The problem with Pjax is that it still keeps state around, when I want to simply remove all state (setTimeouts, setIntervals, websocket connections, events binded to $window etc.)

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

#39

Post by vecinu »

jaggederest wrote: post #35
aaron-lebo wrote: post #31

Earlier quoted context omitted.

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well.…

> How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem. If you mean "leaving aside the most trivial html stuff" to include things like html5…

What about all of the information that was already in the submitted form?

We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.

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

#40

Post by emp_ »

Just pushed live an app today that I had to cave and add babylon-polyfill so it would work in IE 11 after trying to polyfill a dozen missing es6 runtime features from various sources.

That made the final JS output 25% larger, a 90kb increase from the polyfill library alone, so here's a serious optimization waiting to happen (the natural dying of an older browser).

Post reply on HN