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

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

Post reply on HN
Print view View original

91–100 of 328 posts

Re: Browsers are pretty good at loading pages

#91

Post by kowdermeister »

ryacko wrote: post #72
tiborsaas wrote: post #64

Earlier quoted context omitted.

Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy…

CSS doesn’t require javascript, and allows for nearly all the features of a SPA.

Like plotting an equation to canvas? Editing video? Handling drag and drop events?

I've seen that blog post where a guy demonstrated that many UI elements can be done with CSS, I like that. I try to do that myself as much as I can, but let's not pretend that CSS is a programming language and it can replace ANY JavaScript.

Re: Browsers are pretty good at loading pages

#92

Post by trop »

JulianMorrison wrote: post #60
tiborsaas wrote: post #49

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

The idea exists but it's clearly not true, except perhaps in specific, niche uses like re-rendering a continuously refreshed graph. Even for your image gallery, it makes for confusion. Back button does what? Shift-refresh does what? Just let the browser do what it does. If you want the images to render fast, use HTML 2. Writing a web app with server side pages forces you to think about where the state lives. This is…

Google Maps would be the classic example of client-side refresh working so well that it's now the universal choice. At the time, it was a revelation, as the Mapquest-ish predecessors (if I recall) required a click and server-side refresh to scroll or zoom the map.

Of course the revelation here was that tags weren't what we needed to move a map, but rather a click-and-drag plus scroll-wheel behavior to explore a huge image at various levels of detail. If the server-side page-by-page navigation paradigm is a lousy fit for information delivered over the internet, then it may make sense to re-invent the page load.

To use the language of a sibling comment, this brought things to a much more app-ish behavior. And eventually Internet maps have become, especially on mobile devices, an app. Hence the need to break server-side navigation may have foreshadowed the need to break out of the browser.

Re: Browsers are pretty good at loading pages

#93

Post by frereubu »

daxterspeed wrote: post #75
frereubu wrote: post #65

Earlier quoted context omitted.

"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP connection to download a section of HTML for a new part of an SPA it won't be that much different from a full page of HTML, presuming you compress the transfer as you should. "Of course shitty implementations exist" is true of a non-SPA setup too.

While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of co…

I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.

Re: Browsers are pretty good at loading pages

#94

Post by compumike »

nixpulvis wrote: post #85
compumike wrote: post #68

(Disclosure: I'm Carter's desk-neighbor at Triplebyte.) I think there's actually a middle ground where you can utilize some of the more modern techniques to actually do better than the pure static pages approach, while still using normal browser-based page navigation. As a personal challenge, I wanted to see what could be done about performance for a recently-launched side project: the Ultimate Electronics Book [1],…

I use Jekyll for my personal site and it renders MathJax, and even MusicXML with JS, amongst other small things. It's great, all static. https://github.com/nixpulvis/nixpulvis.github.io

Interesting. Am I missing something? I went to https://nixpulvis.com/math/01-fibonacci and it appears to be effectively the same as what I have for MathJax -- pushing the raw LaTeX commands into a specially-labeled HTML element, and then loading the MathJax JS from cdnjs.cloudflare.com in order to process and render them client-side.

Re: Browsers are pretty good at loading pages

#95

Post by bhousel »

jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

I see lots of responses to this article asking "why client-side navigation?". I can share my own experience with building an app a few months ago, and how/why I switched to a client-side single-page app..

The app is this: https://osmlab.github.io/name-suggestion-index/index.html

It is a worldwide list of brands that have been seeded with OpenStreetMap data, and which volunteers have linked to Wikidata identifiers. We use this data in OpenStreetMap editors to help people add branded businesses. Pretty cool!

1. We had data in `.json` files (but not too much data) and we wanted to show it to people working on the project so that they could review the brands.

2. I spent a day or two and built a static document generator. It took our data and spit out an `index.html` and few hundred `whatever.html` files. This worked really well. As the article says, "browsers are pretty good at loading pages". A side benefit - Google is really good at indexing content like this.

3. Then users made the obvious request: "I want to filter the data. Let me type a search string and only show matching brands. Or brands that appear in a certain country".

4. OK, SO.. If your data is spread out over a few hundred files, short answer - you can't do this.

5. But the data is _really_ only a few megabytes of `.json`. I spent a few days to learn React and switch to a single-page client side app so that we can filter across all of it. The new version uses hooks to fetch the few `.json` files that it needs, `react-router` to handle navigation between the index and the category pages. It works pretty ok! Most people would stop here.

6. The first version with client-side filtering performed good enough, but not great. The reason was because, as users type these things happen: The filters get applied, the React components get a new list of brands passed in as props, and React re-renders these new lists to the virtual DOM, and eventually, slowly, the real DOM.

7. It's really easy to build React code like this, and many people do. But it is better to avoid DOM changes in the first place. I changed the components so that the lists stay the same, but filtered things just get classed as hidden `display:none` instead of being added and removed from the DOM, and performance is much better now.

Anyway hope this is helpful to someone!

Re: Browsers are pretty good at loading pages

#96

Post by jakub_g »

Endy wrote: post #17

It's highly amusing to find out about this, as someone who disables ECMAScript on every browser I use. Why is it that certain groups of web authors seem to be under the impression that more "tech" = better? Why can't they be satisfied with what works in a simple and easily-accessed manner? For that matter, why does anyone engage in this constant race to the bottom? If more web authors and developers were to make a st…

It's self-fueling phenomenon and reasons are plenty. My random thoughts:

- Everyone who thinks about themselves as doing "frontend" needs to do hot tech of the day because that's what everyone talks about in the internets (FOMO). If you leave the race, you can't fill your CV with buzzwords and won't find a job in a few years (would you hire a Java developer who still writes Java 4?)

- New people come in and that's the reality they start with and it feels normal. They never wrote a clean piece of HTML+CSS by hand.

- When you're in a company where all people have they minds set up on a given tech because of the reasons above, it's impossible to suggest an alternative tech to the currently fashionable one. You can't tell dozens of people to do a career suicide. Anyway it's typically a very small group (or a single dev) who choose the tech stack and architecture for new projects, and they typically have a very limited time to do so. Going with the flow is the "safe" option.

- Hiring: you don't want to use unpopular unsexy tech, because you won't find candidates, who will fear to take it to not work in a non-future-proof tech stack (COBOL job anyone?)

- Sometimes you just have to do something complex which requires a ton of JS anyway (any highly interactive widgets/apps) and then having a single well-understood framework is better than gluing together many things in a random way.

- Finally, doing complex stuff in a huge team is tricky. To make stuff not collapse, the developer experience is generally favored over user experience.

Re: Browsers are pretty good at loading pages

#97

Post by pmontra »

hombre_fatal wrote: post #55
tiborsaas wrote: post #49

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

A media gallery website is a good example of a use-case for client-side routing. I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it. It worked really well and had great UX. This generalizes to…

Media galleries (carousels) were client side things at least since the original xhr implementation in IE5. Maybe well before that if changing the src of a img let the browser load the new one from the server. I can't remember.

But sites were small and even loading all the page again was not that bad.

By the way, Rails Tutbolinks [1] are a way to get the same result with the server rendering only the html body and the js code in the browser swapping it with the current one.

[1] https://github.com/turbolinks/turbolinks

Re: Browsers are pretty good at loading pages

#98

Post by frereubu »

testis321 wrote: post #74
hombre_fatal wrote: post #55

Earlier quoted context omitted.

A media gallery website is a good example of a use-case for client-side routing. I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it. It worked really well and had great UX. This generalizes to…

> I worked on a porn site that was basically an endless-scroll video gallery. So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video agai…

I hate infinite scroll with a passion. I've often been quite a way down someone's interesting Twitter feed and lost my place somehow, then just given up and gone somewhere else in frustration rather than trying to scroll down a few hundred tweets, waiting each however-many tweets for the next batch to load, just to get back to where I was.

Re: Browsers are pretty good at loading pages

#99

Post by guggle »

tiborsaas wrote: post #49
jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

> Furthermore, you don't lose state, which makes things much more simple.

Or not... I think about infinite scrolls with no proper paging.

Re: Browsers are pretty good at loading pages

#100

Post by pmontra »

kccqzy wrote: post #52
jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

For a company I worked for, we tested client side navigation and non-client (traditional) navigation for the admin interface. And then we asked the admins who use the site in question: all of them loved the client side navigation. So you see, I suspect most users are not like the HN crowd and don't really care about command-click or the back button.

I've got a customer with a complex UI where a lot of things happen. Basically a desktop application in a browser. We built a SPA for that.

Then there are the AWS and Google consoles where nearly every click loads a new page and I don't complain, because it's ok. And Amazon, the shopping site. Every click into a product loads a new page. They seem to be doing pretty well.

I would build SPAs where it's difficult to give a different URL to what's on screen after every click. Server side rendering in every other case.

Post reply on HN