Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#81

Post by compumike » Sun, Jul 21, 2019, 8:53 PM UTC

cousin_it wrote: post #77

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],…

Loads about as fast as I'd expect from a static site. Hover is a bit messy. When I move my mouse down the table of contents, the tooltip obscures the next chapter title, and sometimes grabs the click as well. Back button handling seems to be buggy. If I click from the table of contents to a chapter, then hit back, then click to another chapter, then hit back again and do that a few times, the history becomes filled w…

Thanks for the feedback. Tooltip hover on TOC is annoying -- need to think about that... The scrolling on TOC click was intentional as I wanted to highlight the section you clicked and center it if you do go back to TOC to "remember you place" in the book, but maybe I overdid it here.

Re: Browsers are pretty good at loading pages

#82

Post by kowdermeister » Sun, Jul 21, 2019, 8:53 PM UTC

frereubu wrote: post #65

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…

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

What if there's no content to download? The client could have the same algorithm that the server could render.

For example create a melody with seed: 4564342

The client can render it and if you access it from the server the server does the rendering with the same seed.

Caches also exists, now with PWA-s offline modes would benefit from the History API.

Re: Browsers are pretty good at loading pages

#83

Post by amiga-workbench » Sun, Jul 21, 2019, 8:54 PM UTC

sword_smith wrote: post #36

The biggest advantage of using modern SPAs is that it forces the developer to build the backend as an API with which you can interact programmatically

I do agree with this bit, even though I hate the end product.

I've seen exactly what happens when you have a server side application worked on by a lazy developer, you end up with tightly coupled code inside all your templates and controllers and it devolves into a maintenance nightmare.

Re: Browsers are pretty good at loading pages

#84

Post by zucker42 » Sun, Jul 21, 2019, 8:54 PM UTC

kevingadd wrote: post #25

saagarjha wrote: post #23

Strongly agree with the premise, but > it just isn’t possible for a highly dynamic language like JavaScript to run as fast as the C++ code in browsers With modern tracing JITs, this isn’t always true ;)

As far as I know, no production browser uses tracing anymore. The only modern tracing implementation I'm aware of is LuaJIT.

Do you know why browsers moved away from tracing JIT?

Re: Browsers are pretty good at loading pages

#85

Post by nixpulvis » Sun, Jul 21, 2019, 8:54 PM UTC

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

Re: Browsers are pretty good at loading pages

#86

Post by bfirsh » Sun, Jul 21, 2019, 8:55 PM UTC

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],…

MathJax can render server-side if you want to speed that up: https://github.com/pkra/mathjax-node-page

Re: Browsers are pretty good at loading pages

#87

Post by mceachen » Sun, Jul 21, 2019, 8:56 PM UTC

bloaf wrote: post #57

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…

Do you have an example of a site which does it well?

You can try PhotoStructure (disclaimer, I'm the author). It's an image gallery built with Vue and vue-router (for your images). If you look at the vue-router documentation, they've got some examples to follow.

The back/forward buttons, command-click, and ctrl-shift-t work on all modern desktop and mobile browsers.

I started with traditional page loads, but even with minimal css and no js, screen flashing between pages was prominent (especially on mobile), and visual transitions between pages (like swipe navigation where both prior and next page content is concurrently visible) is difficult.

Re: Browsers are pretty good at loading pages

#88

Post by fnordsensei » Sun, Jul 21, 2019, 8:57 PM UTC

I've been working on search UI. This search UI is substantially more complex than the average one you might come across.

There are potentially multiple search bars (added on command), to which many different variants of filters and search terms can be added. They provide an aggregate search expression which is not reducible to boolean logic. The search results update interactively when the search terms are altered.

It's specialized tool, and meant to be used by people of a certain vocation rather than the general public.

The reason that the search results update interactively is to provide a short feedback loop on the effect of the search terms. Building a mental model ahead of time for the interactions between the query and the hundreds of millions of potential results is a tall order. It therefore seems sensible to provide affordances which facilitate exploration and (in some sense) experimentation. To this end, search results also expand inline to provide a way to inspect results quickly, with the purpose of validating whether the search terms were effective or need alteration.

Now, where do I draw the line between what counts as a "new page" or the "same page" with this? Do I reload the page on every alteration of the search terms? Do I scrap automatic reloading between alterations of search terms and only do so explicitly when the user clicks a button? Should it navigate to a new page when interacting with search results rather than previewing them inline?

This is all rhetorical, of course. All of those changes would make for a much poorer experience for this particular tool and the particular target user group.

Today the web is used to build a lot of stuff where "page navigation" is a poor model to work with as a basis. I can see there being a case for it where a "page" really is a self-contained unit of information. But there are also a lot of cases where declaring some particular state in a long user journey of interconnected actions as a "different page" is going to be arbitrary.

Re: Browsers are pretty good at loading pages

#89

Post by [deleted] » Sun, Jul 21, 2019, 8:57 PM UTC

compumike wrote: post #81

cousin_it wrote: post #77

Earlier quoted context omitted.

Loads about as fast as I'd expect from a static site. Hover is a bit messy. When I move my mouse down the table of contents, the tooltip obscures the next chapter title, and sometimes grabs the click as well. Back button handling seems to be buggy. If I click from the table of contents to a chapter, then hit back, then click to another chapter, then hit back again and do that a few times, the history becomes filled w…

Thanks for the feedback. Tooltip hover on TOC is annoying -- need to think about that... The scrolling on TOC click was intentional as I wanted to highlight the section you clicked and center it if you do go back to TOC to "remember you place" in the book, but maybe I overdid it here.

[deleted]

Re: Browsers are pretty good at loading pages

#90

Post by zucker42 » Sun, Jul 21, 2019, 9:01 PM UTC

robbrown451 wrote: post #12

If you are thinking of things as "pages", this is of course true. I think a good example of a site that makes good use of this sort of thing is Wikipedia (the non-mobile version). I love that I can mouse over links and get more information on something, without having to click to its actual page. It pulls down only the information needed, and leaves everything else in place. This makes browsing far more efficient, at…

Like other comments have noted, that's not what the article is complaining about.

In the context of this article, Wikipedia's design is analogous to the existing MDN site. I think Wikipedia is a website other websites should seek to emulate, because it loads quickly on all devices and connections I've had. Instead many text based, informational sites are going shifting to SPAs or similar JS reliant architectures.