Call me old fashioned, but PHP still gets the job done better than just about anything else.
And usually leads to a BBOM architecture
Because what we're witnessing in JS-land these days is completely sane and rational.
The absurd complexity of server-side rendering
101–110 of 395 posts
Re: The absurd complexity of server-side rendering
#102I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things
because scraping and indexing the site is hard.
because getting first response on super slow speeds doesn't accomplish anything
because many js devs write buggy code that renders in their browser
etc
Re: The absurd complexity of server-side rendering
#103Re: The absurd complexity of server-side rendering
#104I 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.
This is a gross mischaracterization of what's happening.
People want to build interactive pages and products with neat little shiny user-friendly doodads. JavaScript provides that ability. SSR allows you to write JavaScript that will be rendered before the user ever sees it so all that effort that went into making browsers really good at rendering HTML can work for your interactive applialcation too.
I have to assume anyone who doesn't understand the goals or says some nonsense about it being about "advertisers" has spent little to no time in this space.
Re: The absurd complexity of server-side rendering
#105Earlier quoted context omitted.
The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…
You sound like me, but ten years ago. :) I used to have a similarly negative and narrow-minded perspective about PHP, but my colleagues and their outstanding work have enlightened me.
I am entirely unfond of PHP as a language but Laravel - and competently written apps that use it - are damn impressive nonetheless.
Re: The absurd complexity of server-side rendering
#106In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
Confusion is by whoever wrote the headline. Server side render is easy. Isomorphic is hard.
Re: The absurd complexity of server-side rendering
#107This 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.
SSR in terms of webdev means what this post describes: generating HTML on the server. “Rendering” is a bit of a misnomer; a more apt title would be “server side HTML generation”, but that’s a bit long. The alternative to SSR is CSR (client side rendering). Think React SPAs.
I know, I know, the webcrap crowd uses that terminology. Nobody else does.
As someone who spends most of their time right now inside of 3D game-type renderers, I have a hard time thinking of cranking out HTML as "rendering".
What does that crowd call the part of the browser that does layout and display?
Re: The absurd complexity of server-side rendering
#108Earlier quoted context omitted.
The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…
You sound like me, but ten years ago. :) I used to have a similarly negative and narrow-minded perspective about PHP, but my colleagues and their outstanding work have enlightened me.
PHP itself is perfectly designed to run CGI scripts and the correct architecture for web performance (shared-nothing). It's the third party developers that have second-system effect enterprise dreams.
Though maybe some of them have found simplicity again.
Re: The absurd complexity of server-side rendering
#109In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
Its a bit leaky, but I wouldn't call it crappy. What's crappy about it? Be specific.
Re: The absurd complexity of server-side rendering
#110I 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'm always impressed by the labyrinthine towers of JS and frameworks people create to ship out relatively simple sites and web apps. By impressed, I mean that I look upon them both in awe and in horror. And I'm guilty of building them myself, as well. One of the worst things is opening such a project that was written 5+ years ago by someone other than yourself.
>I'm always impressed by the labyrinthine towers of JS and frameworks people create to ship out relatively simple sites and web apps. By impressed, I mean that I look upon them both in awe and in horror.
Well, then... brace yourself for the one[1] I intend to release in a month or so. I've been working on/off it for the last three years.[2]
I'm hoping next month to actually build an application with it :-/
[1] A component library for client-side elements.
[2] Spent about 8 hours in total on it, over three years[3]. Sometimes I need a deadline to finish stuff. Don't judge me, no one's perfect :-)
[3] Still think it took fewer hours than learning React.