6 ms·

Try build a complex website with complex journeys and a component architecture and you'll be begging for React. It's probably because you haven't seen the ligh

Try build a complex website with complex journeys and a component architecture and you'll be begging for React. It's probably because you haven't seen the light. I'd never ever go back to using jQuery unless it was for a basic marketing site - even then I'd probably think of using Vue if anything got more complex than a carousel on the page.

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).
- 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.
debaserab2 7y ago
I bet your marketing manager will be pleased when her website gets de-ranked on Google because all the page rendering is done client side now.
- benbristow 7y ago
  Google's spider renders JavaScript now. https://developers.google.com/search/docs/guides/javascript-seo-basics https://developers.google.com/search/docs/guides/javascript-...
  - debaserab2 7y ago
    That doesn't mean it gets indexed the same. Consuming an SPA with rich UI interactions is much different than consuming a hypertext document that provides a conventional structure for content. SPA's like to do things such as introducing custom routing systems that hijack hyperlinks and simulate browser events through javascript. I'd be very skeptical that you'll end up with a result that's the same as plain old server side rendering.

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

debaserab2 7y ago

I bet your marketing manager will be pleased when her website gets de-ranked on Google because all the page rendering is done client side now.

benbristow 7y ago
Google's spider renders JavaScript now. https://developers.google.com/search/docs/guides/javascript-seo-basics https://developers.google.com/search/docs/guides/javascript-...
- debaserab2 7y ago
  That doesn't mean it gets indexed the same. Consuming an SPA with rich UI interactions is much different than consuming a hypertext document that provides a conventional structure for content. SPA's like to do things such as introducing custom routing systems that hijack hyperlinks and simulate browser events through javascript. I'd be very skeptical that you'll end up with a result that's the same as plain old server side rendering.