Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

161–170 of 395 posts

Re: The absurd complexity of server-side rendering

#161

Earlier quoted context omitted.

> Read the docs introduction for a more in-depth... introduction. Heh. This reminded me of http://itre.cis.upenn.edu/~myl/languagelog/archives/000012.h... . "PERSONNEL WHO ARE NOT AUTHORIZED TO BE IN THE HANGAR ARE NOT AUTHORIZED TO BE IN THE HANGAR"

sign seen in Seattle on a housing project in the 90s: ALL ILLEGAL ACTIVITIES ARE PROHIBITED

That one's not redundant; it says that illegal activities (in addition to violating the law) also violate the rules of the housing project. That kind of thing is bog-standard in all kinds of contracts, because including a clause like that makes your illegal activity grounds for terminating the contract. (In this case, the prohibition on illegal activities presumably allows the project to evict tenants who are convicted of crimes.)

Re: The absurd complexity of server-side rendering

#162
post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

What's the difference between this and AlpineJS?

Re: The absurd complexity of server-side rendering

#163

Shameless plug: If you want seamless SSR with Django logic, but React templates, check out my project at https://www.reactivated.io . It's like HTMX but uses React, and the JS bits are rendered on the server. You can then hydrate on the client. The Reactivated docs site itself uses the project: https://github.com/silviogutierrez/reactivated/tree/main/web...

Setting up something like this myself has always been a pain and I’ve just stuck with DRF + React instead.

Will need to give this a try, thanks for sharing (and building it)!

Re: The absurd complexity of server-side rendering

#165

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both.

I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based UI development it is hard to go back. Especially when you get used to the high quality UI libraries.

Re: The absurd complexity of server-side rendering

#167

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

I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong.

Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now.

Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy.

OS? Ubuntu, or Debian. They'll do well. Again, you need to have really, really good reasons to use anything else.

Of course there's alternatives! But there is absolutely no reason to move away from this stack. For some reason frontend developers seem to be either on a constant treadmill of moving technologies, or being stuck with subpar old tech with clear deficiencies.

Re: The absurd complexity of server-side rendering

#168

Shameless plug: If you want seamless SSR with Django logic, but React templates, check out my project at https://www.reactivated.io . It's like HTMX but uses React, and the JS bits are rendered on the server. You can then hydrate on the client. The Reactivated docs site itself uses the project: https://github.com/silviogutierrez/reactivated/tree/main/web...

Setting up something like this myself has always been a pain and I’ve just stuck with DRF + React instead. Will need to give this a try, thanks for sharing (and building it)!

Yea using Django only for DRF APIs always felt limited. I want Django forms and form sets.

Reach out if you have any questions! Email is on my GitHub profile.

Re: The absurd complexity of server-side rendering

#169
post #73

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

> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.

I've tried this twice and it didn't work out for me.

If you want even just some features like categories and tags you end up with a tool that has some weird metadata language you put over the actual text, the markup obviously is yet another slightly different kind of markdown, and then learn the umpteenth way of linking to internal sites. Then you run the generator, triple check everything is not messed up because of a misplaced space in the meta data and then upload everything to your server.

Compare this to a simple wysiwyg editor in the browser where you hit save. I've made my choice.

Re: The absurd complexity of server-side rendering

#170

Earlier quoted context omitted.

Blazor Server and other HTML over the wire frameworks (Livewire, Hotwire, HTMX, etc.) are the new sweet spot for a lot of LoB web applications I think.

The amount of leverage you can get out of these paths is pretty incredible. The fundamental idea is really simple too if you boil it down to the absolute minimum essence... The following 6 lines of javascript is all it takes to connect a hot pipe from server to client and dynamically invoke whatever is required. function StartApplication() { document.ApplicationSocket = new WebSocket(...); document.ApplicationSocket.…

I can't believe it took people 12 years since the publication of the WebSocket standard to figure this stuff out. Is everyone just running in circles?
Post reply on HN