4 ms·

The irony is that because of the lean structure behind the server, this forum actually responds faster than most webfora that do use AJAX/SPA. Funny given that

The irony is that because of the lean structure behind the server, this forum actually responds faster than most webfora that do use AJAX/SPA. Funny given that the whole purpose of AJAX/SPA was to reduce response time. That's it's reason for existing. Turns out it just complicates things ...

hasenj 9y ago
When you say "irony", are you genuinely surprised by this?
- flukus 9y ago
  No, but I've seen comments on here from people under the impression that rendering on the client is a more efficient use of CPU, or that rendering a page in HTML is significantly more resource intensive than rendering the data in json. There is a generation out there that doesn't seem to know that server side rendering exists.
  - laumars 9y ago
    The benefits from client side Vs server side are really a matter of scale. If you're running a personal forum / whatever then you're not going to notice a whole lot. But when you start having several hundred thousand or more concurrent users then being able to cache your pages in a CDN and only generating JSON responses via APIs really can have a profound impact on your server side resources.
    - techdragon 9y ago
      You can cache server rendered pages in a CDN or Varnish or whatever you like, and there's also the use of the proper http headers to drive client side cache control. All of this works for server side rendered content.
      - laumars 9y ago
        Obviously there are a great many layers to caching (there's a whole multitude of other solutions out there that you've also missed off :p). However with regards to the specific points you've raised: 1) You cannot cache server rendered pages in a CDN (see footnote) if those pages contain user specific information (like this topic does). Information such as a user name, message read status - even on public messages, etc. If you do CDN cache those pages you'll leak user-specific information to other users. This is why you need tools like Varnish that cache page fragments rather than whole pages; or why you serve up HTML templates and then populate user information on the client side via RESTful API calls. 2) For similar reasons as above and again very relevant to the project in this discussion, HTTP Cache-Control headers also wouldn't help with the HTML if your backend is generating the HTML. In fact in those instances you'd probably want to set your max-age to 0 (again, speaking strictly about dynamically generated HTML. Static assets like JS, CSS, and images are a different matter but they're not server generated dynamic content). Granted with browser caching there isn't the risk of leaking user information to other users; the risk is just the browser not fetching an updated forum view / whatever. Caching is one of those things that are easy to set up but also very easy to get wrong. Footnote: Akamai might support it - if you're willing to pay their premium - as it's an immensely sophisticated product. However it's not an option I've seen when using Akamai and the other solutions I've used definitely don't support caching page fragments.
        candiodari 9y ago
        1) nor can you cache client-side rendered pages in a CDN ... you can only cache EMPTY information-free pages in a CDN 2) Agreed, but again, same problem as one Truth of the matter: Javascript rendered pages 1) request(s) for the page 2) response for the page 3) at least one AJAX request (in practice: dozens) (cannot be akamai'ed) 4) waiting for all responses Server side rendering without AJAX 1) request page 2) respond to page Seems to me server side rendering is guaranteed to be faster, if you count the full cycle. But sure, with AJAX you can show your logo faster. With server side rendering only you can show the actual data people are looking for faster.
        9y ago
  - zaarn 9y ago
    >There is a generation out there that doesn't seem to know that server side rendering exists. Oh, don't worry, they're reinventing it in JS. I've had a recent project proposal and one of the engineers said that to make the webpage faster we could prerender the pages on the server side with JS. Like, at that point, you're just using PHP with a different name and worse performance (a small 4$ shared hoster can easily handle 1M users per month, I've yet to see a NodeJS app handle 1M users per month on a 5$ VPS without problems)
    - aaron-lebo 9y ago
      Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? You're comparing different things. Also, JS performs as well or better than PHP. Not sure why you guys get so ideological about this.
      - zaarn 9y ago
        >Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? Tbh, I'm not really interested. I can squeeze amazing performance out of a 10kB self-written JS library with noscript fallbacks than most JS-heavy apps out there. The sites I develop work with dialup connections or worse. Because my phone regularly has only such a connection. Modern JS apps are a pain to use under such conditions, I've not noticed much difference between prerendered JS and unprerendered JS, it's both crap under these conditions. On the other hand, Orange Forum loaded almost instantly (less than 10 seconds) on a crappy GPRS 16kbps connection. Discourse or NodeBB don't load at all and if I'm lucky enough I might see some error message or crapped out webpage. >Also, JS performs as well or better than PHP. Not sure why you guys get so ideological about this. I have only ever seen evidence of the contrary. I can run a 1M user/month website with 128MB of RAM on a shared hoster using PHP. If you get a good shared hosters you can probably hit 10M user/month. I have not seend a nodejs app that can handle 1M user/month on a 5$ VPS, which has 512MB RAM and probably more CPU and disk than the shared hoster offering. But I'm willing to rethink this if I see real world evidence that a comparable software set runs better and more efficiently in JS than PHP. I won't consider synthetic benchmarks since those rarely model real world usage and comparable means the software must be usuable with and without JS on the client enabled.
  - pjmlp 9y ago
    Which is why I never bought into the JS framework fad of the month and keep happily using .NET/Java stacks with server side rendering and minimal JavaScript. We should make the best use of pure HTML/CSS web pages, that is what the web was made for. For anything else, better go native with Web APIs.
aaron-lebo 9y ago
Turns out it just complicates things ... No, a good car is not evidence that the plane just complicates things, it's evidence that you've got a good car.
- dullgiulio 9y ago
  We should be arguing that most people use cars and don't need to take the plane for some simple CRUD apps...
elnygren 9y ago
I think what you say makes no sense at all. The idea of AJAX/SPA was to provide interactivity and a less technical UI that caters to the average Joe. AJAX/SPA moves some of the computation from the backend to the frontend so the service scales better for millions of users. This forum is not going to be fast for millions of users (it might not even be for hundreds of simultaneous users) because the server has to render everything again for everyone. Server side rendering is good for response times, that's why the SPA world went back to it (Google: react ssr). SPA is good for scalability and average Joe UI. ...and AJAX is there so we don't need to do a full page reload all the time. Again, not because of response times.
- dullgiulio 9y ago
  If it were to scale to millions of users, caching would help. At that point, you'd have to cache the JSON responses just the same, so the complexity of cache invalidation would be there in the exact same way. But you would still not have the additional load and bloat on the user browser.
  - elnygren 9y ago
    You are correct; caching is always hard. Load and bloat? Well that depends. If you're doing a realtime collaborative texteditor with a realtime chat, I just don't see how you'd get anything even remotely nice without what you call "load and bloat". However, to return to the original topic. Which is simpler: a) creating a performant data API b) creating a performant server that handles data stuff just like a) AND all the rendering & UI stuff Surely the latter is more complex since it has more responsibilities?
- combatentropy 9y ago
  > AJAX/SPA was to provide [...] a less technical UI I hadn't heard that reason before. Can you please talk more about this? > This forum is not going to be fast for millions of users (it might not even be for hundreds of simultaneous users) because the server has to render everything again for everyone. This theory doesn't match reality. In reality, multipage applications are faster than single-page ones. In fact, most things on the internet still are multipage, including web forums. Most web forums are powered by PHPBB, a multipage web app, and they were powered by PHPBB 15 years ago, when hardware and PHP were much slower. This very site is a multipage web app, and it holds up just fine, even though it has enough users to bring down other websites. Single-page applications seemed like they would be faster, but usually they aren't. First, let's look closer at a multipage application. All of the scripts, styles, and images should be cached after loading the first page, if you set the headers right (the Expires header, mainly). Therefore, what is left? The content. And I have found that the size of the HTML content is often close to the size of the same thing in JSON --- at least the way I write HTML (I try to keep it lean. Few classes, extraneous divs, etc.). This is because JSON has all those keys: { "color": "red" } while HTML has just the values: <div>red</div> That was a simple example, but I measured a bigger one, and the size turned out to be about the same, especially after compression. All of those HTML tags compress well, because of repetition. Now if they are the same size, then they should load in the same time. Except they don't. The server-rendered page loads faster. Why? Because of progressive rendering. When just some of the HTML has come down the pipe, the page appears. But with AJAX, all of the JSON must first load, then be parsed, then wrapped in a template, then inserted into the DOM. Then it appears all at once.
foxhop 9y ago
From what I recall AJAX wasn't for making things faster or for scaling like other siblings posts describe. How I remember it, it was created for user experience reason. Not having to submit a form and refresh the entire page and cause the page to bounce back to the top of the page, etc. AJAX (at least when I learned and implemented it) was for updating the user about an action they performed without refreshing the entire universe in front of their eyes, only updating the contents of a div or something else. The whole web app as a javascript app.js blob idea took the AJAX idea to an extreme. In this extreme it often does slow down page load speeds and negatively effect the user experience when Javascript doesn't work, for whatever reason.

hasenj 9y ago

When you say "irony", are you genuinely surprised by this?

flukus 9y ago
No, but I've seen comments on here from people under the impression that rendering on the client is a more efficient use of CPU, or that rendering a page in HTML is significantly more resource intensive than rendering the data in json. There is a generation out there that doesn't seem to know that server side rendering exists.
- laumars 9y ago
  The benefits from client side Vs server side are really a matter of scale. If you're running a personal forum / whatever then you're not going to notice a whole lot. But when you start having several hundred thousand or more concurrent users then being able to cache your pages in a CDN and only generating JSON responses via APIs really can have a profound impact on your server side resources.
  - techdragon 9y ago
    You can cache server rendered pages in a CDN or Varnish or whatever you like, and there's also the use of the proper http headers to drive client side cache control. All of this works for server side rendered content.
    - laumars 9y ago
      Obviously there are a great many layers to caching (there's a whole multitude of other solutions out there that you've also missed off :p). However with regards to the specific points you've raised: 1) You cannot cache server rendered pages in a CDN (see footnote) if those pages contain user specific information (like this topic does). Information such as a user name, message read status - even on public messages, etc. If you do CDN cache those pages you'll leak user-specific information to other users. This is why you need tools like Varnish that cache page fragments rather than whole pages; or why you serve up HTML templates and then populate user information on the client side via RESTful API calls. 2) For similar reasons as above and again very relevant to the project in this discussion, HTTP Cache-Control headers also wouldn't help with the HTML if your backend is generating the HTML. In fact in those instances you'd probably want to set your max-age to 0 (again, speaking strictly about dynamically generated HTML. Static assets like JS, CSS, and images are a different matter but they're not server generated dynamic content). Granted with browser caching there isn't the risk of leaking user information to other users; the risk is just the browser not fetching an updated forum view / whatever. Caching is one of those things that are easy to set up but also very easy to get wrong. Footnote: Akamai might support it - if you're willing to pay their premium - as it's an immensely sophisticated product. However it's not an option I've seen when using Akamai and the other solutions I've used definitely don't support caching page fragments.
      - candiodari 9y ago
        1) nor can you cache client-side rendered pages in a CDN ... you can only cache EMPTY information-free pages in a CDN 2) Agreed, but again, same problem as one Truth of the matter: Javascript rendered pages 1) request(s) for the page 2) response for the page 3) at least one AJAX request (in practice: dozens) (cannot be akamai'ed) 4) waiting for all responses Server side rendering without AJAX 1) request page 2) respond to page Seems to me server side rendering is guaranteed to be faster, if you count the full cycle. But sure, with AJAX you can show your logo faster. With server side rendering only you can show the actual data people are looking for faster.
        9y ago
- zaarn 9y ago
  >There is a generation out there that doesn't seem to know that server side rendering exists. Oh, don't worry, they're reinventing it in JS. I've had a recent project proposal and one of the engineers said that to make the webpage faster we could prerender the pages on the server side with JS. Like, at that point, you're just using PHP with a different name and worse performance (a small 4$ shared hoster can easily handle 1M users per month, I've yet to see a NodeJS app handle 1M users per month on a 5$ VPS without problems)
  - aaron-lebo 9y ago
    Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? You're comparing different things. Also, JS performs as well or better than PHP. Not sure why you guys get so ideological about this.
    - zaarn 9y ago
      >Do you get why you'd prerender a JS app and why an isomorphic setup is fundamentally different than server side rendering with PHP? Tbh, I'm not really interested. I can squeeze amazing performance out of a 10kB self-written JS library with noscript fallbacks than most JS-heavy apps out there. The sites I develop work with dialup connections or worse. Because my phone regularly has only such a connection. Modern JS apps are a pain to use under such conditions, I've not noticed much difference between prerendered JS and unprerendered JS, it's both crap under these conditions. On the other hand, Orange Forum loaded almost instantly (less than 10 seconds) on a crappy GPRS 16kbps connection. Discourse or NodeBB don't load at all and if I'm lucky enough I might see some error message or crapped out webpage. >Also, JS performs as well or better than PHP. Not sure why you guys get so ideological about this. I have only ever seen evidence of the contrary. I can run a 1M user/month website with 128MB of RAM on a shared hoster using PHP. If you get a good shared hosters you can probably hit 10M user/month. I have not seend a nodejs app that can handle 1M user/month on a 5$ VPS, which has 512MB RAM and probably more CPU and disk than the shared hoster offering. But I'm willing to rethink this if I see real world evidence that a comparable software set runs better and more efficiently in JS than PHP. I won't consider synthetic benchmarks since those rarely model real world usage and comparable means the software must be usuable with and without JS on the client enabled.
- pjmlp 9y ago
  Which is why I never bought into the JS framework fad of the month and keep happily using .NET/Java stacks with server side rendering and minimal JavaScript. We should make the best use of pure HTML/CSS web pages, that is what the web was made for. For anything else, better go native with Web APIs.

aaron-lebo 9y ago

Turns out it just complicates things ... No, a good car is not evidence that the plane just complicates things, it's evidence that you've got a good car.

dullgiulio 9y ago
We should be arguing that most people use cars and don't need to take the plane for some simple CRUD apps...

elnygren 9y ago

I think what you say makes no sense at all. The idea of AJAX/SPA was to provide interactivity and a less technical UI that caters to the average Joe. AJAX/SPA moves some of the computation from the backend to the frontend so the service scales better for millions of users. This forum is not going to be fast for millions of users (it might not even be for hundreds of simultaneous users) because the server has to render everything again for everyone. Server side rendering is good for response times, that's why the SPA world went back to it (Google: react ssr). SPA is good for scalability and average Joe UI. ...and AJAX is there so we don't need to do a full page reload all the time. Again, not because of response times.

dullgiulio 9y ago
If it were to scale to millions of users, caching would help. At that point, you'd have to cache the JSON responses just the same, so the complexity of cache invalidation would be there in the exact same way. But you would still not have the additional load and bloat on the user browser.
- elnygren 9y ago
  You are correct; caching is always hard. Load and bloat? Well that depends. If you're doing a realtime collaborative texteditor with a realtime chat, I just don't see how you'd get anything even remotely nice without what you call "load and bloat". However, to return to the original topic. Which is simpler: a) creating a performant data API b) creating a performant server that handles data stuff just like a) AND all the rendering & UI stuff Surely the latter is more complex since it has more responsibilities?
combatentropy 9y ago
> AJAX/SPA was to provide [...] a less technical UI I hadn't heard that reason before. Can you please talk more about this? > This forum is not going to be fast for millions of users (it might not even be for hundreds of simultaneous users) because the server has to render everything again for everyone. This theory doesn't match reality. In reality, multipage applications are faster than single-page ones. In fact, most things on the internet still are multipage, including web forums. Most web forums are powered by PHPBB, a multipage web app, and they were powered by PHPBB 15 years ago, when hardware and PHP were much slower. This very site is a multipage web app, and it holds up just fine, even though it has enough users to bring down other websites. Single-page applications seemed like they would be faster, but usually they aren't. First, let's look closer at a multipage application. All of the scripts, styles, and images should be cached after loading the first page, if you set the headers right (the Expires header, mainly). Therefore, what is left? The content. And I have found that the size of the HTML content is often close to the size of the same thing in JSON --- at least the way I write HTML (I try to keep it lean. Few classes, extraneous divs, etc.). This is because JSON has all those keys: { "color": "red" } while HTML has just the values: <div>red</div> That was a simple example, but I measured a bigger one, and the size turned out to be about the same, especially after compression. All of those HTML tags compress well, because of repetition. Now if they are the same size, then they should load in the same time. Except they don't. The server-rendered page loads faster. Why? Because of progressive rendering. When just some of the HTML has come down the pipe, the page appears. But with AJAX, all of the JSON must first load, then be parsed, then wrapped in a template, then inserted into the DOM. Then it appears all at once.

foxhop 9y ago

From what I recall AJAX wasn't for making things faster or for scaling like other siblings posts describe. How I remember it, it was created for user experience reason. Not having to submit a form and refresh the entire page and cause the page to bounce back to the top of the page, etc. AJAX (at least when I learned and implemented it) was for updating the user about an action they performed without refreshing the entire universe in front of their eyes, only updating the contents of a div or something else. The whole web app as a javascript app.js blob idea took the AJAX idea to an extreme. In this extreme it often does slow down page load speeds and negatively effect the user experience when Javascript doesn't work, for whatever reason.