23 ms·

Browsers are pretty good at loading pages

• Animats 7y ago
  Why is management paying for all those overdesigned web pages?
  • grishka 7y ago
    Because they don't know a thing about underlying technologies.
• jakobegger 7y ago
  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? It's infuriating.
  • kccqzy 7y ago
    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.
    • petemill 7y ago
      But you can support both with client side navigation
      • kccqzy 7y ago
        I certainly can. It was just not necessary because the people who are using the site didn't care.
    • efrafa 7y ago
      Its also really not that hard to make cmd click + back button to work properly with client side nav.
      • saagarjha 7y ago
        Can you support iOS's "peek" menu as well?
        • regecks 7y ago
          Yes, I tried it just now on a random website I built in Vue. Any sane implementation of client-side navigation uses the History API[1]. It is indistinguishable from "real" navigation in the browser UI, apart from how fast it is. 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> 1. https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
        • baddox 7y ago
          Is there anything special needed to support that? I’m pretty sure you just need an <a> tag with an href. With any SPA framework/library I’m aware of, you have to go out of your way to make it not work.
    • zucker42 7y ago
      Not every project is the same. I suspect there are many applications where an SPA is a much better experience than a traditional website. In my opinion, a documentation site is not one of them.
    • pmontra 7y ago
      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.
  • sergiomattei 7y ago
    Slow? I'm quite sure the whole point of client side apps is for them to be substantially faster - and most are.
    • snek 7y ago
      Did you read the article?
      • olliej 7y ago
        I’m guessing no?
      • cj 7y ago
        I read the article. Perhaps I'm misunderstanding, but did they do this test on a 128 kilobit cellular Internet connection?
        • csande17 7y ago
          I made the video in the article using Chrome's "low-end mobile" throttling preset, which simulates a ~300 kbit connection IIRC. But I saw very similar behavior on my actual phone with an actual 128 kilobit connection in Canada.
          • cj 7y ago
            Thanks for the clarification. Do the conclusions hold up when testing with a broadband network connection?
            • csande17 7y ago
              As I mention in the article, I'm not really able to tell the difference between old MDN and new MDN on the fast network connection I usually use. They both load pretty much instantly for me.
              • 7y ago
  • n8hunzaker 7y ago
    Sadly I think this is true for a lot of sites. However my experience has been that many (particularly in the last 3-5 years) support command-click, back button navigation, and scroll position restoration. 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.
  • hoorayimhelping 7y ago
    I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.
    • RandomInteger4 7y ago
      Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.
      • arethuza 7y ago
        HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". 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].
        • SilasX 7y ago
          Well, the up/downvote transition is client side, but otherwise, yes.
          • eitland 7y ago
            AFAIK it works without js as well :-)
            • arethuza 7y ago
              I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)
  • drdaeman 7y ago
    I believe the only upside is that site framing (headers, navbars, side menus, etc etc) doesn't flicker or jump around reflowing as you navigate across pages. Which is I think why almost every "webapp" out there does this - to provide visually continuous experience, even if this client-side intra-screen navigation is slower. 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.
    • basch 7y ago
      I much prefer getting normal pages to behave more like spa, than spa trying to recreate the web browser experience. Probably most importantly, automatically degrading back to normal web behavior, if the transitions arent supported or js doesnt load. like https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  • marcosdumay 7y ago
    > And if they do, why do they always only do a half-assed job at it? 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.
    • jimmaswell 7y ago
      Just use the history state pushing API and it's not that hard. Put state information in the url and load the right content on refresh.
      • mintplant 7y ago
        Scroll restoration is very difficult to reproduce perfectly. Particularly when content changes between navigating from one page to another and then navigating back, or when the user closes and re-opens the tab/browser.
  • Ambroos 7y ago
    I think it's possible but it's hard to execute well. I tried 4.5 years ago with https://vivavlaanderen.radio2.be/ 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 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.
    • kevincox 7y ago
      > with regular old <a> elements that have those URLs as href. 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.
  • tiborsaas 7y ago
    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 <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.
    • moron4hire 7y ago
      It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.
      • tiborsaas 7y ago
        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 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".
        • ryacko 7y ago
          CSS doesn’t require javascript, and allows for nearly all the features of a SPA.
  • deleted 7y ago
    [deleted]
  • bhousel 7y ago
    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 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!
    • Blackstone4 7y ago
      I believe that a multi page app/website would have the data in a database rather than distributed across html files. The server would then populate the html files before serving them up to clients. 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
  • amelius 7y ago
    Curious, how would you implement Facebook's infinite scroll with only static pages?
    • ignoranceprior 7y ago
      https://mbasic.facebook.com/ https://mbasic.facebook.com/
    • cottsak 7y ago
      Don't ask me how to solve a problem that doesn't need to be solved in the first place! :p #deletefacebook
  • visarga 7y ago
    It's justified if you run a web app that needs to maintain complex state between clicks, such as a text/graphical editor.
    • lucb1e 7y ago
      I don't think anyone disputes that. Maintaining a whole editor state in server side sessions or re-rendering everything from localStorage would be rather silly indeed. This is about changing pages, such as Github annoyingly does when browsing a repository.
  • TwoQ 7y ago
    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.
  • cottsak 7y ago
    Dude! #scrollhijacking is the worst!
  • Sharlin 7y ago
    https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
  • tdxcbkifxx 7y ago
    The problem isn't client side apps. YouTube is a single page app and it works very well for me. No issues with ctrl clicking or anything like that. The real issue is poor SPA implementations.
• nikanj 7y ago
  File under: ”Read, then ignore”. Crappy JS navigation (and scrolling!) is here to stay, unfortunately :(
• dustingetz 7y ago
  He says the reason people code client-side navigations is to load pages more quickly. That's not the reason. Client-side navigation evolved from single page apps, where we use javascript to create dynamic content on the fly, for example a chat application. Now that you're a stateful single page app, we need to rebuild page navigation if our single-page-app has more than one "page". I understand that projects like Gatsby have used this technique for performance, but I see no reason that today's performance optimizations will be valid tomorrow. Page load performance is not the need driving this pattern generally.
  • zucker42 7y ago
    He claimed in the article that a MDN developer said that was the reason.
  • albedoa 7y ago
    > He says the reason people code client-side navigations is to load pages more quickly. That's not the reason. That was the reason given by MDN.
  • latexr 7y ago
    > He says the reason people code client-side navigations is to load pages more quickly. No, he says one of the developers of a specific website (MDN) told him that is why they did it in that particular case.
• snek 7y ago
  I installed noscript to test this, and yes, the beta rewrite, whose selling point is react, is faster when react isn't allowed to run.
• Jonnax 7y ago
  It's the "app-like" experience that everyone is chasing. Loading a new page feels like browsing the internet. Single Page apps feel like a native app on your phone. At least that's what I think the reasoning behind the decision to go client side rendering is.
  • TeMPOraL 7y ago
    Nah, it doesn't "feel like" a native app. It feels like an incredibly fragile app-like porcelain on top of a webpage. A native app, a webview packed as an app and a website looking like an app are all easy to tell apart if you've used all three categories in the past and have at least little attention to details. But yes, I can buy this is part of the reasoning. I think most of it is "we need to make SaaS; cool kids use React, so we'll use React too; now we have an SPA, so the easiest path is client-side navigation".
• robbrown451 7y ago
  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 least for me. Even on a fast computer with a fast connection, going to a whole new page is jarring, comparatively. Obviously if you need more information than the summary provides, great, go to the new page. But if not, this works great. Maybe what Wikipedia does isn't what the article is complaining about. But at least I think the article should mention that "page" is not the only meaningful unit of information on the web, or at least it doesn't have to be.
  • snek 7y ago
    I think you actually make the opposite point you're trying to make. Wikipedia doesn't use JS for navigation, just to provide those little popups. If you have no JS, the site works exactly the same.
  • ryanbrunner 7y ago
    This feels more like the old "progressive enhancement" model than the full blown SPA style that's popular today. Most navigation on Wikipedia is plain old browsers loading HTML pages, but if you happen to support JavaScript, it's used to augment the page to make it a little easier to browse. (I don't actually know for sure whether Wikipedia pages are primarily server rendered, but what you describe is perfectly possible using progressive enhancement).
    • progval 7y ago
      > I don't actually know for sure whether Wikipedia pages are primarily server rendered Yes, Wikipedia works perfectly fine without Javascript
  • zucker42 7y ago
    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.
• tmd83 7y ago
  Modern web is all about bloat and ever complicated ways of doing the meaningless things and how to make a web page more expensive and slower by far than applications that did 10 times 10 years ago. Web has good things going for it biggest being the nearly universal access across devices and platforms but bloat free is not one of them. It might be fast but I feel like it's never going to be efficient in my lifetime. All the browser advancements if they ever make things faster will do so at ever increasing use of resources.
  • zzo38computer 7y ago
    Yes, it is true. It is too complicated and messy, and also stupid. There are other file formats (e.g. plain text) and protocols for other purposes anyways, which is sometimes useful.
• Endy 7y ago
  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 stand for decency and refuse to implement these unnecessary hacks, the Web might be a better place.
  • deleted 7y ago
    [deleted]
  • jakub_g 7y ago
    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.
• thrwaway48295 7y ago
  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.
  • moksly 7y ago
    It takes a little longer to load, but it also lets you continue working while your train goes through a no-internet zone.
    • jancsika 7y ago
      textarea manages client-side state just fine in the HTML version.
      • moksly 7y ago
        Can I open and reply to 25 different emails, and have the replies sit in my outbox until I reconnect? Because that’s a lot more useful to me than how fast it loads.
        • noisem4ker 7y ago
          It sounds like a traditional email client would fit your needs perfectly. Check out Thunderbird: https://www.thunderbird.net/ https://www.thunderbird.net/
• saagarjha 7y ago
  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 ;)
  • kevingadd 7y ago
    As far as I know, no production browser uses tracing anymore. The only modern tracing implementation I'm aware of is LuaJIT.
    • saagarjha 7y ago
      Yes, most browsers have moved away from tracing JITs, but I think PyPy still uses it in addition to LuaJIT. The reason I brought it up was because tracing JITs, as far as I am aware, can give very good performance in the best case where your trace actually works (which is of course a bit of a dirty trick, but when you're up against C++ it's hard to play fair…)
    • zucker42 7y ago
      Do you know why browsers moved away from tracing JIT?
      • saagarjha 7y ago
        Well, one reason is probably because they don’t perform well on programs that cannot trace well.
      • deleted 7y ago
        [deleted]
• nokya 7y ago
  Let's just rethink the discussion without the iOS/macOS crowd and we wouldn't even have to talk about it...
• hrktb 7y ago
  Very concise and well written article. I remember when smartphones became popular, it was an occasion to reset the trends and do basic pages without much JS, no endless hovering menus, no 5 column and 3 popup layouts, no flash intro, etc. Then it started to creep back as power increased. I wish the next big thing resets the field again, one can dream.
• sword_smith 7y ago
  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
  • hedora 7y ago
    The API between the SPA and the server is an internal implementation detail that doesn’t need to support interoperability or backwards compatibility. I see no reason to believe interacting with it directly is easier than scraping an HTML page. (In fact, I’d expect it to actually be much harder and more fragile than scraping html in practice)
    • chc 7y ago
      In my experience scraping both, APIs have tended to be more stable than the structure of HTML pages. I'd guess this is because there's an incentive to keep your API stable (a breaking change for my scraper is also a breaking change for the front-end), whereas there's basically no reason not to rewrite giant chunks of the HTML to accommodate a design change.
  • amiga-workbench 7y ago
    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.
  • dehrmann 7y ago
    This doesn't work as well as you think once you consider multiple endpoints and round trips. You're better off with something like GraphQL or server-side making the API ship views to clients.
• yazboo 7y ago
  > A big one we’re seeing here is called progressive rendering: browsers download the top part of the page first, then show it on the screen while the rest of the page finishes downloading I question your reasoning here -- I don't think this is how progressive rendering works in browsers. The browser has to download the entire document to construct the DOM, and CSS in the head tag all has to be downloaded and parsed into the CSSOM before the browser can make smart decisions about what to render. For a simple page, I also doubt that progressive rendering could account for a >1s difference in rendering time. I would suspect the disparity in loading time is related to network IO.
  • csande17 7y ago
    > The browser has to download the entire document to construct the DOM Actually, the browser can construct the DOM for the first part of the page while it's waiting for the rest of it to download. Like, if the browser starts downloading a page and it sees this: <body> <h1>My Cool Website</h1> <p>Hello there ...it can add the <h1> element to the DOM, since no matter what comes after this in the HTML code, the <h1> will always be first on the page. (It might actually be able to add the <p> tag, too. I'm not 100% on the details.) A cool demo of this is https://harmless.herokuapp.com/main https://harmless.herokuapp.com/main , a JavaScript-less chat app that works by holding the connection open (essentially never "finishing the page load") and sending new chat messages as they arrive. > CSS in the head tag all has to be downloaded and parsed into the CSSOM before the browser can make smart decisions about what to render. That's true, but in this case, the CSS is already present in the browser cache, so it doesn't need to be re-downloaded.
    • yazboo 7y ago
      That's very cool, thanks for the info.
    • progval 7y ago
      Do you know how contact the author? There's an issue with the CSS (it sets the background of the textarea to #fff, which is the same color as the text when the browser/OS uses a dark theme)
• cozzyd 7y ago
  I remember once I had to access the benefits page (Workday) at my employer but I was in a remote location (the middle of the Greenland ice sheet) with a slow/high-latency connection and the required page just would not load properly (presumably the client-side navigation wasn't robust to a slow connection...). I had to VNC (slowly) to a computer in the US in order to fill out some shitty HR form.
• zokier 7y ago
  Client-side rendering/navigation makes sense when you have high ratio of markup to content, or fixed content to changing content. In the olden days people used frames for such fixed navigation stuff etc, but I think we can agree that it was not all that great of a solution.
• lolc 7y ago
  For many sites transferring HTML works fine. I'm surpirsed that MDN would be implemented with client-side-rendering. On the other hand I've had the pleasure of working with both Meteor and Elm thae last few years. It was the first time I had fun implementing client-side code. The resulting apps cannot be reproduced with HTML generated on the server. Often page switches in those apps don't take a round-trip to the server because the data is already loaded and can be rendered right away. Meteor also does incremental rendering by design. So the parts of the data you already have client-side are displayed right away while the rest is being loaded. It is more work to get it right because you have to reproduce functionality the browser would do for you. But often you just don't want to do a full page load and then fetching and patching the right HTML snippets to update parts of the site gets messy real quick.
• russellbeattie 7y ago
  HTML needs to be split into two: A spec focused on dynamic applications using JS and components, and a spec specifically focused on documents, CSS and hypertext. 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.
• compumike 7y ago
  (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], 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/ https://ultimateelectronicsbook.com/
  • cousin_it 7y ago
    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 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 :-)
• fnordsensei 7y ago
  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.
• everydaypanos 7y ago
  He lost me when he described Canada using a dictionary-like wording but also adding some pretty personal perspective. Describing an entire country as Socialist seems super opinionated to me. Client-side navigation is quite tricky to get right - since there is no definition of right. Browser back buttons and scroll positions between back and fourth page loads are not standards-based things and the only way to study them is by just using the browser. The only fashion that I have come to hate in client side navigation is endless scrolling on product pages. In my view it is completely pointless and hitting the back button NEVER returns you to the exact point you were. On product pages I think page-based pagination is the only way to go. Amazon does that. I think only feeds are a use-case where infinite scrolling makes sense. P.S. I wonder if client-side ajax calls are GZIP compressed🧐
  • claudiawerner 7y ago
    >Describing an entire country as Socialist seems super opinionated to me. Not to mention the fact he's wrong; contrary to popular belief, "socialism" has been described as many things but the simple fact of offering healthcare, market regulations and some amount of free Internet access(?) - Socialism is a mode of production in which means of production are operated and managed (and some would say "owned") collectively by the workers, i.e. the majority of the adult population. This is also a form of society in which abstract labour is not valorized. A modern nation with money, capital, rent, predominant wage labour, and capital accumulation is in no way "socialist" - never mind by Marx's term with which he considered "socialism" and "communism" to be one and the same thing.
    • csande17 7y ago
      I, uh, was kidding about Canada being a socialist state... For what it's worth, I had a 128 kilobit connection in Canada because American T-Mobile plans give you one for free when you're outside the country.
      • claudiawerner 7y ago
        Unfortunately it's not always clear who's joking and who's not; many (most?) people who feel the need to comment on socialism and capitalism have done very little reading in political philosophy.
• peteforde 7y ago
  The current generation of less-experienced developers tends to default to building every project in React, even if there's no tangible benefit to accepting this complexity. It's unpopular to express, but the truth is that many junior devs don't know how to do it any other way. I don't blame them for this, because they literally haven't been doing it long enough to have mastered multiple techniques. 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.
  • rellekio 7y ago
    Reduces server costs. Able to process data on client, including mathematical computation via We ebAssembley. Which in effect allows you to create "Web Apps," rather than just a news site, blog, ecommerce, etc... figma.com is an excellent example. Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up. If your client's needs are to just display a static and do not dynamic updates from the server then ignoring the SPA approach is very wise. Client side navigation handled poorly is just that handled poorly. And should be handled by the Senior Developer and not the Junior. As SPA is just another tool for a specific use case.
    • peteforde 7y ago
      Honestly, what do you think we did before the Facebook gods deigned to grace us with React? You understand that we didn't need SPAs to build everything, right? 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.
• golemiprague 7y ago
  It is not about speed, it is about code organisation and responsibilities. It makes sense to just transfer data between the server and the client and leave the client logic and rendering to the client while letting the server deal only with server stuff like authentication or fetching data from a database. It might not be the best choice for a regular website with a bit of interactivity in some specific pages but if you create a web application, something like gmail for example, it makes much more sense even if it might be a bit slower. It basically separate it to an application and an API which most people find as a reasonable architecture rather than sending pages or fragments of pages between the client and the server.
• SilasX 7y ago
  > Most web browsers also store the pages you previously visited so you can quickly go back to them. Not anymore, they don’t. Most of the time I get a huge lag when I hit the back button as all kinds of stuff reloads. I’d prefer if the back button worked like going to a previous tab, where nothing has to reload, but they don’t work like that.
  • lucb1e 7y ago
    > Not anymore, they don't. Hell yes they do, it's the websites that make it impossible most of the time. Try it on a standard website that doesn't use many megabytes of resources (which it would evict for memory reasons). I notice it sometimes when using such websites, it's amazing how fast it feels compared to even so much as a 304 Not Modified round-trip.
    • SilasX 7y ago
      No, they don't make it impossible, because browsers could just implement the same behavior as if I had opened the page in a new tab, and indeed, many people do (and are advised to do) this as a workaround.
• visarga 7y ago
  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 was better with the TurboPascal 7 help in the MS-DOS days. https://pytorch.org/docs/stable/nn.html https://pytorch.org/docs/stable/nn.html Apparently I am not the only one who noticed this bad behaviour: https://github.com/pytorch/pytorch/issues/20984 https://github.com/pytorch/pytorch/issues/20984
  • _nhynes 7y ago
    And the rustdoc for Iterator [0] (everything else is great, though). [0] https://doc.rust-lang.org/std/iter/trait.Iterator.html https://doc.rust-lang.org/std/iter/trait.Iterator.html
    • steveklabnik 7y ago
      As of the next release, it will be a lot better!
• buboard 7y ago
  Try visiting indiehackers.com, the come back to hn for a comparison. I would love to love that site but i value my time and sanity more. Waiting 10 seconds for every click is just torture. 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.
  • soheilpro 7y ago
    I stopped using Indie Hackers because of its terrible UX.
• hjitegi6ehi 7y ago
  Just as a side note. SPA style design often claims that the initial load is slower for the benefit of successive loads. FF reload does override client side caches by default. Relying on warm caches for a good user experience is pretty bad, imho.
• deleted 7y ago
  [deleted]
• nepeckman 7y ago
  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.
• rocky1138 7y ago
  If you're into this and you still use Gmail, switch to HTML mode. I've done it for all my accounts and it's so much better than the JS-laden garbage they've switched to recently.
• gpvos 7y ago
  The only good reason I've seen to have client side navigation is when there's a permanent sound player embedded in the page, so you can keep listening while you browse around the site (possibly for other things to listen to). Although really, for longer-term listening, playing the stream in a separate media player is a better idea. But sites tend to hide their stream addresses, and this is also usable.
• CriticalCathed 7y ago
  > It’s not worth it to try and go behind their backs—premature optimizations like client-side navigation are hard to build, don’t work very well, will probably be obsolete in a couple years, and make life worse for a decent portion of your users. I don't know what is wrong with me -- when I read this sentence all my brain can see is "job security." ______________________________________________________ My take on client side navigation is the desire to cater to smartphone users instead of desktop users. Every few days it seems a popular website does a redesign that is centered around smartphones. They're increasingly bloated and wasteful. Why Twitter, why???
• dingo_bat 7y ago
  If anyone wants to see what js does to page speed, use HN with js disabled. It is lightning fast to load pages. Even though normally HN is fast and light, but I can still see a good difference.
• MattyRad 7y ago
  This is definitely in the same vein as http://boringtechnology.club/ http://boringtechnology.club/ After several years of drinking the client-side kool-aid, I've come to realize that it almost never has a positive ROI. On top of the false premise that it "makes pages faster", it doubles the cost of the entire pipeline/stack, it doubles the amount of documentation that needs to be read/written, and it doubles the statefulness of the app, amongst other things. Maybe under the best conditions by the most knowledgeable devs, client side apps could be impressive, but your typical company doesn't have those resources.
  • cottsak 7y ago
    There's such an "ego load" associated with this investment too. I find that even when a developer comes to realise that the SPA mess is largely unjustified, they're rarely willing to admit or change anything.
    • MattyRad 7y ago
      Agreed. It's very much a sunk cost/escalation of commitment fallacy. https://en.m.wikipedia.org/wiki/Escalation_of_commitment https://en.m.wikipedia.org/wiki/Escalation_of_commitment 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.
      • cottsak 7y ago
        That must be humbling. Props for identifying it and adjusting course tho.
• nojvek 7y ago
  This may get downvoted to oblivion due to the HN bias against js. 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.
  • yc12340 7y ago
    > Just stay in js land as a single page application and communicate with server purely in REST. 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.
  • fyfy18 7y ago
    It's two years later, and I'm still waiting for those improvements in Jira. Until then Jira is a great case study of how not to do things in JavaScript, it's slow, it's inconsistent and I doubt the accessibility is very good. (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)
    • jjcm 7y ago
      We're definitely very slow on load at Atlassian, but our accessibility is actually really good. One benefit of a good component library (in our case React) is it allows mapping of accessibility labels fairly easily. Jira should be fully navigable with just a keyboard and headphones.
  • klez 7y ago
    > This may get downvoted to oblivion due to the HN bias against js. 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.
• inian 7y ago
  Same thing happening on Github - https://www.youtube.com/watch?v=4zG0AZRZD6Q https://www.youtube.com/watch?v=4zG0AZRZD6Q https://jakearchibald.com/2016/fun-hacks-faster-content/ https://jakearchibald.com/2016/fun-hacks-faster-content/
• LoSboccacc 7y ago
  this is the first time I see mentions of react being difficult to optimize and I'd like to know more, is there any in depth quality article about it anybody knows on top of the usual light blogs a search finds?
  • iddan 7y ago
    No there isn’t because it’s BS. React is super easy to optimise. https://reactjs.org/docs/optimizing-performance.html https://reactjs.org/docs/optimizing-performance.html
    • csande17 7y ago
      People say React is easy to optimize, but many of the React apps I use in practice have crummy 50-100 millisecond response times on basic operations like "click button" or "press key in text field". And a significant portion of the performance difference between beta MDN and old MDN was the ~half second the React code took to run in the beta. I'm pretty sure front-end developers aren't writing slow code on purpose. The most reasonable explanation I can come up with is that React makes it easier to write reliable UI code but harder to reason about performance -- features like "by default, all of a component's descendants are recreated and diffed with the DOM on any state change" point strongly in this direction.
• madsbuch 7y ago
  In google maps, gmail, and other places (where data shared between pages generally is loaded) I am very content with client site navigation. As far as I see it really depends whether it is an app or a site that is being developed.
• buro9 7y ago
  I browse using Brave, with JavaScript disabled by default and full "shields up" on every site. Anecdotally I would say that 10% of the web is unusable, another 20% is barely usable... but to my utter surprise the other 70% is functional to some basic level. The one I am most impressed with is Amazon. I am not an Amazon fan at all, and try to avoid shopping there or using their services, but when I do happen to need something in a small quantity and fast Amazon are very good, and so when I visited recently it took me a while to comprehend that the site looked right, felt right, hadn't degraded the experience to any shocking degree, and was fully functional even without JavaScript and 3rd party cookies, etc. There is still a lot to be said for the very simple approach of make it all in HTML on the server first, and only use JavaScript to add small enrichments that can only be done in the client.
• smileysteve 7y ago
  We've also spent 10 years getting to the current state. Backbone was notoriously difficult to manage state in. AngularJs was quick to prototype (though often slower to develop in than HTML) but had massive memory leaks. Even modern Angular and React were new iterations that didn't solve the state problem well until Ngrx/Redux became mainstream.
• jbverschoor 7y ago
  It's funny, actually frustrating, that people create all these frameworks to mimic "native" looks and behavior. But there are soooooooooo many elements that are overlooked, and usually only tested on a few platforms. Don't you just love sites that capture your scrolling? Or buttons that have different hotspot areas or don't support canceling by dragging out of them?
• darkhorn 7y ago
  Client side navigation is for single page applications like applications written with ExtJS.
• barbarbar 7y ago
  Have just read this article again. The author has a very pleasant style of writing. Very good explanations and good reasoning in the conclusion. What could also be mentioned is the sideeffect from having n different proprietary "Routers" from different framework vendors as well as "code-splitting" and so on.
• syllable_studio 7y ago
  Page load speed is not the only reason why client-side rendering is important. When traditional server-side rendered pages need to update state on the page they have two choices: Use DOM manipulation or reload the entire page from the back-end just to update one small piece of the page. The more state that needs updating, the more complex it becomes to manage rendering on both the server and the client. Code redundancies creep in as html templates are duplicated on both sides. In my experience, as soon as a website has any app-like qualities at all, a tool like react just makes sense. It's a great tool that solves a very real problem. I always use universal rendering so that you get the best of both worlds and the page still renders fine for the no-js folks out there (respect).