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

71–80 of 130 posts

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

#71

Post by TeMPOraL »

ozim wrote: post #47
Retric wrote: post #21

Earlier quoted context omitted.

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.

"I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.

If they were really carefully crafted, then they likely can be carefully repackaged into a solution that could be included in those 10 different places with zero - or close to zero - runtime overhead on the code sharing mechanism.

But it takes actual thinking - and care - to do that. Something that seems to be in short supply with the current web trends.

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

#72

Post by jasode »

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…

>I do not know any fellow users who "want javascript". [...] They have no particular affection for javascript, let alone any knowledge of why they need it.

Framing it as end users "do/don't want javascript" isn't helpful for analyzing the advantages/disadvantages of javascript. Obviously, end users don't think of it that way.

We could also say that we don't know any users who "want polycarbonate on their face". That's true, but they do want clear 20/20 vision and we just happen to use polycarbonate as the material that combines the attributes of light weight and inexpensive manufacturing compared to glass.

Nobody wants to "ingest fungus poop" either. Except they do because that's what beer is.

Users also don't want a "30 minute barrage of explosions 5 feet from their body", but they do indirectly want that because they would rather drive a car to the store instead of walk. (Some might extract the wrong idea from that example and insist that we shouldn't be dependent on fossil fuels anyway. Well, people also don't want "volatile chemicals" either which is what lithium batteries are. They also don't want a steel tube shoved up their butt which is what bicycles are.)

(To get back closer to the tech world, end users also didn't ask for "HTML" or "want CSS" or "HTTP" either. They don't think in those terms.)

You're right that they don't want "javascript" per se. What they want is a "fluid experience" in the UI. We happen to use javascript to provide that fluidity.

>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.

True. But it ignores the benefits to users that javascript enables. Things like airplanes also bring hassles such as noise but that ignores the fact that people wouldn't want to give up flying because planes also enable convenience.

Therefore, people do want javascript -- indirectly. They want autocomplete in amazon and netflix search fields. They want smooth map repositioning in Google Maps without page reloads. They want up/down voting buttons and expand/collapse outlines to work in stackoverflow, reddit, HN without jarring page reloads. Many pages in wikipedia also work better with javascript.

Yes, the abuses and misuses of javascript that hijacks scrolling or javascript that breaks apart a single page article across 20 screens with tracking and ads are annoyances we don't want. However, it shouldn't keep us from having a balanced discussion that includes how javascript improves the web experience for the average user. The uncompromising insistence on avoiding of client-side javascript in favor of server-side page regeneration&reload is hostile to the user. Many web users do not browse from desktops with fast fiber optic connections. They browse from mobile phones with ~500+ round-trip latency.[1]

Like most of you, I'm a "power user" so I should be a prime example of an uber geek who "doesn't need javascript". And yet, I use regex101.com every week that relies on javascript. It would be a total hassle if I had to press "submit" everytime I changed a character to experiment with regexes.

[1] https://serverfault.com/a/573815

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

#73

Post by TeMPOraL »

mac01021 wrote: post #57
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'm no fan of “modern js-based design”, but I can pay for a lot less server if I can get the client to do all the rendering for me.

Yup.

But the thing to consider is - a lot of things can be pre-rendered and cached. Your server can render it once and serve to many clients. With client-side rendering, each client is rendering the same thing for themselves, possibly slower than on your server because JS is not exactly the sharpest tool in the shed. So you've saved yourself $N in compute but externalized $N * number of users * relative JS inefficiency. This is not a nice thing to do.

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

#74

Post by sundvor »

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…

Most if not all C# roles I see these days demand Angular / React experience. It's really hard to talk confidently about that unless having actually done it; you'll get picked apart / walked by. And it had better be covered by Jasmine / Karma as well, and using Typescript. In the cloud. Etc.

Thus we have Resume Driven Development - for better, or worse. As an older person (I got my Vic 20 when I was about 10), I find it equal parts inspiring and frustrating. Having a family / child it's nearly impossible to devote anywhere as much time to this as the younger, unencumbered ones must have. Yet I still love the new stuff.

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

#75

Post by mrighele »

TeMPOraL wrote: post #67
ehnto wrote: post #46

Earlier quoted context omitted.

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to…

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

I would love to have a way to tell the browser "don't throw away the current DOM, Just apply the differences". It would work nicely in non-js page to make the experience smooth (and would probably work terribly if there was a lot of J's, of course)

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

#76

Post by caseymarquis »

I'm sure there are niches out there where complex web apps are best built without an SPA framework, but use the right tool for the job! If I'm writing an embedded interrupt routine, I don't use slow clunky C, I use assembly. If I'm writing a complex web application, I use an SPA framework like Vue. If I'm delivering static content, I use minified html and css.

Everything comes with a tradeoff. If you pick the wrong tool, it's a big headache.

Learn to use all the tools.

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

#77

Post by adambyrtek »

kevincennis wrote: post #61
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…

It’s all about how and where you use it. Imagine a world without AJAX. This is obviously an opinion, but it would be super annoying if every button I clicked sent a raw POST to the server and refreshed the page. Do news sites need to be rendered client-side with React + Redux + React Router + all the Babel polyfill garbage? No, I don’t think they do. But some sites are definitely better in my mind for being SPAs. The…

One important and more subtle advantage of SPAs is that they enforce a clean architectural separation of concerns between the untrusted view layer and the backend API. This decoupling allows the frontend team to iterate quickly on user experience and run experiments without affecting the underlying business logic. This also makes it easier to build alternative interfaces (e.g. mobile apps) that share the same API. Of course these benefits matter only when building more complex applications (not simple content sites).

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

#78

Post by nawitus »

mattmanser wrote: post #52
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.…

Well, you don't need a SPA to do that at all . You don't have to do the validation client-side, you can still get the server to do it with some extremely simple javascript. You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation…

The comment said "no Javascript", no "no SPA".

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

#79

Post by nawitus »

ehnto wrote: post #46
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.…

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to…

Needing a page refresh for input validation degrades experience.

"Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules."

Not necessarily. You can use the same exact code, in the same location written in the same language.

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

#80

Post by nawitus »

TeMPOraL wrote: post #67
ehnto wrote: post #46

Earlier quoted context omitted.

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to…

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation? Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

Page refresh takes a longer time than client-side validation.
Post reply on HN