5 ms·

Keep the majority of the rendering server side and it isn't a problem at all. Jquery for some UI enhancement.

by collyw 7y ago

benbristow 7y ago
Then you end up having the page refresh loads of times and having a less smooth experience.
- kickopotomus 7y ago
  There are ways around that. E.g. turbolinks[0]. [0]: https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
- collyw 7y ago
  All the SPA apps I have worked on have been significantly slower than the server side rendered apps I have written myself. Page refresh loads are rarely the problem, its usually a database issue, or just a shit load of API calls to load different menus that would be done in one call with server side rendering.
rmdashrfstar 7y ago
Why would I choose server side rendering? If I build the site in vue with the most optimized output settings, append hashes to files for perfect caching, drop the files in an S3 bucket, throw a CloudFront CDN on top of it with gzip compression, and build the front end of my backend as a REST api sitting in a lambda function that serves HTTPS requests, I never have to worry about server costs being more than pennies a month unless I need to add on other services to my backend.
- jng 7y ago
  Am I the only one to whom this description sounds like some version of hell?
  - Cyberdog 7y ago
    Not at all. Poe's Law is definitely in effect for that post.
  - kls 7y ago
    Having lived thru the hell of trying to deliver web apps via a thin client model I personally prefer rendering on the client for anything that is not a static web page intended for content only (which now days is rarely the case). Thin clients where an anti-pattern championed by the big server vendors, due to the need for big servers. At the time they where justifying the architecture based on the fact that PC hardware was expensive and thin clients would reduce the need for high end PC's. They where trying to sell it before the web, the web just gave them the vehicle to really push it. Those realities are gone and, decent power in pc's is a commodity. If the web where invented today, it would have been a mesh given the current realities of the proliferation of computing power. Unfortunately it has the law of inertia on it's side.
- debaserab2 7y ago
  Hosting a lambda based REST API is not "pennies a month" if your site gets any significant traffic at all.
  - diminoten 7y ago
    Dimes a month, then? It's not a business-relevant amount of money, is the point.
    - debaserab2 7y ago
      Lambda is great for infrequent, high CPU tasks such as batch processing. It isn't ideal for high frequency low CPU tasks like serving web requests. You'll pay a large percentage more doing it this way. Whether that extra expense is relevant to your business depends very much on your scale (or if you're sitting on a boatload of VC cash, I guess).
      - diminoten 7y ago
        How do you know what CPU my HTTP requests need?!
        debaserab2 7y ago
        If your HTTP requests are high CPU and your doing standard crud type actions, there's something wrong with your codebase. High CPU tasks should be offloaded from the HTTP request into a queue.
        diminoten 7y ago
        Who said I was doing standard CRUD, and it seems like now you're defining HTTP requests as low-CPU activities just to make Lambda not fit explicitly. Nothing wrong with doing high-CPU activity in a request/response cycle if it's consistent and timely.
        7y ago
- collyw 7y ago
  > Why would I choose server side rendering? Because you can build a site with around half of the code if you keep it server side.
CameronNemo 7y ago
Actually rendering is something that would be better suited for client side. You can cut down on message sizes if you just fetch JSON and a small templating engine.

Keep the majority of the rendering server side and it isn't a problem at all. Jquery for some UI enhancement.

by collyw 7y ago

Keep the majority of the rendering server side and it isn't a problem at all. Jquery for some UI enhancement.

benbristow 7y ago

Then you end up having the page refresh loads of times and having a less smooth experience.

kickopotomus 7y ago
There are ways around that. E.g. turbolinks[0]. [0]: https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
collyw 7y ago
All the SPA apps I have worked on have been significantly slower than the server side rendered apps I have written myself. Page refresh loads are rarely the problem, its usually a database issue, or just a shit load of API calls to load different menus that would be done in one call with server side rendering.

rmdashrfstar 7y ago

Why would I choose server side rendering? If I build the site in vue with the most optimized output settings, append hashes to files for perfect caching, drop the files in an S3 bucket, throw a CloudFront CDN on top of it with gzip compression, and build the front end of my backend as a REST api sitting in a lambda function that serves HTTPS requests, I never have to worry about server costs being more than pennies a month unless I need to add on other services to my backend.

jng 7y ago
Am I the only one to whom this description sounds like some version of hell?
- Cyberdog 7y ago
  Not at all. Poe's Law is definitely in effect for that post.
- kls 7y ago
  Having lived thru the hell of trying to deliver web apps via a thin client model I personally prefer rendering on the client for anything that is not a static web page intended for content only (which now days is rarely the case). Thin clients where an anti-pattern championed by the big server vendors, due to the need for big servers. At the time they where justifying the architecture based on the fact that PC hardware was expensive and thin clients would reduce the need for high end PC's. They where trying to sell it before the web, the web just gave them the vehicle to really push it. Those realities are gone and, decent power in pc's is a commodity. If the web where invented today, it would have been a mesh given the current realities of the proliferation of computing power. Unfortunately it has the law of inertia on it's side.
debaserab2 7y ago
Hosting a lambda based REST API is not "pennies a month" if your site gets any significant traffic at all.
- diminoten 7y ago
  Dimes a month, then? It's not a business-relevant amount of money, is the point.
  - debaserab2 7y ago
    Lambda is great for infrequent, high CPU tasks such as batch processing. It isn't ideal for high frequency low CPU tasks like serving web requests. You'll pay a large percentage more doing it this way. Whether that extra expense is relevant to your business depends very much on your scale (or if you're sitting on a boatload of VC cash, I guess).
    - diminoten 7y ago
      How do you know what CPU my HTTP requests need?!
      - debaserab2 7y ago
        If your HTTP requests are high CPU and your doing standard crud type actions, there's something wrong with your codebase. High CPU tasks should be offloaded from the HTTP request into a queue.
        diminoten 7y ago
        Who said I was doing standard CRUD, and it seems like now you're defining HTTP requests as low-CPU activities just to make Lambda not fit explicitly. Nothing wrong with doing high-CPU activity in a request/response cycle if it's consistent and timely.
        7y ago
collyw 7y ago
> Why would I choose server side rendering? Because you can build a site with around half of the code if you keep it server side.

CameronNemo 7y ago

Actually rendering is something that would be better suited for client side. You can cut down on message sizes if you just fetch JSON and a small templating engine.