Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

Post reply on HN
Print view View original

31–40 of 395 posts

Re: The absurd complexity of server-side rendering

#31

Post by kingcharles »

atoav wrote: post #3
Daishiman wrote: post #2

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, fast…

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 lin…

And even CSS resets are getting close to zero these days.

Re: The absurd complexity of server-side rendering

#32

Post by eurasiantiger »

gmfawcett wrote: post #13
pphysch wrote: post #7

Earlier quoted context omitted.

And usually leads to a BBOM architecture

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.

This was my PHP experience with CodeIgniter 15 years ago. Nothing new under the sun.

Re: The absurd complexity of server-side rendering

#34

Post by qpiox »

yen223 wrote: post #27
robertoandred wrote: post #12

Earlier quoted context omitted.

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

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

I am a proponent of server-side, use Apache Tapestry for most production apps and have only one yaml file in all the projects.

Re: The absurd complexity of server-side rendering

#35

Post by 65 »

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.

Re: The absurd complexity of server-side rendering

#37

Post by giantrobot »

pphysch wrote: post #17
jvanderbot wrote: post #14

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?

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.

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

Re: The absurd complexity of server-side rendering

#38

Post by codedokode »

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.

Re: The absurd complexity of server-side rendering

#39

Post by paxys »

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.

Re: The absurd complexity of server-side rendering

#40

Post by codedokode »

pphysch wrote: post #7
donatj wrote: post #5

Call me old fashioned, but PHP still gets the job done better than just about anything else.

And usually leads to a BBOM architecture

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.
Post reply on HN