[HN Gopher] The absurd complexity of server-side rendering
___________________________________________________________________
The absurd complexity of server-side rendering
Author : takiwatanga
Score : 66 points
Date : 2022-04-19 19:30 UTC (3 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| bob1029 wrote:
| I've been saying it for years - the hard part is not "server
| side" vs "client side", it's making sure the state stays
| consistent between those 2 buckets.
|
| If you want to remove the hell from your life, you need to be all
| in on one or the other.
|
| For us, we've been keeping all state server-side using things
| like Blazor and hand-rolled js-over-websocket UI frameworks. We
| never have to worry about more than ~10k users, so this works out
| great for us.
|
| If we were webscale, we'd have to consider client side options.
| jamal-kumar wrote:
| Even in smaller applications this is incredibly relevant.
|
| I've recently written something that's meant to interface on a
| local area network, just controlling something on another
| computer, literally just one or two users at a time -- thing is
| the precision of floating points are a big thing here, and we
| have to consider that. So all of the bignum stuff had to stay
| server-side in C++ after much messing around doing math client
| side in javascript only to learn the hard way how completely
| broken that is. Fun fact - You can't maintain state when floats
| start to drift off of values they were supposed to land on due
| to javascript's crappy math libs
| [deleted]
| e67f70028a46fba wrote:
| throw all that complicated stuff away & use htmx
|
| generate html the same ol' way you always have
|
| safe & effective modern hypermedia
| donatj wrote:
| Call me old fashioned, but PHP still gets the job done better
| than just about anything else.
| pphysch wrote:
| And usually leads to a BBOM architecture
| metadat wrote:
| For the uninitiated, BBOM = Big Ball Of Mud.
| gmfawcett wrote:
| I have colleagues using Laravel, and there's nothing muddy-
| ball about their apps at all. Their code is tidy, modern,
| readable, and clearly maintainable.
|
| In terms of practical effect, frameworks influence developers
| more than languages do.
| eurasiantiger wrote:
| This was my PHP experience with CodeIgniter 15 years ago.
| Nothing new under the sun.
| codedokode wrote:
| This is not true. If you need 1000 lines of templates to
| display a page, it will be 1000 lines no matter whether you
| use Twig (PHP) or React (JS). And Twig in my opinion looks
| better than JS code mixed with HTML tags and split into 100
| files 10 lines each.
| marcosdumay wrote:
| Hum... You mean JS needs generic monads?
|
| TypeScript supports them, doesn't it? This shouldn't be too hard
| to fix, but it's a matter of rewriting or encapsulating all of
| the core language's API.
| epolanski wrote:
| What does any of the gist has to do with monads.
| boloust wrote:
| Principled, explicit handling of various function colours.
|
| If implemented like Fantasyland, probably a terrible idea.
| stevebmark wrote:
| In Javascript SSR, if you need the same logic on the client and
| server, define an API module + interface. Make a different API
| bundle on the server that calls NodeJS functions, file reads,
| whatever, directly. Make an API bundle on the client that makes
| AJAX requests to your API endpoints. Now your Javascript can call
| the same `api.fetchWhatever()` method, and await the result, and
| it works on the client and server (if you need it). It's a very
| nice pattern.
| epolanski wrote:
| Thus, you are confirming there is a hugh level of complexity.
|
| I want to add something else on top of what's in that gist: ssr
| is slow, rendering an application twice (on server and client)
| is just slow.
|
| We only do that for cache and seo, every other page suffers.
| kodah wrote:
| I already know I'm off my rocker (and my lawn with that phrasing)
| but I really wish the browser supported Python as a language
| instead of Javascript. I can pickle Python, send it to a client,
| and run it. Combine that with everything else Python 3 has
| brought to the table and I'd have a language that runs client
| side that I can depend on and that I love.
| jvanderbot wrote:
| I opened this thinking it would lament the challenges of server
| side frameworks and templating.
|
| But those things seem so, _so_ sane and simple compared to the
| mess I just read about. It 's worse than I could have imagined.
|
| Who thinks that's a good workable solution? Who's idea was this?
| pphysch wrote:
| Adtech needs a lot of JS to work. JS to determine how long they
| are hovering over this and that element, how long this or that
| ad is in their view, and so on and so forth.
|
| The logical conclusion is that every single HTML element needs
| to be wrapped in a bit of JS somewhere. Nothing should happen
| in the users browser that can't be monitored by JS.
| giantrobot wrote:
| Adtech _wants_ that JavaScript. It doesn 't necessarily
| _need_ it. Most of the metrics generated are ultimately
| worthless. They exist to slap together bullshit graphs to
| overwhelm clients with "data".
| gfodor wrote:
| Phoenix LiveView provides a sane solution to this problem.
| 65 wrote:
| I've been testing out Alpine.js recently and find it to be very
| nice to use. You can have reactive state and most of the
| conveniences of React, but all in your HTML without a build step.
|
| I work with SSR React professionally and many times I yearn for
| being able to just use good old fashioned templating engines and
| client side Javascript - no builds or anything.
| Daishiman wrote:
| The complexity of web development frontend itself is just absurd.
| The mess of dependencies, the mess of language transpiling,
| opaque abstract functions with unreadable call stacks, asset
| management, sync vs async, the random best practice of the week,
| etc.
|
| I look at the state of web pages and apps and it's not even for
| the betterment of user experience! Hacker News and old.reddit.com
| still provide the smoothest, fastest experience at the cost of
| having to zoom in every once in a while, but the price is worth
| it.
| atoav wrote:
| I handwrite all my CSS directly in the browser and the only
| "dependency" I use is a reset.css. The zooming issues some of
| those old themes have can all be solved with a modern css grid
| template (one for smartphone, one for desktop). Needless to say
| sites like these can be blazing fast.
|
| I only use js for small things like maybe hiding some header
| when scrolling down (no jquery, handwritten vanilla js with
| maybe 20 linws of code), but even that would not be strictly
| needed.
| kingcharles wrote:
| And even CSS resets are getting close to zero these days.
| robertoandred wrote:
| I take it you haven't taken a look at backend lately. Vagrant?
| Or Docker? Composer? Maybe Drush. Will this plugin break? Is it
| even still actively maintained? Which database? Are we still on
| the NoSQL fad? Maria, or postgres or mysql? And does my
| production host support my language version, and oh god another
| php vulnerability
| gmfawcett wrote:
| There's maybe two of those questions that you _actually_ have
| to care about as an architect. Nobody 's forcing you to chase
| fashions except you.
| yen223 wrote:
| Frontend folks have an excuse. They cannot avoid using
| JavaScript, since they're limited by what browsers support.
|
| Backend developers _chose_ to write mountains of yaml
| richwater wrote:
| I recall a couple of years ago when Kubernetes was all the
| rage and jesus christ the amount of YAML was unbelievable.
| qpiox wrote:
| I am a proponent of server-side, use Apache Tapestry for
| most production apps and have only one yaml file in all the
| projects.
| yoyohello13 wrote:
| My org just bought a professional bootstrap template. It takes
| 3 build tools and 1500 node packages just to build the SASS
| into a CSS bundle. It boggles my mind that this is normal in
| the front end world.
| ushakov wrote:
| only 1500? you got lucky!
|
| gatsbyjs (React framework) has so many dependencies it breaks
| GitHub's dependency graph
|
| https://github.com/gatsbyjs/gatsby/network/dependencies
| icedchai wrote:
| I ripped out one dependency, and it dropped build times in a
| recent project by an entire minute! Turns out that one
| dependency had 100's of megs in transitive dependencies...
| phist_mcgee wrote:
| I wouldn't exactly call clicking on the 'reply' button, and
| loading a brand new webpage, typing this comment, pressing the
| 'reply' button again, and then getting sent back to the
| original webpage 'smooth'.
| thyrox wrote:
| Laravel livewire / Phoenix liveview and a lot of new frameworks
| are now focusing on bridging this gap between ssr and clientside
| - almost trying to make it seamless.
|
| Though only time will tell, what can of worms that will open
| later.
| Animats wrote:
| This isn't real "server side rendering". This is just generating
| simpler HTML. Real rendering on the server would mean sending a
| canvas or an image or video, like "cloud gaming".
|
| All this complexity seldom translates into sites that do much.
| There are real "applications in the browser" that let the user do
| something, but those are rare, and most are toys. Most of them
| could have been written in Flash, anyway.
| codedokode wrote:
| There are cases when server-side rendering (without SPA) is
| easier and faster. For example: documentation sites, blog-like
| sites, internet stores, sites like Hacker News. In all these
| cases, you can save on development time by writing just one
| application instead of two (server and client), and improve
| performance (no need to load multimegabyte JS applications and
| make multiple AJAX requests to display a page).
|
| Of course, there are cases when SPA-style application is better,
| for example: (graphic/circuit/text) editors, IDEs, mobile
| newsfeed-based apps - everything that resembles an app rather
| than a page with text, menus and images. But in these cases you
| usually don't need server-side rendering. And sometimes you
| cannot even use it - for example, if your code needs to know
| browser windows size to arrange objects on the page.
|
| So I think that SSR (running JS on server) is rarely useful.
| paxys wrote:
| The common mistake teams make getting started with server-side
| rendering for React is thinking that your _entire_ backend has to
| be contained in a single JavaScript bundle. Instead, use any
| language you want to set up your APIs and business logic. Then
| set up a fully independent pool of servers running Node.js whose
| only job is SSR. This setup skips over every problem the author
| mentions.
| kraig911 wrote:
| I gave it a shot at one startup using next.js that wanted to pre-
| hydrate redux state, but also use tracking with session cookies
| et al the regular bag of beans. I spent maybe 6 weeks on it and
| basically I grew to realize I was in a miasma of pain. I didn't
| last much longer. I could've wrote the entire thing just vanilla
| js/css in probably a weekend...
|
| So I can commiserate with this.
| jamal-kumar wrote:
| I love starting off projects in vanilla JS because they
| actually get to a workable state most of the time without a lot
| of effort. Most of the time when you write stuff in vanilla
| js/ts you can just fit that logic in to a react or vue or
| whatever application framework afterwards if you really need
| all those bells and whistles.
|
| I think a lot of people start things off thinking they NEED to
| have all the authentication, cookies etc sorted out from the
| get go when really you just need your ideas in a working form
| first and stuff like HTTP basic auth is mighty fine for
| development
| Rauchg wrote:
| Since the post mentions Next.js, it's worth calling out two
| streams of ongoing work that solve major painpoints of SSR:
|
| 1. A filesystem convention (`*.server.ts`) for more cleanly
| separating client and server component trees
|
| 2. The introduction of a Web standards runtime[1] for SSR.
|
| If anything, we're entering the best generation of SSR ever.
| We'll see new generations of apps shipping less JS to the client,
| rendering and personalizing at the Edge, closer to the user, and
| the infrastructure to support this will be serverless and
| economically every efficient.
|
| [1] https://nextjs.org/docs/api-reference/edge-runtime
| nawgz wrote:
| Is it believed that you'll do less overall compute and
| bandwidth if you use serverless functions to execute (parts of
| your) client, in place of sending static bundles to the client
| and letting them execute it?
|
| I don't really get SSR. Isn't it more desirable to have more of
| the compute required to render the client done by the client
| machinery? I view this both as true in corporate and public web
| scenarios, surely it's cheaper to let the public render the SPA
| than it is to render it for them, surely in corporate this
| takes better advantage of already purchased machines with
| already installed programs instead of developer cycles wasted
| to recreate it, and surely it's better to have less server load
| and deployment complexity in both cases
| stickfigure wrote:
| SSR feels like an echo of JSF (that's JavaServer Faces for you
| youngins) - an exceptionally complicated way of doing simple
| things. IMO, SSR will follow the same arc in history - a brief
| period of popularity, followed by a lot of "what on earth were we
| thinking". Client side rendering is much simpler and cleaner.
| trinovantes wrote:
| SSR is generally for SEO and performance
___________________________________________________________________
(page generated 2022-04-19 23:00 UTC)