5 ms·

"Server rendering is not about SEO, it's about performance. Consider the additional roundtrips to get scripts, styles, and subsequent API requests. In the futur

• TazeTSchnitzel 12y ago
  It's not faster on a mobile device. A pre-rendered page loads quicker.
• ProCynic 12y ago
  Just anecdotally, I've found that the second round trip overwhelms any performance gains from not rendering on the server, especially if you have to boot up a heavy framework such as e.g. angular before even starting it. The isomorphic model is that the first page load happens on the server (1 round trip), and that any additional page loads hit the api directly and re-render the page in the browser (also 1 round trip).
• ssmoot 12y ago
  JSON is just banging strings together on the server side. Rendering HTML on the server side is just banging (somewhat bigger) strings together. JSON has lighter-weight transfer than HTML, but after compression the real-world impact is probably pretty marginal. Say the JSON request was 50% fewer bytes though. It's probably only 20% faster to generate server-side (WAG). If TTFB is 50ms for HTML, maybe it's 40ms for JSON then. But then you render the HTML with a very fast renderer, while you must first parse the JSON into a JavaScript object. Then you create HTML elements paying most of the same rendering costs. If your requests are fairly small and update only a small portion of the page, maybe the JSON is faster. I think you could consider this the "traditional" use-case for AJAX. The JSON isn't really the important part there. If your requests are large, then it's probably much quicker to deliver HTML, and outright skip the interim parsing/programatic-markup-construction penalty. IME. Which seems to be the strategy of sites like Twitter. I think that's a much simpler to reason about and execute solution as well. My theory is that the only way that formula really swings in favor of JS, SPA, etc is if your application is a platform for multiple clients, wether that's businesses or end-points (JS/SPA, iOS, Android, etc), so you get a lot of mileage out of your API. But there's no scenario in which that's the _simpler_ overall solution I think. Though you might get benefits from teams dedicated to each platform, allowing them to ignore the complexities of the API, simplifying their individual domains overall. Which seems like a balancing act I suppose. But circling back around to your comment, for the majority of platforms, rendering on the server allows you to write less code, and burn fewer total CPU cycles to render a request. If, like me, your typical applications are business oriented content-management or reporting based. I think XML makes more sense than JSON for data transport in most cases. Richer types (you can actually represent Dates for example), faster transformations, you get to avoid programmatic generation and slow client-side templating. OTOH if your responses are messages instead of data, and you're going to be handling them programmatically anyway, it's hard to beat the convenience of JSON. /end-rambling
  • RussianCow 12y ago
    >If your requests are large, then it's probably much quicker to deliver HTML, and outright skip the interim parsing/programatic-markup-construction penalty. The problem is you can't easily send HTML to update many parts of the page. For instance, if you have messages as part of your app, but there are multiple ways to read a message, you have to make sure all of those are updated when you read one. It's WAY easier to just have the client know what to update and do that automatically, rather than having the server send several bits of HTML. There's also the fact that you don't have to wait for a response from the server before updating the app, so you can see the result of reading a message instantly (which becomes really important on high-latency connections like 3G). So it certainly depends on your use case, but I think letting the client handle templating/HTML generation is a much better default than the server sending bits of HTML. In my experience, the cost of HTML generation in React.js is pretty minimal. And with React allowing server-side rendering, there really aren't that many drawbacks.
    • ssmoot 12y ago
      I'm definitely interested in playing with React. My Angular experience was pretty painful. If I can summarize your point: Data-binding can simplify complex pages. That can be true. I do think most page interactions for most websites don't come close to approaching that level of complexity however. And even then, a helper-function that takes one message and performs multiple assignments can be simpler to write, simpler to understand and simpler to maintain. You still have to explicitly bind the data after all. If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective. You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc. I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc). From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. Where you can probably put a 2-year expiration date on any project targeting most of the handful of popular JavaScript MVC frameworks. Trying to predict which one is going to go the distance, not replace major components in that time, and provide a smooth, relatively painless upgrade path is probably futile I'd guess.
• albemuth 12y ago
  Dion Almaer tweeted a video comparison using a 3g-throttled connection: https://twitter.com/dalmaer/status/538906815010836480 https://twitter.com/dalmaer/status/538906815010836480