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

41–50 of 130 posts

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

#41

Post by sgk284 »

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

I recently launched the landing page[1] for my startup and the designer gave us a crazy animated design.

All of my personal sites never required JS and have always worked just fine in Lynx. I didn't want any JS on the landing page (not even for analytics, we can do that server side), so decided to see what HTML + CSS can do these days.

I was pretty blown away with how easily I was able to have a half-dozen animations running in parallel with 3 videos playing and being transformed in a 3D space.

Even better, the page works perfectly fine in Lynx! I recognize that there are times with the modern web where JS is required, but I try my damnedest to minimize it. And modern web standards make it easier in ways that were impossible a decade ago (e.g. no more $.fadeIn()).

[1] https://banter.fm

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

#42

Post by digi_owl »

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…

> Could developers have wants that are unique to developers?

There seems to be a sizable portion of this, and far from limited to the web world.

That said, some of it may also come from the managerial level. This thanks to cargo culting akin to the offshoring fever a decade or two back.

meaning that management is pushing for something to be done in a certain way because they read about some big name corp doing the same, and wanting the company to appear "aggressive" to investors...

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

#43

Post by bildung »

vecinu wrote: post #39
jaggederest wrote: post #35

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

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

Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.

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

#44

Post by TekMol »

emp_ wrote: post #40

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

Couldn't you load babylon only in case the browser lacks the desired features?

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

#45

Post by endless1234 »

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

Yeah, if only all web apps could be text only with almost no interactivity, am I right?

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

#46

Post by ehnto »

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

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 maintain two code pathways in two different languages in two different locations if you need to update the validation rules. Where simple works, pick simple.

5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.

While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.

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

#47

Post by ozim »

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.

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

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

#48

Post by blattimwind »

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…

> They said that users really wanted native desktop like seamless change pages.

This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.

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

#49

Post by z3t4 »

It's nice of you to make your web presence work for someone with 400Kbps link with a 400ms round-trip-time (“RTT”), while you're at it, also make sure it works with JavaScript turned off! And browsers with limited CSS support. And is readable on a terminal browser. And 600x400 px resolution.

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

#50

Post by mmcnl »

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.

Are JS frameworks really easier than your good ol' fully server-side rendered websites? I doubt that. There are costs for everything, both for using and _not_ using JS. It's silly to think that only using JS adds a cost and nothing else. That's just tunnel vision.
Post reply on HN