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

81–90 of 130 posts

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

#81

Post by ehnto »

nawitus wrote: post #79
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…

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.

But by how much and does it actually matter? It's also a pretty small example. The problem of complexity outstripping benefits only grows the more you inspect the frontend landscape.

My main point is just that the implication that JS is required otherwise the UX will be unbearable is false. It's also really easy to mess up the UX with JS and I see it constantly. I would take a fast form post over a cumbersome JS powered experience any day.

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

#82

Post by mratzloff »

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?

The answer to this question is always no.

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

#83

Post by [deleted] »

caseymarquis wrote: post #76

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

[deleted]

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

#84

Post by mratzloff »

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…

> Imagine a world without AJAX.

This is my favorite HN quote of the month.

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

#85

Post by gjjrfcbugxbhf »

nawitus wrote: post #80
TeMPOraL wrote: post #67

Earlier quoted context omitted.

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.

But you still need to do the server side valuation.

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

#86

Post by DCoder »

bildung wrote: post #43
vecinu wrote: post #39

Earlier quoted context omitted.

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.

Does "all user input prefilled" include file uploads?

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

#87

Post by nickjj »

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 wrote about this exact topic last week at https://nickjanetakis.com/blog/server-side-templates-vs-rest....

The TL;DR is, the classic web development model still works amazingly well today and you can get real-time aspects by sprinkling in Javascript where needed.

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

#88

Post by azeirah »

sgk284 wrote: post #41
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…

You can even define glsl shaders in css nowadays :x

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

#89

Post by falcolas »

mratzloff wrote: post #84
kevincennis wrote: post #61

Earlier quoted context omitted.

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…

> Imagine a world without AJAX. This is my favorite HN quote of the month.

I remember gmail before it used AJAX. In many ways, I miss that interface - it just worked. Sure, I didn't get real time email notifications, but come on, it's email. Sure, there were a lot of page refreshes, but they were super quick since there wasn't several MB of scripts being parsed and run with each load. Just some HTML with a few JS interactions.

They even still offer that interface - check it out. It works remarkably well (and quickly) to this day.

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

#90

Post by falcolas »

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…

Gmail started out as a multi-page flow, and it worked perfectly fine. Page loads were quick because there wasn't several MB of JS to be interpreted with every page load, just some HTML and CSS.
Post reply on HN