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

21–30 of 395 posts

Re: The absurd complexity of server-side rendering

#21

Post by jamal-kumar »

kraig911 wrote: post #19

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.

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

Re: The absurd complexity of server-side rendering

#22

Post by icedchai »

yoyohello13 wrote: post #6
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…

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.

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

Re: The absurd complexity of server-side rendering

#23

Post by stevebmark »

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.

Re: The absurd complexity of server-side rendering

#24

Post by epolanski »

stevebmark wrote: post #23

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 (i…

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.

Re: The absurd complexity of server-side rendering

#25

Post by epolanski »

marcosdumay wrote: post #9

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.

What does any of the gist has to do with monads.

Re: The absurd complexity of server-side rendering

#26

Post by Animats »

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.

Re: The absurd complexity of server-side rendering

#27

Post by yen223 »

robertoandred wrote: post #12
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 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

Re: The absurd complexity of server-side rendering

#28

Post by trinovantes »

stickfigure wrote: post #20

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.

SSR is generally for SEO and performance

Re: The absurd complexity of server-side rendering

#29

Post by boloust »

epolanski wrote: post #25
marcosdumay wrote: post #9

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.

What does any of the gist has to do with monads.

Principled, explicit handling of various function colours.

If implemented like Fantasyland, probably a terrible idea.

Re: The absurd complexity of server-side rendering

#30

Post by kodah »

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