Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


Am I the only one to whom this description sounds like some version of hell?


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.


Not at all. Poe's Law is definitely in effect for that post.


Hosting a lambda based REST API is not "pennies a month" if your site gets any significant traffic at all.


Dimes a month, then? It's not a business-relevant amount of money, is the point.


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


How do you know what CPU my HTTP requests need?!


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.


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.


Sounds like in your case lambda might be a good fit? I'm not really sure because you're not really explaining your use case.

For the vast majority of crud based web apps that I've seen or worked on in the last decade, lambda would not have been a good fit. There's a lot of people drinking the serverless koolaid right now and applying it to scenarios that don't fit it well.


Just sounds like you're drinking the same koolaid, just the opposite flavor.

Have you actually built a lambda backed web service? Guessing no, or you'd know better than to complain about price. Plenty of better arguments to be had than the one lambda actually does decently on...


Yes, I have written lambda functions. In our case it was very cost effective because it was a batch processing job that was relatively infrequently accessed.

I'm not drinking any kool-aid, I've just broken down the math to see what it would actually cost. You can too if you know what your traffic looks like.

https://blog.binaris.com/lambda-pricing-pitfalls/


"Would" is not a phrase you'd use if you've actually written lambda functions the way we're talking about.

I have. It's pennies, literal pennies. None of those pitfalls actually end up adding up to more than pennies, everything there is entirely theoretical and does not actualize with substantial consequence, in my experience.


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


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


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.


There are ways around that. E.g. turbolinks[0].

[0]: https://github.com/turbolinks/turbolinks


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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: