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?

It's infuriating.

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

Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior.

Of course shitty implementations exists and you only notice the bad ones. If done right, you don't notice that it's happening at all.

Lastly but most importantly, context matters! It's not a silver bullet, but it can be really useful.

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.

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)

Imagine Software Engineers that actually engineered solutions - the use of small async requests would be a boon to everyone! But no one's doing this.

I know first hand of one company doing this nonsense with requesting a full JSON payload (describing the whole house that goes along with the proverbial kitchen sink), rather than requesting updates for the one property on the user's screen. I've proxy-sniffed at least two other, unrelated companies doing exactly the same thing.

This is...disgusting. I was speaking of applications I have personally worked on; the teams/organizations I have worked with were concerned about performance (and measured it with regression testing). I suspect the oversized responses and cherry-picking are a result of back end and client being responsibilities of independent teams and client team is told "use this pre-existing kitchen-sink endpoint".

JavaScript, as she is spoke, is just an awful language. It has brilliant ideas and if applied correctly could make everyone’s lives better but that’s just not how it’s used.

There's nothing inherent in JS to say "you must do a shitty job of optimising your page speed"

I'm working on replacing a PHP app that is currently taking 20 minutes to refresh the index page because their SQL doesn't scale. Is that the fault of PHP, SQL, or the developers who wrote it?

You can write crap code in any language (even Rust!).

It could be argued that the same language, given another chance, would produce a similar culture, though I'm not 100% convinced of that. Anyways, what we need is a reboot of web development culture.

It just seems more likely to me than any culture about a language per se.

But thinking of it, Sturgeon's law may be at play. PHP used to suffer from similar reputation to JavaScript, and only started regaining its status as a proper server choice once the masses moved to greener pastures. Sure, the language was a "fractal of bad design" and had footguns galore, but it wasn't that bad, and most of the traps were avoidable when you had half a brain and used it. The web may be crap very well because it's where anyone fresh to programming can find a high-paying job, and you can become a "senior engineer" after one year of job experience.

But that, still, is a problem. Outside of programming, there are quality standards on the market - often enforced by governments. Even if 90% of chairs are crap, you can't go and sell that crap to the public. Quality standards filter most of the crap out.

If that's the case, I'm not sure what to do. Introducing quality regulations to programming might help solve the problem of website bloat and constant leaks of private data, but it would also destroy the best thing about the web and programming in general - if you have an idea and a computer, you can make it and show it off to everyone.

Some of us are! RFC8620 is purpose-designed for building network efficient APIs: https://tools.ietf.org/html/rfc8620

What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised of content that is static in its nature.

Yeah, because most visitors to most websites can and know how to disable images in browser settings.

In fact, let me know how to do this in iOS Safari. Before you tell me to throw my iPhone and iPad in the trash, get an Android, root the damn phone, install F-droid, compile Chromium with patches, or write my own operating system, now is a good time to stop.

I seriously hope this sort of condescending “elitist” bullshit would die off.

Maybe they would, if the UX culture of these days wasn't removing every feature that isn't used on every interaction, and then devs wouldn't try to build increasingly complex reimplementations of browser features on each page.

In an ideal world, lazy loading of images would be something handled purely by the browsers, and users would be aware how to operate it. The site's job is to declare what it wants to show; the User Agent's job is to decide what to show, when and how. But nah, the web culture prefers to turn browsers into TVs.

Given any browser, how do I reload a lazy-image that failed to load, without resorting to whole page refresh or diving deep into the Web Inspector?

Most browsers have a context menu option to reload regular images, but they cannot and will never handle a bunch of dynamic block elements with background-image option.

I'm also not sure about the background-image'd block elements, for what it's worth.

Edit: by “once loaded” I meant once loading is triggered, if I wasn’t clear enough.

> Just like how Ruby on Rails is slow but we deal with it

Not all of us :)

It is an interesting future we live in, is it the best one?

(I promise I'll reply to your email soon)

But I will give you credit for the fact that it does work with Lynx!

Is there an actual reason to disable highlighting? It lowers usability and accessibility, but I'm not sure what do you get in return?

Also I use Vimium so I never noticed, since that mode of navigation is much faster.

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/

[0]: https://imgur.com/a/FAX6BDW

That being said I challenge the assertion that they are used for no good reason.

- Custom fonts are used because they help shape a brand. Properly used, the choice of fonts communicates a lot (at a subconscious level) about the company or person behind it.

- Unnecessary videos unfortunately work (i.e., help grab and retain user attention). Not for me (quite the contrary!), but for the majority of people stumbling upon a company's website.

- Same for weird gimmicks involving animations and what not. I can feel them draining my battery out and it phisically hurts, but most people like them and take away the impression that "this is a modern person/company".

All in all, many website's primary goal is not to communicate factual information, but to capture user attention and/or communicate at a subconscious level, and gimmicky things work for that purpose :S

I fully support using a custom font for your visual assets - that's what SVG with text exported as curves/outlines was created for. But why should I use your horribly hinted, terribly rendered, absolutely illegible webfont (and have to download it to boot) just to read the copy on your website? Why should anyone?

Look at Apple. Despite what I'm sure their design team tells them, even they don't have an iconic font. They've bounced around between Helvetica, Myriad, Lucida, and a half-dozen other sans serif fonts that share certain design traits (which people do identify and associate in general), yet each time they introduce a new font they update their website to trigger your browser to download the webfont to render the page. It's a pointless exercise in the name of job security.

Companies have had websites going back 30 years. Web fonts have existed for a long time. This trend of each company having to pay tens of thousands to commission an unrecognizable, undistinguishable typeface that all text on their website must appear in is a brand new phenomenon, and there's zero proof it does anything besides (poorly) accomplish what someone thought was a good idea.

> (I promise I'll reply to your email soon)

(Take as much time as you need; also, I didn't expect a reply over the weekend :).)

A great example of how it's quite difficult to reimplement stuff that works perfectly well on traditional pages.

(At least they seem to haven gotten rid of some of the dark patterns they had in the past, that's nice to see)

EDIT: and within a minute more found another state bug :D

Yes, you can make perfect SPAs, but many people fail and it's a good question if the effort required to do it properly is worth it.

I'd love if you can show me how to reproduce this bug.

I just don't have this experience with SPAs breaking. I actually have no idea where it's coming from.

I can see what is happening there: the popup removes scrolling (because of the overlay) but the back button doesn't restore it.

This certainly does lend to the conclusion that managing page state in a SPA is not trivial.

It seems to be a fast and responsive site when it works, though.

LOL.

Y'all, I love speed as much as anyone, but your development priorities should be 1) it works and 2) it's fast.

Using HTML links where 1) is never in doubt and all focus can be placed on 2) seems like good engineering to me.

Reinventing browser navigation is like building a rocket. You should be really, really sure that you need to do it before you try.

Facebook and Google used to be guilty of this, but it’s been a while since I ran into that particular brand of user-hostile web design.

Seriously though, you can't just bolt infinite scrolling into the middle of an existing page if you have content at the bottom.

If anyone's curious, the footer contains: Home, About, Privacy Policy, Terms of Use, Contact, Code of Conduct, DEV Community copyright 2016 - 2019

They've duplicated most of that (but not the copyright) in the sidebar's "Key Links" box, so it's not as big a problem as I've seen on other sites.

If they hadn't, I wonder about the legal implications of making your privacy policy, terms of use, and copyright notice completely unreachable. And why keep them in the footer if you never leave it on screen long enough to click it? Just a "not my job" issue with whoever implemented the continuous scroll? Clearly someone thought about it long enough to put the links somewhere reachable, but not long enough to get rid of the old ones?

Bad: this only works on every other click. Half the time the links just silently fail....

https://i.imgur.com/bx1LUZD.png

Unfortunately for us front end engineers we can't rely on the user having any internet connection let alone a good one. Most of the push behind static site generators is to get as much of the code necessary to display all the website in to your browser as fast as possible, so it's there no matter what happens later. In cases where the user has a fast, robust connection that may well be slower than loading each page on demand, but in cases where the user's connection is slow and flaky (eg on a train) static sites generators do work better.

Perhaps the next generation of websites will take your connection in to account better. It depends on whether browsers and users will be willing to give up that information though. As far as I'm concerned I will use everything I can to improve the user experience on the sites I build.

The site that tends to be the best to use is the ones that don’t take much to load. Connection tends to be spotty, you get bouts of “some” data and then you’re dry again for a while. If you can squeeze a page load in there it’s infinitely better than a half opened page.

Your first page load is -incredibly- important here. It’s the difference between a usable site and an unusable one.

The sites that work the best are the ones that do not try to do very much fancy stuff, because that fancy stuff only half-loads most of the time; leaving you to keep refreshing and hoping the spotty connection finally lets you bring in that 2KiB that will allow the page to actually load.

One, if your first page load tries to load a full page, instead of just some JS that bootstraps the process of loading of the rest of the page, which lets the first load finish before execution. Better yet, it should load the absolute minimum bit of JS site kernel. Then, the first load is likely to succeed on a slow/spotty connection, and we can skip to problem #2 below. This isn't being done correctly in most of the sites I visit for some reason; the first page is either attempted to be downloaded in full, or the "skeleton" of the UI is the piece that always loads the longest.

Two, loading UX. You have a loaded UI skeleton with boxes that need to be filled via further requests. Or, I've clicked on something and a subsection of the site needs to be refreshed. What happens is either nothing, except the SPA getting unresponsive, or I get the dreaded spinners everywhere. If the requests succeed, the spinners eventually disappear. If they don't, they don't. Contrast it to the pre-JavaScript style: if something needs reloading, my page is being rendered essentially top-to-bottom, complete bit of contents popping up as they're loaded; the site is usable in partial state, and if anything breaks, I get a clear error message.

Can this two problems be solved correctly in client-side rendered code? Yes. Can SPA be faster than full page loading? Yes. Is it usually? No, because web development is a culture. When a company decides "let's do SPA" or "let's do client-side rendering", they unfortunately inherit almost all the related dysfunction by default.

I'm going to take the common case of a news article;

Imagine for a second, you're on a train and you have low bandwidth internet, when it works, which is rare. Now you're on hackernews and you've loaded a whole comment thread, you're reading through and someone posts a link to your article.

Now, the article can load with client side routing, but will take longer. And depending on implementation might not actually have the whole article.

The page which is pure html with minor javascript is going to load, in full, and I don't need subsequent requests. And, it's guaranteed to be smaller than the one that you're over-engineering.

Without fail, the sites that rely heavily on JS to do page loading end up performing significantly worse (and in fact outright bugging out, and often failing to load entirely) than sites which just send ordinary HTML docs. A disturbingly-high number of the JS-heavy "web apps" out there seem to have little regard for actually handling failures on a sketchy connection.

Your point would make more sense in the context of an Electron app or something with a permanently-locally-cached copy of the site. That would at least give my elderly friend the means to predownload it when he piggybacks off the public wifi when he goes into town.

Surely some web apps need to work offline. But most web pages do not, and I don't want most sites I visit to store a bunch of data on my machine on the off chance that I'll use them offline.

"Offline first" seems really misguided to me as a rallying cry for all things on the web.

It may also be much harder to implement something like a comment section that is fast and correct with only static html and a server backend.

Not everyone has this, espicially when your someone like myself who writes informational websites for people who won't be connected to any internet for hours at a time.

Super fast response times don't cut it when your response time is non existent at the moment.

I should know, my internet connectivity sucks, and single page applications are almost without exception, a completely awful experience.

You can view e.g. ecommerce sites as blogs with one post per combination of (search query, filter switches, page selected). This necessitates frequent shots to server, but the site otherwise transfers roughly a page's worth of data per viewed page. I've never seen an on-line shop that was made better by being an SPA, over an old-school page reload every click.

Similarly discussion forums - there's Discourse that's arguably more gimmicky with its client-side magic; beyond that, if you want to see what would happen if you turned HN into an SPA, look no further than the dumpster fire the new Reddit design is.

In my experience sites with these kinds of navigation are typically extremely slow with initial page loads taking anywhere from a couple seconds (bad) to 10-20-30 seconds, sometimes even a minute (on a 100 MBit/s connection) and subsequent navigations are often slow as well.

It can be hypothetically faster, because you can theoretically get away with less data transfers and less client work, but in practice the exact opposites materialize.

Some sites might be slow at generating that HTML but then they would be equally slow at generating whatever JSON/API responses used in a SPA, along with loading all the heavy JS in the first place to render it all.

On the client parsing is fast, but the slow part is the browser laying out the page and fetching new resources - but that is going to be slow anyway, even if you do client side rendering. To make that fast you need do something more intelligent than just rendering a different React component, as well as prefetching resources in the background. But how many SPAs actually bother trying to do that?

I agree that SPAs have their place, and they have a lot of advantages over what we had before, but I just don't understand how it has seemingly become the default for any kind of web development - with such disregard for performance.

I haven't benchmarked the difference, but I bet HTTP compression removes most of the difference

> but that assumes your client already has cached the megabytes of JavaScript needed for you SPA

A cache that will need to be busted every time you deploy new code. You do deploy often, right?

Writing a web app with server side pages forces you to think about where the state lives. This is a beneficial discipline.

Of course the revelation here was that <a> 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.

If you are just trying to re-create it, don't.

Not sure about your point, the history API improves UX if you do it right:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

It does everything as hand written, pure HTML page would, just do it faster.

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.

Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.

Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.

https://v8.dev/blog/code-caching-for-devs

https://blog.mozilla.org/javascript/2017/12/12/javascript-st...

https://bugs.webkit.org/show_bug.cgi?id=192782

Also did you mean http caching? Not sure why would want to remove that. It's still important for the browser to get the latest script content before the bytecode caching happens.

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.

Please, don't! Just give me a page with thumbnails that are direct links to the original pictures! That's million times easier, works blazingly fast and I wouldn't need to spend so much time clicking multiple times to save each pic, which is the best case! The worst is serving me blobs of PNG instead of original pics. That's pure hostility.

That was the initial benefit. (Gmail, for example)

Then everyone starting using the client-side model as the de facto architecture for every new website and web app.

The old, "give a man a hammer" adage.

Like any tool, it depends on the job.

But sometimes a tool becomes so popular that it takes courage to choose not to use it.

"Err...well... sure I can explain why I chose to go with plain old HTML.. (gulp)"

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

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 end result and blame the technologies, but this is superficial.

It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".

Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA applications cause the opposite — companies move everything to client-side in order to reduce Amazon bills, and don't care if those client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.

Clearly, there should be a heavy tax on single page apps. They are

1) addictive — by making more Javascript devs, who in turn write more Javascript websites

2) act as luxurious goods ("Look guys — we have created a new version of our website. It looks so cooool (but loads a bit slow)!")

3) have ugly externalities, completely ignored by most of their creators

SPA-s are much-much harder to develop if more teams are working on it. So your first sentence makes little sense.

> companies move everything to client-side in order to reduce Amazon bills

This is never the reason why it happens. Seriously? The cost are not saved, just moved around. SPA-s are developed because they could provide a much better UX. As a side benefit, server side development becomes simpler by providing some REST or GraphQL API. You don't want to be in a place where tens of thousands of lines are generated backend side by backend developers.

> client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.

I appreciate your sense of humor :D

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.

Nah, it makes it more complicated. You still have to handle reloads and back/forward, but now it's on you.

The narrow case where you make an XHR call to just reload a small slug of data instead of the whole page effectively does not exist in the real world. I mean I'm sure a few developers have implemented that exact pattern a few times, I think I remember even doing it myself probably? But it's not something that actually happens.

What's actually happening instead is people are just adding more and more intricate tracking and analytics to all these SPAs. The XHR call to reload a blurb of text kicks off three other XHR calls to register the event with the various analytics/advertising tracking partners. Oh and we're adding a new ad partner next week so make sure you refactor all the AJAX to register event handlers for all these new interactions. And can we add mouse position tracking too?

I'm starting to see some pages break into the tens of megabytes of JS scattered across hundreds of files, nobody is paying any attention to what's fast.

I'm not sure how you fix this, I've largely given up on the web. It's just a thoroughly terrible experience from top to bottom, and effectively unusable if you're a layperson.

I'd count breaking my back button or otherwise mucking with my browser history as "los[ing] state". Maybe we have different definitions of "you" in mind.

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.

If you scroll down on the page, and click on the link, it takes you to a new page. Works great.

If you use browser back button, it takes you to the previous page, but scroll position is lost.

https://reddit.premii.com - Uses client side navigation. Try it on mobile and then desktop. Its not perfect, but works really good for what I want. Its hosted as a static site. I make request to reddit directly to get the content.

Did you read the article? The entire point was that “its faster” isn’t actually true.

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 any website that has some sort of overall state between page transitions, like soundcloud.com playing a track as you click around.

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 again? That sucks.

Endless scrolling sucks. You go down and down and down, and something breaks (eg. bad wifi), and you lose your position, since refresh takes you back to top.

Also: something breaks, you press F5, and now the feed is gone, or is in a completely different place than it was before refresh.

Infinite scroll should be labeled as dark pattern. Its only benefit is to the companies exploiting intermittent rewards; for users, it's just bad ergonomics and bad experience.

But a dark pattern? Definitely not. I have had multiple projects this year where the feedback from UX workshops has overwhelmingly been to use infinite scroll. This is feedback from real users, customers, and clients.

We need to be careful to align the website UX to the correct target users. Are you building something for a very technical market or power users, such as software engineers? Sure, ensure you don't interfere with the experience.

However, if you're targetting business or social users, you need to base your decisions on their priorities. This means the optimal path for their primary use cases. This means optimizing for the 98% of the times the user just scrolls down the feed, not the 2% of the time they scroll a bit and refresh.

and yet, that's the same behavior of the social media sites; you will spend more time (=more ads shown to you) there because you are searching for that damn video again

1. browsers have some sort of cache[1] that allows them to restore closed/previously visited pages without doing a page reload. granted, it's not very reliable, but it'd probably work most of the time as long as you're not memory constrained or visiting too many pages in-between.

2. if the infinite load mechanism also updates the url (via the history api), then this wouldn't be an issue.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

(I still don't particularly like Discourse's implementation of infinite scroll because their custom scroll thing is awful to use.)

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

> Turbolinks intercepts all clicks on <a href> links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

I don't have a Turbolinks application to check but I found this https://github.com/turbolinks/turbolinks/issues/313

and this

https://www.mskog.com/posts/instant-page-loads-with-turbolin...

The behavior you describe is possible but it's not the default and requires adding other libraries.

Oh, that's the easy one. It's half-assed because it's hard as hell to do a good job replacing the browser navigation. It shouldn't be surprising, since browsers are huge pieces of software made basically for displaying content and navigation, it's not reasonable to expect every web page to competently replace half of that job.

I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff.

[NB I really like React and when good SPAs are very very good - but a lot aren't].

One thing for sure: layout tables are undeniably powerful, that's why people want to recreate them but without the penalties that come with real <table>.

Tables had performance problems when they got large and content got potentially dynamic. That I learned only many, many years later - I never did sites big enough to run into such problems then.

The accepted answer in this post is cringeworthy. So much rationalization these days, makes you wonder what we're rationalizing today.

--

[0] - I admit I bought the CSS Zen Garden for a while; it took me some time and experience to realize that, really, no one does that in practice, and it requires ridiculous amounts of either forethought or afterhacks to do it.

It's good enough to read the content and the content is the vital part, but I wouldn't point to HN for a good user experience (beyond the content and lack of dark patterns).

Compare the site you're on right now (HN) to Reddit's new SPA frontend. Which one is faster to browse?

Surely, on a fast-enough connections this flicker is essentially invisible, but if your connection is far from perfect (crappy hotel WiFi or poor cellular reception), it is certainly well noticeable.

Also, it's easier to persist some state across the navigations. Like making it trivial for those (annoying) on-page support chat overlays not losing message history.

This rationale only applies to web "apps", not documents, of course.

like https://github.com/turbolinks/turbolinks

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.

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.

If on the other hand, if you encounter code like the abomination below (which breaks cmd+click, peek and forward/back), you should not (imo) conflate it with actual client-side navigation. I suspect that's what some comments here are referring to.

    <a href="#" onclick="loadContentIntoPane('contact')">Contact Us</a>

I tried 4.5 years ago with https://vivavlaanderen.radio2.be/ - disclaimer: the experience isn't great on mobile (design issue, not tech) and the JS/HTML is massive (it was my first JS project ever, so I messed a bit with Webpack etc).

One of the tricks I used is partial rendering. If you click an artist page (the square/rectangular people photos with a name) and have JS enabled it'll first only render the header, then add a few body items, then the rest of the body items. Since we used a horribly inefficient handmade Markdown to JS thing with a renderer in old naive React it took way too long to render them all at the same time, it'd easily lock up the browser for two seconds on a large page.

Another ridiculous thing was to preload enough data to render the top part of every single artist page while you're on the homepage. A complete waste of data, but otherwise navigation would need a request before being able to render something useful and that defeated the point.

I did pay a lot of attention to making it feel like real navigation though. Almost any meaningful interaction modifies the URL, and the site is practically fully functional without JS. Navigation and Cmd-clicking should all work perfectly. Including scroll positions handling. SEO worked really well too.

So for a classic website format, to make client side rendering work, you need:

- a URL for every view change, with regular old <a> elements that have those URLs as href.

- server rendering that actually handles all of those URLs

- something that restores scroll positions on navigation

- phased/batched rendering on click if your initial new view doesn't render in say 100ms (basically faking progressive rendering)

The development experience was a bit frustrating back in the day, and I don't think it paid off. Which is why for the next project (https://www.klara.be) we decided to go back to server rendering, but using React on the server. Some parts of the page (like the coloured box top right on desktop) are rendered as a skeleton on the server, and then React on the client reuses the same exact code to make these parts interactive again. Partial universal React basically, and it worked very well. I think klara.be feels like a nice and snappy site and it was way easier to develop for.

This is the most common problem I have. I middle-click and nothing happens (or it loads in the same page)

That being said this is partially an API issue since the website needs to guess what a "regular click" is. It would be nice if there was an "onnavigate" event which would trigger for regular clicks (or other ways to follow a link in the same page) but not for things such as "open in new tap" shortcuts.

More often than not, I've seen that tracking scripts break this more than anything else. Particularly command+click.

Still - it'd be great of there was an API to preserve UI state moving into a new entry in browser history. I don't want to lose scroll position for a sidebar if I'm drilling down into a large list of data.

Being able to add hints through markup for when to preserve UI state could go a long way towards making page-refresh based form and navigation behavior competitive again.

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.

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!

It sounds like you started by trying to build a static website and then decided you wanted something more dynamic...so shifted to react where you are doing the dynamic data manipulation on the client as opposed to a server..not a like for like comparison

Page losing is dominated by two things:

* the network. Browsers are written knowing that networking is terrible, so aggressively optimize their use of any data, including starting layout, rendering, and even JS before the page has completed loading. That’s not possible for client JS that is using XML and JSON data as neither will parse until the data is complete (this is part of why XHTML was so appallingly slow and fragile).

* JS execution - people love shoe horning JS into early page rendering. If you care about your page performance the first thing to do after networking is pushed all JS out of the path-to-initial-render. By design “client side” navigation blocks all content rendering on executing JS to build out the html/dom that a browser is much faster handling directly.

As a side benefit to making your site faster by not manually reimplementing things the browser already does for you and does better, you all get better back/forward, correct interaction with the UI, work correctly with any accessibility features that are operating, correct scrolling behavior, correct key handlers, ...

The benefit of client side rendering is you get to say you spent a lot of time doing something that already worked.

The correct answer is it all depends. Certain things are faster to do in JS. Certain things are faster as a page load. One has to profile and see what makes sense.

There is a reason Atlassian is dog slow and trello runs circles around in terms of UI performance. The immediate <100ms navigation between views is probably why Atlassian ended up buying Trello. It would have eaten their lunch.

Once you have a substantial amount of JS, and you’re an app site, which a lot of sites do, it’s usually faster to not make the browser parse and compile again. Just stay in js land as a single page application and communicate with server purely in REST.

Now, come on. Very few people in here would say that js had no place in the web. A lot of people are against js when alternatives exist. Trello is an application, so js makes sense there. A blog article that doesn't even display when js does not load, that's where people have a problem.

A similar issue comes up with Google AMP: it's billed as a web performance move but it's regularly slower and the failure mode is that you don't see anything at all. That doesn't mean that the problem is completely intractable but the act of taking over a core function put the onus on them to do a less shoddy job.

So maybe this is kind of obvious, but the whole purpose of client-side scripting is to make the site more interactive, right? If your site is completely static, you shouldn't be using client-side scripting. If you're site is very dynamic and interactive, you should be relying a lot on client-side scripting. Imagine writing a video game for the web where every key stroke was sent to a web server and every video frame was retrieved from the server. That would be way too slow due to the amount of interactivity involved and the latency introduced by the communication with the server between every frame.

(It's also a great case study of how it doesn't matter how good or bad your app is, the success of your business doesn't depend on that)

This is a sensible conclusion. Unfortunately, "js land" tends to grow as application grows. And nobody actually unloads their Javascript when it is no longer necessary (can you even do that?)

Server-side rendering means, that you shouldn't leak memory — otherwise your app will literally stop working.

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], which is a free online electronics textbook that has interactive circuit simulations built in. Here's what I ended up with in the spirit of progressive enhancement:

1) Static site generated by Jekyll (with a few custom plugins) and hosted on S3+CloudFront with appropriate caching headers

2) No JS blocking initial page load

3) No custom CSS fonts to download

4) Prefetch and dns-prefetch headers

5) Tell browser to preload next page on link mouseover (instant.page)

6) Lazy-loading of schematic images (lozad / IntersectionObserver) when they're nearly within scroll range

7) Client-side instant search index (awesomplete + custom code)

8) Tooltips with section descriptions on internal navigation links (balloon.css)

There are heavier components to this too:

1) Equation rendering (MathJax) is heavy and slow but starts rendering the equations after initial page load, and prioritizes equations within the first few thousand vertical pixels first. (Sadly I need the full power of MathJax; the faster KaTeX engine can't handle all of my equations.)

2) The schematic editor / client-side circuit simulation engine is an entirely separate SPA. (But by modern standards it's probably a smaller payload than many sites today use for serving totally static content with a few forms.)

The result is a site that loads pretty darn fast -- maybe faster than a static page due to preloading and lazy-loading -- but packs in a lot of functionality appropriate to the problem. Any techniques I'm missing?

[1] https://ultimateelectronicsbook.com/

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 with many instances of table of contents.

Also something weird happens when I click a chapter link. Like, the whole table of contents scrolls for an instant and then I see the chapter.

Edit: if I disable JS, all these problems go away and the site feels just as fast. So good job on that :-)

Also, incorporating lazy loading into the browser would make NoScript viable in far more websites. Most of the time the only reason why I consider enabling JavaScript for a website is to view lazy-loading images, everything else works good enough (or better) without JavaScript. With lazy loading being done by the browser, almost no website I come across would have this problem, unless they choose to intentionally break without Javascript. Of course, this wouldn't be a problem in the first place without lazy loading, but alas, here we are, with most websites using it.

I don't necessarily expect browsers that implement it to have a user-visible way to disable lazy loading, though, so you may be out of luck there. You _might_ be able to create userscripts that force non-lazy loading on all potentially-lazy elements by using the opt-out frob browsers would add for websites.

On Chromium side, maybe Vivaldi and the like could provide the option to disable it, if it is not too difficult of a change on Chromium. But for sure, I would be very surprised if Chrome offered that option, so not much of an improvement for Chrome users, or maybe even a deterioration if sites start to adopt it even more, now that it is supported natively.

Would you mind sharing this script? I use NoScript heavily and something would certainly be better than nothing in a lot of cases.

My experience with the previous version was that while it sometimes worked, on some websites it broke more than it fixed; and when I modified the script to account for that issue, it broke something somewhere else, as websites use very different methods to display images that I couldn't imagine (hence I welcome a standard way of doing it). So I ended up using the script on a whitelist basis instead. Maybe the new version works more properly, so that I can enable it globally again.

[1] https://superuser.com/questions/938345/load-all-images-even-...

Not sure what would make it faster, but thought I'd report that with Safari 10.1.2 the site is currently broken for me. The MathJax equations never load, and I get text mixed with spinning circles.

Javascript Console contains: [Error] SyntaxError: Cannot declare a let variable twice: 'e'. (anonymous function) (compiled_postbody-544dfbba31d691e567064ba96e9eec29f4257fe5909a4ddb5218cd36d823e215.js:1).

Edit: I'm unable to reproduce this with Safari 12.1.1. Did some searching and this is a known bug in Safari 10 which was resolved in 2017: https://github.com/webpack-contrib/uglifyjs-webpack-plugin/i... / https://bugs.webkit.org/show_bug.cgi?id=171041 -- I will try to workaround.

https://github.com/nixpulvis/nixpulvis.github.io

That was the reason given by MDN.

No, he says one of the developers of a specific website (MDN) told him that is why they did it in that particular case.

Ajaxy navigation has its place i guess, but your website has to be fast for that too. The worst offenders i have seen here must be all the advertising managers like google adwords, facebook ads. Each request takes a horrible amount of time to load, which makes the interface completely unintuitive. Is the browser loading a page or not? Is this popup from the first time i clicked the button or from the second time? Where did this other popup come from and why now? It's like reading HTML sent through UDP.

Also bad is that junior engineers see shoddy client side code and internalize it. As an example, one junior engineer asked me how he was supposed to iterate over an array server side when I told him he didn't need to use Vue on a page. Server-side rendering fixtures had been completely forgotten.

I accept my responsibility in causing this mess though. I niavely pushed the SPA on my myself, my coworkers, and our end users years ago and have to live with that sin daily.

The fact that in 2019, we still don't have standard browser features that let us create rich text documents in a WYSIWYG interface is ridiculous.

We've ended up with a dozen editors all producing slightly different markup, workarounds like Markdown and AMP, and browser engines that are so complicated even a massive company like Microsoft finally gave up creating its own.

This isn't about technology at this point, it's about standardization. We need to have a simple tag which marks the beginning and end of textual information, with massive restrictions on what tags are used and the JS and CSS in that section, so that a simple, standard and ubiquitous editor can both read and write hypertext 100% the same while still including all the basic functionality of a common word processor, like fonts, colors and sizing.

This isn't a technical challenge on the level of WebGL, web sockets, HTTP/2, media extensions, etc. It's just a matter of specifying a subset of functionality for a specific use-case, standardized for the sake of simplicity and interoperability.

Managers go with it because it's still hip and easy to hire for. If things go wrong, well, it was good enough for Facebook.

I wouldn’t say it’s easier to build in these SPA frameworks nor harder. Attention to detail is something people recognize or learn over time.

As for whether an SPA is harder or easier, that's not really the relevant dimension. You should not be making technology decisions for your company based on what your new junior devs are comfortable with. They will actually level up faster if they are forced to take what they've learned and apply it to something they weren't working on in their nine-week intensive.

Meanwhile, there's nothing "easy" about React and co when you factor in the layers of abstraction and bikeshedding involved in a typical full-stack deployment today. Compared to when I learned, you suddenly have to also be confident with bash, git, docker, AWS, postgres, webpack, and the whole concept of a virtual DOM before you even start modelling your data or thinking about state transformations. Now go compare that to the original Rails "blog in 15" video and you'll have a hard time claiming that anything is easier. The drop in developer ergonomics over this golden era of JS tooling is stunning in its unneccesary masochism.

That's very far fetched. A React app can just be the default template from CRA + some place to host the generated files (like Netlify if you want something simple). You don't need to know any of the above.

Most of what's gotten better on the web has been about standardization and drastic improvements to EcmaScript. Unfortunately, we've taken all of these new toys and made sites that load slower, on average, on today's phones than typical sites did in 2009. The problem is far worse in developing nations where phones are many generations behind.

Don't get me wrong: I'm glad that React exists and if I was building Trello, it would obviously be an excellent tech choice.

However, there's exactly nothing simpler or faster about a React app vs a properly-cached SSR fronted by Turbolinks and a tiny framework like Stimulus for 98% of applications. I don't know how this became a sacred cow but at some point the Reactive defenders started reminding me of Scientologists.

People were really, really stoked about Java when it came out, too. One codebase that will run without modification on every device, they said.

Call me a blending edge buff, but once WebGPU rolls out you can blur the distinction of web site and native program. But I would not utilize such on statically rendered website. But I would use it on a portable version of Photoshop, Blender, AutoCAD, or Minecraft.

Can you do the above today, inefficiently yes. But once WebGPU (gpu multi processing via a compute shaders with shared instructions) hits in combination with WebAssembley Workers (shared instruction cpu processing with proper floats across X cores) it will be an entirely different story.

What is insane to me is that these UI frameworks run in combination with the DOM on the main thread. That they are not designed from the ground up to run SSR and it is an afterthought.

Or in the instance of third world can even be managed by a Service Worker that drip feeds updates and presents th em on the site they are on next time they visit.

1 million and one ways to skin a cat. No way is better, it depends on the client's budget and use case.

For that matter, why does anyone engage in this constant race to the bottom? If more web authors and developers were to make a stand for decency and refuse to implement these unnecessary hacks, the Web might be a better place.

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