Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state management with MobX. To top it off you can write performant backend API's in Node.js with again TypeScript sharing contracts (Interfaces) between backend and frontend. I for one am really happy with the current state of affairs.
The absurd complexity of server-side rendering
271–280 of 395 posts
Re: The absurd complexity of server-side rendering
#272foreach($seo_urls as $path){
$hash = sha256($path);
exec('wget http://mywebsite.com/$path -o $project_root/seo/pages/$hash');
}
-----
if($agent_type == 'search_engine_bot'){ $path = $request->path; if(in_array($path, $seo_urls)){ $hash = sha256($path); echo file_get_contents($project_root/seo/pages/$hash); exit; } }
----
Would this work?
Edit: well i guess not.. because wget cant render javascript.. so.. maybe with a headless browser?
Re: The absurd complexity of server-side rendering
#273I figured this out several years ago when I tried to build a full-stack framework to seamlessly connect the front end and back end into a single development experience (kind of like what Meteor and Next.js turned out to be). I ended up cancelling that project, pulled out the RPC + pub/sub internals and spun it off into a separate set of libraries which became successful on their own.
I've been saying this for years. Although code reuse is possible between server and browser and sometimes it saves a lot of time, it's not common enough to be a default (as part of a monolithic framework) and there are security implications which make it highly desirable to differentiate between the two.
I do think frameworks are overused. IMO, frameworks make more sense in DevOps for infrastructure orchestration to provide resilience and scalability. For example, I think Kubernetes makes sense as a framework - Critiques of its complexity are not related to its frameworkness; there is literally no other way to do orchestration - Orchestration is the top layer which runs everything and sits above everything (including hosts and processes). Frameworks don't make much sense in development space IMO; they're mostly a way for companies to achieve lock-in.
Even on the front end, Google Polymer had already proved through their WebComponents polyfills that frameworks were not necessary to achieve reactivity on the front end. A simple, lightweight library is usually enough.
Re: The absurd complexity of server-side rendering
#274I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could bene…
This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever.
I wish there were more stacks like Clojure/Script.
While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know what the closest thing to this is these days?
Re: The absurd complexity of server-side rendering
#275I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so…
> I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets.
If you want to remove the hell from your life, you need to be all in on one or the other.
A full rendered web page is the server state displayed on the client. Except of removing all dynamic in page interaction, you are ALWAYS in risk for de-synched state between client and server. There is no single side state, as long as someone sees your server sate.
Re: The absurd complexity of server-side rendering
#276https://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.
I find writing isolated unit tests tough when using htmx over the wire frameworks like HTMX and HotWire. The options are to mock the server and test the page, which is not exactly unit test.
So I am curious is there an easy way to write unit tests for htmx bits of the page?
Re: The absurd complexity of server-side rendering
#277Ah, someone who has discovered that writing in tiny paragraphs makes for addictive reading even if the substance is minimal.
Re: The absurd complexity of server-side rendering
#278https://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?
They solve different problems.
Alpine is about defining in-browser behaviours in a nice, simple, declarative way.
HTMX is about defining data loading and brower-server interactions in a nice, simple, declarative way.
The author of HTMX have often suggested using HTMX and Alpine together for this very reason, they work very well together.
Re: The absurd complexity of server-side rendering
#279I make a difference between website and webapp.
a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article)
a webapp has the main goal of managing and reacting to a complex, non trivial user state.
website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on the frontend.
webapp, go client side all in, screw server side rendering.
yes, you can marry website and webapp via server side rendering / hydration. but the cost to make this really really fast and spiralling complexity and edge cases, does not make it worth it.
choose the right tool for the job, and just because it has web** in its name, does not make it automatically a job for react/angularjs/newest-coolest-framework
Re: The absurd complexity of server-side rendering
#280Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time. It think this is bad assumption to begin with. If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is on…
Being used server side JS since before NodeJS came along on JVM. I would say your assessment is correct (input validation) around that time. However React, Vue, Preact, Svelt, SolidJS (not to mention web components) changed that. We now have a group of people ONLY associated html rendering with those type of frameworks and components. So HTML rendering on the server side is pivoted to cater to those type of front end developer with 'Hydration'. The EJS templating type of rendering has being phased out. It is not good or bad, it is catering to what developers are use to.