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
The absurd complexity of server-side rendering
161–170 of 395 posts
Re: The absurd complexity of server-side rendering
#162https://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.
Re: The absurd complexity of server-side rendering
#163Shameless 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...
Will need to give this a try, thanks for sharing (and building it)!
Re: The absurd complexity of server-side rendering
#164SSR is the dumbest thing I’ve ever heard of. Client and server are different things, treat them that way. The whole web dev community keeps tripping all over itself to make simple things wildly complicated.
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 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
#166You're all clueless.
Re: The absurd complexity of server-side rendering
#167The 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
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
#168Shameless 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)!
Reach out if you have any questions! Email is on my GitHub profile.
Re: The absurd complexity of server-side rendering
#169There 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.
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
#170Earlier 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.…