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

161–170 of 328 posts

Re: Browsers are pretty good at loading pages

#161

Post by sangnoir »

TeMPOraL wrote: post #101
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…

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

> The whole point of the article is that it's not true.

Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone.

I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such as state management: for the projects I have worked on, adding "Undo" logic was far simpler with client-side state-management. YMMV)

Re: Browsers are pretty good at loading pages

#162

Post by saagarjha »

zucker42 wrote: post #84
kevingadd wrote: post #25

Earlier quoted context omitted.

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?

Well, one reason is probably because they don’t perform well on programs that cannot trace well.

Re: Browsers are pretty good at loading pages

#163

Post by nixpulvis »

compumike wrote: post #94
nixpulvis wrote: post #85

Earlier quoted context omitted.

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.

Yep, that part is pretty easy, and not too bad in terms of fallback while loading. I love how easy it is most of the time to write nice looking math.

Re: Browsers are pretty good at loading pages

#164

Post by nepeckman »

I'm going to push back against the idea that proliferation of client navigation is caused by inept developers. I think that component architecture is a fundamental improvement for web development. Breaking the interface into smaller, well defined chunks promotes code reuse and makes the relationship between parts of the interface more clear. Additionally, almost any web application is going to include some functionality that is best handled with client side rendering. I posit that this puts developers in a position where client side rendering eats more and more of their application, creating SPAs where they are not needed.

Re: Browsers are pretty good at loading pages

#165

Post by TwoQ »

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…

It also breaks a lot of disability features, like text to speech (in many instances) or navigation using keyboard keys instead of a cursor.

On the plus side, not having to reload a new page for each click can have some interesting benefits. These systems remind me of flash content, except they are perhaps less terrifying and intrusive.

Re: Browsers are pretty good at loading pages

#166

Post by steveklabnik »

_nhynes wrote: post #154
visarga wrote: post #142

You can also make a mess of server side nav. Just take a look at PyTorch documentation: 2.5MB of shit loaded in 26s. At least 10 fonts, 300KB of CSS and 455KB of JS. What I hate most about it is that the 'in page search' function doesn't work for many seconds after the page starts showing, and it's the only way to navigate such a long-ass page. Even with such a huge page most functions have no example of usage, it wa…

And the rustdoc for Iterator [0] (everything else is great, though). [0] https://doc.rust-lang.org/std/iter/trait.Iterator.html

As of the next release, it will be a lot better!

Re: Browsers are pretty good at loading pages

#168

Post by jancsika »

moksly wrote: post #32
thrwaway48295 wrote: post #20

What I can't get over is Chrome and Gmail. They're the same company, but managed to make an abstraction between these two groups where it takes several seconds to load and display a list of text fields on a mid-range PC. The HTML version is instant.

It takes a little longer to load, but it also lets you continue working while your train goes through a no-internet zone.

textarea manages client-side state just fine in the HTML version.

Re: Browsers are pretty good at loading pages

#169

Post by thinkloop »

StavrosK wrote: post #109
TeMPOraL wrote: post #101

Earlier quoted context omitted.

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io (I promise I'll reply to your email soon)

Your site is great and the perfect usecase for traditional links, but it's literally like 99% content, with very little markup. The difference is more stark on design heavy pages.

Re: Browsers are pretty good at loading pages

#170

Post by extra88 »

quazar wrote: post #126
TeMPOraL wrote: post #114

Earlier quoted context omitted.

By "keyboard" I assume you mean TAB-key-based navigation (I don't know of any other included in the browsers)? If so, it looks to me that links are in fact TAB-stops, but they're not being highlighted. It's something that should be solvable with a CSS adjustment.

If the links are not highlighted by default, then tab navigation is basically non-existent since I cannot see where I'd be redirected and I personally bother to write custom CSS only for the websites I visit very often. Is there an actual reason to disable highlighting? It lowers usability and accessibility, but I'm not sure what do you get in return?

> Is there an actual reason to disable highlighting?

Some browsers, Chrome especially, show the focus outline when elements are clicked with a mouse and some people think it looks unacceptably bad.

Focus-visible is a CSS property meant to solve that but it’s only supported in Firefox and requires browser heuristics to do the right thing.

https://caniuse.com/#feat=css-focus-visible

https://css-tricks.com/keyboard-only-focus-styles/

Post reply on HN